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 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-Level: 
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 ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.202.212.147 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.06.08.08.46.29
 (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

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=9Cwit=
h 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.

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.

Kind regards,

Adam=

