Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
Richard Barnes <rlb@ipv.sx> Fri, 16 January 2015 16:57 UTC
Return-Path: <rlb@ipv.sx>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411EF1ACEEF for <jose@ietfa.amsl.com>; Fri, 16 Jan 2015 08:57:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27ZtcbZmSDZf for <jose@ietfa.amsl.com>; Fri, 16 Jan 2015 08:57:17 -0800 (PST)
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F252F1ACE44 for <jose@ietf.org>; Fri, 16 Jan 2015 08:57:16 -0800 (PST)
Received: by mail-lb0-f178.google.com with SMTP id u14so19422792lbd.9 for <jose@ietf.org>; Fri, 16 Jan 2015 08:57:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BBYAbxKlHutow5gektBnNE78vzs7CeuqywJps7Bn3Kg=; b=TDYzbGHJXJ9idMvQOh/+SCDU2XKh7h/sDKWqHHnb/UWTyIVdOrSD1vTaF7fiis38YC bZVdXfaN5BhbI8nWomMMAUu+Aitviii4zMmb3eDG35YsyXL7nIVvk31tvR69Pb7Zs/rO BH4HGmUMK9lC9wrJRi+R/BK5b5gT+hlExKUU9OJ5y+CyDAPQu3jZ2mtJTWzxWj+QljQy c3jOF/mQ+9SSC7BB+NxlKXgSjG1hlb05YbjILeBdZoP0L28AW6joJrsedNJvC0dOZBzb 5XmRcby3Porkfcqp+Vjfnl4S+jzmu08bU5DMmjV1MEOswc8n/s04X38SvtNS9ksApQ7x 8xKw==
X-Gm-Message-State: ALoCoQldJO4WAEpwWy2b2z1WcGCIBU5vG6IxqGEvLk+kU7CVI5PN9mFd4ocHyTLrefGnQR03cTUf
MIME-Version: 1.0
X-Received: by 10.112.85.11 with SMTP id d11mr16707979lbz.100.1421427435418; Fri, 16 Jan 2015 08:57:15 -0800 (PST)
Received: by 10.25.12.215 with HTTP; Fri, 16 Jan 2015 08:57:15 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439E6525AA@TK5EX14MBXC291.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739439BB262D8@TK5EX14MBXC286.redmond.corp.microsoft.com> <CAL02cgRzkXuJgUZ4LTHsiq8ou3zvQZRJFhvbn-Hkmc4BcftDXw@mail.gmail.com> <FED254BC-0616-416F-9624-870A4EA85767@gmail.com> <4E1F6AAD24975D4BA5B16804296739439BB563FF@TK5EX14MBXC286.redmond.corp.microsoft.com> <CAHbuEH6ON0t_3emDA_VDt8zMF0XFFkS0mSYdmesQ_WuhDVjR5A@mail.gmail.com> <CAL02cgTW9vDRovf4RVqfxj4CHZmxcR5R2rvT4QDzJ8eCer5nYQ@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439E6525AA@TK5EX14MBXC291.redmond.corp.microsoft.com>
Date: Fri, 16 Jan 2015 11:57:15 -0500
Message-ID: <CAL02cgTqxtdJHo0reJHZxh0P90DOZa_2B1R+k41XnpSfm=hsCg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="001a11345ed65ccd3c050cc7ddcc"
Archived-At: <http://mailarchive.ietf.org/arch/msg/jose/vaEQyouDypq8I9fBA7qFazTS-OM>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, "draft-ietf-jose-json-web-key@tools.ietf.org" <draft-ietf-jose-json-web-key@tools.ietf.org>, The IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Jan 2015 16:57:24 -0000
That text looks fine to me! On Thu, Jan 15, 2015 at 10:02 PM, Mike Jones <Michael.Jones@microsoft.com> wrote: > How about this (slightly revised) wording? > > > > In almost all cases, applications make decisions about whether to trust a > key based on attributes bound to the key, such as names, roles, or the > source of the key, rather than based on the key itself. When an > application is deciding whether to trust a key, there are several ways that > it can bind attributes to a JWK. Two example mechanisms are PKIX [RFC5280] > and JSON Web Token (JWT) [JWT]. > > > > For instance, the creator of a JWK can include a PKIX certificate in the > JWK's "x5c" member. If the application validates the certificate and > verifies that the JWK corresponds to the subject public key in the > certificate, then the JWK can be associated with the attributes in the > certificate, such as the subject name, subject alternative names, extended > key usages, and its trust chain. > > > > Also for instance, a JWT can be used to associate attributes with a JWK by > referencing the JWK as a claim in the JWT. The JWK can be included > directly as a claim value, or the JWT can include a TLS-secured URI from > which to retrieve the JWK value. Either way, an application that gets a > JWK via a JWT claim can associate it with the JWT’s cryptographic > properties and use these and possibly additional claims in deciding whether > to trust the key. > > > > -- Mike > > > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Thursday, January 15, 2015 6:36 PM > *To:* Kathleen Moriarty > > *Cc:* Mike Jones; jose-chairs@tools.ietf.org; > draft-ietf-jose-json-web-key@tools.ietf.org; The IESG; jose@ietf.org > *Subject:* Re: [jose] Richard Barnes' Discuss on > draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT) > > > > > > > > On Thu, Jan 15, 2015 at 9:11 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > Richard, > > I am close to be done with a final check on comments for this draft > and see that one of your comments was not addressed and maybe should > be. > > The comment left in the datatracker is as follows: > > Section 9.1. > It might help here to note that technologies like PKIX and JWT can allow > relying parties to verify the provenance of a key and binding of > attributes to > it. > > This is a slightly edited version from earlier discussions, which > leads me to think you may not have been happy with the 'discussion' > http://www.ietf.org/mail-archive/web/jose/current/msg04627.html > > Can you take a look at this and if you have text to propose, that > would be appreciated. > > > > Chatted this over with Mike briefly, think the following captures our > intent better. (Obviously, Mike should feel free to object/revise/etc.) > > """ > > In almost all cases, applications make decisions about whether to trust a > key based on attributes bound to the key, such as names or roles, rather > than the raw key itself. When a relying party is trying to decide whether > to trust a key, there are several ways that he can associate attributes to > the JWK. Two examples that are relevant to JWK are PKIX and JWT. > > > > The creator of a JWK can include a PKIX certificate in the JWK's "x5c" > attribute. If the relying party verifies the certificate, and verifies > that the JWK corresponds to the subject public key in the certificate, > then the JWK can be associated with the attributes in the certificate, such > as the subject name, subject alternative names, extended key usages, and > its trust chain. > > > > JSON Web Token (JWT) objects can associate attributes to a JWK by > referencing the JWK as a claim in the JWT. The JWK can be included > directly as a claim value, or the JWT can include a secure reference to the > JWK (e.g., an HTTPS URI). Either way, a relying party that gets a JWK from > a JWT claim can associate it with the JWT's cryptographic properties and > optionally the additional claims in deciding whether to trust the JWK. > > """ > > > > > > > On Tue, Nov 4, 2014 at 12:33 AM, Mike Jones <Michael.Jones@microsoft.com> > wrote: > > +1 > > > > > > > > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > > Sent: Monday, November 03, 2014 8:02 PM > > To: Richard Barnes > > Cc: Mike Jones; jose-chairs@tools.ietf.org; > > draft-ietf-jose-json-web-key@tools.ietf.org; The IESG; jose@ietf.org > > > > > > Subject: Re: [jose] Richard Barnes' Discuss on > > draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT) > > > > > > > > Thank you, Richard. > > > > Sent from my iPhone > > > > > > On Nov 3, 2014, at 10:14 PM, Richard Barnes <rlb@ipv.sx> wrote: > > > > Thanks a lot! I cleared. > > > > > > > > On Sat, Oct 25, 2014 at 2:34 AM, Mike Jones <Michael.Jones@microsoft.com > > > > wrote: > > > > Hi Richard, > > > > In -36 I added that if both "use" and "key_ops" are used, then the > > information they convey MUST be consistent, per your suggestion. I also > > replaced the [TBD]@ietf.org with the actual list name. Hopefully this > will > > enable you to clear your DISCUSSes on this draft. > > > > Thanks again, > > -- Mike > > > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Monday, October 20, 2014 9:19 AM > > To: Richard Barnes > > Cc: The IESG; jose-chairs@tools.ietf.org; > > draft-ietf-jose-json-web-key@tools.ietf.org; jose@ietf.org > > > > Subject: RE: [jose] Richard Barnes' Discuss on > > draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT) > > > > Thanks for your responses, Richard. Replies are inline below... > > > >> From: Richard Barnes [mailto:rlb@ipv.sx] > >> Sent: Saturday, October 18, 2014 11:38 AM > >> To: Mike Jones > >> Cc: The IESG; jose-chairs@tools.ietf.org; > >> draft-ietf-jose-json-web-key@tools.ietf.org; jose@ietf.org > >> Subject: Re: [jose] Richard Barnes' Discuss on > >> draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT) > >> > >> On Tue, Oct 14, 2014 at 5:53 AM, Mike Jones < > Michael.Jones@microsoft.com> > >> wrote: > >> Thanks for your review. The -34 draft contains the following > resolutions. > >> I hope that you can clear your DISCUSSes on that basis. > >> > >> -- Mike > >> > >> > -----Original Message----- > >> > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard > >> > Barnes > >> > Sent: Wednesday, October 01, 2014 7:34 PM > >> > To: The IESG > >> > Cc: jose-chairs@tools.ietf.org; > >> > draft-ietf-jose-json-web-key@tools.ietf.org; > >> > jose@ietf.org > >> > Subject: [jose] Richard Barnes' Discuss on > >> > draft-ietf-jose-json-web-key-33: (with DISCUSS and COMMENT) > >> > > >> > Richard Barnes has entered the following ballot position for > >> > draft-ietf-jose-json-web-key-33: Discuss > >> > > >> > When responding, please keep the subject line intact and reply to > >> > all email addresses included in the To and CC lines. (Feel free to > >> > cut this introductory paragraph, however.) > >> > > >> > > >> > Please refer to > >> > http://www.ietf.org/iesg/statement/discuss-criteria.html > >> > for more information about IESG DISCUSS and COMMENT positions. > >> > > >> > > >> > The document, along with other ballot positions, can be found here: > >> > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/ > >> > > >> > > >> > > >> > -------------------------------------------------------------------- > >> > -- > >> > DISCUSS: > >> > -------------------------------------------------------------------- > >> > -- > >> > > >> > Section 4.3. > >> > "The "use" and "key_ops" JWK members SHOULD NOT be used together." > >> > Did the WG discuss how these could combine? What was the outcome of > >> > that discussion? This could be an important point for > >> > interoperability. For example, WebCrypto enforces them both, so it > >> > will break if it gets a key with "use" and "key_ops" set to > inconsistent > >> > values. > >> > https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html > >> > #rsa- > >> > pss-operations > >> > >> I believe that the working group discussion is accurately reflected in > >> this text from the spec: > >> The "use" and "key_ops" JWK members SHOULD NOT be used together. > >> Applications should specify which of these members they use, if > >> either is to be used by the application. > >> > >> To keep things simple, applications should choose one or the other, > based > >> on their needs. Note that this is a "SHOULD NOT" - not a "MUST NOT", > so if > >> WebCrypto believes they have a good reason to allow either or both, > they're > >> not violating the spec. But specifying which combinations are legal and > >> which aren't in the JWK spec seems very high on the complexity to > usefulness > >> ratio. I hope that you will choose to withdraw this DISCUSS on that > basis. > >> > >> How about if we require that they be consistent if used together, but > punt > >> the definition of consistency to WebCrypto? > >> > >> """ > >> The "use" and "key_ops" JWK members SHOULD NOT be used together. > >> Applications should specify which of these members they use, if > >> either is to be used by the application. If both "use" and "key_ops" > >> members > >> are present, then they MUST be consistent (see [WebCrypto]). > >> """ > > > > I suspect some reviewers wouldn't agree with the "(see [WebCrypto])" > part, > > but I can add the rest of your suggested sentence, if that will do it for > > you. > > > >> > Section 8. > >> > "[TBD]@ietf.org" > >> > This needs to be populated before approval. I don't know what's > >> > customary here, but "jose@ietf.org" is an obvious candidate. > >> > >> Per the spec, jose-reg-review@ietf.org is already the recommended name. > >> Yes, we would create this list before final approval, just as > >> oauth-ext-review@ietf.org was created before RFC 6749 was approved. I > hope > >> that you'll choose to withdraw this DISCUSS on that basis. > >> > >> That sounds fine to me. Who has the action to get that list set up? > > > > Kathleen is doing this, per earlier comments on the thread. > > > >> > -------------------------------------------------------------------- > >> > -- > >> > COMMENT: > >> > -------------------------------------------------------------------- > >> > -- > >> > > >> > Section 1.1. > >> > The pointer for BASE64URL should be to JWS. One level of > >> > indirection, please :) > >> > >> Agreed > >> > >> > Section 4. > >> > It might be worth being explicit (here or elsewhere): > >> > "A JWK MUST NOT contain algorithm-specific members for key type > >> > other the one specified in its "kty" attribute." > >> > >> I agree with the sentiment, but this actually contradicts the statement > >> that member names that are not understood MUST be ignored. > >> > >> Good point. Perhaps we could phrase this as a requirement on creators, > >> leaving consumers free to be more liberal? > >> > >> """ > >> The creator of a JWK MUST NOT include algorithm-specific members for key > >> type other the one specified in its "kty" attribute. Consumers of JWKs > >> SHOULD NOT reject JWKs with such members, however, in the interest of > >> extensibility. > >> """ > > > > In another thread, Carsten Bormann had explicitly objected to situations > in > > which there are different requirements on producers and consumers, unless > > absolutely necessary. I don't think the situation you're describing (for > > instance, including an extraneous "x" value in an RSA key value) rises to > > the level of severity that it warrants placing different requirements on > > producers and consumers. Rather, my intuition at this point (which > could, > > of course, be wrong), is that doing so would be likely to itself generate > > DISCUSS positions. I think we're better off leaving this as-is. > > > >> > Section 4.1. > >> > "cryptographic algorithm family used with the key" > >> > "... such as "RSA" or "EC"." > >> > >> Agreed > >> > >> > Section 4.7. > >> > "base64 encoded ([RFC4648] Section 4 -- not base64url encoded) DER" > >> > It seems unpleasant for implementations to have to support two > >> > flavors of base64, especially since this doesn't use PEM directly. > >> > Did the WG discuss just using BASE64URL? > >> > >> Not much, although each certificate value is actually a PEM-encoded > value, > >> including allowing newlines, etc. People agreed with that goal when we > did > >> discuss it. > >> > >> > Section 9.1. > >> > It might help here to note that technologies like PKIX and JWT can > >> > allow relying parties to verify the provenance of a key and binding of > >> > attributes to it. > >> > >> Can you propose specific language for this? What I have in mind is > >> delivering a JWK or JWK Set on a TLS channel using a URL that is > >> cryptographically bound to the use of the key - possibly using the URL > as > >> the issuer of a JWT signed with the key, but you may have something > else in > >> mind. > >> > >> I had in mind more the traditional, "use a certificate to bind > attributes > >> to a key" sense. How about this? > >> > >> """ > >> In most applications today, there are trusted authorities that vouch for > >> the provenance of a key and bind attributes to it. For example, in > >> PKIX-based applications, participants use certificates to verify that a > >> certificate authority has bound certain attributes to a key, such as a > name > >> or key usage. JWK supports this style of provenance through the "x5u", > >> "x5c", "x5t", and "x5t#S256" attributes, all of which reference a > >> certificate that a relying party can use to associate attributes to the > JWK. > >> Other assertions systems, such as JWT, can likewise be used to assert > >> bindings of attributes to keys. > >> In some applications, it may also be convenient to use TLS as an ersatz > >> assertion mechanism. For example, an application could require JWKs to > be > >> downloaded with associated attributes over HTTPS as a way of having the > >> HTTPS server assert a binding of the JWK to its attributes. This is > similar > >> to the way that the XMPP POSH mechanism uses HTTPS to assert delegations > >> from one way to another. In such applications, however, care needs to > be > >> taken to ensure that secure transports are always used, and to avoid > >> confusion with other uses of the TLS server in question. The former > >> situation would allow an attacker to create bogus assertions, and the > latter > >> would let an attacker trick the server into issuing bogus assertions. > >> """ > > > > It may be just me, but the whole notion of binding attributes to keys > seems > > to be a bit off topic - at least in a section on "Key Provenance and > Trust". > > The point of this section is that applications will make trust decisions > > about keys based on the trustworthiness of the way they got the key. > > Whether or not there may also be attributes bundled with the key is > > independent of this, so I'm not prone to talk about it here. If you > think > > it needs to be talked about elsewhere, can you motivate the reason for > doing > > so? > > > > Other comments on your proposed text above follow... > > > > In what specific way are you thinking that "Other assertions systems, > such > > as JWT, can likewise be used to assert bindings of attributes to keys"? > > While I agree that this is true, I suspect that most implementers > wouldn't > > find that particular wording actionable. > > > > In your second proposed paragraph, while you're talking about "binding of > > the JWK to its attributes", I think the core of the message here is that > TLS > > URLs can be used to provide clear provenance for sets of keys. I'm fine > > with saying that in some way. > > > > I agree with your comments about secure transports being used and > ensuring > > that keys are only retrieved from locations advertised by the > application as > > being their key locations. > > > >> > >> Thanks again, > >> -- Mike > > > > -- Mike > > > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > -- > > Best regards, > Kathleen > > >
- [jose] Richard Barnes' Discuss on draft-ietf-jose… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Jim Schaad
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Barry Leiba
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Barry Leiba
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Jim Schaad
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Barry Leiba
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Barry Leiba
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Kathleen Moriarty
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Kathleen Moriarty
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Kathleen Moriarty
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Richard Barnes
- Re: [jose] Richard Barnes' Discuss on draft-ietf-… Mike Jones