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

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 8 Feb 2013 18:47:46 +0000

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-masked] >
Cisco Systems, Inc.

On Jan 31, 2013, at 3:15 PM, Matt Miller (mamille2) <[email-masked]> wrote:

> I could also see it like the following:
> 
> {
>  "kty":"RSA",
>  "kid":"[email-masked]",
>  "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-masked] >
> Cisco Systems, Inc.
> 
> On Jan 31, 2013, at 2:45 PM, Brian Campbell <[email-masked]>
> 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-masked]> 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-masked]>
>>> wrote:
>>> 
>>>> 
>>>> On Jan 31, 2013, at 9:20 AM, Brian Campbell <[email-masked]>
>>> 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-masked] >
>>>> Cisco Systems, Inc.
>>>> 
>>>>> On Tue, Jan 29, 2013 at 8:04 PM, John Bradley <[email-masked]>
>>> 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-masked]
>>>> 
>>>>>> 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-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>> 
>>> 
>>> 
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: John Bradley <[email-masked]>
Date: Fri, 8 Feb 2013 11:56:22 -0700

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.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Feb 2013 12:43:35 -0700

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

On Fri, Feb 8, 2013 at 11:56 AM, John Bradley <[email-masked]> 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.
>
> > 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
> >
> >> 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.
> >>
> >> On Jan 31, 2013, at 2:45 PM, Brian Campbell <[email-masked]
> >
> >> wrote:
> >>
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-B
> >of
> >>>> [
> >>>>>>> JWS<
> >>>>

---

From: "Salvatore D'Agostino" <[email-masked]>
Date: Fri, 8 Feb 2013 15:10:27 -0500

+1

From: Brian Campbell [mailto:[email-masked]] 
Sent: Friday, February 08, 2013 2:44 PM
To: John Bradley
Cc: [email-masked]; Matt Miller (mamille2)
Subject: Re: [jose] Adding a X509/PKIX JWK type? [WAS: issues with x5c in
JWE]

John B.

>
> Unless there's strong objection, Brian Campbell and I are likely to start
work on a new I-D that documents our musings.
>>>>>>> I just noticed a couple of things in the JWE's x5c definition that
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-4.
1.9

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 08 Feb 2013 13:15:47 -0700

On 2/8/13 11:47 AM, Matt Miller (mamille2) 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.

Sounds like a good idea.

Not that you need anyone's permission to work on a non-WG
Internet-Draft. :-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Feb 2013 15:45:47 -0700

But just a non-objection from Peter Saint-Andre is very valuable in its own
right ;)

On Fri, Feb 8, 2013 at 1:15 PM, Peter Saint-Andre <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRFVzzAAoJEOoGpJErxa2p4CkP/AyqSYm8ryd9kjq11AsPxdjn
> 4IYynE02urlTcq7gr+4dX7nS7BcggPX77BxqOD+/4FDDaqnXjeCHFZa4UO1PCdfC
> 6WOaDSy20lz7sanVcaKy3Rlng70xVJXzqmp3AvcuYTeLniZr9NzJvlFDv96XxCV6
> fl8UOWHDr8VEOHtcjaHaQdU7rwm8aszZzFp2oOtgnAvqC5TWfIVZHnz4YpTisieU
> 38ZOafXO+OH31dpa5xIkVC7bmWk3xNew+h7WHnoHfFdloS3/SFlqSoZVrQQ3V/Ed
> u4DzxPRHG0skbAN119IlKO6/nkYqtAIiRZ8Exq6SAc6NgBq4+D9g2BQ8yBKHttLW
> Vku/Wb6pc9WWO2GQ0Zjy7SsJC3BdxdozagyTsv8EOc85sZ5ZMC34gwYDHPyoG80S
> V/23qNQhjfKzuEsxjhVZ3q+XKZ+vjL79sMSpSwAKZ7trMdu/d7eH+KKM3jAoEbH8
> ejb2JkFeKmprkDCbBMqXeygWyVHLHO5RQFV0Zudn+rvkQZvM5agE+U7RouN+Gvw6
> 6QuCEfE7SRiAkigPdqU+mPR45HuhaF8V6EZ8lyrqULHhFiYnUb/6rFOIHt6O2OdN
> OGSmt6kLqH9JiaUG6erGC0KAhQP9obeEPlp5cKMZDlfYgkzbxVylVA1SKCmIC2IN
> caqrzbQrFupevrJC9qP8
> =3bg2
> -----END PGP SIGNATURE-----
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Feb 2013 17:48:37 -0500

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!

---

From: John Bradley <[email-masked]>
Date: Fri, 8 Feb 2013 15:54:20 -0700

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-masked]> 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-masked]> wrote:

---

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Feb 2013 18:02:37 -0500

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-masked]> wrote:

> 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.
>
> 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-masked]
> > wrote:
>

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 8 Feb 2013 23:03:34 +0000

I have no such need for an x5c outside of a JWK. Hence my suggestion for a JWK specifically for wrapping PKIX.  In fact, I personally have a strong preference for removing anything key-related from the base headers that isn't "jwk" or "kid" (or now possibly "spi").

I'd much rather see this in the JWK spec; I only suggested a new draft to help frame such a discussion.

- m&m

---

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Feb 2013 16:07:04 -0700

There are definitely a number of different ways to skin the X509/PKIX in
JWK cat. This I-D isn't necessarily intended to be the final solution but
hopefully a way to start the productive conversation.