Inline. On Mon, Oct 14, 2013 at 10:09 AM, Manger, James H < [email protected]> wrote:
> > I was thinking today about how it would be nice to replace PKCS#12 with > > something JWK-based. For background, PKCS#12 is a format that can > > store a certificate (unencrypted) alongside an encrypted private key. > > I agree. A JWK-based alternative for PKCS#12 for Java keystores should be > possible. > > > It seems to me like the obvious thing would be to replace this with a > > JWK Set containing two keys: (1) a public key with the certificate in > > the "x5t" attribute, and (2) the corresponding private key as an > > Encrypted JWK. > > I'm not so sure about that design. > It means a public/private key pair are 2 key entries, whereas currently > they are 1. > > It means an Encrypted JWK and a plain key entry can both appear in the > same slot (entries in the "keys" array) so they need to be distinguished. I > guess by "Encrypted JWK" you mean the JOSE serialization of a JWE whose > content is a JWK. Will you look for a "kty" field? Looking at an "alg" > field is unlikely to work. > Yes, that's what I meant by Encrypted JWK. (In the sense of: http://tools.ietf.org/html/draft-ietf-jose-json-web-key-17#section-6) The main thing here is that the parser needs a way to correlate the public and private keys. You could use "kid" for this, but matching on "kty" and the public key fields ("n", "e"; "x", "y") would be more reliable. > PKCS#12 (and Java keystores) can store a certificate in the clear, but it > is still integrity-protected by a MAC keyed with a password. Mixing plain > JWKs and Encrypted JWKs does not give the same security properties. > That's true, but it's not really clear to me what the benefit is of integrity-protecting the cert or the (cert, private key) pair. The certificate has its own integrity protection (obviously), and it's not like someone can fake the public/private binding. And if you still wanted this, you could wrap the whole thing in a JWS using a PBMAC. But that would be key management for MAC, which is Something The WG Has Decided Not To Do. > Another option could be to put an JWE as a field in a JWK. Or to expect > people to protect all the private keys and associated public keys together > in a single JWE (Encrypted JWK) when any part needs protection. It means > you cannot get the public key without the password. Does that kill the > required functionality, or is that ok in 99% of cases? I don't know, off the top of my head. You certainly *could* use a single Encrypted JWK, just like you can make everything encrypted in a PKCS#12 object. But it appears to me to be far more common to not encrypt the cert. --Richard > > However, it's not immediately clear to me that the JWK Set format in - > > 17 allows this. Proposed edit to clarify: > > > > OLD: "The value of the "keys" member is an array of JWK values" > > NEW: "The value of the "keys" member is an array of JWK and/or > > Encrypted JWK values" > > > > Thoughts? > > -- > James Manger >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
