Return-Path: 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 659081A6FF9 for ; Thu, 25 Sep 2014 09:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 QNPIBNORKFXB for ; Thu, 25 Sep 2014 09:47:18 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9711A0149 for ; Thu, 25 Sep 2014 09:47:17 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so13119192lam.28 for ; Thu, 25 Sep 2014 09:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3XZz7vvuK/Bl59Q/6CFs98iYG4bN7AkUTbqHmvxrKoo=; b=Dj9OBpng5TNkIw2CaIAX9F0XKnUmVkHClLSVirQbXsDKrLw70hKfwzswStclmE0Cup Qv2CgxNMwAtsK02xI+okERgNooAk99/sL+L4LF2jODa4CqbWm9VlzqjIY9pd7TyfEqDw 1TFRLd9XD1fqRqv05ncAmuUIzzfWSJahk/RzDhx6RShHLD5fvIsd3QtyDtIR+/gZGHwH NS944bEJuH/kB3DeK6wRfW2OqSP+E6jUQ0BEKWQX2zZxQ43b2564HNEmnZMXiAJdWhFG UW88MU1gWVitF1oD2Rrf5Jg/4D/KG4ads89r+/QgWBbYbIcRKisaWhUWF34SDhKO99zY Jg9g== MIME-Version: 1.0 X-Received: by 10.112.168.38 with SMTP id zt6mr13693669lbb.60.1411663636029; Thu, 25 Sep 2014 09:47:16 -0700 (PDT) Received: by 10.112.41.233 with HTTP; Thu, 25 Sep 2014 09:47:15 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BA78909@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AEB89F6@TK5EX14MBXC292.redmond.corp.microsoft.com> <5411BC12.9040808@bbn.com> <4E1F6AAD24975D4BA5B16804296739439BA6F3C8@TK5EX14MBXC286.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439BA78909@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Thu, 25 Sep 2014 12:47:15 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c346749168ea0503e68d84 Archived-At: http://mailarchive.ietf.org/arch/msg/jose/mZvPkxoXhqWZL1jCkuSptINTpYc Cc: "jose-chairs@tools.ietf.org" , "Moriarty, Kathleen" , "jose@ietf.org" Subject: Re: [jose] SECDIR review of draft-ietf-jose-json-web-key-31 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 16:47:22 -0000 --001a11c346749168ea0503e68d84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 25, 2014 at 12:28 PM, Mike Jones wrote: > My sincere apologies. Upon review, it appears that I missed a whole > block of resolutions agreed to in this thread. Those that I believe I > missed were: > > =C2=B7 changing =E2=80=9Cdata associated with a key=E2=80=9D to = =E2=80=9Cdata cryptographically > secured by a key=E2=80=9D? (And of course, deleting the extraneous =E2= =80=9Cthan=E2=80=9D.) > > =C2=B7 add that this implies a that there is secure way to deliver= the > needed decryption key for the JWE > > =C2=B7 In addition to the common parameters, each JWK will have me= mbers > that are key type-specific. > > =C2=B7 Rather than saying =E2=80=9CSHOULD be used=E2=80=9D, we cou= ld change it to just > say =E2=80=9Cis used=E2=80=9D. > > =C2=B7 The "alg" member is used to specify the algorithm with whic= h the > key is to be used. > > =C2=B7 The "use" parameter is employed to indicate whether a publi= c key > is for encrypting data or verifying the signature on data. > > =C2=B7 This specification will be used both in open environments = =E2=80=A6 and > closed environments =E2=80=A6 > > =C2=B7 change =E2=80=9Ccan be=E2=80=9D to =E2=80=9Cis=E2=80=9D > > =C2=B7 Clarification about improving interoperability > > =C2=B7 Similarly, if the =E2=80=9Calg=E2=80=9D member is present, = it SHOULD correspond > to the algorithm specified in the certificate. > > =C2=B7 we could add language saying that certificate thumbprints a= re > also known as certificate fingerprints > > =C2=B7 We could be more explicit and talk about performing > authenticated encryption > > > > Also, there was an issue about the RFC 1421 reference that we did not > reach a resolution on. In looking at 1421, it=E2=80=99s no longer clear = to me that > this is the best reference for the =E2=80=9Cx5u=E2=80=9D certificate form= at definition. > I=E2=80=99ll have to investigate that further. > > > > Finally, on the basis of Stephen=E2=80=99s comment on two weeks being pot= entially > two short for the registration review period and people taking multi-week > vacations, I propose that we change it to three weeks. > > > > Kathleen, do you want me to publish updated drafts today addressing these > missed resolutions? My thinking is that it would probably be better to g= o > into the telechat with these issues having been addressed. > > > If you can get this done today, then yes. Barry has started his reviews and is making quick progress. *reduced the distribution list Thanks, Kathleen > -- Mike > > > > *From:* Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > *Sent:* Thursday, September 25, 2014 7:25 AM > *To:* Mike Jones > *Cc:* Stephen Kent; secdir@ietf.org; jose-chairs@tools.ietf.org; > Moriarty, Kathleen; jose@ietf.org > *Subject:* Re: [jose] SECDIR review of draft-ietf-jose-json-web-key-31 > > > > Hi Mike, > > > > It appears that the explanation for thumprints/fingerprints was not > included in the current version and was agreed to. This came up several > times in reviews and I think it would be helpful for the reader. Let me > know if I missed something or if this was an oversight and it will be > addressed in the next revision. > > > > Also, there is some suggested text from Steve on "alg" members. Where > does that stand? I think I am missing the resolution. > > > > These issues are in the email thread right next to each other. > > > > Thanks! > > > > On Tue, Sep 23, 2014 at 7:40 PM, Mike Jones > wrote: > > Thanks again for your review, Stephen. The resolutions discussed below > have been incorporated in draft -32. > > > > See the thread =E2=80=9CJWK member names, was: [jose] SECDIR review of > draft-ietf-jose-json-web-key-31=E2=80=9D for the status of that particula= r issue. > > > > -- Mike > > > > *From:* Stephen Kent [mailto:kent@bbn.com] > *Sent:* Thursday, September 11, 2014 8:13 AM > *To:* Mike Jones; secdir@ietf.org; jose-chairs@tools.ietf.org; Moriarty, > Kathleen > *Cc:* jose@ietf.org > *Subject:* Re: SECDIR review of draft-ietf-jose-json-web-key-31 > > > > Mike, > > Thanks for the reply to my comments. > > I've retained your replies and responded to them, below. > > > I agree that =E2=80=9Cemploying countermeasures to=E2=80=9D is more accur= ate than > =E2=80=9Cpreventing=E2=80=9D. I also agree that the =E2=80=9Cavoiding mi= stakes=E2=80=9D language is not > actionable =E2=80=93 I propose to just remove it. > > Great. > > Actually, it was spoken by then-Security AD Sean Turner. ;-) > > gee, I thought Sean was wise, but I didn't realize he was a Jedi ;-). > > How about changing =E2=80=9Cdata associated with a key=E2=80=9D to =E2=80= =9Cdata cryptographically > secured by a key=E2=80=9D? (And of course, deleting the extraneous =E2= =80=9Cthan=E2=80=9D.) > > OK. > > The wording above is needlessly awkward. Nonetheless, this says that key > sets containing symmetric or private keys should be encrypted by embeddin= g > them in another JSON crypto format (JWE). It would be nice to add that th= is > implies a that there is secure way to deliver the needed decryption key f= or > the JWE, else this recommendation just adds a layer of indirection, and > does not solve the problem. > > Fair enough. I propose that we add something along those lines. > > OK, I look forward to seeing the revised wording here. > > Section 9.3 discusses a countermeasure against a specific attack on RSA > key use. This seems unduly narrow, since this spec is intended for use wi= th > RSA, DH, DSS, and ECDH keys. Why devote a long paragraph to this one issu= e, > while saying nothing about equally serious concerns that arise for other > algorithms? > > > > This particular attack is described both because the countermeasure > requires specific key representation actions and because a working group > member asked it to be included. For what it=E2=80=99s worth, I expect th= at > additional security considerations will be added when resolving Russ > Housley=E2=80=99s gen-art review of the JWS specification. > > If comparable alg-specific countermeasures are added based on Russ's > comments then > this may be OK, but in isolation this RSA-specific attack seem out of > place. > > These non-goals were agreed to by the working group from the very > beginning, while the working group was still being chartered. The group > wanted to build something simple and easily deployable to represent keys = in > JSON =E2=80=93 not reinvent all the work that the PKIX working group did = on > certificates and certificate chains, etc. Do any working group members > want to suggest specific wording to try to capture this sentiment? > > OK. > > The example that comprises Section 3 should include an explanation of > the parameters, else it=E2=80=99s not a great example. > > > > The parameters and values of them are explained in the paragraph precedin= g > the example text. It says: > > > > The following example JWK > > declares that the key is an Elliptic Curve [DSS ] key, it is used with > > the P-256 Elliptic Curve, and its x and y coordinates are the > > base64url encoded values shown. A key identifier is also provided > > for the key. > > > > Each statement above corresponds to a parameter in the example, and in th= e > same order. > > OK. I missed that. > > I suppose that one option is to be more verbose above and add > parenthetical remarks after each statement above saying which parameter > does this. So for instance, the parenthetical phrase =E2=80=9C(=E2=80=9C= kty=E2=80=9D parameter)=E2=80=9D > could be added before the first comma. Do others in the working group > think that would make the example easier to read, harder to read, or do a= ny > of you have an alternative suggestion? > > I defer to the WG on this presentation issue. > > In addition to the common parameters, each JWK will have members that > > are algorithm-specific. > > > > They=E2=80=99re not algorithm-specific =E2=80=93 they=E2=80=99re key type= -specific. Another way > of eliminating the repeated use of the word =E2=80=9Cparameters=E2=80=9D = is to replace the > second sentence with =E2=80=9CThese members represent the key value=E2=80= =9D. Would that > work for you (and the working group)? > > Yes, I meant key-type specific. But if one were to use that term instead > of "algorithm specific" > I still think my wording is better. > > This topic has been heavily discussed by the working group, and while the > specs used to just say that objects with duplicate member names MUST be > rejected, working group members, including Tim Bray (the editor of the JS= ON > spec), prevailed on us to weaken this so that parsers that implement the > ECMAscript behavior of returning only the last member name may be legally > used. (The argument was made that there was more security downside in > effectively requiring people to write and debug their own strict parsers > than in using laxer, but well-supported and debugged parsers.) > > I find that argument unpersuasive, but I defer to the cognizant Ad on thi= s. > > However, we also intentionally require that producers use only one > instance of each member name, so that legally produced objects will never > exercise the ambiguities that are present in real JSON parsers. That > seemed to be the most practical solution to the working group. > > Based on year of experience in PKIX that is not a great solution. If the > consumer of a data > structure fails to strictly enforce the requirement imposed on the > producer of the data structure, > the result is that non-conforming producers do not receive "appropriate" > feedback. > > > The term "Collision-Resistant Name" is already present in the Terminology > section. However, previous reviewers had requested that definitions not = be > repeated in multiple specs, so it=E2=80=99s incorporated by reference, ra= ther than > repeating the definition here. The notion is that of an implementation > wants to use a collision-resistant name such as =E2=80=9C > http://names.example.com/the-name=E2=80=9D, it can do so without having t= o create > a public specification and register the name with IANA. > > I found the definition by reading one of the other specs, but I didn't se= e > a clear explanation of > why this is a reasonable alternative to using an IANA registry. The text > above does still does > not provide a rationale. > > I agree that the =E2=80=9CSHOULD=E2=80=9D language is awkward. Rather t= han saying > =E2=80=9CSHOULD be used=E2=80=9D, we could change it to just say =E2=80= =9Cis used=E2=80=9D. > > OK. > > Would the language =E2=80=9CThe =E2=80=9Calg=E2=80=9D member can be used = to specify the > cryptographic operation that the key is intended to be used for=E2=80=9D = work > better for you? Or would people like to just see the parenthetical remar= k > deleted? > > How about: > > The "alg" member is used to specify the algorithm with which the key is t= o > be used. > > Section 4.5 defines the key_ops parameter. It=E2=80=99s not clear how t= his > parameters and =E2=80=9Cuse=E2=80=9D relate. There is also an odd sentenc= e at the end of > the first paragraph: > > > > The "key_ops" parameter is intended for use cases in which public, > > private, or symmetric keys may be present. > > > > This seems to encompass all of the types of keys that JWK carries, so the > sentence seems to add no useful qualification for when this parameter is > intended to be used. > > > > This is in contrast to the related statement in the =E2=80=9Cuse=E2=80=9D= definition: > > > > The "use" parameter is intended for use cases in which > > it is useful to distinguish between public signing keys and public > > encryption keys. > > Too subtle for me, and the language above seems a bit wimpy. Why not say: > > The "use" parameter is employed to indicate whether a public key is for > encrypting > data or verifying the signature on data. > > If you want to see this parameter name changed, you=E2=80=99ll need to = file a > bug against the WebCrypto spec and get it changed there. Then I=E2=80=99= m sure > that JOSE will gladly follow. > > My request is directed to the IESG, suggesting that they take this action= . > > > > This specification will be used both in open environments, in which > multiple organizations will need to have a common understanding of any > extensions used, and closed environments, which the producing and consumi= ng > organization will always be the same and private values could be safely > used. IANA registration is definitely the right thing to do for open > environments. It=E2=80=99s probably unnecessary for deployments in close= d > environments. > > Then say this. > > Same answer as for Section 4. > > ibid. > > =E2=80=9CCan=E2=80=9D is being used as a non-2119 synonym for =E2=80=9CMA= Y=E2=80=9D here. That being > said, we could just change =E2=80=9Ccan be=E2=80=9D to =E2=80=9Cis=E2=80= =9D, since it=E2=80=99s explicitly said > that its use is optional at the end of the paragraph. > > please revise accordingly. > > It=E2=80=99s the inclusion of other metadata about the key that might im= prove > interoperability that=E2=80=99s being referred to =E2=80=93 not the inclu= sion of the cert > reference. For instance, including =E2=80=9Cuse=E2=80=9D or =E2=80=9Calg= =E2=80=9D parameters might be > useful to applications that can=E2=80=99t process the certificate. > > that's not what the text said, hence my confusion. > > As for the cert vs. cert chain question, in the general case, a chain may > be required to establish trust. However, a chain of length one (a single > certificate) will also be sufficient in some use cases. We=E2=80=99re no= t > inventing anything new here. The data format is specified in RFC 1421. > > could you point specifically to where 1421 uses two names to identify > equivalent data structures > for transport of certs/cert chains? I trued a quick search of the text an= d > didn't locate the > text to which you appear to refer. > > I had thought there were uses of RSA keys where the same key is used bot= h > for signing and encryption (even though this is a deprecated practice). > > Yes, that practice is frowned upon, and we prefer that certs use an OID > that makes it clear > how a key is to be used. How about the following text: > > Similarly, if the "alg" member is present, it MUST be consistent with > > the algorithm specified in the certificate. > > > > But we could change this to =E2=80=9CSimilarly, if the =E2=80=9Calg=E2=80= =9D member is present, it > SHOULD correspond to the algorithm specified in the certificate.=E2=80=9D= Or is > that overly strong for some certificates and uses of them? > > I prefer this text. > > Also, the name seems misleading since the chain MAY contain additional > certs, and hence may not be a chain at all! > > > > I=E2=80=99m not sure if I=E2=80=99m following you here. Are you suggesti= ng the > possibility of having multiple certificates not chaining to one another i= n > the representation? This isn=E2=80=99t allowed by the specification, as = written. > Are you suggesting that it needs to be allowed? > > > > Thumbprint is the term used in the Windows libraries, such as > http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509= certificates.x509certificate2.thumbprint(v=3Dvs.110).aspx. > Whereas OpenSSL uses fingerprint > http://www.openssl.org/docs/apps/x509.html. I know that there would be > an uproar if we tried to make a breaking change to the =E2=80=9Cx5t=E2=80= =9D name at this > point, because it=E2=80=99s in widespread production use. However, we co= uld add > language saying that certificate thumbprints are also known as certificat= e > fingerprints, so people familiar with either term will know what this is. > > Yes, do add that explanatory text. > > The term =E2=80=9Cbase64url=E2=80=9D is incorporated by reference in the = terminology > section (Section 2). > > > > Actually, Appendix C in JWS is not normative. It=E2=80=99s just example = code. > The normative definition of the encoding is in Section 5 of RFC 4648. > > Then 4648 should be cited. > > > > It used to be a =E2=80=9CSHOULD=E2=80=9D but the working group felt that = the =E2=80=9CMUST =E2=80=A6 > unless=E2=80=9D wording was a more accurate statement of the requirement. > > I defer to the cognizant AD here, but the notion of SHOULD is really MUST > ... unless ... > > > > Section 8 (IANA Considerations) establishes a two-week review period for > creating new (IANA) registry items. This seems too short; some people tak= e > multi-week vacations. I note that the same text appears in the JWS and JW= E > documents. > > > > This text was taken from RFC 6749. > > I didn't review that RFC. My comment still stands. > > Aren=E2=80=99t appendices normally informative? > > normally, but not always. > > We could be more explicit and talk about performing authenticated > encryption. > > please do. > > Steve > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > > > -- > > > > Best regards, > > Kathleen > --=20 Best regards, Kathleen --001a11c346749168ea0503e68d84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 25, 2014 at 12:28 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

My sincere apologies.=C2= =A0 Upon review, it appears that I missed a whole block of resolutions agre= ed to in this thread.=C2=A0 Those that I believe I missed were:

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 changing =E2=80=9Cda= ta associated with a key=E2=80=9D to =E2=80=9Cdata cryptographically secure= d by a key=E2=80=9D?=C2=A0 (And of course, deleting the extraneous =E2=80= =9Cthan=E2=80=9D.)

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 add that th= is implies a that there is secure way to deliver the needed decryption key = for the JWE

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In addition to the common parameters, each JWK = will have members that are key type-specific.=

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Rather than saying = =E2=80=9CSHOULD be used=E2=80=9D, we could change it to just say =E2=80=9Ci= s used=E2=80=9D.

=C2=B7= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The "alg" member is used to specify t= he algorithm with which the key is to be used.

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The "use" parameter is employed to in= dicate whether a public key is for encrypting data or verifying the signatu= re on data.

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This specification w= ill be used both in open environments =E2=80=A6 and closed environments =E2= =80=A6

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 change =E2=80=9Ccan = be=E2=80=9D to =E2=80=9Cis=E2=80=9D

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Clarification about = improving interoperability

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Similarly, if the = =E2=80=9Calg=E2=80=9D member is present, it SHOULD correspond to the algori= thm specified in the certificate.<= u>

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 we could add languag= e saying that certificate thumbprints are also known as certificate fingerp= rints

=C2=B7=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We could be more exp= licit and talk about performing authenticated encryption

=C2=A0

Also, there was an issue = about the RFC 1421 reference that we did not reach a resolution on.=C2=A0 I= n looking at 1421, it=E2=80=99s no longer clear to me that this is the best reference for the =E2=80=9Cx5u=E2=80=9D certificate format definition= .=C2=A0 I=E2=80=99ll have to investigate that further.=

=C2=A0

Finally, on the basis of = Stephen=E2=80=99s comment on two weeks being potentially two short for the = registration review period and people taking multi-week vacations, I propose that we change it to three weeks.

=C2=A0

Kathleen, do you want me to publish updated drafts today addressing th= ese missed resolutions?=C2=A0 My thinking is that it would probably be better = to go into the telechat with these issues having been addressed.<= /u>

=C2=A0

<= /div>
If you can get this done today, then yes.=C2= =A0 Barry has started his reviews and is making quick progress.=C2=A0
=

*reduced the distribution list

Thanks,
Kathleen

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: Kathleen= Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]
Sent: Thursday, September 25, 2014 7:25 AM
To: Mike Jones
Cc: Stephen Kent; secdir@ietf.org; jose-chairs@tools.ietf.org; Moriarty, Kathleen; jose@ietf.org
Subject: Re: [jose] SECDIR review of draft-ietf-jose-json-web-key-31=

=C2=A0

Hi Mike,

=C2=A0

It appears that the explanation for thumprints/finge= rprints was not included in the current version and was agreed to.=C2=A0 Th= is came up several times in reviews and I think it would be helpful for the= reader.=C2=A0 Let me know if I missed something or if this was an oversight and it will be addressed in the next revision.=

=C2=A0

Also, there is some suggested text from Steve on &qu= ot;alg" members.=C2=A0 Where does that stand?=C2=A0 I think I am missi= ng the resolution.

=C2=A0

These issues are in the email thread right next to e= ach other.

=C2=A0

Thanks!

=C2=A0

On Tue, Sep 23, 2014 at 7:40 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Thanks again for your rev= iew, Stephen.=C2=A0 The resolutions discussed below have been incorporated = in draft -32.

=C2=A0

See the thread =E2=80=9CJ= WK member names, was: [jose] SECDIR review of draft-ietf-jose-json-web-key-= 31=E2=80=9D for the status of that particular issue.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike

=C2=A0

From: Stephen = Kent [mailto:kent@bbn.com= ]
Sent: Thursday, September 11, 2014 8:13 AM
To: Mike Jones; secdir@ietf.org; jose-chairs= @tools.ietf.org; Moriarty, Kathleen
Cc: jose@ietf.org=
Subject: Re: SECDIR review of draft-ietf-jose-json-web-key-31=

=C2=A0

Mike,

Thanks for the reply to my comments.

I've retained your replies and responded to them, below.<= /p>

=C2=A0
I agree that =E2=80=9Cemploying countermeasures = to=E2=80=9D is more accurate than =E2=80=9Cpreventing=E2=80=9D.=C2=A0 I als= o agree that the =E2=80=9Cavoiding mistakes=E2=80=9D language is not action= able =E2=80=93 I propose to just remove it.

Great.<= /p>

=C2=A0 Actually, it was spoken by then-Security = AD Sean Turner. ;-)

gee, I thought Sean w= as wise, but I didn't realize he was a Jedi ;-).

How about changing =E2=80= =9Cdata associated with a key=E2=80=9D to =E2=80=9Cdata cryptographically s= ecured by a key=E2=80=9D?=C2=A0 (And of course, deleting the extraneous =E2=80=9Cthan=E2=80=9D.)<= u>

OK.

=C2=A0The wording above is= needlessly awkward. Nonetheless, this says that key sets containing symmetric or private keys should be encrypted by = embedding them in another JSON crypto format (JWE). It would be nice to add= that this implies a that there is secure way to deliver the needed decrypt= ion key for the JWE, else this recommendation just adds a layer of indirection, and does not solve the problem.

Fair enough.=C2=A0 I prop= ose that we add something along those lines.

OK, I look forward to= seeing the revised wording here.

Section 9.3 disc= usses a countermeasure against a specific attack on RSA key use. This seems= unduly narrow, since this spec is intended for use with RSA, DH, DSS, and ECDH keys. Why devote a long paragraph to this one = issue, while saying nothing about equally serious concerns that arise for o= ther algorithms?

= =C2=A0

This particular attack is= described both because the countermeasure requires specific key representa= tion actions and because a working group member asked it to be included.=C2=A0 = For what it=E2=80=99s worth, I expect that additional security consideratio= ns will be added when resolving Russ Housley=E2=80=99s gen-art review of th= e JWS specification.

If comparable alg-spe= cific countermeasures are added based on Russ's comments then
this may be OK, but in isolation this RSA-specific attack seem out of place= .

=C2=A0These non-goals wer= e agreed to by the working group from the very beginning, while the working= group was still being chartered.=C2=A0 The group wanted to build something simpl= e and easily deployable to represent keys in JSON =E2=80=93 not reinvent al= l the work that the PKIX working group did on certificates and certificate = chains, etc.=C2=A0 Do any working group members want to suggest specific wording to try to capture this sentiment?

OK.

=C2=A0The example that comprises Section 3 should includ= e an explanation of the parameters, else it=E2=80=99s not a great example.

= =C2=A0

The parameters and values= of them are explained in the paragraph preceding the example text.=C2=A0 I= t says:

=C2=A0

=C2=A0=C2=A0 The following example JWK=

=C2=A0=C2=A0 declares that the key is an Elliptic Cu=
rve [DSS] key, it =
is used with
=C2=A0=C2=A0 the P-256 Elliptic Curve, and its x and=
 y coordinates are the
=C2=A0=C2=A0 base64url encoded values shown.=C2=A0 A=
 key identifier is also provided
=C2=A0=C2=A0 for the key.

= =C2=A0

Each statement above corr= esponds to a parameter in the example, and in the same order.=

OK. I missed that.

I suppose that one option= is to be more verbose above and add parenthetical remarks after each state= ment above saying which parameter does this.=C2=A0 So for instance, the parenth= etical phrase =E2=80=9C(=E2=80=9Ckty=E2=80=9D parameter)=E2=80=9D could be = added before the first comma.=C2=A0 Do others in the working group think th= at would make the example easier to read, harder to read, or do any of you have an alternative suggestion?

I defer to the WG on = this presentation issue.

=C2=A0 In= addition to the common parameters, each JWK will have members that

=C2=A0 are algorithm-specific.

=C2=A0

They=E2=80=99re not algorithm-specific =E2=80= =93 they=E2=80=99re key type-specific.=C2=A0 Another way of eliminating the= repeated use of the word =E2=80=9Cparameters=E2=80=9D is to replace the se= cond sentence with =E2=80=9CThese members represent the key value=E2=80=9D.=C2=A0 Would that work for you (a= nd the working group)?

Yes, I meant key-type= specific. But if one were to use that term instead of "algorithm spec= ific"
I still think my wording is better.

This topic has been heavily discussed by the = working group, and while the specs used to just say that objects with dupli= cate member names MUST be rejected, working group members, including Tim Bray (the editor of the JSON spec), prevailed on us to weake= n this so that parsers that implement the ECMAscript behavior of returning = only the last member name may be legally used.=C2=A0 (The argument was made= that there was more security downside in effectively requiring people to write and debug their own strict parser= s than in using laxer, but well-supported and debugged parsers.)<= /u>

I find that argument = unpersuasive, but I defer to the cognizant Ad on this.

However, we also intentionally require that p= roducers use only one instance of each member name, so that legally produce= d objects will never exercise the ambiguities that are present in real JSON parsers.=C2=A0 That seemed to be the most practical s= olution to the working group.

Based on year of expe= rience in PKIX that is not a great solution. If the consumer of a data
structure fails to strictly enforce the requirement imposed on the producer= of the data structure,
the result is that non-conforming producers do not receive "appropriat= e" feedback.


The term "Collision-Resistant Name" is already present in the Terminology section.=C2=A0 H= owever, previous reviewers had requested that definitions not be repeated in multiple specs, so it=E2=80=99s incorporated by reference, rather than = repeating the definition here.=C2=A0 The notion is that of an implementatio= n wants to use a collision-resistant name such as =E2=80=9Chttp://names.examp= le.com/the-name=E2=80=9D, it can do so without having to create a public specification and register = the name with IANA.

I found the definitio= n by reading one of the other specs, but I didn't see a clear explanati= on of
why this is a reasonable alternative to using an IANA registry. The text ab= ove does still does
not provide a rationale.

=C2=A0I agree that the = =E2=80=9CSHOULD=E2=80=9D language is awkward.=C2=A0 Rather than saying =E2= =80=9CSHOULD be used=E2=80=9D, we could change it to just say =E2=80=9Cis used=E2=80=9D.

OK.

Would the language =E2=80=9CThe =E2=80=9Calg= =E2=80=9D member can be used to specify the cryptographic operation that th= e key is intended to be used for=E2=80=9D work better for you?=C2=A0 Or wou= ld people like to just see the parenthetical remark deleted?

How about:

The "alg" member is used to specify the al= gorithm with which the key is to be used.

=C2=A0Section 4.= 5 defines the key_ops parameter. It=E2=80=99s not clear how this parameters= and =E2=80=9Cuse=E2=80=9D relate. There is also an odd sentence at the end= of the first paragraph:

=C2=A0

=C2=A0=C2=A0 The "key_ops" parameter is intended for use cases= in which public,

=C2=A0=C2=A0 private, or symmetric keys may be present.

=C2=A0

This seems to en= compass all of the types of keys that JWK carries, so the sentence seems to= add no useful qualification for when this parameter is intended to be used.

=C2=A0

This is in contrast to th= e related statement in the =E2=80=9Cuse=E2=80=9D definition:<= u>

=C2=A0

=C2=A0=C2=A0 The "use" parameter is intended for use = cases in which

=C2=A0=C2=A0 it is useful to distinguish between public signing= keys and public

=C2=A0=C2=A0 encryption keys.

Too subtle for me, an= d the language above seems a bit wimpy. Why not say:

The "use" parameter is employed to indicat= e whether a public key is for encrypting
data or verifying the signature on data.

=C2=A0If you want to see = this parameter name changed, you=E2=80=99ll need to file a bug against the = WebCrypto spec and get it changed there.=C2=A0 Then I=E2=80=99m sure that JOSE will = gladly follow.

My request is directe= d to the IESG, suggesting that they take this action.

=C2=A0<= /p>

This specification will b= e used both in open environments, in which multiple organizations will need to have a common understanding of any extensions used, and closed environm= ents, which the producing and consuming organization will always be the sam= e and private values could be safely used.=C2=A0 IANA registration is defin= itely the right thing to do for open environments.=C2=A0 It=E2=80=99s probably unnecessary for deployments in c= losed environments.

Then say this.=

Same answer as for Sectio= n 4.

ibid.

=E2=80=9CCan=E2=80=9D is = being used as a non-2119 synonym for =E2=80=9CMAY=E2=80=9D here.=C2=A0 That= being said, we could just change =E2=80=9Ccan be=E2=80=9D to =E2=80=9Cis=E2=80=9D, since it=E2=80=99s expli= citly said that its use is optional at the end of the paragraph.<= /u>

please revise accordi= ngly.

=C2=A0It=E2=80=99s the in= clusion of other metadata about the key that might improve interoperability= that=E2=80=99s being referred to =E2=80=93 not the inclusion of the cert reference.=C2=A0 For i= nstance, including =E2=80=9Cuse=E2=80=9D or =E2=80=9Calg=E2=80=9D parameter= s might be useful to applications that can=E2=80=99t process the certificat= e.

that's not what t= he text said, hence my confusion.

As for the cert vs. cert = chain question, in the general case, a chain may be required to establish trust.=C2=A0 However, a chain of length one (a single certificate) will al= so be sufficient in some use cases.=C2=A0 We=E2=80=99re not inventing anyth= ing new here.=C2=A0 The data format is specified in RFC 1421.=

could you point speci= fically to where 1421 uses two names to identify equivalent data structures=
for transport of certs/cert chains? I trued a quick search of the text and = didn't locate the
text to which you appear to refer.

=C2=A0I had thought there= were uses of RSA keys where the same key is used both for signing and encr= yption (even though this is a deprecated practice).

Yes, that practice is= frowned upon, and we prefer that certs use an OID that makes it clear
how a key is to be used. How about the following text:

=C2=A0=C2=A0 Similarly, if the "al= g" member is present, it MUST be consistent with<= /p>

=C2=A0=C2=A0 the algorithm specified in= the certificate.

=C2=A0<= /p>

But we could change this = to =E2=80=9CSimilarly, if the =E2=80=9Calg=E2=80=9D member is present, it S= HOULD correspond to the algorithm specified in the certificate.=E2=80=9D=C2=A0 Or is that overly s= trong for some certificates and uses of them?

I prefer this text.

=C2=A0Also, the name seems misleading since the chain MA= Y contain additional certs, and hence may not be a chain at all!

=C2=A0

I=E2=80=99m not sure if I= =E2=80=99m following you here.=C2=A0 Are you suggesting the possibility of = having multiple certificates not chaining to one another in the representation?=C2=A0 This isn=E2=80=99= t allowed by the specification, as written.=C2=A0 Are you suggesting that i= t needs to be allowed?

=C2=A0<= /p>

Thumbprint is the term us= ed in the Windows libraries, such as http://msdn.microsoft.com/= en-us/library/system.security.cryptography.x509certificates.x509certificate= 2.thumbprint(v=3Dvs.110).aspx.=C2=A0 Whereas OpenSSL uses fingerprint http://ww= w.openssl.org/docs/apps/x509.html.=C2= =A0 I know that there would be an uproar if we tried to make a breaking change= to the =E2=80=9Cx5t=E2=80=9D name at this point, because it=E2=80=99s in w= idespread production use.=C2=A0 However, we could add language saying that = certificate thumbprints are also known as certificate fingerprints, so people familiar with either term will know what this is.<= u>

Yes, do add that expl= anatory text.

The term =E2=80=9Cbase64u= rl=E2=80=9D is incorporated by reference in the terminology section (Sectio= n 2).

=C2=A0

Actually, Appendix C in J= WS is not normative.=C2=A0 It=E2=80=99s just example code.=C2=A0 The normat= ive definition of the encoding is in Section 5 of RFC 4648.

Then 4648 should be c= ited.

=C2=A0

It used to be a =E2=80=9C= SHOULD=E2=80=9D but the working group felt that the =E2=80=9CMUST =E2=80=A6= unless=E2=80=9D wording was a more accurate statement of the requirement.

I defer to the cogniz= ant AD here, but the notion of SHOULD is really MUST ... unless ...<= u>

=C2=A0

Section 8 (IANA = Considerations) establishes a two-week review period for creating new (IANA= ) registry items. This seems too short; some people take multi-week vacations. I note that the same text appears in the JWS an= d JWE documents.

=C2=A0=

This text was taken from = RFC 6749.

I didn't review t= hat RFC. My comment still stands.

Aren=E2=80=99t appendices= normally informative?

normally, but not alw= ays.

=C2=A0We could be more explicit and talk about performing= authenticated encryption.

please do.

Steve


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=C2=A0

--

=C2=A0

Best regards,

Kathleen




--

Best regards,
Kathleen
--001a11c346749168ea0503e68d84--