I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-jose-json-web-signature-31
Reviewer: Russ Housley
Review Date: 2014-08-24
IETF LC End Date: 2014-09-03
IESG Telechat date: unknown

Summary:  Not quite ready.  Some issues to resolve.

Major Concerns:  

- At first reading, I thought that Sections 2 and 3 were defining the
  same terms.  On the second or third reading, I figured it out.
  I think it would be more clear in Section 3 to state that a JWS is
  constructed from a sequence of the things that are already defined
  in Section 2.
  
- In Section 5.2, it says that in some cases, all must successfully
  validate, but in other cases, only a specific signature, MAC, or
  plaintext value needs to be successfully validated. How does the
  recipient know which case applies?

- In Section 8, why not say that TLS 1.2 or later MUST be supported?

- Section 10 says, "The entire list of security considerations is
  beyond the scope of this document..."  This reads like a red flag to
  me.  While it is not possible to discuss every possible implementation
  consideration that impacts security, the document should cover the
  topics discussed in RFC 3552.  At a minimum, I think the following
  need to be discussed:
    -- the consequences of compromise of the signer's private key
    -- the consequences of compromise of the MAC key
    -- the consequences of poor random numbers, which are needed for
       more than just key entropy with some algorithms like ECDSA
    -- awareness that cryptographic algorithms become weaker with time

Minor Concerns:

- Section 1, 1st paragraph says: "The JWS cryptographic mechanisms
  provide integrity protection for an arbitrary sequence of octets."
  This is true, but this is not the whole story.  A sentence or two
  should be added about when a signature mechanism is appropriate
  and when a MAC mechanism is appropriate.  Alternatively, a pointer
  to Section 10.4 could be included.

- In Section 4.1.4, should the value match the subject key identifier
  if an X.509 certificate is used?

- In Section 4.1.5, why is TLS required to fetch digitally signed
  X.509 certificates?

- Section 10.2 talks about chosen plaintext attacks.  However, there
  are much worse things than chosen plaintext attacks that will result
  if a third party can get a signer to sign a content of its choosing.

Other Comments:

- I suggest a rewording for a part of Section 2:

  OLD:

   JOSE Header
      JSON object containing the parameters describing the cryptographic
      operations and parameters employed.  The members of the JOSE
      Header are Header Parameters.

  NEW:

   JOSE Header
      JSON object containing the parameters describing the cryptographic
      operations and parameters employed.  The JOSE Header is composed
      of a set of Header Parameters.

- I think that Section 3.1 would be more clear by saying:

   In the JWS Compact Serialization, a JWS object is represented as:
   
      BASE64URL(UTF8(JWS Protected Header)) || "." ||
      BASE64URL(JWS Payload)  || "." ||
      BASE64URL(JWS Signature)

- I think that Section 3.1 would be more clear by saying:

   In the JWS JSON Serialization, a JWS object is represented as:
   
      BASE64URL(UTF8(JWS Protected Header)) || "." ||
      JWS Unprotected Header || "." ||
      BASE64URL(JWS Payload) || "." ||
      BASE64URL(JWS Signature)

   Then, the text needs to say that whitespace may appear anywhere.

- Some additional whitespace would make Section 7.2 easier to read.

- The IANA Considerations section requires the establishment of a new
  mail list: jose-reg-review at ietf.org.  The process for setting up the
  list is described at the bottom of this web page:
  

http://www.ietf.org/list/nonwg.html

.