#70: Review of 2119 Language
There are a number of places where 2119 language is used in appropriately
or there are requirements that are not stated or mis-stated. I am going
to go though one paragraph in detail to show what I am talking about.
Additional members MAY be present in the JWK. If not understood by
implementations encountering them, they MUST be ignored. Member
names used for representing key parameters for different kinds of
keys need not be distinct. Any new member name SHOULD either be
registered in the IANA JSON Web Key Parameters registry Section 7.1
or be a value that contains a Collision Resistant Namespace.
Additional members MAY be present in the JWK. --- This is not a protocol
statement. There is no way to write a test for this that an
implementation would need to pass. This is just a fact that needs to be
dealt with. There is nothing that can be done to prevent it. Thus
s/MAY/might/
You now have three different entities that you need to discuss at this
point and they need to be identified by name where appropriate. We can
now talk about entities that create/define a new member to be present in a
field, entities that put other members into a JWK and entities that
consume a JWK and now need to deal with the fact that these additional
members are present.
If not understood by implementations encountering them, they MUST be
ignored. ---- I assume that this statement is addressed to comsumers of
JWKs althought that is not exactly what it says. Looking at this
requirement - there are two possible responses that could be placed here.
Either they MUST be ignored, or they SHOULD be ignored with a statement
about when they would not be ignored. (This might be desirable behavior
for some high security applications where not enforcing restrictions place
on the key by the creator is undesirable.) Either of these statements
would be fine but the identification of who the statement is being
addressed to and what the 'they' referes to can all be cleaned up. Thus
"Consumers of JWKs that encounter addition members MUST ignore them."
However there is an additional statement which might need to be included
here which is not - what are these implementations supposed to do with
members which they understand but are not defined by this document. In
this case the correct action would be to enforce the semantic and not to
ignore them. However is it required that they be enforced or not - this
is not a stated requirement - thus "Consumers of JWKs that encounter
members not defined in this document, MUST apply the correct semantics for
those members that they understand, and MUST ignore those members that
they do not understand."
Any new member name SHOULD either be registered in the IANA JSON WEB Key
Parameters registry Section 7.1 or be a value that contains a Collision
Resistant Namespace. --- It is not clear if this requirement is aimed at
creators of JWK objects or at the entities that are going to create the
definitions of new items. This type of thing needs to be clarified. If
this is named at creators of JWKs, then it needs to be clear how this
would be implemented. This would need a statement more along the lines of
"Creators of JWK objects SHOULD verify that member names used are either
URI objects, or are registered in the IANA JSON Web Key Parameters
registry (give the URL to the registry here). JWKs for which this is not
true need to be used only in closed systems." On the other hand, if this
is targeted at definers then it needs to say so. It should also give the
conditions under which the SHOULD can be violated if not immediately
obvious.
I have not had the time and energy to do this detailed of an analysis on
the entire document yet, but it needs to be done.
Another example of this is the phrase "Use of this member is OPTIONAL."
Does this mean that it does not need to be populated, or does it mean that
it does not need to be applied even if populated?
--
-------------------------+-------------------------------------------------
Reporter: | Owner: draft-ietf-jose-json-web-
[email protected] | [email protected]
Type: defect | Status: new
Priority: major | Milestone:
Component: json-web- | Version:
key | Keywords:
Severity: - |
-------------------------+-------------------------------------------------
Ticket URL: <https://grenache.tools.ietf.org/wg/jose/trac/ticket/70>
jose <http://tools.ietf.org/jose/>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
