JSON Public Key Spec Results at IIW on Thursday

The final session at IIW related to JSON Web Tokens (JWTs) explored whether and how to represent public key information as JWTs or other JSON structures as an alternative to X.509 certificates. Thanks to Breno de Medeiros for taking notes, which I’ve pasted in below:

Issue/Topic: Public Key Certificates as JWT
Session: Thursday 1E
Convener: Mike Jones, Microsoft
Notes-taker(s): Breno de Medeiros
Tags: If and how to represent public key certificates as JSON Web Tokens
Discussion notes:

• Certificate installation a difficult and core technical obstacle in configuring security
• Not all cases require PKI validation; motivation examples given by J. Panzer et. al., drove the proposal for the Magic Signatures specs
• In the absence of PKI certificates, it’s not possible to ‘preserve’ the security context around fetching the certificate
• Is there a need to invent another type of JSON-based certificate? Do we have a need for certificates in addition to bare keys?
• Why re-invent X.509? Create a JSON binding for the subset of KeyInfo from X.509 that is needed to advertise keys
• After reviewing the KeyInfo, decided that the part of it of interest is trivially small and already described in competing proposals
• Even a JWT is too complex, only need to create a simple descriptor for the key in JSON
• Key_id needed

Decision: Go with simple approach

• Keep this mini-spec separate from JWT and cross-reference? Or include this in the expanded spec of JWT to include encryption?

Decision: Keep specs separate

• Need to allow this to have a URL-safe representation such as compact JWT?

Examples of what these representations might look like are as follows:

{"keyvalues":
  [
    {"alg":"ECDSA",
     "x":"MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
     "y":"4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM",
     "keyid":"1"},

    {"alg":"RSA",
     "modulus": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMstn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
     "exponent":"AQAB",
     "keyid":"2"}
  ]
}

Near the end of the discussion, it was pointed out that want we are proposing is much closer to the XMLDSIG KeyValue element than the KeyInfo element.

The participants recognize that the security of these raw keys is dependent upon the security of the mechanisms for distributing them — in most cases TLS.

References:

• XML Signature Syntax and Processing (Second Edition): http://www.w3.org/TR/xmldsig-core/
• Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures: http://tools.ietf.org/html/rfc4050
• Additional XML Security Uniform Resource Identifiers (URIs): http://tools.ietf.org/html/rfc4051
• Magic Signatures: http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-experimental-00.html