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#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 protected]
>> https://www.ietf.org/mailman/listinfo/jose
>>
>>
>>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
