The registration instructions don't appear to be stored with the registry at
http://www.iana.org/assignments/jose/jose.xhtml. The closest there is there is
the Reference field, which specifies [RFC7515], which I assume is how the
designated experts are expected to retrieve the instructions.
Does anyone on the thread know if it's possible to add a copy of the
registration instructions in the registry itself? If so, then we'd have a
mechanism by which we could update them, as Jim suggested.
-- Mike
-----Original Message-----
From: Jim Schaad [mailto:[email protected]]
Sent: Thursday, June 11, 2015 3:36 PM
To: Mike Jones; 'Adam W. Montville'; 'The IESG'; [email protected];
[email protected]
Cc: [email protected]
Subject: RE: sector review of draft-ietf-jose-jwk-thumbprint-05
> -----Original Message-----
> From: Mike Jones [mailto:[email protected]]
> Sent: Thursday, June 11, 2015 2:25 PM
> To: Adam W. Montville; The IESG; [email protected]; draft-ietf-jose-jwk-
> [email protected]
> Cc: [email protected]
> Subject: RE: sector review of draft-ietf-jose-jwk-thumbprint-05
>
> Hi Adam,
>
> Thanks for the secdir review.
>
> > From: Adam W. Montville [mailto:[email protected]]
> > Sent: Monday, June 08, 2015 8:46 AM
> > To: The IESG; [email protected];
> > [email protected]
> > 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
> - 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.
>
> > 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.
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
>
> > Kind regards,
> > Adam
>
> Thanks again!
> -- Mike
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
