Comments on JWK thumbprints: http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00
draft-jones-jose-jwk-thumbprint needs to be much clearer about the properties of a thumbprint and the circumstances where it is appropriate and inappropriate to use. Superficially a thumbprint looks like both an unambiguous id and a unique id for a key, but I doubt the latter property can be relied upon. For instance, it would be dangerous to use these thumbprints in a blacklist of revoked keys. It looks fairly easy for a malicious party to modify the representation of a key to give a different thumbprint for the same key (eg change "e":"AQAB" to "e":"AAEAAQ"). "Only the REQUIRED members of a key's representation are used" This rule sounds like trouble. Consider a key that is a point on an elliptic curve. Sometimes x & y are specified; sometimes the crypto only uses the x coordinate; sometimes y is "compressed" to a flag. It seems quite feasible that a JWK format might not REQUIRE "y" in its syntax. Consider an element that has a default value when absent. It is not REQUIRED in the syntax (so would be omitted from the thumbprint), but it can still be required to be understood when it is present. It is a bit nasty that you cannot calculate a key’s thumbprint without type-specific knowledge (about which elements to keep). Keeping all JWK elements in the thumbprint would be better. The spec defines a canonical JSON encoding without explicitly admitting that (eg it doesn't use the word "canonical"). "Characters .. MUST be represented in the simplest manner possible" What is the "simplest manner possible"? I guess "a" is simpler than "\u0061"; less sure about "\n" vs "\u000A"; no idea for "\u000b" vs "\u000B"; escaping "/" as "\/" is (unfortunately) simpler in some environments; "\uD834\uDD1E" vs the 4-bytes "<F0 9D 84 93>"? "all characters within the Basic Multilingual Plane .. MUST NOT be escaped" Is this hinting that U+1D11E (musical symbol G clef) that is outside the BMP should be escaped? Surely it is better to UTF-8 encoded this as 4 bytes. There is no mention of how to handle elements whose value is a number. It is easy to imagine key formats with integer fields (eg a PBKDF iteration count). Presumably an element "p2c":1e5 would actually have to be serialized as "p2c":100000. I guess this doc is going ignore floating point numbers under the (fairly reasonably) assumption that they may never be needed in JWKs. John Bradley said: > Having a well understood method that is resistant to bit stealing and other > sorts of attacks is a good thing, rather than applications rolling there own. What is "bit stealing"? > This is useful in OpenID Connect for calculating a synthetic subject based on > the public key of a self signed JWT. If a key and its thumbprint are both in a message it is asking for trouble as some code will assume (without checking) that they match. A "jkt" member in a JWK is a bad idea. -- James Manger _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
