Re: [jose] Adding a X509/PKIX JWK type? [WAS: issues with x5c in JWE]

[Brian Campbell <[e-mail]>]

I also support it (though I guess that's kind of obvious huh?).


On Fri, Feb 8, 2013 at 11:56 AM, John Bradley <[e-mail]> wrote:

> I agree that being able to include a x5c or reference a x5u form a JWK
> allows for more consistency around key references and key use.
>
> I support developing an ID to discuss this.
>
> John B.
> On 2013-02-08, at 11:47 AM, "Matt Miller (mamille2)" <[e-mail]>
> 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 < [e-mail] >
> > Cisco Systems, Inc.
> >
> > On Jan 31, 2013, at 3:15 PM, Matt Miller (mamille2) <[e-mail]>
> wrote:
> >
> >> I could also see it like the following:
> >>
> >> {
> >> "kty":"RSA",
> >> "kid":"[e-mail]",
> >> "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 < [e-mail] >
> >> Cisco Systems, Inc.
> >>
> >> On Jan 31, 2013, at 2:45 PM, Brian Campbell <[e-mail]
> >
> >> 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 <[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
> >>>>>
> >>>>
> >>>>
> >>
> >> _______________________________________________
> >> jose mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/jose
> >
> > _______________________________________________
> > jose mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jose
>
>