Subject: Re: [jose] draft-ietf-jose-jwk-thumbprint-00 comments

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Jan 2015 14:53:04 -0800

> -----Original Message-----
> From: Mike Jones [mailto:[email-masked]]
> Sent: Monday, January 19, 2015 1:00 PM
> To: Jim Schaad; [email-masked]
> 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-masked]]
> > Sent: Saturday, December 06, 2014 11:56 AM
> > To: [email-masked]
> > 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

---

From: Mike Jones <[email-masked]>
Date: Thu, 22 Jan 2015 22:32:29 +0000

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

> Sent: Monday, January 19, 2015 2:53 PM
> To: Mike Jones; [email-masked]
> Cc: 'Nat Sakimura'; [email-masked]
> > Thumbprints in
> > http://tools.ietf.org/html/draft-ietf-jose-jwk-thumbprint-
> > 00#section-4.4.
> 
> > > 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
> > > 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.
> >
> > 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
> >
> > > converted to a JWK structure and then the thumbprint computed.  
> > > That makes more sense that what is written here.
> >
> > is supported in
> > http://tools.ietf.org/html/draft-ietf-jose-json-web-key-
> > 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.

> So the first paragraph might not be correct.

I added a note saying that JSON.stringify() doesn't perform the sorting.

> > > 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
> > 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 -
> 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.

> > > 12.  I would suggest not specifying the hash explicitly except 
> > > where the discussion is of jkt rather than general description.
> >