Re: [jose] Comments on the -03 JSON Web Signature document

["Jim Schaad" <[e-mail]>]

<NO HAT>

 

None interesting things have been removed.

 

Jim

 

 

From: Mike Jones [mailto:[e-mail]] 
Sent: Friday, February 10, 2012 2:28 PM
To: Jim Schaad; [e-mail]
Cc: [e-mail]
Subject: RE: [jose] Comments on the -03 JSON Web Signature document

 

This note replies the comments from your note where the resolutions to them
were incomplete or different than you proposed.  Per our e-mail exchange, I
won't clutter the discussion by replying to comments whose resolutions are
already incorporated into the working group drafts.

 

1.  I have a personal problem with the fact that the draft is still named
"JSON Web Signature" rather than something like "JSON Integrity Objects".  I
doubt that I am the only person who has this issue given the number of
people who gave opinions during the charter discussion and the resulting
charter description "JSON-structured integrity protection to data".  This
becomes a major re-write of the document internally as well.

 

Per discussion that occurred within the WG after the Taipei meeting on the
list, for the same reasons that the WG uses the term "signature", the spec
continues to use the vernacular term "signature" as the most readable of the
choices in the title.  For instance, see
http://www.ietf.org/mail-archive/web/jose/current/msg00315.html and
http://www.ietf.org/mail-archive/web/jose/current/msg00309.html.  That being
said, the terminology within the specs has been changed to no longer call
both digital signatures and HMACs "signatures", and so I believe is now
correct throughout.

 

[JLS] I disagree with this, but am not going to fight this issue at this
time.

 

16.  The text states that the key must be associated with the signer of the

content.   The current document for json keys does not have any way of

associating a key with the signer.  What does this requirement really mean?

 

It's intended to mean that there must be a way to verify that the content
was signed by the correct party, using a key controlled by that party.  I'd
welcome better language for this concept (possibly lifted from another
crypto spec?).

 

[JLS]  I have a problem with the statement both in the original text and
above.  If we are looking at a bare key for doing the validation, we have no
idea who the correct party is in general.   The fact that the key was found
at https://example.com/Tom_Piperson does not tell me without other
information who the key is associated with.  Going back and re-reading the
MUST statement I think that it could be removed entirely.  I am not sure
that I even understand what the test should be for an interop matrix.  If
the algorithm is understood by the sender and not the validator is the MUST
violated?  Is processing a sender or a validator function or both?  If I
were to successfully forge a message, would the MUST still be true?  

 

18.  It would be useful to know if there was going to be any registry for
the "typ" header.  If not, then it would be useful to state that the values
of the "typ" header are based on agreement between the parties.  It would
also be useful to state the expected behavior in the case the the value of
the typ field is either unknown, does not match the expected value or is
missing.  Are values of the "typ" field supposed to have the same type of
public/private values as does algorithm?  If not what happens when a
collision exists between two different applications?

 

Per my comments on the open issues listed in the drafts, an argument can be
made for deleting this parameter from the JWS spec entirely and leaving its
definition up to profile specs like JWT.  If this isn't done, then a
registry could be considered for names not residing in a collision-resistant
namespace.

 

[JLS] If it is believe that a parameter this list is going to be "commonly"
used by many different profilers, then I believe that the core items needs
to be done the in the base specification.  I would therefore not be in favor
of punting it out to somebody else.  The only exception would be if we are
going to have a very light core and a "real" core specs.  In this case the
very light core spec could punt to the "real" core spec.  Having said that I
think that a registry would be a good idea.

 

23.  Having done a much more detailed read.  The last para in section 4.2
can be expanded as follows:

 

New header parameters should be introduced sparingly, an implementation
which does not understand a newly introduced parameter will fail validate of
the JWS.  However, uses which use the JWS structure but define additional
semantics, such as the JSON Web Token usage, are expected to define
additional public header parameters.

 

The first concept (must-understand of header parameters) is already in the
second sentence of the description of header parameters (in Section 4).  I
could however, add the sentence "However, it is expected that some
additional header parameters will be defined by specific profiles and
specifications using this specification" to cover the second point, if that
works for you.

 

[JLS]  I see no problems with re-iterating why it is a problem, but would
not insist on it.  Telling people that it  breaks is usually insufficient,
telling them why it breaks means they have a starting place to look for
problems.

 

24.  Why MUST I do the following steps (since to me this implies an order of
operations).  Is there a reason that I cannot do things in the order of 3,
4, 5, 1, 2, 6, 7?

 

Reordered and partially rewrote to be more logical.  Please review.

 

[JLS] Sorry, my core problem was insufficiently defined in my message.  My
problem is that the order of the steps is NOT NORMATIVE.  The result needs
to be the same as the steps given, but the order that I do things can be
anything that works for me.

 

[JLS] In step 3 is there a reason that I cannot perform canonicalization?
The current text explicitly forbids it.

 

[JLS] Having followed and read RFC4627 - I note that a JSON  object IS
permitted to have the same member name listed twice.  No restriction about
if the values are required to be the same.

 

[JLS] For decode - I think that step 5 should be folded into the text for
step 1.

 

[JLS] I would suggest that section 5 be sub-divided - one for creation and
one for validation.

 

[JLS] I think that I am having some problems with the fact that the
validation process apparently is now totally based on the alg being used and
does not have any reliance on this specification.   At a minimum the text in
validate step 6 needs to say that the input for processing is the
concatenation of ..

 

21, Section 6.1 - The last para states that there is a correspondingly
longer key and result.  While the result is going to be longer, there is no
requirement that the key be longer unless you are going to make a statement
to that effect.  One could use a 512 bit key for all of the algorithms.

 

I believe that this statement is true for the HS256, HS384, and HS512
algorithms, but I agree that it's not particularly enabling.  I'll put
describing the expected key sizes for all the algorithms on my to-do list.

 

[JLS] Where did this text wander off to?  Some place in JWA?