Thanks again for the feedback, Jim. Draft -03 incorporates changes intended to address these points. Further replies are inline...
> -----Original Message----- > From: jose [mailto:[email protected]] On Behalf Of Jim Schaad > Sent: Friday, February 20, 2015 12:19 PM > To: [email protected] > Cc: [email protected] > Subject: [jose] Comments on draft-ietf-jose-jwk-thumbprint-02 > > 1. I expected to see the abstract and the introduction modified to compare > this to taking the hash of an X.509 Subject Public Key Info structure rather > than > keeping the current comparison to a certificate. That is a more correct > comparison. Done - plus see the new section http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-03#section-7 comparing JWK Thumbprints to digests of X.509 values. > 2. I did miss in my last message summarizing the last call the question of > keeping or removing symmetric keys. I don't remember what your final > position was on this. Please verify for me. They were kept, since thumbprints are good ways of computing Key ID values and Key IDs are sometimes used with symmetric keys. The following security considerations text was also added in response to the original discussion on this topic: A hash of a symmetric key has the potential to leak information about the key value. Thus, the JWK Thumbprint of a symmetric key should be typically be concealed from parties not in possession of the symmetric key, unless in the application context, the cryptographic hash used, such as SHA-256, is known to provide sufficient protection against disclosure of the key value. > 3. In section 3.2.2 - the first optional should not be in all upper case. > It should match the capitalization that is in the title for the section. > This location does not imply a protocol requirement. Done > 4. In section 3.3 - ditto item 3 on the world REQURED, you are not making > protocol statements here so lower case is more appropriate. Done > 5. In section 3.3 - in paragraph two - s/as the REQURED members/as the > members/ - it is not expected to be true for optional members either. Done > 6. In section 4 - I think that the statement that stringify would be used for > emitting the JSON object to be used for hash input is false. This paragraph > needs > to be updated to reflect consistency. Saying in the first sentence - use > stringify > and in the last sentence don't use stringify is not helpful. The inconsistent text was removed. > 7. Please explain why you think the following references are normative: > JWE, SHS JWE was not normative and was removed. SHS is normative, since it's where SHA-256 is defined. Thanks again, -- Nat & Mike _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
