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

"Matt Miller (mamille2)" <mamille2@cisco.com> Fri, 08 February 2013 23:03 UTC

Return-Path: <mamille2@cisco.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 4101521F8C1E for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 15:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 veN7TX0MyLI7 for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 15:03:40 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 837FD21F8A4F for <jose@ietf.org>; Fri, 8 Feb 2013 15:03:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12653; q=dns/txt; s=iport; t=1360364618; x=1361574218; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rt7n2Aq9hj2QIeJSAozWX879RDP5O3DRnl5wQcZ68nM=; b=aHJC61X0bpKOOz9x/lRd5FwTEZOa+mXSrIUi2dTv2s0Ml2c9hEmCsK05 gBf4ZwFNW6j0Krd8KMgAxrCZIezMQN949dB5wSPVhRqK5Tv/5Fa2/5//n z/AHSRTjCqQTRiKT7KyU0h/o3NZVftPc3qt0zxI+xsZApnH/aQdL3hm8T 8=;
X-Files: smime.p7s : 2283
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFADCDFVGtJV2Z/2dsb2JhbAA7CsENFnOCHwEBAQMBAQEBawsFCwIBCA4KCiQCJQslAgQOBQgBBYd9Bgy/MI0aCoNXYQOPFYElgiiEX482gwCBaAcXBhg
X-IronPort-AV: E=Sophos; i="4.84,632,1355097600"; d="p7s'?scan'208"; a="175106123"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 08 Feb 2013 23:03:36 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r18N3ZBw012424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Feb 2013 23:03:36 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.98]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 17:03:35 -0600
From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Thread-Topic: [jose] Adding a X509/PKIX JWK type? [WAS: issues with x5c in JWE]
Thread-Index: AQHOBizJwxS0jVSG1US2RD28XLRIZ5hw9RiAgAABmQCAAAKUAA==
Date: Fri, 8 Feb 2013 23:03:34 +0000
Message-ID: <BF7E36B9C495A6468E8EC573603ED9411511F238@xmb-aln-x11.cisco.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> <CAL02cgS8Bc2Sosba41w_D_V8txE-Jb8ZOz2Dhs33GCQWLSwvFQ@mail.gmail.com> <9DFAD552-38E8-4E80-B49E-29A6597DD6C0@ve7jtb.com>
In-Reply-To: <9DFAD552-38E8-4E80-B49E-29A6597DD6C0@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.129.24.55]
Content-Type: multipart/signed; boundary="Apple-Mail=_D8B777F3-1F6C-4DFF-BA8D-BE4637574968"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: Richard Barnes <rlb@ipv.sx>, Brian Campbell <bcampbell@pingidentity.com>, "jose@ietf.org" <jose@ietf.org>
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 23:03:41 -0000

I have no such need for an x5c outside of a JWK. Hence my suggestion for a JWK specifically for wrapping PKIX.  In fact, I personally have a strong preference for removing anything key-related from the base headers that isn't "jwk" or "kid" (or now possibly "spi").

I'd much rather see this in the JWK spec; I only suggested a new draft to help frame such a discussion.


- m&m

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

On Feb 8, 2013, at 3:54 PM, John Bradley <ve7jtb@ve7jtb.com>
 wrote:

> I think Matt has need of the x5c outside of the JWK.
> 
> Though if you could represent a link to a x5u and a x5c object in a JWK then I guess you might be able to remove them from the base spec.
> 
> I think that is probably part of the discussion we need to have.
> 
> John B.
> 
> On 2013-02-08, at 3:48 PM, Richard Barnes <rlb@ipv.sx> wrote:
> 
>> Wouldn't it be simpler just to push the x5u and x5c attributes over to JWK, and leave them out of the base object altogether?  
>> 
>> That actually seems a lot more sensible to me than the current design.  And it wouldn't require writing another draft!
>> 
>> 
>> On Fri, Feb 8, 2013 at 1:47 PM, 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
>> 
>> 
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>