Hi Adam,
Thanks again for your review comments.
https://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-06 has been posted
to address them. See sections 3.4 (Selection of Hash Function) and 6 (IANA
Considerations).
Thanks again,
-- Nat and Mike
From: Kathleen Moriarty [mailto:[email protected]]
Sent: Monday, June 22, 2015 12:51 PM
To: Mike Jones
Cc: Adam W. Montville; The IESG; [email protected];
[email protected]; [email protected]
Subject: Re: sector review of draft-ietf-jose-jwk-thumbprint-05
Yes, thank you.
Kathleen
Sent from my iPhone
On Jun 22, 2015, at 9:18 PM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
I’d be glad to add the explanation below to the draft and to also include an
IANA considerations section that states we are updating the expert review
instructions for a registry, as Jim Schaad had suggested. Chairs and Kathleen,
do you want Nat and I to proceed to publish an updated draft?
-- Mike
From: Adam W. Montville [mailto:[email protected]]
Sent: Friday, June 12, 2015 5:07 AM
To: Mike Jones
Cc: The IESG; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: Re: sector review of draft-ietf-jose-jwk-thumbprint-05
On Jun 11, 2015, at 4:25 PM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
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]<mailto:[email protected]>;
[email protected]<mailto:[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.
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
