Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05

"Adam W. Montville" <adam.w.montville@gmail.com> Fri, 12 June 2015 12:06 UTC

Return-Path: <adam.w.montville@gmail.com>
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" <adam.w.montville@gmail.com>
In-Reply-To: <BY2PR03MB442BD780448D808BA10D657F5BC0@BY2PR03MB442.namprd03.prod.outlook.com>
Date: Fri, 12 Jun 2015 07:06:30 -0500
Message-Id: <4CA0A65D-E5FD-408C-A6B9-6ECB12A81B7C@gmail.com>
References: <A1BD2DB0-A7D9-4635-8A3B-074303AF2E55@gmail.com> <BY2PR03MB442BD780448D808BA10D657F5BC0@BY2PR03MB442.namprd03.prod.outlook.com>
To: Mike Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/7wonszBlyd-aEH7krocGhNwtN4o>
Cc: "draft-ietf-jose-jwk-thumbprint.all@ietf.org" <draft-ietf-jose-jwk-thumbprint.all@ietf.org>, The IESG <iesg@ietf.org>, "jose@ietf.org" <jose@ietf.org>, "secdir@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 <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2015 12:06:36 -0000

> 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 “with issues” 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’s unclear how relying parties are going to know which hash algorithm has been used.  The examples use SHA-256, but I’m 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#section-4 <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.
> 
> 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’t be disclosed so that slow folk like myself get the picture straight away.


> 
>> Additionally, in Section 4, “JSON and Unicode Considerations” some “should”s are used, but I’m not reading them as SHOULDs. Should they be SHOULDs?  For example, the start of the third paragraph in that section: “if 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.”  It’s 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 “should”s around that may need to be considered as “SHOULD”s. I also see Jim’s (and others’) subsequent notes on the subject, so this is good from my perspective.

> 
>> Kind regards,
>> Adam
> 
> 				Thanks again!
> 				-- Mike