[Bug 27374] New: Please remove older Editorial Notes from spec

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27374

            Bug ID: 27374
           Summary: Please remove older Editorial Notes from spec
           Product: Web Cryptography
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Web Cryptography API Document
          Assignee: sleevi@google.com
          Reporter: hhalpin@w3.org
                CC: public-webcrypto@w3.org

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 20 November 2014 01:13:30 UTC