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

Brian Campbell <bcampbell@pingidentity.com> Fri, 08 February 2013 23:07 UTC

Return-Path: <bcampbell@pingidentity.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 01CF221F8479 for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 15:07:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.907
X-Spam-Level:
X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 dL3i7yYomUbD for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 15:07:39 -0800 (PST)
Received: from na3sys009aog137.obsmtp.com (na3sys009aog137.obsmtp.com [74.125.149.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4123621F8806 for <jose@ietf.org>; Fri, 8 Feb 2013 15:07:36 -0800 (PST)
Received: from mail-ie0-f199.google.com ([209.85.223.199]) (using TLSv1) by na3sys009aob137.postini.com ([74.125.148.12]) with SMTP ID DSNKURWFOKUCR0ziXdNFLbIuuTnY3YzGj777@postini.com; Fri, 08 Feb 2013 15:07:36 PST
Received: by mail-ie0-f199.google.com with SMTP id c13so18663901ieb.2 for <jose@ietf.org>; Fri, 08 Feb 2013 15:07:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=0b1HtyaCwJklyCEioW08DuJSfKY+p2eED+Cz2bxzyFE=; b=Qt+HI/ASK4PTzWOhdwdcG9oNB9ozLZjPfqi96zxgOVrheKNwq4Bx3eqzS1RWxcsnjY SiG9rU2dTmTGGyEATaTMT8OD5AgMFw0YYHptAAHnCPE0ZSfvtBG+pBc22MOfSSYkaGhZ /Y1sEwy7wRG0ah1GZxiDYRZ4LOzpwz9davLVk3CQRjuApVDHatB9M08cCd/gIunICyN4 keFin6+h+HuldPYc3FwZYxtIPmo3h+J24oH4Nbo60EgdRW9Vc/AJjjconLtoqn7OyepP oX5BdNqLBGhYbSzP1V0IzR+F6krDp7gChPjixkxbYa2OcVRKgKLR2S7H7UHEJzILStGq pF6Q==
X-Received: by 10.50.169.106 with SMTP id ad10mr5961286igc.88.1360364855788; Fri, 08 Feb 2013 15:07:35 -0800 (PST)
X-Received: by 10.50.169.106 with SMTP id ad10mr5961274igc.88.1360364855664; Fri, 08 Feb 2013 15:07:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.139.8 with HTTP; Fri, 8 Feb 2013 15:07:04 -0800 (PST)
In-Reply-To: <CAL02cgS8Bc2Sosba41w_D_V8txE-Jb8ZOz2Dhs33GCQWLSwvFQ@mail.gmail.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>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 8 Feb 2013 16:07:04 -0700
Message-ID: <CA+k3eCSj7PdA3jc4MpWWOQ9haXDN_YAvp13BN_XDLaZCBVMCcQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: multipart/alternative; boundary=e89a8f2346bbfca23d04d53e9f67
X-Gm-Message-State: ALoCoQkPi7GrR2N4wsKW8iFRRD/WQRMd5R3tgTENgNniYiLHEDqlQ6DI1RkhQ0R5fGtt1WOHIrrOiieRFf6ongLp/O8jfeXMd7acm8zqC9pDDinjyHMXblxjSab+NiIJmQo7AHIEh7C4
Cc: "jose@ietf.org" <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 23:07:41 -0000

There are definitely a number of different ways to skin the X509/PKIX in
JWK cat. This I-D isn't necessarily intended to be the final solution but
hopefully a way to start the productive conversation.


On Fri, Feb 8, 2013 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
>>
>>
>