After some off-list discussions, a couple of us believe it would be worthwhile to somehow wrap a PKIX certificate chain in a JSON Web Key.  A couple of us are leaning toward a new JWK type to do this.  One impact, I think, is that anywhere we currently have "x5c" (and potentially "x5t" and "x5u") are effectively replaced by an actual JWK object.  However, a few of us have other use cases where a PKIX certificate JWK would solve some problems.

Unless there's strong objection, Brian Campbell and I are likely to start work on a new I-D that documents our musings.


Thoughts?

- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

On Jan 31, 2013, at 3:15 PM, Matt Miller (mamille2) <mamille2@cisco.com> wrote:

> I could also see it like the following:
> 
> {
>  "kty":"RSA",
>  "kid":"juliet@capulet.lit",
>  "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
> 
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.
> 
> On Jan 31, 2013, at 2:45 PM, Brian Campbell <bcampbell@pingidentity.com>
> wrote:
> 
>> 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 <ve7jtb@ve7jtb.com> wrote:
>> 
>>> 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.
>>> 
>>> On 2013-01-31, at 1:42 PM, "Matt Miller (mamille2)" <mamille2@cisco.com>
>>> wrote:
>>> 
>>>> 
>>>> 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#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
>>>>>> jose@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> _______________________________________________
>>>>> 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