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
