> -----Original Message----- > From: Mike Jones [mailto:[email protected]] > Sent: Monday, January 19, 2015 1:00 PM > To: Jim Schaad; [email protected] > Cc: Nat Sakimura > Subject: RE: draft-ietf-jose-jwk-thumbprint-00 comments > > [Adding Nat to the thread, who has agreed to be co-editor] > > Thanks for the details and useful comments, Jim, as always! > > > -----Original Message----- > > From: Jim Schaad [mailto:[email protected]] > > Sent: Saturday, December 06, 2014 11:56 AM > > To: [email protected] > > Subject: draft-ietf-jose-jwk-thumbprint-00 comments > > > > A round of comments on the draft before last call > > > > 1. Is the term JWK Thumbprint really going to be tied to a specific hash > > algorithm? You should re-write this definition so that it is not specific > > to a single hash algorithm. > > The definition "JWK Thumbprint" in http://tools.ietf.org/html/draft-ietf-jose- > jwk-thumbprint-00#section-2 is not algorithm-specific. It is: > The digest value for a key that is the subject of this specification. > > The computation of the particular value, of course, is algorithm-specific. Just > like the other JOSE drafts, different identifiers would be used for computations > using different algorithms. We talk about the use of other algorithms for JWK > Thumbprints in http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint- > 00#section-4.4.
In section 3- "Specifically, this function is the SHA-256 hash" In section 3.3 - "the SHA-256 hash function" Except for the example, it should not show up until section 4. > > I'll go through the doc and try to ensure that the generic term JWK Thumbprint > is hash-function agnostic, with only the field name definitions specifying the > particular hash function. > > > 2. In section 3: the term "JWK value" does not match up with > > anything in the JWK spec. I think you can just remove value. > > OK > > > 3. In Section 3.2.1 - I need to see some justification to every do a > > thumbprint of a private key set rather than a public key set. I don't see > > any benefit for having this section in the document. > > The justification of defining the computation on private keys is interoperability. > If we don't define this, different parties are likely to do the computation in > different ways - some including the private key values and some using only the > public key values. We can say something to this effect in the next draft. That requires a single sentence in the previous section to say not a separate section. > > > 4. In section 3.2.2 - I don't see a justification in this section, just > > that we aren't going to do it. Specifically there is no discussion of the > > security problems of not hashing the associated data. The way this is > > defined is more analogous to computing the hash of a SPKI structure > > than of an X.509 certificate. There is a lot of data that has > > security properties that is not included in the thumbprint thus > > allowing for potential attack vectors by an attacker changing the JWK > structure in such a way as is not detectable. > > > > You may believe that there are not problems, there is at least one > > person who does - so the issue needs to be addressed - even it is just > > a discussion on why this is not a problem in the authors opinion. > > The justification already in the draft is "so that their absence or presence in the > JWK doesn't alter the resulting value". We can add Security Considerations text > on what JWK Thumbprints do and don't do because they include on the key > value but not key attributes. No that is not a justification, that is how it is implemented. If you do a thumbprint on a certificate it will be different if the extensions are different. You are comparing this to a thumbprint on a certificate not a thumbprint on a public key. I am willing to assume that you have a reason for not including these fields other than the fact that "it is easier" but that needs to be stated. This is the correct place to state that justification. The justification needs to be along the lines of "We do not include the other key parameters defined in JWK key computation because it is felt that this information is not significant for enforcement purposes. The presence or absence of these key parameters is not a security property of the key." > > > 5. In section 3.4 - I would not use the term "any keys" but rather > > "keys not in JWK format. > > OK > > > 6. Section 3.4 - I would re-write this as saying, the key can be > > converted to a JWK structure and then the thumbprint computed. That > > makes more sense that what is written here. > > How about we change "These are sufficient to create the hash input" to "These > are sufficient to create the hash input from the JWK representation of the key"? Its better. > > > 7. Section 4 - what is the use case for putting a jkt member in a JWK > > object? What are the security implications of using a jkt value that is > > given to you rather than computed by in this case? > > They are the same as the use case for putting a "x5t" member in a JWK (which > is supported in http://tools.ietf.org/html/draft-ietf-jose-json-web-key- > 41#section-4.8). It's for the convenience of the recipient. Do you want us to > add some Security Considerations text saying that it is context-dependent > whether an application needs to verify that the "x5t" value in the JWK was > correctly computed from the other members of the JWK? (We didn't do that > for the "x5t" member in the JWK spec itself - we just relied on the "MUST".) No it is not the same use case. Putting an x5t parameter into a JWK is a pointer to another structure - the certificate. It would only be a potential problem if you had both the x5t and x5c element, which is not really likely. Putting a jkt parameter into a structure is like putting a pointer to yourself in the structure. This type of usage is what kid is for > > > 8.Section 5- so does the JSON.stringify() give the correct answer? > > The example at http://msdn.microsoft.com/en- > us/library/ie/cc836459(v=vs.94).aspx suggests "no", since the strings are not > lexicographically sorted. So the first paragraph might not be correct. > > > 9. Section 5 - I don't understand how the last paragraph applies to > > anything. If the value cannot survive a round trip read/write operation > > so that I can construct the structure that is going to be hashed then > > you are dead in all cases. If it is not completely consistent then it > > is not going to hash correctly for comparison purposes. > > The advice is to other spec writers about how to avoid non-round-trippable > values. For instance, the advice "future JWK member names should be avoided > for which different platforms or libraries might emit different representations" > in paragraph 1 and the suggestion to restrict member names to ASCII in > paragraph 2. Postel's law applies in this case to writers of JWK extensions - > reminding them to be conservative in what they specify. This seems to be the wrong document for that. This advice should have been in JWK not here. However even numbers which do not contain fraction parts may be emitted in some other form than whole numbers so that seems problematical in any event. Some integers do not have a representation that is exact. > > > 10. You need to address the security concerns of hashing the private > > portion of a symmetric key. > > Good point. > > > 11. You have the wrong description in section 4.4 for the proposed tag. > > Good catch. This will be changed to "(JWK Thumbprint using SHA-3-256) ". > > > 12. I would suggest not specifying the hash explicitly except where > > the discussion is of jkt rather than general description. > > This seems closely related to your point 1. I'll go through the doc and try to > ensure that the generic term JWK Thumbprint is hash-function agnostic, with > only the field name definitions specifying the particular hash function. > > > Jim > > Thanks for taking the time to write these useful comments, Jim! > > -- Mike _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
