From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Mike Jones'" <Michael.Jones@microsoft.com>,
 "'Adam W. Montville'" <adam.w.montville@gmail.com>,
 "'The IESG'" <iesg@ietf.org>, <secdir@ietf.org>,
 <draft-ietf-jose-jwk-thumbprint.all@ietf.org>
References: <A1BD2DB0-A7D9-4635-8A3B-074303AF2E55@gmail.com>
 <BY2PR03MB442BD780448D808BA10D657F5BC0@BY2PR03MB442.namprd03.prod.outlook.com>
In-Reply-To: <BY2PR03MB442BD780448D808BA10D657F5BC0@BY2PR03MB442.namprd03.prod.outlook.com>
Date: Thu, 11 Jun 2015 15:35:40 -0700
Message-ID: <003d01d0a496$f2ee7d70$d8cb7850$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQH/CRWIcZSXbJbM2kM+qRSrEj4cCAIc57yonTo0IvA=
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/P0WKJIcckKwtvIL4EDFD4Op-98o>
Cc: jose@ietf.org
Subject: Re: [secdir] sector review of draft-ietf-jose-jwk-thumbprint-05
Precedence: list



> -----Original Message-----
> From: Mike Jones [mailto:Michael.Jones@microsoft.com]
> Sent: Thursday, June 11, 2015 2:25 PM
> To: Adam W. Montville; The IESG; secdir@ietf.org; draft-ietf-jose-jwk-
> thumbprint.all@ietf.org
> Cc: jose@ietf.org
> Subject: RE: sector review of draft-ietf-jose-jwk-thumbprint-05
>=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.
> >
> > 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.
>=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
> > 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.

If we really wanted to make sure that the recommendation was followed, =
then it would make sense to adjust the IANA reviewers instructions for =
the registry.  Putting a SHOULD or a MUST in this document would not =
have any effect since it does not define a protocol and might not be =
seen by anybody defining a new header field.

Jim

>=20
> > Kind regards,
> > Adam
>=20
> 				Thanks again!
> 				-- Mike