Re: [jose] Adding a X509/PKIX JWK type? [WAS: issues with x5c in JWE]
John Bradley <ve7jtb@ve7jtb.com> Fri, 08 February 2013 18:56 UTC
Return-Path: <ve7jtb@ve7jtb.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 A714021F8B9B for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 10:56:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 42lpg22owPy3 for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 10:56:28 -0800 (PST)
Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id CE88421F8B13 for <jose@ietf.org>; Fri, 8 Feb 2013 10:56:28 -0800 (PST)
Received: by mail-pa0-f49.google.com with SMTP id kp6so2214685pab.8 for <jose@ietf.org>; Fri, 08 Feb 2013 10:56:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=Kwth9RyOJ/C9+aZXQ6TQYzI2cEtMYWONuaWGyU7hUcc=; b=NChOeMKlub9Fn6RIAleT6LGmUSlNC1dULeov/uBqc7X4YKbMTkVO545qU6AuPyFVUd GQSqyxjBtYDhvhaUz9AIFqbHlpa+33gtSfE9VYaMNdlW0cKZ7+iN5CQ6ATlv+3PUlaqm zX7jSN0H20q/caMCAXJUq2+b9q128fHrZ3/RkaS98WBYWVmHVMCZkbeXsrytqkP+Vuc+ EqyAN8h/q/0i/UfRy+QfC7m7JLZ53H9CdfuDtglOOubc0ofDGGtxbgXS10td4066sKu/ hX35XRfGmgLHnGv1hyoylPf6A4EzJhJoORJZAv0dp5b9lyZVf3ZqdFqjpNWdxjlUdYAh UcHg==
X-Received: by 10.66.83.8 with SMTP id m8mr19980464pay.40.1360349788046; Fri, 08 Feb 2013 10:56:28 -0800 (PST)
Received: from dhcp50-95-212-134.hil-phxpphs.phx.wayport.net (dhcp50-95-212-134.hil-phxpphs.phx.wayport.net. [50.95.212.134]) by mx.google.com with ESMTPS id y9sm56459010paw.1.2013.02.08.10.56.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 10:56:26 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_D209EB3C-2289-435D-B804-FC65C778ED75"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <BF7E36B9C495A6468E8EC573603ED9411511DB49@xmb-aln-x11.cisco.com>
Date: Fri, 08 Feb 2013 11:56:22 -0700
Message-Id: <89EBA4C7-2599-4230-9E1B-646E550DBFB8@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>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkXsEf0m1S1viWz1MV3xjOhhVwTBvRC4PqZa70q+244sCQbD+hejvWSfsNVBpAMygEgcOAz
Cc: 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 18:56:29 -0000
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
- [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