CR transition update - some quick editorial updates?

The main point is we need to convince the W3C and AC we've dealt with
formal objections, all bugs, and open issues which means they will check
to see if the spec accurately deals with those updates. I agree we've
dealt with them *all* substantially, so I'd like to see the text of the
spec make that a bit more clear on a few controversial points re adding
some temporary editors notes - and also, removing some danging editors
notes we've left in:

The 3 objections:

1) Elliptic Curve bugs re NUMS and Curve 25519
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839

We should probably add this Editor's Note to the 3.1.1

"We expect the WebCrypto specification to support whatever alternative
named curves outside of the NIST elliptic curves are recommended by CFRG
either in the main specification or as an extension specification."

We also need to put Trevor's Draft in W3C Space and probably at same
time as CR as a Working Draft and list it in extensions here:

 I've pinged him about this, I imagine it can happen by end of the week.

2) Security Considerations

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

 Moving with Graham to have his draft threat analysis to CFRG this week,
will ping you guys to add a link.

3) Browser Interop

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

Could we add a "Feature at Risk" or Editor's Note in 18.2 that says (as
mentioned earlier in the list)(feel free to edit):

"We will define a browser profile after interoperability testing is
conducted with different implementations. This browser profile should be
*normative* and should describe the exact behavior of the browser in
case part of the algorithms are not available, or partially available,
or disabled by the user."

Or have we decided to drop this given the way we've dealt with errata?
If so, we should note that in the Bugzilla.

Then there's lots of minor Editorial Notes:

4)Hanging Editorial Notes


a) Anyone got time to do this?

Editorial note

TODO: Specify the mapping between key.algorithm.hash and the appropriate
Hash functions (and back to OID).

b) 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?
Editorial note

c) Probably OK to just say "Editor's note" just put in main text rather
than as an Open Issue.

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).

d) 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?)


e) 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)

f) 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.

g)  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.

 Lastly, is everyone OK with me closing all the issues in bug-tracker
(mostly decided in the spec)?

http://www.w3.org/2012/webcrypto/track/issues/open
http://www.w3.org/2012/webcrypto/track/issues/raised


  yours,
     harry

Received on Monday, 17 November 2014 19:07:22 UTC