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; [email protected]
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:[email protected]] On Behalf Of Mike Jones
Sent: Thursday, 24 July 2014 1:13 AM
To: [email protected]
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
