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

From: Mike Jones <[email-masked]>
Date: Fri, 6 Jul 2012 18:13:13 +0000

Thanks once again.  Responses inline...

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Thursday, June 07, 2012 11:56 AM
To: [email-masked]; [email-masked]
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

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 16 Jul 2012 18:30:29 -0700

In section 4 -

There is an interesting question about the following:

{ alg:"none", enc:"AES128GCM" }

This returns different results depending on which test you are using for
determining if the header is a JWE or a JWS.  This belies the last sentence
in paragraph #2.

In Section 4.1.1

It is stated that the value of "alg" is case sensitive.  It is stated that
it may be a URI.  URIs say that there may be case insensitive portions of
the URI value.  This needs to be reconciled.

 

From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, July 06, 2012 11:13 AM
To: Jim Schaad; [email-masked]
Subject: RE: json-web-encryption -02 comments

Thanks once again.  Responses inline.

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Thursday, June 07, 2012 11:56 AM
To: [email-masked]; [email-masked]
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.

[JLS] And I am suggesting that the introduction SHOULD address the fact that
a serialization method is presented in this document.  The process of
encryption and the process of serialization are separate things and both are
covered in this document.  This should be documented in the abstract.

This should also be picked up in the abstract as well.

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.

[JLS] I think that I find the concept that it represents the content as JSON
to be weird, since the final formatting is actually dotted notation if you
are looking at the "compact encryption format" that was covered in this
document.

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.

[JLS] I find this confusing.  A MAC also provides integrity protection and
that is in a different document.

Section 3

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

Done

Section 4 - JWE Header

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?

[JLS] This response would eliminate that ability to do a stream based
decode.  That would return decrypted data and then return the error.

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.

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?

[JLS] and how is that key known?  Is a wrapped key always required in this
case.  

Section 4.1.4 

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.

[JLS] Then I assume that the following is legal

{ alg:"RSA1_5", epk:{.}, .}

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.

[JLS]  I do not feel that this means that it should not be registered.  It
merely means that we will only register one, and we will make the bar very
high for the ability to register a second one.  Otherwise this should be a
Boolean with a value of true.  It either is or is not compressed.

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

following:

a) Get the keys

b) For each key -

   iii) Does it work?

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

[JLS] That is nice that you have added an example.  However this does not
mean that the text should not be clarified.  I think that you really want to
say that this field is an array of strings, each element in the array being
a base64url encoded certificate.  The certificates are ordered such that
certificate i is issued by certificate i+1. 

Is it legal for a partial chain to be presented or must the full chain
always be presented?

Is there a reason that you are not just using the PEM encoding in this
location as well?

If there is a requirement for having a chain of certificates in this
location, why is there not a requirement for having an array of certificates
in the x5t case? 

As a recipient I should never need more than the EE certificate in order to
map from a public key to a private key.   Other than letting me know what
the chain was that the sender used to validate my certificate, I don't know
what the reasoning behind sending the chain would be.

[JLS] A standard encoding would be using the PEM string or using a CMS certs
only.   Changing the base64url to remove trailing characters is not really
an issue.   Unless the new JavaScript CryptoAPIs (as an example) take a
base64 encoded certificate as input the user code is going to deal with the
encoding/decoding question anyway.

3. See comment 1 above

Ditto

Section 4.1.12

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

[JLS] This does nothing to change my statement above.  In fact it enforces
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.

[JLS] I do not believe that mime types and subtypes are case insensitive
values in MIME itself.  This needs to be resolved.

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

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.

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

Done

[JLS] I am asking that there only be one set of steps for doing this, and it
is for AEAD algorithms.  

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.

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

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 18 Jul 2012 15:44:04 +0000

Replies inline...

From: Jim Schaad [mailto:[email-masked]]
Sent: Monday, July 16, 2012 6:30 PM
To: Mike Jones; [email-masked]
Subject: RE: json-web-encryption -02 comments

In section 4 -

This returns different results depending on which test you are using for determining if the header is a JWE or a JWS.  This belies the last sentence in paragraph #2.

Your example is an invalid input - either invalid as a JWS because it includes the extra "enc" member or invalid as a JWE because "none" is not a valid encryption method.  In either case, the input MUST be rejected.

The sentence you are referring to reads:  "Both methods will yield the same result."  I will change this to "Both methods will yield the same result for all valid inputs."

(By the way, I suspect you were thinking of the example above in the context of enabling the option of direct symmetric encryption without using a CMK, per Open Issue 6 in JWA, which is good. :)  I plan to make a proposal on syntax for that later today.)

In Section 4.1.1

It is stated that the value of "alg" is case sensitive.  It is stated that it may be a URI.  URIs say that there may be case insensitive portions of the URI value.  This needs to be reconciled.

The intent is still that these fields be compared in a case sensitive manner.  These are not URIs you dereference - they are URIs used as identifiers.  We could add text something to the effect of "When a StringOrURI value is a URI and the URI scheme includes portions that are matched in a case insensitive manner, this specification requires those portions of the URI be expressed using only lowercase characters, so a case-sensitive equality test will be effective."  I'd add similar text to the registry instructions for these fields as well.  Does that clarification work for you?

                                                            -- Mike

From: Mike Jones [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, July 06, 2012 11:13 AM
To: Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: RE: json-web-encryption -02 comments

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

Introduction

[JLS] And I am suggesting that the introduction SHOULD address the fact that a serialization method is presented in this document.  The process of encryption and the process of serialization are separate things and both are covered in this document.  This should be documented in the abstract.

[JLS] I think that I find the concept that it represents the content as JSON to be weird, since the final formatting is actually dotted notation if you are looking at the "compact encryption format" that was covered in this document.

[JLS] I find this confusing.  A MAC also provides integrity protection and that is in a different document.

Section 3

Done

Section 4 - JWE Header

[JLS] This response would eliminate that ability to do a stream based decode.  That would return decrypted data and then return the error.

Section 4.1.1

Section 4.1.2

1. See comment 2 above

Ditto

Corrected

[JLS] and how is that key known?  Is a wrapped key always required in this case.

Section 4.1.4

Section 4.1.5

{ alg:"RSA1_5", epk:{...}, ...}

Done

Done

Section 4.1.6

[JLS]  I do not feel that this means that it should not be registered.  It merely means that we will only register one, and we will make the bar very high for the ability to register a second one.  Otherwise this should be a Boolean with a value of true.  It either is or is not compressed.

Section 4.1.7

following:

a) Get the keys

b) For each key -

   iii) Does it work?

Section 4.1.8

1.  See comment 1 above.

Ditto

Section 4.1.9

Section 4.1.11

[JLS] That is nice that you have added an example.  However this does not mean that the text should not be clarified.  I think that you really want to say that this field is an array of strings, each element in the array being a base64url encoded certificate.  The certificates are ordered such that certificate i is issued by certificate i+1.

Is it legal for a partial chain to be presented or must the full chain always be presented?

Is there a reason that you are not just using the PEM encoding in this location as well?

If there is a requirement for having a chain of certificates in this location, why is there not a requirement for having an array of certificates in the x5t case?

As a recipient I should never need more than the EE certificate in order to map from a public key to a private key.   Other than letting me know what the chain was that the sender used to validate my certificate, I don't know what the reasoning behind sending the chain would be.

[JLS] A standard encoding would be using the PEM string or using a CMS certs only.   Changing the base64url to remove trailing characters is not really an issue.   Unless the new JavaScript CryptoAPIs (as an example) take a base64 encoded certificate as input the user code is going to deal with the encoding/decoding question anyway.

3. See comment 1 above

Ditto

Section 4.1.12

[JLS] This does nothing to change my statement above.  In fact it enforces it.

Section 4.1.13

[JLS] I do not believe that mime types and subtypes are case insensitive values in MIME itself.  This needs to be resolved.

Section 4.2

(Ditto for section 4.3)

Section 5

key wrap key

Done

[JLS] I am asking that there only be one set of steps for doing this, and it is for AEAD algorithms.

Section 6

Done

Section 7

Section 8.1

Done

Section 11.1

Will do

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 18 Jul 2012 19:47:42 -0700

From: Mike Jones [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2012 8:44 AM
To: Jim Schaad; [email-masked]
Subject: RE: json-web-encryption -02 comments

Replies inline.

In section 4 -

Your example is an invalid input - either invalid as a JWS because it
includes the extra "enc" member or invalid as a JWE because "none" is not a
valid encryption method.  In either case, the input MUST be rejected.

[JLS2] It is not clear to me that this is a correct statement.  My
implementation does understand both alg and enc - I don't see anything that
says they must occur only in the correct contexts.  This is also going to be
effected by the discussion of permit or deny for unknown headers that is
being discussed elsewhere.

The sentence you are referring to reads:  "Both methods will yield the same
result."  I will change this to "Both methods will yield the same result for
all valid inputs."

[JLS2] So you are comfortable with the fact that different implementations
may respond with different error messages based on how they go about doing
the checking of what the structure is going to be.  - Specifically if they
think that a signed or an encrypted message is going to come first.

(By the way, I suspect you were thinking of the example above in the context
of enabling the option of direct symmetric encryption without using a CMK,
per Open Issue 6 in JWA, which is good. J  I plan to make a proposal on
syntax for that later today.)

In Section 4.1.1

The intent is still that these fields be compared in a case sensitive
manner.  These are not URIs you dereference - they are URIs used as
identifiers.  We could add text something to the effect of "When a
StringOrURI value is a URI and the URI scheme includes portions that are
matched in a case insensitive manner, this specification requires those
portions of the URI be expressed using only lowercase characters, so a
case-sensitive equality test will be effective."  I'd add similar text to
the registry instructions for these fields as well.  Does that clarification
work for you?

[JLS2] by itself it does not deal with all of the possible issues.  I don't
think it matters that they are for de-reference or not.  The issue is the
same in all cases.  However besides the issue of case, there are also
questions on using quoting characters, equivalent characters, utf8 encoding,
I don't know if there is a problem with doing canonicalization of order of
composite characters or not.

                                                            -- Mike

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

Introduction

 

Section 3

Done

Section 4 - JWE Header

Section 4.1.1

Section 4.1.2

1. See comment 2 above

Ditto

Corrected

Section 4.1.4 

Section 4.1.5 

Done

Done

Section 4.1.6

Section 4.1.7

following:

a) Get the keys

b) For each key -

   iii) Does it work?

Section 4.1.8

1.  See comment 1 above.

Ditto

Section 4.1.9

Section 4.1.11

3. See comment 1 above

Ditto

Section 4.1.12

Section 4.1.13

Section 4.2

(Ditto for section 4.3)

Section 5

key wrap key

Done

Section 6

Done

Section 7

Section 8.1

Done

Section 11.1

Will do

---

From: Mike Jones <[email-masked]>
Date: Fri, 20 Jul 2012 22:14:46 +0000

[mbj2] Replies inline...

From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, July 18, 2012 7:48 PM
To: Mike Jones; [email-masked]
Subject: RE: json-web-encryption -02 comments

Replies inline...

From: Jim Schaad [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, July 16, 2012 6:30 PM
To: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: RE: json-web-encryption -02 comments

In section 4 -

[JLS2] It is not clear to me that this is a correct statement.  My implementation does understand both alg and enc - I don't see anything that says they must occur only in the correct contexts.  This is also going to be effected by the discussion of permit or deny for unknown headers that is being discussed elsewhere.

[mbj2] Fair enough - I'll make this more explicit so that it's clear that for a JWS only JWS fields must be used and similarly for JWE.  Actually, your example provides good support for the current position that not-understood values must be rejected.

[JLS2] So you are comfortable with the fact that different implementations may respond with different error messages based on how they go about doing the checking of what the structure is going to be.  - Specifically if they think that a signed or an encrypted message is going to come first.

[mbj2] Yes.  First, we're not specifying error messages - only accept/reject behaviors.  And whether the implementation uses "alg":"none" to start JWS processing and rejects the input because of the invalid "enc" member or whether it uses the presence of the "enc" member to start JWE processing and rejects the input because of the invalid "alg" value, the result is still the same - rejecting the input.

In Section 4.1.1

[JLS2] by itself it does not deal with all of the possible issues.  I don't think it matters that they are for de-reference or not.  The issue is the same in all cases.  However besides the issue of case, there are also questions on using quoting characters, equivalent characters, utf8 encoding, I don't know if there is a problem with doing canonicalization of order of composite characters or not.

[mbj2] I'll clarify this then to indicate that comparison is to be done on the values provided as-is, with no escape processing or canonicalization performed of any kind (other than the escape processing involved in parsing the JSON string itself).

Thanks again for helping to clarify the specs.

                                                          -- Mike

                                                            -- Mike

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

Introduction

Section 3

Done

Section 4 - JWE Header

Section 4.1.1

Section 4.1.2

1. See comment 2 above

Ditto

Corrected

Section 4.1.4

Section 4.1.5

Done

Done

Section 4.1.6

Section 4.1.7

following:

a) Get the keys

b) For each key -

   iii) Does it work?

Section 4.1.8

1.  See comment 1 above.

Ditto

Section 4.1.9

Section 4.1.11

3. See comment 1 above

Ditto

Section 4.1.12

Section 4.1.13

Section 4.2

(Ditto for section 4.3)

Section 5

key wrap key

Done

Section 6

Done

Section 7

Section 8.1

Done

Section 11.1

Will do