[jose] Adding a X509/PKIX JWK type? [WAS: issues with x5c in JWE]
"Matt Miller (mamille2)" <mamille2@cisco.com> Fri, 08 February 2013 18:47 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 573BD21F8A4A for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 10:47:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.474
X-Spam-Level:
X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 Ipw1ouL7fo2F for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 10:47:52 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1B821F8976 for <jose@ietf.org>; Fri, 8 Feb 2013 10:47:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10633; q=dns/txt; s=iport; t=1360349268; x=1361558868; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OWwkZM3xz6TPIz19WIhfDidaD+AEiPsFgUusuZOrmKY=; b=FMLMtlAM785u7dCDnJuq1OAPODlLCZ+KZvBMeyyjRoWep+zUlYOxYqne EZxEcZ+LfhELtW0Iy3zwBdKVvAJr0rkcotMOCm1i/qGGJ73gaN97DbX1e 5tn6gbmi5Q+3Cby8dRy67D829nXI5R7kNkDxSN2+z1ydu9JQtIO/F2G1f E=;
X-Files: smime.p7s : 2283
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAOtGFVGtJXHB/2dsb2JhbAA7CsELFnOCHwEBAQMBAQEBawsFCwIBIAokAiULJQIEDgUIAQWHfQYMvnGNGgqDV2EDjxWBJYIohF+PNoMAgWgHFwYY
X-IronPort-AV: E=Sophos; i="4.84,630,1355097600"; d="p7s'?scan'208"; a="174808124"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 08 Feb 2013 18:47:48 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r18Ill4a026729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Feb 2013 18:47:47 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.98]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 12:47:47 -0600
From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: "jose@ietf.org" <jose@ietf.org>
Thread-Topic: Adding a X509/PKIX JWK type? [WAS: issues with x5c in JWE]
Thread-Index: AQHOBizJwxS0jVSG1US2RD28XLRIZw==
Date: Fri, 08 Feb 2013 18:47:46 +0000
Message-ID: <BF7E36B9C495A6468E8EC573603ED9411511DB49@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>
In-Reply-To: <BF7E36B9C495A6468E8EC573603ED9411510A1F3@xmb-aln-x11.cisco.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=_87BB5D5A-4043-4108-9B88-C00B1D68CC37"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: Brian Campbell <bcampbell@pingidentity.com>
Subject: [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 18:47:54 -0000
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] issues with x5c in JWE Brian Campbell
- Re: [jose] issues with x5c in JWE John Bradley
- Re: [jose] issues with x5c in JWE Brian Campbell
- Re: [jose] issues with x5c in JWE Matt Miller (mamille2)
- Re: [jose] issues with x5c in JWE Mike Jones
- Re: [jose] issues with x5c in JWE John Bradley
- Re: [jose] issues with x5c in JWE Brian Campbell
- Re: [jose] issues with x5c in JWE Matt Miller (mamille2)
- [jose] Adding a X509/PKIX JWK type? [WAS: issues … Matt Miller (mamille2)
- Re: [jose] Adding a X509/PKIX JWK type? [WAS: iss… John Bradley
- Re: [jose] Adding a X509/PKIX JWK type? [WAS: iss… Brian Campbell
- Re: [jose] Adding a X509/PKIX JWK type? [WAS: iss… Salvatore D'Agostino
- Re: [jose] Adding a X509/PKIX JWK type? [WAS: iss… Peter Saint-Andre
- Re: [jose] Adding a X509/PKIX JWK type? [WAS: iss… Brian Campbell
- Re: [jose] Adding a X509/PKIX JWK type? [WAS: iss… Richard Barnes
- Re: [jose] Adding a X509/PKIX JWK type? [WAS: iss… John Bradley
- Re: [jose] Adding a X509/PKIX JWK type? [WAS: iss… Richard Barnes
- Re: [jose] Adding a X509/PKIX JWK type? [WAS: iss… Matt Miller (mamille2)
- Re: [jose] Adding a X509/PKIX JWK type? [WAS: iss… Brian Campbell