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 >>> >> >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
