Skip to main content

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