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

"Adam W. Montville" <adam.w.montville@gmail.com> Mon, 08 June 2015 15:47 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 3F8CF1B2F87; Mon, 8 Jun 2015 08:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tK1oM0UBbjnz; Mon, 8 Jun 2015 08:46:59 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 F00871B2F73; Mon, 8 Jun 2015 08:46:31 -0700 (PDT)
Received: by oigz2 with SMTP id z2so32745638oig.1; Mon, 08 Jun 2015 08:46:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=wysmFZRSRrr97qDayB6EZE12aQsG7Jqtib4dNPbzBFs=; b=PGEW7PPU1CVKwoDrf2CMPcm6hnM3G1mCuSPH2T9WpvFxra6nl7Ffbafd40+3PMfnA3 8dcIIhGAattfNLwIVfJYJesn7z3hYta9dTKNyLn3HKhLN0YBVDO8FLkQOryDT2R6yvZD ekUEEfZOKOxUwY8HcMDS1NlCOzFGRVeZdGjxa1bmOmP2BCI9ZQcmV0Bin6L4IdCBh+C4 oOotCg+r2fCIQyLuTnQ9KpCswyKXUYQJpscvoOY7wa5YI5pQzoV/yHdMaeaHiMIK1KJJ 09fxvJyffm5aTIt5xTDKjq+ZKy0qYp2QAdJXTcwzZvzJVVnk5vlXYQ5YbLvcZ0ZlzHv6 +8nQ==
X-Received: by with SMTP id l141mr11865531oig.89.1433778391344; Mon, 08 Jun 2015 08:46:31 -0700 (PDT)
Received: from adams-mac-mini.attlocal.net ([2602:306:3406:4830:693d:fac2:3df1:e032]) by mx.google.com with ESMTPSA id sm8sm2003006obb.13.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jun 2015 08:46:30 -0700 (PDT)
From: "Adam W. Montville" <adam.w.montville@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1BD2DB0-A7D9-4635-8A3B-074303AF2E55@gmail.com>
Date: Mon, 8 Jun 2015 10:46:29 -0500
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-jose-jwk-thumbprint.all@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/I5QhkbwEWPcouO1yXjOR0tKrsGQ>
Subject: [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: Mon, 08 Jun 2015 15:47:05 -0000


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.

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.

Kind regards,