Hm. I would be interested in what the use case would be for having x5u outside of a JWK. If you don't have a JWK, you don't have a public key, so why would you care about a cert?
On Fri, Feb 8, 2013 at 5: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 > > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
