Re: CR transition update - some quick editorial updates?

On 11/18/2014 11:36 AM, GALINDO Virginie wrote:
> Harry, Ryan,
> 
> A general remark for progressing : I would be happy if we would not modify the specification, to avoid re-opening the discussions. I think that there is enough material in the bugzilla and mailing list to testify the hard conversation we had, and consensus we reached, without having to add editorial notes into the specification (except the ones we decided as a WG to add).
> 

I'll then put links to the Bugzilla rather than the actual edits in the
spec for some of the issues. I am worried about the Editorial Notes that
are still open in the document causing some red flags (particularly
those that refer to "open issues" since the point of the CR transition
is that we've closed our issues) - do the editors want to give to give
those one final look over this week?

       cheers,
         harry

> Regards,
> Virginie
> 
> 
> 
> -----Original Message-----
> From: Harry Halpin [mailto:hhalpin@w3.org]
> Sent: lundi 17 novembre 2014 20:31
> To: Ryan Sleevi
> Cc: public-webcrypto@w3.org; Mark Watson; GALINDO Virginie
> Subject: Re: CR transition update - some quick editorial updates?
> 
> On 11/17/2014 08:16 PM, Ryan Sleevi wrote:
>> 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.
>>
> 
> I was communicating what I believe the WG agreed on and making sure it's clear in the spec text, as I have to prepare a transition report which the W3C will double-check to make sure we've resolved our open issues and objections. However, those were just friendly suggestions, I think they can be dealt with in the transition report by linking directly to the resolutions and then I can try to argue how those are dealt with the text.
> 
>  I agree we should *not* revisit any compromises or decisions. If you think any of these notes would cause that, do not add them of course!
> 
> However, we should at very least get rid of dangling editors notes and clear up the issue tracker since everything is now in Bugzilla.
> 
>>>
>>> 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.
> 
> OK, I can also just claim the errata-based extension mechanism should take care of this objection and point to that resolution and part of the text.
> 
>>
>>> 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.
> 
> I think that's what we agreed here:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985
> 
> "RESOLUTION: Leave the bug open; expect to resolve it after testing phase by developing one or more profiles."
> 
> If you want to rephrase that resolution in an editor's report that would be good, otherwise I can point to the bugzilla resolution in the Transition Report.
> 
>>
>>> 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
>>
> ________________________________
>  This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
>

Received on Tuesday, 18 November 2014 14:13:19 UTC