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 protected] [mailto:[email protected]] On Behalf Of Matt
Miller (mamille2)
Sent: Thursday, January 31, 2013 8:42 AM
To: Brian Campbell
Cc: John Bradley; [email protected]
Subject: Re: [jose] issues with x5c in JWE
On Jan 31, 2013, at 9:20 AM, Brian Campbell <[email protected]> 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 protected] >
Cisco Systems, Inc.
> On Tue, Jan 29, 2013 at 8:04 PM, John Bradley <[email protected]> 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 protected]>
>> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
