Re: CR transition update - some quick editorial updates?

On Nov 17, 2014 9:07 AM, "Harry Halpin" <hhalpin@w3.org> wrote:
>
> 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:

Has the W3C or AD requested this, which you are communicating as staff co
tact, or is this your personal opinion? We have discussed many of your
proposals at length in the past, and it would not seem fruitful to revisit
hard-sought compromises unless specifically requested.

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

Note our continued objections to this language being present.

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

Note that committing to future unchartered work continues to be
problematic. Further, your proposed language goes beyond anything discussed
to date.

Rather than haggle over language, it would help if you clarified if this is
your personal opinion (which the wording suggests) or if this is requested
by the W3C/AC.

> 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