Thanks again for the useful-as-always comments, Jim. The comments are
addressed in the -01 draft. Also see a few replies inline below.
Best wishes,
-- Mike
> -----Original Message-----
> From: Jim Schaad [mailto:[email protected]]
> Sent: Monday, January 19, 2015 2:53 PM
> To: Mike Jones; [email protected]
> Cc: 'Nat Sakimura'; [email protected]
> Subject: RE: draft-ietf-jose-jwk-thumbprint-00 comments
>
>
>
> > -----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
I think the use cases are more similar than you're thinking of them as. The
x5t *is* a pointer to self, in that it's pointing to the x5c in the same
structure. And for what it's worth, actually Microsoft's production uses of
x5c in JWKs that I'm aware of always do also include x5t.
> > > 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.
I added a note saying that JSON.stringify() doesn't perform the sorting.
> > > 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.
I added a note about the effective integer range, citing the I-JSON spec.
> > > 10. You need to address the security concerns of hashing the
> > > private portion of a symmetric key.
> >
> > Good point.
I added a Security Considerations paragraph about this.
> > > 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
