JSON Web Encryption (JWE)
RFC 7516

Note: This ballot was opened for revision 32 and is now closed.

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Richard Barnes) (was Discuss) No Objection

Comment (2014-10-01 for -36)
No email
send info
Section 3.3.
Why doesn't this example include the JSON encoding?

Section 4.1.3.
"This Header Parameter MUST be integrity protected"
Why is this the case?  There is no security reason that "zip" must be integrity-protected, and this requirement isn't made for any other parameter.

Section 7.2.
The requirement that the "recipients" field MUST be present seems odd.  What's the justification for this?

Appendix A seems kind of unnecessary given draft-ietf-jose-cookbook.

Alissa Cooper No Objection

Comment (2014-09-28 for -33)
No email
send info
== Section 2 ==
It seems a bit odd that some of these terms are re-defined by this document rather than re-using existing definitions, e.g. from RFC 4949 (plaintext, ciphertext, etc.). Was that deliberate?

== Section 4.1 ==
"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

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?

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-10-02 for -33)
No email
send info
1.1/3.1/7.1: I think you should define BASE64URL(null) as
null so that one knows that one can see ".." in compact
representations, e.g if there this is no AAD or IV. Adding an
example of such would be good too. Or, if ".." is not
allowed, then you need to say that clearly.  (This could be
clarified loads of ways, I don't care which you pick.)

(Brian Haberman) (was No Record, No Objection) No Objection

Comment (2014-10-02 for -33)
No email
send info
I agree with Alissa's Comment about the definitions and Richard's Discuss point about the recipient list.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2014-09-25 for -32)
No email
send info
-- Section 5.2 --

   Finally, note that it is an application decision which algorithms are
   acceptable in a given context.  Even if a JWE can be successfully
   decrypted, unless the algorithms used in the JWE are acceptable to
   the application, it SHOULD reject the JWE.

It's a small point, but what does it mean for an algorithm to be 
"acceptable", if not to define this very point?  That is, if I accept (don't 
reject) a decryption with algorithm X, doesn't that *mean* that algorithm X 
is acceptable to me?

-- Section 7.2 --

      The "recipients" member value MUST be an array of JSON objects.
      Each object contains information specific to a single recipient.
      This member MUST be present, even if the array elements contain
      only the empty JSON object "{}" (which can happen when all Header
      Parameter values are shared between all recipients and when no
      encrypted key is used, such as when doing Direct Encryption).

I'm not sure how to read this.  Which of these is a correct version of the 
"recipients" member for the case in the second sentence?:

a.   "recipients": {}
b.   "recipients": [{}]
c.   "recipients": []

Can you word this to make the answer clearer in the text?

-- Section 9 --

   o  If the object is using the JWS JSON Serialization or the JWE JSON
      Serialization, the members used will be different.  JWSs have a
      "signatures" member and JWEs do not.  JWEs have a "recipients"
      member and JWSs do not.

But you say that unrecognized members should be ignored, so an object that 
contains both a "signatures" member and a "recipients" member would be 
considered valid, but might be judged to be either one or the other, 
depending upon the order of the checking.  Does this matter?  Possibly not, 
but I wanted to ask.

(Ted Lemon) No Objection

Comment (2014-10-02 for -33)
No email
send info
This question is almost certainly due to my thick-headedness with respect to authentication algorithms, but:

   16.  Let the Additional Authenticated Data encryption parameter be
        ASCII(Encoded Protected Header).  However if a JWE AAD value is
        present (which can only be the case when using the JWE JSON
        Serialization), instead let the Additional Authenticated Data
        encryption parameter be ASCII(Encoded Protected Header || '.' ||
        BASE64URL(JWE AAD)).

   17.  Decrypt the JWE Ciphertext using the CEK, the JWE Initialization
        Vector, the Additional Authenticated Data value, and the JWE
        Authentication Tag (which is the Authentication Tag input to the
        calculation) using the specified content encryption algorithm,
        returning the decrypted plaintext and validating the JWE
        Authentication Tag in the manner specified for the algorithm,
        rejecting the input without emitting any decrypted output if the
        JWE Authentication Tag is incorrect.

How does it make sense for the AAD encryption parameter to consist of ASCII and BASE64 text?  How would a decryption algorithm use this?   I know nothing about AAD parameters in encryption algorithms, so I realize this is probably a very naive question.

(Martin Stiemerling) No Objection

(Pete Resnick) (was Discuss) Abstain

Comment (2014-12-02 for -37)
No email
send info
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.

1: Lose the last paragraph. It's not a core goal. Certainly not in the charter.

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.


   In the JWE JSON Serialization, a JWE object is represented as the
   combination of these eight values...

That's not true, and potentially confusing. In the JSON Serialization, the JWE
object is represented as a JSON object with 8 members:

  protected, whose value is BASE64URL(UTF8(JWE Protected Header)),
  unprotected, whose value is JWE Shared Unprotected Header...



- Add "If this were part of an Protected Header, it would be encoded as..."

Please show the regular JSON Serialization, not just the compact. The compact
is lousy as an overview example. If you want to add the compact after the JSON,
that's OK.

4.1.2: Change "MUST reject" to "will be unable to decrypt". Strike the last sentence of the first paragraph.


It looks like steps 1, 2, 3, and 6 are actually one big step. They should
probably be combined and clarified in some way.

4 and 5 could be reasonably combined.

19 - Delete everything after the first sentence (and optionally point to
section 7).

5.2: If these things are steps, start with the verb. See 2 below as an example,
but look at the other steps as well.

   1 - Say what to parse out and refer to section 7. Again, don't privilege

   4 could be significantly shortened if you didn't separate the
   serializations. Just make it the union. If some of the members are absent
   (for whatever reason), that's fine.

   4 and 5 should be combined.

   8-11 seem like they could be combined/refactored in some useful way.

   (I'll also note here that the "recipient" construct is still weird to me.
   It's just a "key owner" or something like that, right?)

   14 and 15 - Ditch the parenthetical.

   18 is kind of silly. If decryption failed, it failed. No need to
   additionally "reject" (whatever that is supposed to mean). The second and
   third sentences are just implementation detail. Delete 18.

9: It took me a bit to figure out why this section is here. This is only a
problem for the Compact Serialization. The second bullet makes this clear: For
the JSON Serialization, the answer is, "They're different if they're
different." I suggest rewriting this section to make it clear that you're
trying to help folks who need to distinguish between compact serializations.

Appendix A: Leaving the JSON Serialization until the end and putting a compact
serialization in every example stinks. Let's not make it harder for
implementers to figure out how to use the JSON Serialization.