Re: [jose] JWK Thumbprint spec incorporating feedback from IETF 90

[Mike Jones <[e-mail]>]

Thanks for the useful review, James. A few comments...

Why do you write "there can be alternative representations for a given mathematical key, each giving a different thumbprint"? Do you have an example?

You'll note that JWA 6.2.1, 6.3.1, and 6.4 do already say which members are required, so there's no need to repeat this info in the registry.  I will add text saying that optional members such as "use" are never used in the thumbprint, even if required for some applications.

As for why the "kty" registry is where it is, that's because the "kty" values such as "RSA" are defined there - since they're algorithm specific.

-- Mike
________________________________
From: Manger, James<mailto:[e-mail]>
Sent: ‎7/‎25/‎2014 3:48 AM
To: Mike Jones<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [jose] JWK Thumbprint spec incorporating feedback from IETF 90

Mike,

> http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-01

These JWK thumbprint changes are ok (saying anything “unusual” is undefined, to avoid defining canonical JSON).

However, the more important issues have not been addressed.
See my earlier comments http://www.ietf.org/mail-archive/web/jose/current/msg04054.html

Are JWK thumbprints suitable to use on a blacklist of revoked keys? Almost certainly not. The spec needs to be much clearer about when  it is and isn’t suitable to use these thumbprints.

SUGGESTION: Add this introductory text.

  A JWK thumbprint is a short label that unambiguously identifies a single mathematical key. When a thumbprint from another party matches a thumbprint you have, it is safe to assume the other party is referring to the same mathematical key as you. A matching thumbprint does not indicate that the other party has the same metadata about the key (eg algorithms, key-id, etc).

  When thumbprints do not match, it does not guarantee that different keys are being referenced as there can be alternative representations for a given mathematical key, each giving a different thumbprint. Consequently, a list of thumbprints is not a suitable way represent a blacklist of revoked keys, for instance.

SUGGESTION: Add a paragraph to the Security Considerations section warning against using JWK thumbprints in a blacklist.

  (perhaps based on the 2nd paragraph from the suggestion above)



The thumbprint spec say only REQUIRED fields are included in a thumbprint. The JWK spec says:
  “Use of the "use" member is OPTIONAL, unless the application requires its presence.”
I hope this doesn’t imply that “use” is sometimes omitted from the thumbprint, but sometimes included in the thumbprint because some applications require its presence.


Since you need special knowledge for each specific “kty” value to calculate a thumbprint (ie the fields to include for that “kty” value), it would be better to require each definition of a new “kty” value to explicitly list its thumbprint fields.

SUGGESTION: Modify the JSON Key Types Registry [JWA, section 7.4] to include a “Thumbprint fields” item. Modify draft-jones-jose-jwk-thumbprint to refer to this item, instead of REQUIRED fields.

  Thumbprint fields:
    List of fields (in addition to “kty”) that are included when calculating a
    thumbprint for a key with this “kty” value.

   o  "kty" Parameter Value: "EC"
   o  Thumbprint fields: "crv", "x", "y"

   o  "kty" Parameter Value: "RSA"
   o  Thumbprint fields: "e", "n"

   o  "kty" Parameter Value: "oct"
   o  Thumbprint fields: "k"


It is strange to define JWK in one spec, but establish a registry for type of JWKs in a different spec [JWA].
SUGGESTION: Move JWA sections 7.4 and 7.4.1 to the JWK spec.

--
James Manger

From: jose [mailto:[e-mail]] On Behalf Of Mike Jones
Sent: Thursday, 24 July 2014 1:13 AM
To: [e-mail]
Subject: [jose] JWK Thumbprint spec incorporating feedback from IETF 90

I’ve updated the JSON Web Key (JWK) Thumbprint specification to incorporate the JOSE working group feedback on the -00 draft from IETF 90<http://www.ietf.org/meeting/90/>.  The two changes were:

·         Said that the result is undefined if characters requiring escaping are needed in the hash input.

·         Added instructions for representing integer numeric values in the hash input.

If a canonical JSON representation standard is ever adopted, this specification could be revised to use it, resulting in unambiguous definitions for those values (which are unlikely to ever occur in JWKs) as well.  (Defining a complete canonical JSON representation is very much out of scope for this work!)

The specification is available at:

·         http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-01