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<http://iiw.idcommons.net/JSON_Spec_Work_continued>, 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 Jason 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
-- Mike
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
