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 501031A8A0E; Wed, 24 Jun 2015 05:12:06 -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 cNvex3SgnfBR; Wed, 24 Jun 2015 05:12:03 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 EBFE71A89FB; Wed, 24 Jun 2015 05:12:02 -0700 (PDT) Received: by oiax193 with SMTP id x193so28247723oia.2; Wed, 24 Jun 2015 05:12:02 -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=lo6xcEmpXTUKrVG8yN5UGZWH+K8fTeZGFlClQwBh+kY=; b=CZZJX+DB1JPiskbev95o6Ceojj6W9pPEFYV97Op/W8kAgwTEGFxHrRR/IHJ22/zyKC 7KF8lqVfE3SGHSIPnokXCZ9W885JOCvWTUIB/dlJC0/VuNW+D5YeE1dVMU1au1zuqx0Q njaCHCaxw4kqtvgaElILT2AKulMNUs6APngjDeyZSQb9IBbceJBcB5Z7rr3hWwlSpWLU d8/Yp0c09HVQoRGFWe2G2zkMV/SfmSegE9wlsYdfGD409dSTAHbsX/KUrT/J97GPd93N Mu3N1P/bV5Dt36lWxfEAPiICQjF8UmgtHaVv1rB3hqeBiclZ1ty2zvMJiMiUF36DiCQ0 F0bQ== X-Received: by 10.202.87.134 with SMTP id l128mr8591043oib.83.1435147922407; Wed, 24 Jun 2015 05:12:02 -0700 (PDT) Received: from adams-mac-mini.attlocal.net ([2602:306:3406:4830:b059:3770:4dda:970e]) by mx.google.com with ESMTPSA id k129sm14032408oia.14.2015.06.24.05.11.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jun 2015 05:12:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AFF50B74-E35C-4317-9037-F9F5CA66C996" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: "Adam W. Montville" In-Reply-To: Date: Wed, 24 Jun 2015 07:11:58 -0500 Message-Id: References: <4CA0A65D-E5FD-408C-A6B9-6ECB12A81B7C@gmail.com> 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: Wed, 24 Jun 2015 12:12:06 -0000 --Apple-Mail=_AFF50B74-E35C-4317-9037-F9F5CA66C996 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Nat and Mike, Thanks for your attention on this issue. I see the following text in = section 3.4: Note that in many cases, only the party that creates a key will need to know the hash function used. A typical usage is for the producer of the key to use the base64url-encoded JWK Thumbprint value as a "kid" (key ID) value. The consumer of the "kid" treats it as an opaque value that it uses to select the key. Only if multiple parties will be reproducing the JWK Thumbprint calculation for some reason, will parties other than the original producer of the JWK Thumbprint need to know which hash function was used. Would it make the draft clearer if that last sentence were omitted? The = way this paragraph reads is such that draft considers and would allow = for multiple parties generating key IDs, but then we=E2=80=99re back at = not knowing which algorithm was chosen. If that last sentence were = omitted, this would be less of an issue. =20 > On Jun 24, 2015, at 3:40 AM, Mike Jones = wrote: >=20 > Hi Adam, > =20 > Thanks again for your review comments. = https://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-06 = has been = posted to address them. See sections 3.4 (Selection of Hash Function) = and 6 (IANA Considerations). > =20 > Thanks = again, > -- Nat and = Mike > =20 > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 > Sent: Monday, June 22, 2015 12:51 PM > To: Mike Jones > Cc: Adam W. Montville; The IESG; secdir@ietf.org; = draft-ietf-jose-jwk-thumbprint.all@ietf.org; jose@ietf.org > Subject: Re: sector review of draft-ietf-jose-jwk-thumbprint-05 > =20 > Yes, thank you. > Kathleen=20 >=20 > Sent from my iPhone >=20 > On Jun 22, 2015, at 9:18 PM, Mike Jones > wrote: >=20 > I=E2=80=99d be glad to add the explanation below to the draft and to = also include an IANA considerations section that states we are updating = the expert review instructions for a registry, as Jim Schaad had = suggested. Chairs and Kathleen, do you want Nat and I to proceed to = publish an updated draft? > =20 > -- = Mike > =20 > From: Adam W. Montville [mailto:adam.w.montville@gmail.com = ]=20 > Sent: Friday, June 12, 2015 5:07 AM > To: Mike Jones > Cc: The IESG; secdir@ietf.org ; = draft-ietf-jose-jwk-thumbprint.all@ietf.org = ; jose@ietf.org = > Subject: Re: sector review of draft-ietf-jose-jwk-thumbprint-05 > =20 > =20 > On Jun 11, 2015, at 4:25 PM, Mike Jones > wrote: > =20 > Hi Adam, >=20 > Thanks for the secdir review. >=20 >=20 >=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 >=20 >=20 > Hi, >=20 >=20 >=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=9Cw= ith 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. > =20 > 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 >=20 >=20 >=20 >=20 >=20 >=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. > =20 > 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 >=20 >=20 >=20 >=20 >=20 > Kind regards, > Adam >=20 > Thanks = again! > -- = Mike --Apple-Mail=_AFF50B74-E35C-4317-9037-F9F5CA66C996 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Nat and Mike,

Thanks for your attention on this issue.  I see the = following text in section 3.4:

Note that in many = cases, only the party that creates a key will need
   to know the hash function used.  A typical = usage is for the producer
   of the key = to use the base64url-encoded JWK Thumbprint value as a
   "kid" (key ID) value.  The consumer of the = "kid" treats it as an
   opaque value = that it uses to select the key.  Only if multiple
   parties will be reproducing the JWK Thumbprint = calculation for some
   reason, will = parties other than the original producer of the JWK
   Thumbprint need to know which hash function was = used.


Would it make the draft clearer if that = last sentence were omitted?  The way this paragraph reads is such = that draft considers and would allow for multiple parties generating key = IDs, but then we=E2=80=99re back at not knowing which algorithm was = chosen.  If that last sentence were omitted, this would be less of = an issue.  


On Jun 24, 2015, at 3:40 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Hi Adam,
 
Thanks again for your = review comments.  https://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-06 has been posted to = address them.  See sections 3.4 (Selection of Hash Function) and 6 = (IANA Considerations).
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = Thanks again,
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            -- = Nat and Mike
From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] 
Sent: Monday, June 22, 2015 12:51 = PM
To: Mike Jones
Cc: Adam = W. Montville; The IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org; jose@ietf.org
Subject: Re: sector review of = draft-ietf-jose-jwk-thumbprint-05
 
Yes, thank you.
Kathleen 

Sent from my = iPhone


On Jun 22, 2015, = at 9:18 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99d be glad to = add the explanation below to the draft and to also include an IANA = considerations section that states we are updating the expert review = instructions for a registry, as Jim Schaad had suggested.  Chairs = and Kathleen, do you want Nat and I to proceed to publish an updated = draft?
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: Adam W. = Montville [mailto:adam.w.montville@gmail.com] 
Sent: Friday, June 12, 2015 5:07 = AM
To: Mike Jones
Cc: The = IESG; secdir@ietf.org; draft-ietf-jose-jwk-thumbprint.all@ietf.org; jose@ietf.org
Subject: Re: sector review of = draft-ietf-jose-jwk-thumbprint-05
 
 
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

        &= nbsp;       =             &n= bsp;   =             &n= bsp;   =             &n= bsp;   Thanks again!
        &= nbsp;       =             &n= bsp;   =             &n= bsp;   =             &n= bsp;   -- = Mike
<= /div>
= --Apple-Mail=_AFF50B74-E35C-4317-9037-F9F5CA66C996--