Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E131A86E2; Fri, 12 Jun 2015 05:06:36 -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 m_fG45C26UL9; Fri, 12 Jun 2015 05:06:34 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1366C1A1EF6; Fri, 12 Jun 2015 05:06:34 -0700 (PDT) Received: by oigz2 with SMTP id z2so20519067oig.1; Fri, 12 Jun 2015 05:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=EjYunyZx2un6QeuN4WSDIxKvpsJepURMRS69uHppZW0=; b=uztRoMoTyI/iZ17RwibKqNGuOHD3e9sBdIgGwLagXfDPkIKOIO8RUTQSqBGHjGEGrM Ed5LdqddcWIZ1MCzb2PZFPQFD8zt6hhLA+taculsNoZHxdqEm6FfNG4Ukxqfusiw1Way 9NaX7w0gLNYfutoqtnFp9JSWb/X7VulPnIqgag4vlCyDymXGVDvMsnsU8zwPdwg8DGcn ZEw7Y5uNtnDLp5DS2xtttCSG/Iwa8le7HiqdakfkDyE4VtsvDvtheU1eZDHklaCWqwwT oKRatYvIIh6FdSMGQIRFTjrb/5fBt5e2CiQvDWjfAATonloNitRqnA5U35YDV/CNw7Aj c2ug== X-Received: by 10.60.175.72 with SMTP id by8mr12147137oec.35.1434110793388; Fri, 12 Jun 2015 05:06:33 -0700 (PDT) Received: from adams-mac-mini.attlocal.net ([2602:306:3406:4830:7109:e5a9:442:72ed]) by mx.google.com with ESMTPSA id h195sm2484458oig.1.2015.06.12.05.06.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jun 2015 05:06:32 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DFB11325-054C-4A8B-97FC-DD6F100E5B08" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: "Adam W. Montville" In-Reply-To: Date: Fri, 12 Jun 2015 07:06:30 -0500 Message-Id: <4CA0A65D-E5FD-408C-A6B9-6ECB12A81B7C@gmail.com> References: To: Mike Jones X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "draft-ietf-jose-jwk-thumbprint.all@ietf.org" , The IESG , "jose@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 12:06:36 -0000 --Apple-Mail=_DFB11325-054C-4A8B-97FC-DD6F100E5B08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 11, 2015, at 4:25 PM, Mike Jones = wrote: >=20 > Hi Adam, >=20 > Thanks for the secdir review. >=20 >> From: Adam W. Montville [mailto:adam.w.montville@gmail.com] >> Sent: Monday, June 08, 2015 8:46 AM >> To: The IESG; secdir@ietf.org; = draft-ietf-jose-jwk-thumbprint.all@ietf.org >> Subject: sector review of draft-ietf-jose-jwk-thumbprint-05 >=20 >> Hi, >=20 >> I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >>=20 >> I believe the document is ready with (potential) issues. The =E2=80=9C= with issues=E2=80=9D might be due to ignorance on my part. The draft = does a very good job of explaining the canonical form of a JSON Web Key = that can be used for establishing a thumbprint under varying = circumstances, complete with what I found to be helpful examples. >>=20 >> The primary issue I have is that it=E2=80=99s unclear how relying = parties are going to know which hash algorithm has been used. The = examples use SHA-256, but I=E2=80=99m not seeing where SHA-256 might be = specified as a MUST or even a SHOULD. Moreover, the example output = ultimately shows only the Base-64 encoding of the resulting hash, which = says nothing about the algorithm used to identify a key. >=20 > Earlier drafts had included fields whose names were intended to = communicate the information about the hash function used - see the "jkt" = field definitions in = http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#section-4 = = - but several working group reviewers suggested that these fields were = unnecessary and that the typical usage would be as "kid" (key ID) field = values. With that removal, it falls onto the application to specify the = hash algorithm for its particular usage. >=20 > This isn't as bad as you might think, however, because typically the = consumer of the "kid" doesn't need to know the algorithm because it = won't be reproducing the computation. It just relies on the fact that a = unique key ID value was generated for the key and compares "kid" values = as opaque strings to find the appropriate key. In this usage, the = producer of the key is the only party that needs to know the hash = algorithm that it is using. I hope this helps. Yes, this does help, thank you. It seems like something that could be = easily added to the draft to explain why the generating algorithm = needn=E2=80=99t be disclosed so that slow folk like myself get the = picture straight away. >=20 >> Additionally, in Section 4, =E2=80=9CJSON and Unicode = Considerations=E2=80=9D some =E2=80=9Cshould=E2=80=9Ds are used, but = I=E2=80=99m not reading them as SHOULDs. Should they be SHOULDs? For = example, the start of the third paragraph in that section: =E2=80=9Cif = new JWK members are defined that use non-ASCII member names, their = definitions should specify the exact Unicode code point sequences used = to represent them.=E2=80=9D It=E2=80=99s not clear to me whether this = is a strong statement or just a recommendation - it seems that this = draft could help the future by making stronger statements to encourage = future interoperability. >=20 > For the other JOSE specifications, our chair Jim Schaad took the = position that RFC 2119 keywords should be reserved for testable protocol = behaviors and that other uses of the English word "should" should not = use "SHOULD". The authors followed that convention in this document. I = do understand that other authors and working groups have taken different = positions in this regard. If there are particular uses that you still = feel should be changed to use RFC 2119 keywords, please call them out. This is all good, too. I was simply pointing out that there are = =E2=80=9Cshould=E2=80=9Ds around that may need to be considered as = =E2=80=9CSHOULD=E2=80=9Ds. I also see Jim=E2=80=99s (and others=E2=80=99) = subsequent notes on the subject, so this is good from my perspective. >=20 >> Kind regards, >> Adam >=20 > Thanks again! > -- Mike --Apple-Mail=_DFB11325-054C-4A8B-97FC-DD6F100E5B08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 11, 2015, at 4:25 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Hi Adam,

Thanks for the secdir review.

From: Adam W. Montville = [mailto:adam.w.montville@gmail.com]
Sent: = Monday, June 08, 2015 8:46 AM
To: The IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org
Subject: sector review of = draft-ietf-jose-jwk-thumbprint-05

Hi,

I have reviewed this document as part of the security = directorate's ongoing effort to review all IETF documents being = processed by the IESG. These comments were written primarily for the = benefit of the security area directors. Document editors and WG chairs = should treat these comments just like any other last call comments.

I believe the document is ready with = (potential) issues.  The =E2=80=9Cwith issues=E2=80=9D might be due = to ignorance on my part.  The draft does a very good job of = explaining the canonical form of a JSON Web Key that can be used for = establishing a thumbprint under varying circumstances, complete with = what I found to be helpful examples.

The = primary issue I have is that it=E2=80=99s unclear how relying parties = are going to know which hash algorithm has been used.  The examples = use SHA-256, but I=E2=80=99m not seeing where SHA-256 might be specified = as a MUST or even a SHOULD.  Moreover, the example output = ultimately shows only the Base-64 encoding of the resulting hash, which = says nothing about the algorithm used to identify a key.

Earlier drafts had = included fields whose names were intended to communicate the information = about the hash function used - see the "jkt" field definitions in http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-01#se= ction-4 - but several working group = reviewers suggested that these fields were unnecessary and that the = typical usage would be as "kid" (key ID) field values.  With that = removal, it falls onto the application to specify the hash algorithm for = its particular usage.

This isn't as bad as you = might think, however, because typically the consumer of the "kid" = doesn't need to know the algorithm because it won't be reproducing the = computation.  It just relies on the fact that a unique key ID value = was generated for the key and compares "kid" values as opaque strings to = find the appropriate key.  In this usage, the producer of the key = is the only party that needs to know the hash algorithm that it is = using.  I hope this helps.

Yes, this does help, thank you.  It seems = like something that could be easily added to the draft to explain why = the generating algorithm needn=E2=80=99t be disclosed so that slow folk = like myself get the picture straight away.



Additionally, in Section 4, =E2=80=9CJSON and Unicode = Considerations=E2=80=9D some =E2=80=9Cshould=E2=80=9Ds are used, but = I=E2=80=99m not reading them as SHOULDs. Should they be SHOULDs? =  For example, the start of the third paragraph in that section: = =E2=80=9Cif new JWK members are defined that use non-ASCII member names, = their definitions should specify the exact Unicode code point sequences = used to represent them.=E2=80=9D  It=E2=80=99s not clear to me = whether this is a strong statement or just a recommendation - it seems = that this draft could help the future by making stronger statements to = encourage future interoperability.

For the other JOSE specifications, our chair Jim = Schaad took the position that RFC 2119 keywords should be reserved for = testable protocol behaviors and that other uses of the English word = "should" should not use "SHOULD".  The authors followed that = convention in this document.  I do understand that other authors = and working groups have taken different positions in this regard. =  If there are particular uses that you still feel should be changed = to use RFC 2119 keywords, please call them out.

This is all = good, too.  I was simply pointing out that there are =E2=80=9Cshould=E2= =80=9Ds around that may need to be considered as =E2=80=9CSHOULD=E2=80=9Ds= . I also see Jim=E2=80=99s (and others=E2=80=99) subsequent notes on the = subject, so this is good from my perspective.


Kind regards,
Adam

= = = Thanks again!
= = = = -- = Mike

= --Apple-Mail=_DFB11325-054C-4A8B-97FC-DD6F100E5B08--