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

[Mike Jones <[e-mail]>]

Thanks once again.  Responses inline...



-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Thursday, June 07, 2012 11:56 AM
To: [e-mail]; [e-mail]
Subject: json-web-encryption -02 comments



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.



I'm somewhat confused by this comment, as the introduction doesn't discuss serialization.  That concept isn't introduced until the "JWE Compact Serialization" term definition in Section 2 and the presentation of the compact serialization in Section 3.



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.



Like JWS, this sentence has been clarified to:  It represents this content using JavaScript Object Notation (JSON) <xref target="RFC4627"/> data structures.



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).



This now reads:  The JWE cryptographic mechanisms encrypt and provide integrity protection for arbitrary sequences of bytes.



4.  I think a new paragraph should start with "Cryptographic algorithms..."

this is a new topic.  (What is not in this document.)



Done



Section 3



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



Done



Section 4 - JWE Header



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



See my response in the JWK comments



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?



It should return an error and return no decrypted data



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.



Now using the term Content Master Key (CMK) here.  Note that the Content Encryption Key (CMK) is distinct from (and derived from) the CMK.



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



Moved the document reference to be adjacent to the registry reference, saying that both apply



Section 4.1.2



1. See comment 2 above



Ditto



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



Corrected



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



Because the CEK is derived from the CMK, and so always exists



Section 4.1.4



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



Interesting question.  I'd say that this is because we can't assume the existence of bignum libraries to convert between very large integers and the byte sequence, or that JSON parsers won't choke on very large integers.



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



It is, in JWA.  Also clarified that it is REQUIRED with some "enc" algorithms.



Section 4.1.5



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



It is, in JWA.  Also clarified that it is REQUIRED with some "alg" algorithms.



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



Done



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



Done



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.



This could be done, but it is counter to an explicit working group decision to support only one compression algorithm.  I'd be glad to do this if the WG decides to open the door to the possibility of additional algorithms.



Section 4.1.7



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



Added: this can be used to determine the private key needed to decrypt the JWE



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 ---???



Also, the decryptor might use "kid" and/or "use" parameters for deciding which key(s) to use.  Obviously, if no applicable key can be located, the decryption will fail.



Section 4.1.8



1.  See comment 1 above.



Ditto



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.



What do others in the working group think of potentially relaxing this requirement?  If we do relax it, what alternative language should be used?



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.



I've added an example to clarify this.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-03#appendix-B



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



So we're using a standard encoding for certificate chains



3. See comment 1 above



Ditto



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.



Added:     When used with a JWK, the "kid" value MAY be used to match a JWK "kid" parameter value.



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.



See the new Section 7.2 in JWS



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)



I understand why you're saying this, but we did say "Implementations MUST understand the entire contents of the header; otherwise, the JWE MUST be rejected" in the enclosing section introduction (Section 4), so I'm reluctant to repeat it in 4.2 and especially reluctant to repeat it again so soon in 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



The key wrap key is unnecessary, as far as I can tell, at least when there's a single recipient.  It results in an additional encryption step that seems to me to add no additional security.



However, per James Manger's note and my response to it, I do understand that value of having a CMK in the multiple recipients case.  I've added this topic to the list of open issues for the working group to discuss.



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



In step 9. :-)  Yes, I'd already seen this and fixed it.



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



Done



4.  Note previous discussion on only documenting AEAD algorithms



I'm not sure what change you're asking for here?



Section 6



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



Done



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.



It's input validation for the decryption process, just like step 2 was



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



Again, per my earlier responses to you and Sean on this topic from your JWA comments, since the CMK is randomly generated for each encryption, I believe that the additional parameters add no security value.  Adding a key length would only make sense if we were going to use this same CMK to generate other keys using the same Label ("Encryption" or "Integrity") but with a different key length.  But we never will, so I believe that the parameter is superfluous.



Section 8.1



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



Done



Section 11.1



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



This could be introduced if the working group adopts a second serialization method, such as the JSON Serialization defined in draft-jones-json-web-encryption-json-serialization, or one of the other candidates.  However, a better approach might be to define a different media type value, such as application/jwe-js for the different serialization.



Of course, if we have a pure JSON serialization, one could argue for just using the application/json media type.



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



Will do