I have no such need for an x5c outside of a JWK. Hence my suggestion for a JWK specifically for wrapping PKIX. In fact, I personally have a strong preference for removing anything key-related from the base headers that isn't "jwk" or "kid" (or now possibly "spi").
I'd much rather see this in the JWK spec; I only suggested a new draft to help frame such a discussion. - m&m Matt Miller < [email protected] > Cisco Systems, Inc. On Feb 8, 2013, at 3:54 PM, John Bradley <[email protected]> wrote: > I think Matt has need of the x5c outside of the JWK. > > Though if you could represent a link to a x5u and a x5c object in a JWK then > I guess you might be able to remove them from the base spec. > > I think that is probably part of the discussion we need to have. > > John B. > > On 2013-02-08, at 3:48 PM, Richard Barnes <[email protected]> wrote: > >> Wouldn't it be simpler just to push the x5u and x5c attributes over to JWK, >> and leave them out of the base object altogether? >> >> That actually seems a lot more sensible to me than the current design. And >> it wouldn't require writing another draft! >> >> >> On Fri, Feb 8, 2013 at 1:47 PM, Matt Miller (mamille2) <[email protected]> >> wrote: >> After some off-list discussions, a couple of us believe it would be >> worthwhile to somehow wrap a PKIX certificate chain in a JSON Web Key. A >> couple of us are leaning toward a new JWK type to do this. One impact, I >> think, is that anywhere we currently have "x5c" (and potentially "x5t" and >> "x5u") are effectively replaced by an actual JWK object. However, a few of >> us have other use cases where a PKIX certificate JWK would solve some >> problems. >> >> Unless there's strong objection, Brian Campbell and I are likely to start >> work on a new I-D that documents our musings. >> >> >> Thoughts? >> >> - m&m >> >> Matt Miller < [email protected] > >> Cisco Systems, Inc. >> >> On Jan 31, 2013, at 3:15 PM, Matt Miller (mamille2) <[email protected]> >> wrote: >> >>> I could also see it like the following: >>> >>> { >>> "kty":"RSA", >>> "kid":"[email protected]", >>> "n":".....", >>> "e":"AQAB", >>> "x5u":"https://capulet.lit/juliet.crt"; >>> // and/or "x5c":[....] >>> } >>> >>> Having a "X509" JWK type might solve one problem I can see having in >>> XMPP-E2E, but it that same problem could be solved with the above. >>> >>> Then again, I could be completely off in the weeds. >>> >>> >>> - m&m >>> >>> Matt Miller < [email protected] > >>> Cisco Systems, Inc. >>> >>> On Jan 31, 2013, at 2:45 PM, Brian Campbell <[email protected]> >>> wrote: >>> >>>> John and Mike beat me to it but yeah, the general idea of some kind of X509 >>>> support in JWK has now independently come up in my world twice in as many >>>> days. >>>> >>>> I must say that, from a general design of things perspective, it seems like >>>> a total abomination. But maybe, just maybe, it'd be useful enough to >>>> overcome such pity objections? >>>> >>>> Though, to be fair, Matt's idea is pretty different than what John has in >>>> mind. Getting to some level of agreement would likely be more than just a >>>> formality. >>>> >>>> >>>> On Thu, Jan 31, 2013 at 9:54 AM, John Bradley <[email protected]> wrote: >>>> >>>>> 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 >> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
