> 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. 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. 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? > 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
