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

["Manger, James" <[e-mail]>]

Mike,

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

How about these 3 examples?
The 1st version is the "proper" representation.
The 2nd version has an unnecessary leading 0 byte on "e". The maths still works. It disobeys JWA-31 6.3.1.2 "MUST utilize the minimum number of octets", but my guess is that almost nothing will check that when receiving a key. It isn't clear if such a MUST is supposed to apply to receivers or only key generators.
The 3rd version has "n" that is twice the proper value (eg 2 * fFe2... = -K9s...). It will work about half the time, which is sufficient for an attacker.

{"e":"AQAB","kty":"RSA","n":"fFe2QIXxQ-3-CpRZVoAhD9XKB4WUkN5VjoGfuEz-fbsa4IG7OFEyDti_ZoiC6XR1eW3sg3scVOprxxJ_cs94eO_yfWOO4CHq0aDjsmg3F77IIHSZ3_M7WsWlnzo-IwILfRK_0Jsq4KdblUnyNgSBP_as9CoTQXPtveTev1HuLFfa_gKiavHoGfx1W-nnrbrd3WIfa_sZ1X92Ur9DuLLXwsiy6SXc9cm4DxsnUQ-PQCWIDP1Wg-jWGBQuGbzrz1TnvDftKMZ0f4WFRGRa2EZnFhdhNrwVDy1XXMr2iMyjtjCRrnZnDaBjggLplK8gLklDakY7bn6yguhkyEdeVfraXw"}

{"e":"AAEAAQ","kty":"RSA","n":"fFe2QIXxQ-3-CpRZVoAhD9XKB4WUkN5VjoGfuEz-fbsa4IG7OFEyDti_ZoiC6XR1eW3sg3scVOprxxJ_cs94eO_yfWOO4CHq0aDjsmg3F77IIHSZ3_M7WsWlnzo-IwILfRK_0Jsq4KdblUnyNgSBP_as9CoTQXPtveTev1HuLFfa_gKiavHoGfx1W-nnrbrd3WIfa_sZ1X92Ur9DuLLXwsiy6SXc9cm4DxsnUQ-PQCWIDP1Wg-jWGBQuGbzrz1TnvDftKMZ0f4WFRGRa2EZnFhdhNrwVDy1XXMr2iMyjtjCRrnZnDaBjggLplK8gLklDakY7bn6yguhkyEdeVfraXw"}

{"e":"AQAB","kty":"RSA","n":"-K9sgQvih9v8FSiyrQBCH6uUDwspIbyrHQM_cJn8-3Y1wQN2cKJkHbF-zREF0ujq8tvZBvY4qdTXjiT-5Z7w8d_k-scdwEPVo0HHZNBuL32QQOkzv-Z2tYtLPnR8RgQW-iV_oTZVwU63KpPkbAkCf-1Z6FQmgufbe8m9fqPcWK-1_AVE1ePQM_jqt9PPW3W7usQ-1_Yzqv7spX6HcWWvhZFl0ku565NwHjZOoh8egEsQGfqtB9GsMChcM3nXnqnPeG_aUYzo_wsKiMi1sIzOLC7CbXgqHlquuZXtEZlHbGEjXOzOG0DHBAXTKV5AXJKG1Ix23P1lBdDJkI68q_W0vg"}


The point is that ensuring there cannot be alternative representations was never a design criteria for JWK (nor JSON more generally). So we need to warn people not to use JWK thumbprints in situations where security fails if an attacker could create an alternative representation of a key.



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

It would have been quite reasonable for us to save 11 bytes in most cases by specifying an RSA key as:
  "n" -- base64url of modules; MUST be present
  "e" -- base64url of public exponent; OPTIONAL; defaults to 65537 (AQAB in base64url) if absent

The JWK thumbprint rule ("include all MUST parameters") would then fail.

Another key type could easily make a similar choice. Varieties of elliptic curve keys only need an x coordinate; some need a boolean flag instead of a full y value; some need a co-factor...

It would be more sensible to have a dedicated "Thumbprint fields" line in each JWK registration as evidence that someone though about what a thumbprint of that key type needs to cover. It is cute that "MUST be present" and "suitable to include in thumbprint" are the same for some key types, but there is little reason this will always be the case.



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

Defining specific algs in a separate doc (JWA) makes some sense (algs could change while the framework remains). However, a registry is part of the framework.
If new algs emerge so we deprecate JWA for a new version, we need to repeat the registry establishment!

--
James Manger


________________________________________
From: Manger, James
Sent: ‎7/‎25/‎2014 3:48 AM
To: Mike Jones; [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.  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