[jose] #70: Review of 2119 Language

["jose issue tracker" <[e-mail]>]

#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-
  [e-mail] |  [e-mail]
     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/>