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

John Bradley <ve7jtb@ve7jtb.com> Fri, 08 February 2013 22:54 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 6585221F8B8B for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 14:54:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uwZWyQEc52g0 for <jose@ietfa.amsl.com>; Fri, 8 Feb 2013 14:54:26 -0800 (PST)
Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0099C21F86C9 for <jose@ietf.org>; Fri, 8 Feb 2013 14:54:25 -0800 (PST)
Received: by mail-da0-f46.google.com with SMTP id p5so1987160dak.5 for <jose@ietf.org>; Fri, 08 Feb 2013 14:54:25 -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=t1cjGeq52h1y68TAaV0uOKMhOPXyAy/62Bp8NqCrd9E=; b=A9CiK50aMHUfDaO+04iHIq2rd7UFdUd7flRtoDYfn4f/SR/4+YGe4ullQ7fQZGMRDp 78f4+dWP+9tIX/Vrz0bcPXhjbYhckIHUvS9ba+LJEmTc2m1mSrVz9FDPww47KkmRFCfV pDZBHamJkHJfWhdC1FElnNhfxVFpFlhpwKHAgDmjOdmC2H6lUKuA+RU3XwPE2osjEPFN RvUUmHqi9jQVs6hq65cN3n7i996QThHqnAY+s1gX06vbEH8Rc1xug/9fw0pFPH3B1KvR HPdG0p9i80KdS3t+avN6DmeOrnbUvISOteJ+0f6UXvduoiwszkFmldAx7MXXZL+VJhDn CZBw==
X-Received: by 10.66.81.68 with SMTP id y4mr21644376pax.66.1360364065480; Fri, 08 Feb 2013 14:54:25 -0800 (PST)
Received: from [192.168.43.179] (mobile-166-137-218-110.mycingular.net. [166.137.218.110]) by mx.google.com with ESMTPS id u10sm7710419pax.14.2013.02.08.14.54.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 14:54:23 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_348A3606-8169-4769-9152-F6D7A998F681"; 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: <CAL02cgS8Bc2Sosba41w_D_V8txE-Jb8ZOz2Dhs33GCQWLSwvFQ@mail.gmail.com>
Date: Fri, 8 Feb 2013 15:54:20 -0700
Message-Id: <9DFAD552-38E8-4E80-B49E-29A6597DD6C0@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> <CAL02cgS8Bc2Sosba41w_D_V8txE-Jb8ZOz2Dhs33GCQWLSwvFQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlbvSIHT5iu7LucLsfQxrKsCCmW9QLIW6FQlGMAE+4n4S/PE2AXtVZVuoQKcEd3Cv3EyYkH
Cc: Brian Campbell <bcampbell@pingidentity.com>, "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 22:54:27 -0000

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