This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27374 - Please remove older Editorial Notes from spec
Summary: Please remove older Editorial Notes from spec
Status: RESOLVED MOVED
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-20 01:13 UTC by Harry Halpin
Modified: 2016-05-23 22:51 UTC (History)
2 users (show)

See Also:


Attachments

Description Harry Halpin 2014-11-20 01:13:28 UTC
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.
Comment 1 Mark Watson 2016-05-23 22:51:54 UTC
Moved to https://github.com/w3c/webcrypto/issues/30