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@xxxxxxxx. The process for setting up the list is described at the bottom of this web page: http://www.ietf.org/list/nonwg.html.