Re: [jose] issues with x5c in JWE

[Brian Campbell <[e-mail]>]

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 <[e-mail]> 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)" <[e-mail]>
> wrote:
>
> >
> > On Jan 31, 2013, at 9:20 AM, Brian Campbell <[e-mail]>
> 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 < [e-mail] >
> > Cisco Systems, Inc.
> >
> >> On Tue, Jan 29, 2013 at 8:04 PM, John Bradley <[e-mail]>
> 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 <[e-mail]
> >
> >>> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/jose
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> jose mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/jose
> >
>
>