Brian and I were discussing a couple of options off the list. One possible thing might be to add x5c and/or x5u elements to jwk.
In Connect we are looking at how to deal with key rollover for signing. The problem with specifying a x5u is that while it is a vert chain it is a single cert chain, so you need to have multiple and there is no easy way to have the same keyid for a jwk key and a x5u key. My idea was to allow x5u elements in a jwk so that you can have a single keyid and key use that apples to both formats. I can see a use for x5c in jwk as well especially where it is being sent in band. So while it may sound crazy a number of us may be thinking the same thing. John B. On 2013-01-31, at 1:42 PM, "Matt Miller (mamille2)" <[email protected]> wrote: > > On Jan 31, 2013, at 9:20 AM, Brian Campbell <[email protected]> > wrote: > >> Seems to me that something like x5c would be a lot more meaningful and >> useful for a possible future ECDH-SS algorithm for JWE. But it would be >> about the encrypting party or sender's certs in that case, right? Which >> would be different than how it's currently being used. And that might be >> another argument for not having it in JWE right now. >> >> Of course that starts to beg the "must understand headers" question but I >> digress... > > I was starting to come to similar conclusions. > > This probably sounds crazy, but maybe we can pretend x.509 certs can be > wrapped into a JSON Web Key? > > { > "kty":"X509", > "x5c": [....] > } > > > - m&m > > Matt Miller < [email protected] > > Cisco Systems, Inc. > >> On Tue, Jan 29, 2013 at 8:04 PM, John Bradley <[email protected]> wrote: >> >>> Yes for encryption (Leaving ECDH-SS aside ) the recipoient decrypts with a >>> secret. I would expect a kid in the header. >>> >>> I suppose they if the recipient published a x5c that the sender used to >>> encrypt with then you could include the x5c as a reference though a >>> thumbprint would be simpler as the recipient is probably keeping its >>> private keys in a key-store of some sort. >>> >>> In any event we would minimally want to change that to >>> >>> "The certificate containing the public key of the entity that is to >>> decrypt the JWE MUST be the first certificate." >>> >>> >>> Thanks Brian >>> >>> John B. >>> >>> >>> On 2013-01-29, at 11:08 PM, Brian Campbell <[email protected]> >>> wrote: >>> >>> I just noticed a couple of things in the JWE's x5c definition that struck >>> me as maybe not right. >>> >>> From >>> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-4.1.9 >>> >>> "The certificate containing the public key of the entity that encrypted >>> the JWE MUST be the first certificate." - but it's not the public key of >>> the entity that encrypted, is it? It's the public key of the entity that >>> will decrypt. The other entity. >>> >>> "The recipient MUST verify the certificate chain according to [RFC5280] >>> and reject the JWE if any validation failure occurs." - maybe I'm missing >>> something but why would the recipient verify it's own certificate chain? >>> >>> And the first hyperlink in "See Appendix >>> B<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-B>of >>> [ >>> JWS<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#ref-JWS>] >>> for an example "x5c" value" takes you to Appendix B of JWE, which is >>> Acknowledgements, rather than JWS as the text would suggest. >>> >>> So all those little nits could be fixed. But maybe it'd be better to just >>> remove x5c from JWE all together? As Richard pointed out previously, >>> http://www.ietf.org/mail-archive/web/jose/current/msg01434.html, there's >>> really no point in sending a whole chain to help the recipient identify its >>> own key. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
