Subject: Re: [jose] Comments on draft-ietf-jose-json-web-algorithms-02

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

Thanks for taking the time to provide the detailed feedback.  Responses inline...

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, May 21, 2012 3:46 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Comments on draft-ietf-jose-json-web-algorithms-02

Here are comments this document

Abstract

1.  Since I called it out for JWK I will make the comment that I do not have a problem with enumerate in this document.

Noted

Section 1

1.  Just a comment - I am not sure why you feel the name to create a specific acronym for this document but it does not really matter.

It provides a shorthand name to refer to this document from others.

2.  Need to expand JSON if you are going to use it.

Not done here, because the word "JSON" here is used as part of a name, rather than as a reference to a specification or kind of data structure.  I did expand it the first time it is used to refer to the RFC 4627 data structures, in all the documents.

3.  New paragraph for sentence starting with "Enumerating..."  Separate justification from what this document does and hash.

Done

4.  Move last sentence to the end of the first paragraph

Done

Section 2

1.  In general I would like to see this duplicated into this document.

Readers should not have to reference another document for this purpose.

Done

Section 3.1

1.  I am not overly happy with the existence of a "none" algorithm.  Does it really need to exist?

Yes.  It is already widely used in contexts where content can be either signed or plaintext.  And while it used to be defined in JWT, you'd earlier suggested that it be moved here, since it is of broader applicability than just JWTs.

Section 3.2

1.  You may want to reference RFC4231 as well.  It contains test vectors and such for the SHA2 HMACs

If this spec were about implementing the SHA2 HMAC algorithms, I would agree, but since it's only about using them, I don't think this reference is necessary.  Feel free to push back on this, however...

2.  HMAC SHA-256 is a MAC function not a hash function (para #2)

Removed use of the incorrect designation

3.  I have not yet read the updated JWS document, but I do worry about the fact that this document is saying that the output should be base64url encoded.  If the JWS document says the same thing injudiciously then one could easily see that people might double encode the result.

I don't think there's a problem, as both documents make a clear distinction between the "JWS Signature" value and the "Encoded JWS Signature" value, and are careful to use the right term in the right place.  (But obviously send me corrections if you find a place where the wrong term is used.)

4.  I have a real problem with people saying that UTF-8 and ASCII are the same.  They aren't and saying that they are does not make it so.

They actually are the same in this case, since the JWS Secured Input consists of only 7-bit ASCII characters (since they contain only base64url encoded content and periods characters) that are represented the same in both encodings.  But I agree that the previous text was potentially confusing and overly verbose.  The text now only uses the phrase "the ASCII representation of the JWS Secured Input", both here, and in the JWS spec.

5.  I find it confusing to constantly refer to the JWS specification throughout this text.  For one thing it makes it harder to refer to these documents for other uses in JSON of these algorithms (such as for an encrypt and MAC algorithm).

These defined terms have now been incorporated into this document, per your comment on Section 2, so there should be no longer any need to refer to the JWS spec to understand this section.

Section 3.3

1.  I am not sure why there is a reference to both RFC 3447 and FIPS 186-3.

RSA v1.5 is fully defined and described in 3447.

I eliminated the redundant reference

2.  I would move the justification of PKCS v1.5 to security considerations and not put it here.

Done

Section 3.4

1.  I am not sure that the statement on key sizes makes any sense given that a key size is implied by the group being used.

Removed

2.  Given that we are using JSON as the basic structure - why not use a JSON structure rather than concatenate - just the question of size?

The concatenation is the standard representation produced by most implementations.  I added a note to this effect in the spec.  (And yes, the size is better as well.)

3.  If you are doing a guide for idiots - then you need to give the array sizes for R and S for each of the algorithms

Done for all the signing/MAC algorithms.  This is especially important for ES512, where the signature output size is a 132 byte array, which might surprise some people.  (It's the concatenation two 66 byte arrays, each representing a 521 bit integer.)  In fact, I added an example of ES512 to the spec for this very reason.

4.  I have never see the R,S pair be referred to as a point before.  I believe it is just an ordered pair of integers and not a point on the field.

The "point" terminology is used by XML DSIG 2.0, at least about the (x, y) pair.  See http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/#sec-ECKeyValue.  I could be wrong that (R, S) are also a point, but given that the P-521 signature is a pair of 521-bit integers, it sure seems like it is.  Any ECDSA experts care to weigh in?

5.  The following sentence puzzles me "The ECDSA validator will then determine if the digital signature is

   valid, given the inputs."   This sentence is just after the steps of how

to do validation so saying it will then be validated does not make sense to me.

Deleted

Section 3.5

1. I would put the justification for plaintext JWS in JWS not here.  In fact I would almost prefer a version of JWS that omitted the alg parameter to say that it has no security than what is done here.  I think this entire section should be moved into JWS.

Since "none" is an algorithm, it's in the JWA spec.  Section 3.5 describes how to create a JWS using it, just like Sections 3.2, 3.3, 3.4 describe how to create JWSs using other algorithms.  I've changed the title of this section to 'Using the Algorithm "none"' to make it more parallel and removed the justification text.  A modified version of it appears in a new paragraph in the Security Considerations section, making it clear that since this algorithm provides no integrity protection, and that it should only be used in certain contexts.

Section 3.6

1.  I don't see the purpose of the last paragraph in this section.  It has nothing to do with algorithms.

This subsection is not only about algorithms - it's about extensions to JWS, the parameters registry for which is also in the JWA spec because it's shared between JWS and JWE.  The first and second paragraphs of this subsection is about extensions via algorithms and has a reference to that JWA registry.  The third paragraph is about extensions via parameters, and has a reference to that JWA registry.  Not that 3.6 is parallel to 4.11 which has the same content for JWEs.

All that being said, I'd be open to a different editorial structuring, if someone wants to make an alternative proposal.

Section 4.5

1.  RSA-OAEP is under specified.  There are a number of parameters for OAEP that must be defined to go with it.  These include the mask function and a hash function.  Look at RFC 3447 for the details.

This is now fully specified.  The description now reads:  RSA using Optimal Asymmetric Encryption Padding (OAEP), as defined in RFC 3447, with the default parameters specified by RFC 3447 in Section A.2.1

Section 4.6

1.  I would rephrase the last paragraph as being you must re-generate a new EPK for each key agreement done rather than saying that you cannot reuse them.  The way specified might say that you can never re-use them rather than you should only rarely re-use them and in an unpredictable manner.

Done

2.  I strongly disagree with setting OtherInfo parameters to be empty.   We

need to define and fill in the AlgorithmId at a minimum.  Note that this can be an implicit computation and does not need to be carried as extra data.

At a minimum I would suggest something along the lines of JOSE-### where ### is the number of bits to get generated.

Per my response to Sean's related comment, it's not clear to me what additional value these parameters add in our usage of the algorithm.  If we believe that the content master key is undeterminable by an attacker (a requirement for any security at all!) then adding a constant AlgorithmID to the computation I don't believe changes the security properties.  (That being said, we *could* use the "alg" value "ECDH-ES" as the AlgorithmID if people felt better about doing this.)

Also given that the text now says (per your previous comment) that "A new epk (ephemeral public key) value MUST be generated for each key agreement transaction", it's not clear that adding parameters identifying the participating parties adds any security value either.  That being said, I'd be glad to learn why I'm wrong.

If there are good security reasons for requiring PartyUInfo and PartyVInfo values, do you have suggestions on how to create acceptable values without carrying more parameters in the header?  (I've already suggested that we could use the "alg" value "ECDH-ES" as the AlgorithmID, which wouldn't require more parameters.)

For instance, I don't want to blindly follow XML ENC's lead and punt the issue by requiring that conforming uses provide explicit PartyUInfo and PartyVInfo values.

Finally, I'll note that the KDF function used by TLS http://tools.ietf.org/html/rfc5246#section-5 uses no party parameters.  Why do we need them then?

3.  Same comment as above about key sizes - key sizes are specified by the curve being used.

Deleted

Section 4.8

1. Use of an IV is REQUIRED not RECOMMENDED

Done.  Now reads:  Use of an initialization vector of size 128 bits is REQUIRED with this algorithm.

Section 4.9

1.  Specification of the data to be processed needs to be in JWE not in this document.  It should just specify that there are the following inputs:

Additional data and data to be encrypted.   Interesting question of is this

where the key is generated or not - I would ignore that issue.

The computation of the "additional authenticated data" value is now only in the JWE spec and referenced from this section of JWA

Section 4.10

1.  Is this section needed?  It is a duplicate of the same data in section

3.2 (or it should be)

Now references Section 3.2 and only describes the differences

Section 4.11

1.  for last paragraph see comment on 3.6

Same response as for 3.6

Section 6.1

1.  I would move this registry to either the signature or encryption documents and not put it here.  What does this document populate it with?

Done

Section 6.2

1.  Make life easy for IANA and me - create a table of the values

Done both here and in the other documents

2.  Can an algorithm have more than one usage?

Yes, clarified in doc

Section 6.3

1.  This registry should be in either the encryption or signature draft

Done - now in JWS

Section 6.4

1.  This registry should be in the JWK document

Done

Section 6.5

1.  Make life easy for IANA and me - create a table of the values

Done both here and in the other documents

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 8 Jul 2012 22:16:09 -0700

Responses to previous comments and some new comments.

Open issue feedback - Do AES ECB - no

From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, July 06, 2012 10:41 AM
To: 'Jim Schaad'
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02

Thanks for taking the time to provide the detailed feedback.  Responses
inline.

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, May 21, 2012 3:46 PM
To: Mike Jones
Cc: [email-masked]
Subject: Comments on draft-ietf-jose-json-web-algorithms-02

Abstract

1.  Since I called it out for JWK I will make the comment that I do not have
a problem with enumerate in this document.

Noted

[JLS] On the other had since you said it was addressed in the mail for the
JWK document and it is not changed I do have a problem there.

Section 1

1.  Just a comment - I am not sure why you feel the name to create a
specific acronym for this document but it does not really matter.

Not done here, because the word "JSON" here is used as part of a name,
rather than as a reference to a specification or kind of data structure.  I
did expand it the first time it is used to refer to the RFC 4627 data
structures, in all the documents.

[JLS]  The rules state that it is to be expanded on the first use.  If it is
not done on the first use then the RFC editor will do so.  It should be ok
in the key document since it is done almost immediately after the first use.
As it currently stands it does not follow this rule.

3.  New paragraph for sentence starting with "Enumerating..."  Separate
justification from what this document does and hash.

Done

Done

Section 2

Done

[JLS] However only the relevant terms should be included.  If JWE Ciphertext
is never used then it does not need to be included at this point.

Section 3.1

1.  I am not overly happy with the existence of a "none" algorithm.  Does it
really need to exist?

Yes.  It is already widely used in contexts where content can be either
signed or plaintext.  And while it used to be defined in JWT, you'd earlier
suggested that it be moved here, since it is of broader applicability than
just JWTs.

[JLS] I don't disagree with it being here rather than in the JWT document.
However there is a question if it would be better represented as having an
absent alg parameter rather than having a "none" algorithm.  It would
accomplish the same thing and be less suggested if an actual signature/MAC
algorithm existing on the document.

Section 3.2

1.  You may want to reference RFC4231 as well.  It contains test vectors and
such for the SHA2 HMACs

If this spec were about implementing the SHA2 HMAC algorithms, I would
agree, but since it's only about using them, I don't think this reference is
necessary.  Feel free to push back on this, however.

3.  I have not yet read the updated JWS document, but I do worry about the
fact that this document is saying that the output should be base64url
encoded.  If the JWS document says the same thing injudiciously then one
could easily see that people might double encode the result.

I don't think there's a problem, as both documents make a clear distinction
between the "JWS Signature" value and the "Encoded JWS Signature" value, and
are careful to use the right term in the right place.  (But obviously send
me corrections if you find a place where the wrong term is used.)

4.  I have a real problem with people saying that UTF-8 and ASCII are the
same.  They aren't and saying that they are does not make it so. 

They actually are the same in this case, since the JWS Secured Input
consists of only 7-bit ASCII characters (since they contain only base64url
encoded content and periods characters) that are represented the same in
both encodings.  But I agree that the previous text was potentially
confusing and overly verbose.  The text now only uses the phrase "the ASCII
representation of the JWS Secured Input", both here, and in the JWS spec.

[JLS] Do you know this to be a true statement for all future encodings of
JWS values as oppose to the current one that is defined in JWS.  For
example, in the documents proposed by myself and Richard this is not a true
statement.  Instead the header is UTF8 encoded and that value is processed
without having done the ASCII encoding from base64url.

5.  I find it confusing to constantly refer to the JWS specification
throughout this text.  For one thing it makes it harder to refer to these
documents for other uses in JSON of these algorithms (such as for an encrypt
and MAC algorithm).

These defined terms have now been incorporated into this document, per your
comment on Section 2, so there should be no longer any need to refer to the
JWS spec to understand this section.

[JLS] That does not address my concern.  If you do a combo HMAC and encrypt
algorithm are you going to suddenly turn the header and content into a JWS
Secured Input? (And do they suddenly become US ASCII strings?)

Section 3.4

4.  I have never see the R,S pair be referred to as a point before.  I
believe it is just an ordered pair of integers and not a point on the field.

The "point" terminology is used by XML DSIG 2.0, at least about the (x, y)
pair.  See
http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124/#sec-ECKeyValue.  I
could be wrong that (R, S) are also a point, but given that the P-521
signature is a pair of 521-bit integers, it sure seems like it is.  Any
ECDSA experts care to weigh in?

[JLS] A fast review of the algorithm on Wikipedia confirms what I was
thinking.  The value of R is obtained from a point on the field  (using just
k) and the value S is then computed from the value of x and the hash value.
This means that (r,s) is not a point on the field. 

Section 3.6

1.  I don't see the purpose of the last paragraph in this section.  It has
nothing to do with algorithms.

This subsection is not only about algorithms - it's about extensions to JWS,
the parameters registry for which is also in the JWA spec because it's
shared between JWS and JWE.  The first and second paragraphs of this
subsection is about extensions via algorithms and has a reference to that
JWA registry.  The third paragraph is about extensions via parameters, and
has a reference to that JWA registry.  Not that 3.6 is parallel to 4.11
which has the same content for JWEs.

All that being said, I'd be open to a different editorial structuring, if
someone wants to make an alternative proposal.

Section 4.5 

1.  RSA-OAEP is under specified.  There are a number of parameters for OAEP
that must be defined to go with it.  These include the mask function and a
hash function.  Look at RFC 3447 for the details.

This is now fully specified.  The description now reads:  RSA using Optimal
Asymmetric Encryption Padding (OAEP), as defined in RFC 3447, with the
default parameters specified by RFC 3447 in Section A.2.1

[JLS] It is strongly recommended that the hash function for OAEP and the
hash function for the content be the same values.  Additionally, why would
we recommend using SHA1 for any of these parameters given that it is not
recommended for any other purpose?

Section 4.6

need to define and fill in the AlgorithmId at a minimum.  Note that this can
be an implicit computation and does not need to be carried as extra data.

At a minimum I would suggest something along the lines of JOSE-### where ###
is the number of bits to get generated.

Per my response to Sean's related comment, it's not clear to me what
additional value these parameters add in our usage of the algorithm.  If we
believe that the content master key is undeterminable by an attacker (a
requirement for any security at all!) then adding a constant AlgorithmID to
the computation I don't believe changes the security properties.  (That
being said, we *could* use the "alg" value "ECDH-ES" as the AlgorithmID if
people felt better about doing this.)

Also given that the text now says (per your previous comment) that "A new
epk (ephemeral public key) value MUST be generated for each key agreement
transaction", it's not clear that adding parameters identifying the
participating parties adds any security value either.  That being said, I'd
be glad to learn why I'm wrong.

If there are good security reasons for requiring PartyUInfo and PartyVInfo
values, do you have suggestions on how to create acceptable values without
carrying more parameters in the header?  (I've already suggested that we
could use the "alg" value "ECDH-ES" as the AlgorithmID, which wouldn't
require more parameters.)

For instance, I don't want to blindly follow XML ENC's lead and punt the
issue by requiring that conforming uses provide explicit PartyUInfo and
PartyVInfo values.

Finally, I'll note that the KDF function used by TLS
http://tools.ietf.org/html/rfc5246#section-5 uses no party parameters.  Why
do we need them then?

[JLS] The object of having the algorithm identifier be present is to make
sure that if you are doing two kdfs from the same key pairs for different
purposes that they will never end up generating the same key values (or a
prefix of the same key values).   While it is not immediate obvious that
this is going to be possible with the JOSE documents, it is a known security
issue and one that is easily addressed.  One way would be as I suggested
above and used a string with the number of bits.  Another way would be to
use the algorithm that the key is going to be used for (which is how it is
defined).  Thus this should be the ACUTAL content encryption algorithm used
(i.e. AES128GW or AES128CBC+HS256).

At this point I now would say that the KDF MUST have the ability to have a
PartyUInfo value specified.  When the KDF was implicit in the key agreement
algorithm tag it did not matter.  At that point if someone defined a new
static-static version of ECDH then they would be required to define what KDF
function was to be used and could then require that the PartyUInfo field be
defined in the KDF function that required.  As it stands now, the KDF is no
longer tied to the key agreement algorithm and must therefore meet the
necessary security requirements for a static-static version of DH as well as
the ephemeral static versions.  (On the other hand it still may be implicit,
but this was not completely obvious as there is a kdf function that would be
used in some cases leading to a confusion about what the kdf function was
actually being used for.)

For TLS, both the PartyUInfo and the PartyVInfo values are present and used
when computing the key from the master secret.  Since they are present at
that point they do not need to be present when computing the master secret
itself.   When using TLS to compute other secrets - such as a TLS Unque
value, the equivalent of the algorithm ID is used at that point to make sure
that all such keys computed are going to be unique to that purpose.

Section 4.11

Same response as for 3.6

Section 6.1

1.  I would move this registry to either the signature or encryption
documents and not put it here.  What does this document populate it with?

Done

Section 6.2

[JLS] What is the purpose of putting the Implementation Requirements into
the table?  Different applications may have different requirements and these
requirements may change over time.  It does not make sense to require the
table to be updated every time the set of requirements change.  The only
exception to that might be an obsoleted or do not use field, but even that
can be somewhat iffy.

Section 6.3

Done - now in JWS

Section 6.4

Done

Section 6.5

---

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

Responses inline...

From: Jim Schaad [mailto:[email-masked]]
Sent: Sunday, July 08, 2012 10:16 PM
To: Mike Jones
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02

From: Mike Jones [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Friday, July 06, 2012 10:41 AM
To: 'Jim Schaad'
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, May 21, 2012 3:46 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Comments on draft-ietf-jose-json-web-algorithms-02

Abstract

Noted

[JLS] On the other had since you said it was addressed in the mail for the JWK document and it is not changed I do have a problem there.

Saying in the JWK feedback that it was addressed in JWA was a typo in my e-mail on my part.  I intentionally did not change away from the word "enumerates" in JWA both since you said that you *didn't* have a problem with it, and because I believe it accurately conveys what the JWA document does.  But I'd be open to an alternative description if you'd like to supply wording that's even clearer.

Section 1

[JLS]  The rules state that it is to be expanded on the first use.  If it is not done on the first use then the RFC editor will do so.  It should be ok in the key document since it is done almost immediately after the first use.  As it currently stands it does not follow this rule.

How would adding a sentence like this work for you?

"All these specifications utilize JavaScript Object Notation (JSON) [RFC4627] based data structures."

Done

Done

Section 2

Done

[JLS] However only the relevant terms should be included.  If JWE Ciphertext is never used then it does not need to be included at this point.

Agreed.  I already did a pass and removed unused terms.  In the example of JWE Ciphertext, this term is used in the definition of JWE Header, which is used in the body of the specification, and so is necessary.  If you find some that are not used directly or indirectly, please point them out, and I'll remove them.

Section 3.1

[JLS] I don't disagree with it being here rather than in the JWT document.  However there is a question if it would be better represented as having an absent alg parameter rather than having a "none" algorithm.  It would accomplish the same thing and be less suggested if an actual signature/MAC algorithm existing on the document.

The due diligence that users of  "alg":"none" have to perform is actually no less than the due diligence that they have to apply when using any other "alg" value.  At some future time, for instance, if HMAC SHA-256 is broken, then using "HS256" would be arguably be worse than using "none", because "HS256" might provide the illusion of security, where in fact, there would be none - sort of like if someone were to propose to use "HMD5" now.  That there's no security is at least apparent with "none". :)

Algorithms must always be used that are security-appropriate given the needs of the application in the particular context and the current state of cryptography/cryptanalysis.  Having a "none" algorithm doesn't change that.

Section 3.2

[JLS] Do you know this to be a true statement for all future encodings of JWS values as oppose to the current one that is defined in JWS.  For example, in the documents proposed by myself and Richard this is not a true statement.  Instead the header is UTF8 encoded and that value is processed without having done the ASCII encoding from base64url.

It's true of all of the JOSE working group documents.  If the working decides to change this, at that point we would, of course, make an appropriate companion change to these statements.

[JLS] That does not address my concern.  If you do a combo HMAC and encrypt algorithm are you going to suddenly turn the header and content into a JWS Secured Input? (And do they suddenly become US ASCII strings?)

Actually, I suspect that the JWS Secured Input would be the concatenation of the header, encrypted key, and ciphertext, just as is done now, assuming that a JWS-based computation is done within the composite algorithm to compute the JWE Integrity Value.  There's actually nothing about the JWS computation that requires that the secured value is ASCII; by the point the HMAC computation is done, the secured input is a byte array.  (The text about "bytes of the ASCII representation of..." is about how to create the byte values for that array, given the particular choices in the current specifications.)

Is there are particular wording change that you'd suggest that doesn't change the semantics of the specifications, but would be easier for developers to understand?

Section 3.4

[JLS] A fast review of the algorithm on Wikipedia confirms what I was thinking.  The value of R is obtained from a point on the field  (using just k) and the value S is then computed from the value of x and the hash value.  This means that (r,s) is not a point on the field.

OK, I'll reword.  Thanks for the research.

Section 3.6

Section 4.5

[JLS] It is strongly recommended that the hash function for OAEP and the hash function for the content be the same values.  Additionally, why would we recommend using SHA1 for any of these parameters given that it is not recommended for any other purpose?

This has to do with the working group's goal of having developers actually be able to deploy the resulting specification.  Using the .NET Framework as an example (because it's one that I'm familiar with), the RSA encryption choices available are PKCS 1-1.5 and OAEP with the default parameters.  A .NET JWE implementation would be extremely difficult if we stray from what's actually deployed.

If you look at PHP, Ruby, Python, OpenSSL, MacOS, Android, iOS, Windows Phone, etc. as actually deployed, you'll find similar limitations.  (In fact, you will not find OAEP support at all on some of these developer platforms.)

We could delete OAEP entirely on that basis if the working group chooses, or make it DEPRECATED, rather than OPTIONAL, but I don't believe that defining variants using non-default parameters would be useful, given that they couldn't be used on most development platforms.

On a related note, some colleagues and I have started to gather data on what JWA algorithms are implemented on what development platforms.  I'll send a separate note shortly requesting presentation time during the meeting to discuss and help refine the data that we've gathered.

Section 4.6

[JLS] The object of having the algorithm identifier be present is to make sure that if you are doing two kdfs from the same key pairs for different purposes that they will never end up generating the same key values (or a prefix of the same key values).   While it is not immediate obvious that this is going to be possible with the JOSE documents, it is a known security issue and one that is easily addressed.  One way would be as I suggested above and used a string with the number of bits.  Another way would be to use the algorithm that the key is going to be used for (which is how it is defined).  Thus this should be the ACUTAL content encryption algorithm used (i.e. AES128GW or AES128CBC+HS256).

I suspect that using the concatenation of the "enc" and "int" values as the AlgorithmID, as you suggest above, is the right solution when doing Key Derivation.  This is already on the Open Issues list to discuss on the mailing list and in Vancouver.

At this point I now would say that the KDF MUST have the ability to have a PartyUInfo value specified.  When the KDF was implicit in the key agreement algorithm tag it did not matter.  At that point if someone defined a new static-static version of ECDH then they would be required to define what KDF function was to be used and could then require that the PartyUInfo field be defined in the KDF function that required.  As it stands now, the KDF is no longer tied to the key agreement algorithm and must therefore meet the necessary security requirements for a static-static version of DH as well as the ephemeral static versions.  (On the other hand it still may be implicit, but this was not completely obvious as there is a kdf function that would be used in some cases leading to a confusion about what the kdf function was actually being used for.)

Key Agreement and Key Derivation are different cases.  In the case of Key Agreement, the KDF *is* tightly bound to the algorithm definition.  See the definition of "ECDH-ES" in http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-03#section-4.1.  Note also that use of a unique random ephemeral public key is required, so unless your keygen algorithm is broken, there's no chance of generating the same derived keys.

I believe it's already clear in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-03#section-4.1.4 that the "kdf" member is used in the Key Derivation case - not the Key Agreement case.  But we can tighten this language further, if you'd like to suggest better wording.

For TLS, both the PartyUInfo and the PartyVInfo values are present and used when computing the key from the master secret.  Since they are present at that point they do not need to be present when computing the master secret itself.   When using TLS to compute other secrets - such as a TLS Unque value, the equivalent of the algorithm ID is used at that point to make sure that all such keys computed are going to be unique to that purpose.

I believe you're discussing the Key Derivation case in the above paragraph.  Again, I think that using the concatenation of the "enc" and "int" values as the AlgorithmID may be the right outcome for Key Derivation.  But just as in the Key Agreement case, given that a unique random CMK value MUST be used, there's no chance of generating the same derived keys for other parties, unless the keygen algorithm generates duplicate keys (in which case you have bigger problems).

That being said, if there's a way of utilizing PartyUInfo and PartyVInfo values in the KDF computation that doesn't involve carrying them as additional header parameter values, I'd certainly personally be open to that as well.

Section 4.11

Same response as for 3.6

Section 6.1

Done

Section 6.2

[JLS] What is the purpose of putting the Implementation Requirements into the table?  Different applications may have different requirements and these requirements may change over time.  It does not make sense to require the table to be updated every time the set of requirements change.  The only exception to that might be an obsoleted or do not use field, but even that can be somewhat iffy.

Sean Turner had suggested this.  Apparently it is done in other specifications and registries.  (Examples, Sean?)  It's certainly easier for implementers to understand, because they'll always be able to count on the registry's implementation status to be up to date.  This can change, for instance, as algorithms move from OPTIONAL to RECOMMENDED to REQUIRED, or when they move from any of those states to DEPRECATED.

Section 6.3

Done - now in JWS

Section 6.4

Done

Section 6.5

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 13 Jul 2012 16:53:54 -0700

From: Mike Jones [mailto:[email-masked]] 
Sent: Friday, July 13, 2012 2:21 PM
To: Jim Schaad
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02

Responses inline.

 

 

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, May 21, 2012 3:46 PM
To: Mike Jones
Cc: [email-masked]
Subject: Comments on draft-ietf-jose-json-web-algorithms-02

Abstract

Noted

Saying in the JWK feedback that it was addressed in JWA was a typo in my
e-mail on my part.  I intentionally did not change away from the word
"enumerates" in JWA both since you said that you *didn't* have a problem
with it, and because I believe it accurately conveys what the JWA document
does.  But I'd be open to an alternative description if you'd like to supply
wording that's even clearer.

Section 1

"All these specifications utilize JavaScript Object Notation (JSON)
[RFC4627] based data structures."

[JLS2] that would address the problem.

Done

Done

Section 2

Done

Agreed.  I already did a pass and removed unused terms.  In the example of
JWE Ciphertext, this term is used in the definition of JWE Header, which is
used in the body of the specification, and so is necessary.  If you find
some that are not used directly or indirectly, please point them out, and
I'll remove them.

Section 3.1

The due diligence that users of  "alg":"none" have to perform is actually no
less than the due diligence that they have to apply when using any other
"alg" value.  At some future time, for instance, if HMAC SHA-256 is broken,
then using "HS256" would be arguably be worse than using "none", because
"HS256" might provide the illusion of security, where in fact, there would
be none - sort of like if someone were to propose to use "HMD5" now.  That
there's no security is at least apparent with "none". J

Algorithms must always be used that are security-appropriate given the needs
of the application in the particular context and the current state of
cryptography/cryptanalysis.  Having a "none" algorithm doesn't change that.

[JLS] I would disagree based on past history.  But will no press the issue,

Section 3.2

It's true of all of the JOSE working group documents.  If the working
decides to change this, at that point we would, of course, make an
appropriate companion change to these statements.

Actually, I suspect that the JWS Secured Input would be the concatenation of
the header, encrypted key, and ciphertext, just as is done now, assuming
that a JWS-based computation is done within the composite algorithm to
compute the JWE Integrity Value.  There's actually nothing about the JWS
computation that requires that the secured value is ASCII; by the point the
HMAC computation is done, the secured input is a byte array.  (The text
about "bytes of the ASCII representation of." is about how to create the
byte values for that array, given the particular choices in the current
specifications.)

Is there are particular wording change that you'd suggest that doesn't
change the semantics of the specifications, but would be easier for
developers to understand?

[JLS2]  My point is that you can write all of this text purely in terms of -
this is the input that you are dealing with.  I don't care what the input is
or where it came from, this is the input value.  This is the output value.
Based on the input value you get this output value by doing this.  Again - I
don't care what the using specification calls these fields because it does
not matter in terms of implementing the crypto function that does algorithm
FOO.

Section 3.4

Section 3.6

Section 4.5 

This has to do with the working group's goal of having developers actually
be able to deploy the resulting specification.  Using the .NET Framework as
an example (because it's one that I'm familiar with), the RSA encryption
choices available are PKCS 1-1.5 and OAEP with the default parameters.  A
.NET JWE implementation would be extremely difficult if we stray from what's
actually deployed.

If you look at PHP, Ruby, Python, OpenSSL, MacOS, Android, iOS, Windows
Phone, etc. as actually deployed, you'll find similar limitations.  (In
fact, you will not find OAEP support at all on some of these developer
platforms.)

We could delete OAEP entirely on that basis if the working group chooses, or
make it DEPRECATED, rather than OPTIONAL, but I don't believe that defining
variants using non-default parameters would be useful, given that they
couldn't be used on most development platforms.

On a related note, some colleagues and I have started to gather data on what
JWA algorithms are implemented on what development platforms.  I'll send a
separate note shortly requesting presentation time during the meeting to
discuss and help refine the data that we've gathered.

[JLS2] I think that defining the set of algorithms based on the fact that
Microsoft does not have people who understand what is necessary for crypto
code is probably a bad idea.  If we go with what is deployed then we should
not do OAEP and just have RSA v1.5 anyway since as you stated there is not
universal deployment of OAEP anyway.

Section 4.6

I suspect that using the concatenation of the "enc" and "int" values as the
AlgorithmID, as you suggest above, is the right solution when doing Key
Derivation.  This is already on the Open Issues list to discuss on the
mailing list and in Vancouver.

Key Agreement and Key Derivation are different cases.  In the case of Key
Agreement, the KDF *is* tightly bound to the algorithm definition.  See the
definition of "ECDH-ES" in
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-03#section-4.
1.  Note also that use of a unique random ephemeral public key is required,
so unless your keygen algorithm is broken, there's no chance of generating
the same derived keys.

I believe it's already clear in
http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-03#section-4.
1.4 that the "kdf" member is used in the Key Derivation case - not the Key
Agreement case.  But we can tighten this language further, if you'd like to
suggest better wording.

I believe you're discussing the Key Derivation case in the above paragraph.
Again, I think that using the concatenation of the "enc" and "int" values as
the AlgorithmID may be the right outcome for Key Derivation.  But just as in
the Key Agreement case, given that a unique random CMK value MUST be used,
there's no chance of generating the same derived keys for other parties,
unless the keygen algorithm generates duplicate keys (in which case you have
bigger problems).

That being said, if there's a way of utilizing PartyUInfo and PartyVInfo
values in the KDF computation that doesn't involve carrying them as
additional header parameter values, I'd certainly personally be open to that
as well.

Section 4.11

Same response as for 3.6

Section 6.1

Done

Section 6.2

Sean Turner had suggested this.  Apparently it is done in other
specifications and registries.  (Examples, Sean?)  It's certainly easier for
implementers to understand, because they'll always be able to count on the
registry's implementation status to be up to date.  This can change, for
instance, as algorithms move from OPTIONAL to RECOMMENDED to REQUIRED, or
when they move from any of those states to DEPRECATED.

[JLS2] OK - I note that he asked the question about this, but I don't really
see any recommendation that it be done. 

Section 6.3

Done - now in JWS

Section 6.4

Done

Section 6.5

---

From: Mike Jones <[email-masked]>
Date: Sat, 14 Jul 2012 00:30:40 +0000

[mbj2] Additional responses...

From: Jim Schaad [mailto:[email-masked]]
Sent: Friday, July 13, 2012 4:54 PM
To: Mike Jones
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-jose-json-web-algorithms-02

Responses inline...

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, May 21, 2012 3:46 PM
To: Mike Jones
Cc: [email-masked]<mailto:[email-masked]>
Subject: Comments on draft-ietf-jose-json-web-algorithms-02

Abstract

Noted

Section 1

Done

Done

Section 2

Done

Section 3.1

Section 3.2

[JLS2]  My point is that you can write all of this text purely in terms of -  this is the input that you are dealing with.  I don't care what the input is or where it came from, this is the input value.  This is the output value.  Based on the input value you get this output value by doing this.  Again - I don't care what the using specification calls these fields because it does not matter in terms of implementing the crypto function that does algorithm FOO.

[mbj2] OK, I understand your point.  I've been using the names somewhat like variable names in mathematical presentations - so that there's a shorthand name for a specific value or function, but I'll look at whether it might be simpler in some cases to rely on direct explanations of input/output computations rather than relying on the variable names for those values or functions.

Section 3.4

Section 3.6

Section 4.5

[JLS2] I think that defining the set of algorithms based on the fact that Microsoft does not have people who understand what is necessary for crypto code is probably a bad idea.  If we go with what is deployed then we should not do OAEP and just have RSA v1.5 anyway since as you stated there is not universal deployment of OAEP anyway.

[mbj2] From your response, I think you took my example out of context.  The current algorithm set wasn't developed with only Microsoft in mind.  It was developed with all the common developer platforms in mind.  (PHP, Ruby, Python, OpenSSL, MacOS, Android, iOS, Windows Phone, Java, BouncyCastle, Objective C, Windows, etc. - and if you think that I'm missing some, please let me know.)  A bunch of us sat down at the Internet Identity Workshop and tried to systematically look across the developer documentation for the platforms above and determine what algorithms should actually be usable on most platforms and for which algorithms the deployment status is spottier.  That's the basis of the current REQUIRED/RECOMMENDED/OPTIONAL designations (and the basis of why some algorithms aren't listed at all).

Using the OAEP example, indeed, OAEP is presently optional in JWA precisely because it's not universally deployed.

The working group can obviously fine tune the algorithm set and Implementation Requirements.  If people believe we should add/subtract or change requirements for specific algorithms, by all means, let's have that discussion.

Section 4.6

Section 4.11

Same response as for 3.6

Section 6.1

Done

Section 6.2

[JLS2] OK - I note that he asked the question about this, but I don't really see any recommendation that it be done.

[mbj2] It made the spec easier to understand and simpler, so as an editor, it seemed like a good idea to me.

Section 6.3

Done - now in JWS

Section 6.4

Done

Section 6.5