Re: [jose] Adding a X509/PKIX JWK type? [WAS: issues with x5c in JWE]

"Salvatore D'Agostino" <sal@idmachines.com> Fri, 08 February 2013 20:10 UTC

Return-Path: <sal@idmachines.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2773421F883A for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 12:10:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osk0Rtn+OYLo for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 12:10:32 -0800 (PST)
Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id A337121F8B62 for <jose@ietf.org>; Fri, 8 Feb 2013 12:10:32 -0800 (PST)
Received: from mailpod1.hostingplatform.com (mailpod1.networksolutionsemail.com [206.188.198.65]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r18KAUWO008834 for <jose@ietf.org>; Fri, 8 Feb 2013 15:10:30 -0500
Received: (qmail 19365 invoked by uid 0); 8 Feb 2013 20:10:29 -0000
Received: from unknown (HELO salPC) (sal@idmachines.com@71.174.33.134) by 0 with ESMTPA; 8 Feb 2013 20:10:29 -0000
From: "Salvatore D'Agostino" <sal@idmachines.com>
To: "'Brian Campbell'" <bcampbell@pingidentity.com>, "'John Bradley'" <ve7jtb@ve7jtb.com>
References: <CA+k3eCRbkefo3M+7QK_anM+H-VQLj2b+Jvw+8EXKPnSuc4Y_7Q@mail.gmail.com> <DAD9D0F9-1889-41B8-8F87-2FC689E9397B@ve7jtb.com> <CA+k3eCQqTpiTdDwdkqFNU9UApM8H4TjjkKq+XupSQuhLkbjRsg@mail.gmail.com> <BF7E36B9C495A6468E8EC573603ED94115109840@xmb-aln-x11.cisco.com> <0BC322C1-A6C5-46B8-BC2A-3A7E000952EF@ve7jtb.com> <CA+k3eCTi1Ss2grSALqZngtnCfv8ks0xRm_uXaeA7cdngua4_VQ@mail.gmail.com> <BF7E36B9C495A6468E8EC573603ED9411510A1F3@xmb-aln-x11.cisco.com> <BF7E36B9C495A6468E8EC573603ED9411511DB49@xmb-aln-x11.cisco.com> <89EBA4C7-2599-4230-9E1B-646E550DBFB8@ve7jtb.com> <CA+k3eCReyceVZAf=TSP26JM2JK0BpDOE1RkAkqBu3UWkVTbYRw@mail.gmail.com>
In-Reply-To: <CA+k3eCReyceVZAf=TSP26JM2JK0BpDOE1RkAkqBu3UWkVTbYRw@mail.gmail.com>
Date: Fri, 8 Feb 2013 15:10:27 -0500
Message-ID: <09b401ce0638$56f009b0$04d01d10$@com>
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac4GNJUba5vMzpbWSziLi2FmPTrsowAA7R+A
Content-Language: en-us
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_09AC_01CE060E.66251C60"
Cc: jose@ietf.org, "'Matt Miller \(mamille2\)'" <mamille2@cisco.com>
Subject: Re: [jose] Adding a X509/PKIX JWK type? [WAS: issues with x5c in JWE]
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Feb 2013 20:10:34 -0000

+1

 

From: Brian Campbell [mailto:bcampbell@pingidentity.com] 
Sent: Friday, February 08, 2013 2:44 PM
To: John Bradley
Cc: jose@ietf.org; Matt Miller (mamille2)
Subject: Re: [jose] Adding a X509/PKIX JWK type? [WAS: issues with x5c in
JWE]

 

I also support it (though I guess that's kind of obvious huh?).

 

On Fri, Feb 8, 2013 at 11:56 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I agree that being able to include a x5c or reference a x5u form a JWK
allows for more consistency around key references and key use.

I support developing an ID to discuss this.

John B.

On 2013-02-08, at 11:47 AM, "Matt Miller (mamille2)" <mamille2@cisco.com>
wrote:

> 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
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose