Re: [jose] issues with x5c in JWE

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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Matt Miller (mamille2)
Sent: Thursday, January 31, 2013 8:42 AM
To: Brian Campbell
Cc: John Bradley; jose@ietf.org
Subject: Re: [jose] issues with x5c in JWE

On Jan 31, 2013, at 9:20 AM, Brian Campbell <bcampbell@pingidentity.com> 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 < mamille2@cisco.com >
Cisco Systems, Inc.

> On Tue, Jan 29, 2013 at 8:04 PM, John Bradley <ve7jtb@ve7jtb.com> 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 
>> <bcampbell@pingidentity.com>
>> 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#sec
>> tion-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#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.
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>> 
>> 
>> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose