JSON Web Signature (JWS)
draft-ietf-jose-json-web-signature-41
Yes
(Kathleen Moriarty)
No Objection
(Adrian Farrel)
(Barry Leiba)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
Abstain
Note: This ballot was opened for revision 32 and is now closed.
Kathleen Moriarty Former IESG member
Yes
Yes
(for -32)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -33)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2014-09-28 for -33)
Unknown
== Section 2 == "These terms defined by the JSON Web Encryption (JWE) [JWE] specification are incorporated into this specification: "JSON Web Encryption (JWE)" and "JWE Compact Serialization"." Seems like "JWE JSON Serialization" should be included in this list as well. == Section 4.2 == "As indicated by the common registry, JWSs and JWEs share a common Header Parameter space; when a parameter is used by both specifications, its usage must be compatible between the specifications." Since both the JWS and JWE specifications are on their way to becoming RFCs, would it make more sense to say "its usage is compatible between the specifications"? Or is this for the future when new parameters may get defined? == Section 9 == Do we use iesg@iesg.org? I usually use iesg@ietf.org.
Barry Leiba Former IESG member
No Objection
No Objection
(for -33)
Unknown
Brian Haberman Former IESG member
(was No Record, No Objection)
No Objection
No Objection
(for -33)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -33)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -33)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -33)
Unknown
Richard Barnes Former IESG member
(was Discuss)
No Objection
No Objection
(2014-10-01 for -37)
Unknown
Section 2. In the definition of "Unsecured JWS", it would be good to note that this requires "alg" == "none". Section 3.3. Why doesn't this section have a JSON-encoded form as well? Appendix A.5. I would prefer if this example could be removed. JWT is the only use case for Unsecured JWS right now, and there's already an example in that document. Thanks for Appendix C. FWIW, it has been implemented: http://dxr.mozilla.org/mozilla-central/source/dom/crypto/CryptoBuffer.cpp#85
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -33)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-10-02 for -33)
Unknown
no-obj I think Pete is wrong about section 8 and would DISCUSS its removal;-) Its needed for jku handling. 4.1.2: TLS server auth is good here, but only makes sense if the jku parameter itself was signed and there wasn't any odd HTTP 3xx re-direction and/or if the authority in the jku value is reflected in the subject or SAN of the TLS server cert. Why is it ok to not include such detail? Is all of that correct and appropriate in 6125 (which I see you reference from section 9) 4.1.4: why isn't this case-sensitive still as in JWKs? (Is that a result of lots of copied text over >1 draft?) 4.1.5-4.1.8: If all of that text is replicated elsewhere it should only be included in one and cross-referenced.
Ted Lemon Former IESG member
No Objection
No Objection
(2014-10-02 for -33)
Unknown
The following sample text is encoded assuming a CR+LF line terminator: {"typ":"JWT", "alg":"HS256"} I think it would be better to just encode it as a single line, as was done in the JWE spec, so as to avoid confusing people who use operating systems that use the single-character line ending ("newline"). I suspect this applies to other examples as well. If you have to go multiline, you could also address this by just saying "line separators in examples are CR+LF ([13, 10])". This looks like an attack surface: The Header Parameter names within the JOSE Header MUST be unique; recipients MUST either reject JWSs with duplicate Header Parameter names or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 (The JSON Object) of ECMAScript 5.1 [ECMAScript]. Is this really safe? I believe you mean "base64 padding characters" here: 2. The encoded representation of the JWS Protected Header MUST be successfully base64url decoded following the restriction that no padding characters have been used. I mention this because I don't think you require that no whitespace characters be present in the encoded JWS protected header, and someone might read this text that way. This concern exists in several other paragraphs in this document, and also in the JWE document. I don't know if it's worth dealing with, but it seems like it might make peoples' lives easier if you stated explicitly that you are talking about /base64/ padding. Why not just make this a requirement of JWE: o Require that the "alg" Header Parameter be carried in the protected header. (This is always the case when using the JWS Compact Serialization and is the approach taken by CMS [RFC6211].) Relying on the application to get this right seems chancy. This document has a really great security considerations section. Thanks for being so thorough and clear.
Pete Resnick Former IESG member
(was Discuss)
Abstain
Abstain
(2014-12-02 for -37)
Unknown
I've got some suggestions for improvements below, but overall I cannot support this document, so I'm entering an ABSTAIN. I don't think this WG has actually fulfilled its charter with regard to this document set. The WG was supposed to produce a "JSON syntax that can be used by applications to describe secure data objects". I don't believe it did that. Instead, it produced a compact serialization for a particular purpose and then backed into a JSON syntax. The compact serialization drove the effort and produced IMO a substandard JSON serialization. I don't believe that (reliable) interoperable implementations of the JSON serialization will be possible using this document set. However, there is at least rough consensus that these documents are usable as-is, and I don't think there's anything to be gained by holding them up any further. I hope the WG will adopt some of the remaining comments, but my intention is not to discuss this any further. If you wish to address any of the comments and need clarification, I'm glad to help with that. ------ I really wish you would have factored out what's common between JWS and JWE so you didn't have so much repeated text. Throughout: I thought you were changing all "recipient"s to "consumer"s. I haven't changed them below, but you might want to do a proper search for them. 1: Lose the last paragraph. It's not a core goal. Certainly not in the charter. 2. A "JSON Web Signature Signature" is an unfortunate terminology choice. If there is a whole *thing* that is the combination of the header, the signature, and the payload, perhaps that should have been a "JOSE Web Object", or better yet a "JOSE Object". Then you could simply have "JOSE Signature", "JOSE Payload", and "JOSE Header". I'm also unclear why the word "Web" appears in each of these things -- except "JOSE Header", which I find equally strange. They should not just be for use on the Web. This whole "JW*" terminology thing is goofy. 3. "JWS object" is undefined. Please reverse the order of section 3.1 and 3.2. 3.1: Failure to have an unprotected header in the compact serialization means that these things are not round-trippable. That's very unfortunate and I think a failure of the protocol. 3.2: OLD In the JWS JSON Serialization, a JWS object is represented as the combination of these four values, BASE64URL(UTF8(JWS Protected Header)), JWS Unprotected Header, BASE64URL(JWS Payload), and BASE64URL(JWS Signature) NEW In the JSON Serialization, the JWS object is represented as a JSON object with 3 members: header, whose value is JWS Shared Unprotected Header protected, whose value is BASE64URL(UTF8(JWS Protected Header)) payload, whose value is BASE64URL(JWS Payload) signature, whose value is BASE64URL(JWS Signature) (This doesn't account for multiple signatures, and I'd wish you'd clarify what the structure actually looks like, but this is at least better.) Also, there is no need for the Payload to be (a) part of the serialization and (b) base64ed. 3.3: OLD The following example JWS Protected Header declares that the encoded object is a JSON Web Token (JWT) [JWT] and the JWS Protected Header and the JWS Payload are secured using the HMAC SHA-256 [RFC2104, SHS] algorithm: There's a couple of typos in there. I think you meant: NEW (1) The following example JWS Protected Header declares that the encoded object is a JSON Web Token (JWT) [JWT] and the JWS Payload is secured using the HMAC SHA-256 [RFC2104, SHS] algorithm: However, I'm not clear why that's an example of a *Protected* Header. Looks like it could be any old header. So I think better is: NEW (1) The following example JOSE Header declares that the encoded object is a JSON Web Token (JWT) [JWT] and the JWS Payload is secured using the HMAC SHA-256 [RFC2104, SHS] algorithm: Then you would fix: OLD Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value: NEW If this were a JWS Protected Header, the encoding of BASE64URL(UTF8(JWS Protected Header)) gives this value: Also: Concatenating these values... This section is not about the compact serialization. If you want to give both example serializations in this section, fine, but if you are giving a general "Example JWS" as the title of the section states, don't just give the compact. 4.1.1/4.2: I see no need to mention that the alg could be a "Collision-Resistant Name" (what a term!). The alg should be registered. If it's not, you're in private agreement space anyway, so it needn't be specified in the spec. Same thing for Public Header Parameter Names: If you're going to do this interoperably, you're going to have to know what the thing means; otherwise, it's out of band anyway. I say get rid of the whole concept of using non-registered names. 4.1.6: This is a section where you did not clean up the "reject" language. Here are my suggested changes: OLD The recipient MUST validate the certificate chain according to RFC 5280 [RFC5280] and reject the signature if any validation failure occurs. NEW The recipient MUST validate the certificate chain according to RFC 5280 [RFC5280] and consider the signature invalid if any validation failure occurs. 4.1.11: This is a section where you did not clean up the "reject" language. Here are my suggested changes: OLD If any of the listed extension Header Parameters are not understood and supported by the recipient, it MUST reject the JWS. NEW If any of the listed extension Header Parameters are not understood and supported by the recipient, it MUST consider the JWS signature invalid. 5.1: s/MUST perform/performs 2. BASE64URLing the payload shouldn't be required. 3. Replace everything after the colon with "the JWS Protected Header and/or the JWS Unprotected Header, as appropriate." 4. Strike the parenthetical "(which can only happen...)". Sounds like you are discouraging use of the JSON Serialization and the Unprotected Header. 5. I don't see a need for the second sentence. Delete. 8. Replace with "Create the desired serialized output, as described in Section 7." Stop privileging Compact. 5.2: s/MUST be taken/are performed. I made an attempt to untangle the serialization from the actual algorithm. I failed. I think this is likely to be hard to implement strictly from the spec. 10.12: This is a section where you did not clean up the "reject" language. Here are my suggested changes: OLD In particular, any JSON inputs not conforming to the JSON-text syntax defined in RFC 7159 input MUST be rejected in their entirety. NEW In particular, any JSON inputs not conforming to the JSON-text syntax defined in RFC 7159 input MUST be treated as invalid in their entirety by JWS consumers. OR In particular, any JSON inputs not conforming to the JSON-text syntax defined in RFC 7159 input MUST be rejected in their entirety by JSON parsers. OLD Such input MUST be rejected in its entirety. NEW JWS consumers MUST treat the signatures of such input as invalid. Appendix E: s/reject/considered invalid/g