Re: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorithms-25

[Mike Jones <[e-mail]>]

Thanks for the useful reviews, Scott and Burt.  Replies are inline.



-----Original Message-----
From: jose [mailto:[e-mail]] On Behalf Of Hollenbeck, Scott
Sent: Friday, April 04, 2014 5:43 PM
To: [e-mail]
Cc: Kaliski, Burt
Subject: [jose] WG Last Call Comments: draft-ietf-jose-json-web-algorithms-25



Sec. 3.4:  For ECDSA P-521 SHA-512, as noted, "R and S will be 521 bits each, resulting in a 132-octet sequence."  Unclear how R and S are to be converted into respective 66-octet values (pad with 0 bits on the left versus right).  Should be consistent with practice in other specifications, e.g., IEEE 1363.



Per http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#section-6.2.1.2, this is specified by the SEC1 specification, which the "x" and "y" definitions reference.  (SEC1 specifies padding on the left in Section 2.3.1 - "BitString-to-OctetString Conversion".)



Sec. 4.1:  Any interest in RSA-KEM as a CEK-determination method, e.g., as specified in RFC 5990?  RFC 5990 only provides a key-wrapping version (output of KDF, i.e., the KEK, is used to wrap the CEK), but the specification could be adapted to a "direct" version where the output of the KDF itself is used as a CEK.



The set of algorithms included in JWA are based upon a survey done of the algorithms that are actually widely deployed across common development tools, and will therefore result in interoperable implementations.  The results of that survey are captured in the attached spreadsheet.  During the survey, no one made the case that RSA-KEM was widely deployed, and therefore should be included in the standard set of algorithms.  That being said, there's nothing stopping people from writing a spec defining an RSA-KEM algorithm identifier and registering it in the JSON Web Signature and Encryption Algorithms Registry if it's useful in their application context.



Sec. 4.3:  RSAES-OAEP as defined in RFC 3447 allows other hash functions and MGFs than the default (MGF1 with SHA-1).  Because SHA1 is being phased out for other purposes (though not necessarily unsuitable for MGF1 or OAEP purposes), should SHA256/384/512 options also be specified here?  No algorithm identifiers / OIDs would need to be defined, just the JWK parameter syntax, e.g., in additional header parameters, or with a new "alg" header parameter.



This was discussed early in the working group.  Again, because the focus of the algorithms chosen is on ones that are actually widely deployed, the default OAEP settings were chosen.  Many implementations don't provide a way of specifying non-default OAEP parameters, and as you point out, SHA-1 for OAEP purposes is not unsuitable.  Again, if people want to define new algorithm identifiers for OAEP with different parameters, they can, but this won't necessarily result in widely interoperable implementations.



Sec. 4.6.2:  The AlgorithmID value is derived from either the "enc" or the "alg" header parameter value.  It is not clear whether the UTF-8 parameter value includes the tag as well as the value, or just the value.  In the latter case, to ensure cryptographic separation between the two cases, it should be stated elsewhere that the set of allowed "enc" and "alg" header parameter values should be distinct from one another.



The text says:
      In the Direct Key Agreement case,
      Data is set to the octets of the UTF-8 representation of the "enc"
      Header Parameter value.  In the Key Agreement with Key Wrapping
      case, Data is set to the octets of the UTF-8 representation of the
      "alg" Header Parameter value.



"Header Parameter value" as used in JWE is just the value - not also the name, which is called "Header Parameter name".  Per your second comment, the "Direct Key Agreement case" only occurs when "alg" is "dir", so there's no actual ambiguity.



Burt and Scott



                                                                Best wishes,

                                                                -- Mike

_______________________________________________

jose mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/jose