I hadn’t noticed before that the JSON Web Key (JKW) draft suggests the
following as possible key id values:
* "kid":"Current"
* "kid":"Upcoming"
* "kid":"Deprecated"
These are not what I consider key identifiers. Perhaps they are key tags, or
key relations (rel values).
Seeing these examples does help explain why the draft says “key id values
within a JWK Set need not be unique”, which always seemed to defeat the point
of a key id.
I don’t think values such as “Current”, “Upcoming”, or “Deprecated” match with
what most people will expect from a field labelled a key id (kid). Such “kid”s
will change during a keys lifetime! I hope a key doesn’t change from “Current”
to “Previous” between the moment a JWS is signed and the time it is verified
(seconds, minutes, hours, months later), because that will break the
verification!
Surely this definition of “kid” is broken.
Suggestion: define a “rel” parameter that can be included in a JWK that can
hold relations such as “current”. The “rel” parameter would never appear in a
JWS/JWE, just a JWK.
Suggestion: define “kid” as a proper key id.
On a related matter, the examples in JWS don’t use “kid”. For instance, 3.1 JWS
Example has a header {"typ":"JWT", "alg":"HS256"}. This is bad practice. You
need a specific key to verify this JWS so that specific key should be
identified. Without a (proper) “kid” you compromise the ability to change keys.
We should not encourage such behaviour.
JWS also goes to some effort to integrity protect the header. Some of the value
in doing that is undermined if the details required to process the message
(such as the identity of the key) are not included within that integrity
protection. If we really need concise headers we would be better keeping “kid”
and omitting “alg”, relying on the good crypto practice of only using a given
key with a single algorithm (hence “kid” implies “alg”).
Suggestion: add "kid" parameters to all the JWS examples (eg "kid":"k37d5FGSR")
--
James Manger
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
