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

From: Mike Jones <[email-masked]>
Date: Fri, 10 Feb 2012 22:28:13 +0000

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.

9.  Is "member names" considered to be a normal method to refer to the

elements in an object?    If so then no objections, if not then I would

rationalize the string.  I normally see something like name/value pairs so I don't know where "member" came from.

Yes, this is JSON terminology.

13.  Section 4.1 - I find the table version to be difficult to read given the amount of text in the semantics field.  Having this many really short lines inhibits readability.

I believe the correct solution is to restructure the text by making each table row its own <section> so that the identifier names are all indexed.  This is on my to-do list as editor.

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?).

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.

19.  'kid' parameter - I want to write a library to deal with this specification I don't know what to do with the kid parameter.  It would be more useful if you specified what would go in this value if the jku or x5u fields were used.  Why would I not use the kid field rather than the x5t parameter using the same value?  Why is this parameter even defined if one does not know how to use it.

I agree that we should likely strengthen this description, at least by describing the relationship between this parameter and the JWK kid parameter.  In that case, the semantics should be well-defined.

20. 'x5u' parameter - I think you want to be able to allow for a bare x509 certificate w/ no packaging.  This is a very common method of having pointers to certificates as well.  This would not be pulling a certificate chain (which would require a CMS degenerate signed data blob) but a single certificate.

Agreed.  If the WG agrees, we should add this.

21. 'x5t' parameter - there may be push back from the security ADs on the IESG about the fact that this is not an algorithm agnostic manner of doing this.  What would the correct way be for using the SHA-256 hash rather than

the SHA-1 hash as a thumbprint for the certificate?   One way would be to do

an <algorithm>:<value> pair and saying that the "sha1:" can be omitted.

What do people think of this proposal?

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.

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.

28.  It would be good at this point to say if the normal methods of looking up an field name are going to work according to the text you have outlined.

i.e. should one expect that aobj.alg is going to return the right answer?

This statement seems to me to be too implementation-specific (are you thinking of JavaScript, Ruby, Perl, Python, ... syntax?).  That being said, I believe that the "standard" methods should work in most/all programming environments with JSON support, but this certainly can't be a normative statement.

31.  Section 6.1 - is there a reason to compare the values as base64url encoded rather than in the native binary values?

Either could be done.  I'll put making this text more general in this manner on my to-do list for the next revision of the JWA spec.  (This text now lives in 3.1 there.)

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.

24. Section 8.1 - can JSON names include strings outside of the Basic Multlingual plane?

Yes.  The text below is from the JSON spec (RFC 4627):

   To escape an extended character that is not in the Basic Multilingual
   Plane, the character is represented as a twelve-character sequence,
   encoding the UTF-16 surrogate pair.  So, for example, a string
   containing only the G clef character (U+1D11E) may be represented as
   "\uD834\uDD1E".

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 11 Feb 2012 22:04:43 -0800

<NO HAT>

None interesting things have been removed.

Jim

From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, February 10, 2012 2:28 PM
To: Jim Schaad; [email-masked]
Cc: [email-masked]
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.

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?

[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?