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