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

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

The following comments are personal and do not necessarily reflect the
opinions of the chairs.

I just started at the front and started reading so there are probably
duplicates with section 9

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.

2. As per the charter description, I expect that section 6 is moving to a
new document.  When should this be expected?

3.   In Section 2, why not describe the JWS Header as the JSON object rather
than as the string containing the object.  Additionally I would note that
the integrity protection is applied to the Encoded JWS Header and the
Encoded JWS Payload in the current document.

4. Please re-write the term "Digital Signature" in section 2 to reflect
charter consensus.

5. In section 2 - Base64url Encoding - s/to the he/to the/

6.  In section 3 (pre 3.1), this does not seem to be a reasonable place to
put a MUST - it would go better in the description of the header itself.

7.  In section 3 para #1 - I don't know why there should be a reference at
this point to JWTs.  JWTs should become a profile of this document and the
encryption document.  At most it is a driving reason for doing this document
and not the other way around.  (i.e. lose the text from 'as is done' on)

8.  In section 3 para #2 - The second sentence does not flow from the first.
Either you are describing what the Payload is in a basic thing - or you need
to describe the fact that the JWS header is signed in the previous sentence
so that the "A portion of" clause makes sense.

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.

10.  In section 3.1 - you need to respect the limit on number of columns in
your example.

11. In section 3.1 - you have not completed the example as you have not
shown the final JWS encoding.

12.  In section 4 - Is JWS being rejected for processing the same as saying
the integrity protection failed or is it a different error?  Is this
protocol dependent in terms of what type of errors are to be returned by the
surrounding protocol?

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.

14.  'alg' says both that the parameter is required and that "if present".
If it is required then the "if present" would seem to be incorrect.

15.  The values in table 3 are not reserved but defined (i.e. we are not
reserving them for future use)

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?

17.  I would suggest that the text reference the fact that an IANA table is
going exist with a set of publicly defined values for the alg header
parameter.

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?

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.

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.

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.

22.  Please give me a test that I can use to validate the following protocol
requirement from section 4.2:
In each case, the definer
   of the name or value MUST take reasonable precautions to make sure
   they are in control of the part of the namespace they use to define
   the header parameter name.
This is a case where I believe that the MUST should not be a protocol
requirement.

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.

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?

25.  In section 5,create step 3 - I am confused because when you say create
the object I think of the code
	Obj = {"alg": "RSA-SHA256"}
Given that, I don't understand what the text dealing with canonicalization
and white space is about.  This would deal with the serialized object rather
than the object itself.  But you have not said create and serialize the
object.  In my mind an object is a blob and a serialized object is one
representation of  the object, but it is not the actual object.

26. Reverse steps 1 and 2 in the validation process.  That is the more
likely order to be dealing with things.  I would also move steps 3 and 5 to
before the current step 2. It makes more sense to completely deal with the
header and then move the body rather than jumping back and forth.  If you
make the result prescriptive rather than the steps it will allow people to
do things in any order desired.

27.  There is a lack of flow between the paragraph that says see section 8
because comparing Unicode strings is hard and the text in that says this is
how to do it.

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?

29.  Add reference to RFC 4868

30.  Section 6.1 - step 2 - it was not immediately clear to me which was the
previously generated HMAC - i.e. the one from step 1 or the one from the
previous step 1.

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

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.

22. section 6.2 - I don't consider the header parameter methods to
necessarily be retrieval methods - i.e. hash of cert does not tell you how
to find it.  

23.  Section 6.4 - I would have a recommendation that the the xml digsig
(and the mime?) ones would not be permittable if there is a different one
defined here.  Also you do not say what should be done if I wanted to use
the RSA PSS XML Digsig url in terms of setting paraemters - do I put the xml
encoding into the parameters?

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