Re: [jose] issues with x5c in JWE

["Matt Miller (mamille2)" <[e-mail]>]

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