This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
These rather cosmetic edits are holding up the spec being shipped as a Candidate Recommendation. I am providing exact text of the algorithm to be resolved after a quick sentence. 1) Please complete. Editorial note TODO: Specify the mapping between key.algorithm.hash and the appropriate Hash functions (and back to OID). 2) I'd say "yes" but happy to let editors decide Editorial note Should this be folded into RsaHashedKeyGenParams and rely on the optional nature of the dictionary fields? 3) Probably OK to just say "Editor's note" just put in main text rather than as an Open Issue w/o a number? Editorial note OPEN ISSUE: The import/export of JWK ignores the "alg" field, because it does not provide a 1:1 mapping between ECDSA (which choses the hash at sign/verify time, because it is safe to do so) and the JWS alg (which incorporates the hash algorithm). 4) Can salt just made be optional, and behavior of not expecting it be made conforming or non-conforming based on CR test interop? Editorial note The definition of HKDF allows the caller to supply an optional pseudorandom salt value, which is used as the key during the extract phase. If this value is not supplied, an all zero string is used instead. However, support for an explicit salt value is not widely implemented in existing APIs, nor is it required by existing usages of HKDF. Should this be an optional parameter, and if so, what should the behaviour be of a user agent that does not support explicit salt values (is it conforming or non-conforming?) 5) Maybe just say "The following *may* be specified later if demanded"): Editorial note Should the following be specified. RSASSA-PKCS1-v1_5 with SHA-1 RSA-PSS with SHA-1 RSA-OAEP needs specifiers for the hash algorithms. ECDSA with SHA-1 ECDSA where the curve (P-256, P-384, P-521) is not aligned with the hash (SHA-256, SHA-384, SHA-512) 6) Just delete? Editorial note ISSUE-33 One proposed technical solution for user agents is to implement "key tainting", in which it records how a particular key has been used (eg: algorithms, parameters), and prevents it from being re-used in a manner that is unsafe or contrary to the security - such as preventing a PKCS1-v1.5 key from being used with RSA-PSS, or preventing an RSA-OAEP w/ MGF1-SHA1 from being used with RSA-OAEP w/ MGF1-SHA256. Questions exist about whether this should be encouraged or permitted, and the interoperability concerns it might cause. 7) I think we should just say we can't guarantee this in the text and remove the note: ISSUE-35: The specification for wrapKey/unwrapKey does not specify how authors that do not trust the execution environment may indicate required attributes for keys that are unwrapped. An example is unwrapping a key with a non-extractable key, marking the newly unwrapped key as non extractable, and then further indicating that all keys unwrapped with the newly unwrapped key are also non-extractable.
Moved to https://github.com/w3c/webcrypto/issues/30