Bug 27374 - Please remove older Editorial Notes from spec

[mwatson2]

Bug 27374 from Bugzilla (this appears to referring to a list of issues elsewhere):

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.

[mwatson2]

@hhalpin Are these issues still current ? Where is the original list that is referred to ?

[bdhess]

With respect to point number 7 above (the extractability of unwrapped keys), I would support the notion that unwrapped keys inherit the value of the extractable property from the unwrappingKey, and that the extractable parameter be dropped.

[mwatson2]

I believe the bug here refers to editorial notes which were removed at CR and so we need to consider whether they are in fact still valid and need to be addressed before PR.

I don't believe any of the above 7 items require action, because:
(1) is already specified
(2) has been discussed and decided in another issue
(3) The JWK import / export is fully defined by the procedures
(4) has been discussed and decided in another issue
(5) Anything may be added in future versions. No need for a note.
(6) There has been no proposal for key tainting and it is not included in the specification
(7) A different note has been added to address this

There are also a few Editorial Notes in the specification which I will address with a PR.

[mwatson2]

PR #156