Subject: [jose] json-web-encryption -02 comments

From: "Jim Schaad" <[email-masked]>
Date: Thu, 7 Jun 2012 11:55:50 -0700

Introduction

1.  I would separate the introduction into two paragraphs.  One to address
the general encryption issue and one to address the compact serialization
issues.  This will allow for an easier addition/removal to deal with other
serialization issues.

2.  I find sentence #2 confusing since this document is defining how to do
the encryption process so we are not really dealing with pre-encrypted
content which is what this appears to me to say.

3.  What do you mean by the type of content being encrypted?  This could
either mean the format of the content (i.e. JSON vs Mime) or the type of
content (i.e. a JSON token vs a JSON signature object).

4.  I think a new paragraph should start with "Cryptographic algorithms..."
this is a new topic.  (What is not in this document.)

Section 3

1.  Simple clarity s/confidentiality of the contents of the
Plaintext/confidentiality of the Plaintext/

Section 4 - JWE Header

1.  Do we think parsers can enforce the uniqueness requirement?

2.  What does it mean to reject a JWE?  Should it decrypt and say it is a
bad decrypt or should it fail to decrypt?

Section 4.1.1

1.  You should be constant about what  you call the encryption key, master
key or JWE Encrypted key.  A search and replace should be done to make them
constant.

2.  Refer to the registry not to the document for the list of algorithms.

Section 4.1.2

1. See comment 2 above

2.  the encryption algorithm is not used to secure the cipher text.  It is
used to produce the cipher text

3.  Why does the enc algorithm not require the existence of a key for it's
use?

Section 4.1.4 

1.  (Curiosity question) Other than "size" is there a reason that an iv must
be base64url encoded?

2.  The presence of this parameter MUST be specified for all content
encryption algorithms.

Section 4.1.5 

1.  See comment 2 above - alternate language would be say MUST be absent
unless otherwise specified by the algorithm.

2.  epk should talk about key agreement algorithms not a specific algorithm.

3.  Content of the key should be specified by the algorithm and not by this
document.

Section 4.1.6

1.  Should specify the use the "alg" registry for the zip parameter (in case
a new one comes into existence) and this algorithm should be registered as
the only algorithm.

Section 4.1.7

1.  Should make clear that this is the way of identifying what private key
is needed to decrypt the content.

2.  Should this be used?  It implies that the decryptor needs to do the
following:
a) Get the keys
b) For each key -
   i) Do I have the private key for this?
   ii) Does it match the algorithm?
   iii) Does it work?
c) if no function keys found then ---???

Section 4.1.8

1.  See comment 1 above.

Section 4.1.9

1.  I would eliminate the (implicit) requirement that the certificate be
validated before decryption.  There is no reason that a client should not be
able to decrypt a message to themselves if their certificate has been
revoked or is expired.  This is just a requirement at send time.

Section 4.1.11

1.  I don't understand the format used here.  The data could be either
encoded as a string or an array of strings or something else that is a
concatenated string form.

2.  Why is this not base64url encoded given that all other locations are?

3. See comment 1 above

Section 4.1.12

1.  This is so underspecified that I would know how to go about using it.
Any code that I wrote would therefore ignore it.

Section 4.1.13

1.  The list of possible typ values should apparently include the mime
registry as well.  This is neither in the value registry (which should
probably be setup to avoid collisions with mime types) or a URI.

Section 4.2

1.  Should re-iterate the "if you don't know it then reject it" sentence
here - it has been a long time since we have seen it.

(Ditto for section 4.3)

Section 5

1.  I disagree with the concept of using a key agree algorithm to create the
CMK.   Look at CMS to see how they handle key agree algorithms to create a
key wrap key

2.  In step 8 - when did you create the encoded JWE header?

3.  Separate the serialization format from the encryption algorithm.  This
may just affect step 14.

4.  Note previous discussion on only documenting AEAD algorithms

Section 6

1.  Separate serialization from message decryption.  If alternate
serializations are used then step 1 fails.

2.  Note that you have imposed some additional restrictions on the JSE
header in step three - specifically that no duplicate fields exist.  This is
not in the decryption process.

Section 7

1.  If you are using the NIST KDF function, then the length of the output
key should really be included in the OtherInfo

Section 8.1

1.  Refer to the registry not to the document (ditto for section 8.2)

Section 11.1

1.  Should there be an optional parameter which describes which
serialization method is being used?

2.  Check with IANA if you or the IESG should be listed under the contact
section.