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.
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. 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. 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. Burt and Scott _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
