Subject: [jose] issues with x5c in JWE

From: Brian Campbell <[email-masked]>
Date: Tue, 29 Jan 2013 19:08:07 -0700

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.

---

From: John Bradley <[email-masked]>
Date: Wed, 30 Jan 2013 00:04:09 -0300

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 of [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

---

From: Brian Campbell <[email-masked]>
Date: Thu, 31 Jan 2013 09:20:27 -0700

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...

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.
>
> "The certificate containing the public key of the entity that is to
> decrypt the JWE MUST be the first certificate."
>
>
> Thanks Brian
>
> John B.
>
>
> "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
> And the first hyperlink in "See Appendix B<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#appendix-B>of [

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 31 Jan 2013 16:42:20 +0000

> Of course that starts to beg the "must understand headers" question but I

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.

---

From: Mike Jones <[email-masked]>
Date: Thu, 31 Jan 2013 16:51:17 +0000

I know that John had been thinking along the same lines...  It's not beautiful but it may be a practical solution.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt Miller (mamille2)
Sent: Thursday, January 31, 2013 8:42 AM
To: Brian Campbell
Cc: John Bradley; [email-masked]
Subject: Re: [jose] issues with x5c in JWE

On Jan 31, 2013, at 9:20 AM, Brian Campbell <[email-masked]> wrote:

> 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...

{
  "kty":"X509",
  "x5c": [....]
}

- m&m

>> 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.
>> 
>> On 2013-01-29, at 11:08 PM, Brian Campbell 
>> <[email-masked]>
>> wrote:
>> 
>> "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?
>> 
>> B<http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#a
>> ppendix-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.
>> 
>> 
>> 
>> 
>> 
>>

---

From: John Bradley <[email-masked]>
Date: Thu, 31 Jan 2013 13:54:33 -0300

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.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 31 Jan 2013 14:45:43 -0700

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:

> 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.
>
> with a
> >>> On 2013-01-29, at 11:08 PM, Brian Campbell <[email-masked]
> >
> >>> wrote:
> >>>
> >>> 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
> >]
> just
> there's

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 31 Jan 2013 22:15:40 +0000

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