W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

Re: [W3C Web Crypto WG] Security considerations and recommended algorithms bug

From: Harry Halpin <hhalpin@w3.org>
Date: Mon, 12 May 2014 11:39:13 +0200
Message-ID: <537096C1.5040707@w3.org>
To: Ryan Sleevi <sleevi@google.com>
CC: GALINDO Virginie <Virginie.GALINDO@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/12/2014 11:17 AM, Ryan Sleevi wrote:
> On Mon, May 12, 2014 at 2:01 AM, Harry Halpin <hhalpin@w3.org>
> wrote:
> 
> On 05/12/2014 10:56 AM, Ryan Sleevi wrote:
>>>> On Mon, May 12, 2014 at 1:53 AM, Harry Halpin
>>>> <hhalpin@w3.org> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On 05/12/2014 03:36 AM, Ryan Sleevi wrote:
>>>>>> Virginie,
>>>>>> 
>>>>>> Can you please comment on what you mean by "Blocking
>>>>>> Bug"? That has a
>>>>> very
>>>>>> specific connotation within the W3C process.
>>>>> 
>>>>> I think this is what Virginie means:
>>>>> 
>>>>> Note that for each comment we get during Last Call, we have
>>>>> to "formally address all issues raised by Working Group 
>>>>> participants, other Working Groups, the Membership, and
>>>>> the public about the Working Draft." [1]
>>>>> 
>>>>> Note that comments out of scope of the charter don't count.
>>>>> Rich Salz would count as "the public".
>>>>> 
>>>>> In particular then, we have to "In the context of this
>>>>> document, a Working Group has formally addressed an issue
>>>>> when the Chair can show (archived) evidence of having sent
>>>>> a response to the party who raised the issue. This response
>>>>> should include the Working Group's resolution and should
>>>>> ask the party who raised the issue to reply with an
>>>>> indication of whether the resolution reverses the initial
>>>>> objection." [2]
>>>>> 
>>>>> Simply put, usually we need to send an email before May
>>>>> 20th stating that "Here's what we did (or did not do) and
>>>>> why in response to your review. Can you live with the
>>>>> response?"
>>>>> 
>>>>> If the answer is "yes" or no answer, then we move to CR. If
>>>>> we get a "no", then we have to continue dialogue until a
>>>>> reasonable solution that both the WG and the reviewer can
>>>>> live with until we exit CR. The point of Last Call is to
>>>>> get these kind of comments finished before really focusing
>>>>> on the test-suite.
>>>>> 
>>>>> I'm sure we can find a reasonable solution!
>>>>> 
>>>>> cheers, harry
>>>>> 
>>>>> 
>>>>> [1] 
>>>>> http://www.w3.org/Consortium/Process-20010719/tr.html#last-call
>>>>>
>>>>> 
[2]
>>>>> 
> http://www.w3.org/Consortium/Process-20010719/groups.html#formal-address
>>>>>
>>>>>
>>>>>
>>>>
>>>>>
>
> 
Harry,
>>>> 
>>>> Thanks for the detailed response. I am familiar with each of
>>>> those, and that's why I sought Virginie's clarification.
>>>> 
>>>> In this context, *every* bug is filed is a blocking bug,
>>>> which is why I do not understand why special attention has
>>>> been provided.
>>>> 
>>>> Further, in this context, a response has been provided
>>>> explaining things.
>>>> 
>>>> So the question is, what makes this different than bugs such
>>>> as https://www.w3.org/Bugs/Public/show_bug.cgi?id=25387 ?
>>>> Arguably, nothing.
> 
> As long as the author responds to your response that they are 
> satisfied or they never respond, then we can assume they are 
> satisfied. If they respond they are unsatisfied, then we just keep 
> iterating with them until a reasonable solution is found. Rich
> does seem unsatisfied, as noted by the "kind" of bug he filed.
> 
> 
>> Harry,
> 
>> The process you described is with respect to Formal Objections.
> 
>> Can you please provide a reference for where the W3C sees public
>> comment as being such? The process you've described is a process
>> that can make it impossible for a group to progress, by allowing
>> a member of the public to refuse to accept a solution, so I doubt
>> the process is, indeed, as you described.
> 
>> Indeed, the process described at 
>> http://www.w3.org/2005/10/Process-20051014/policies.html#formal-addressdoes
>>
>> 
NOT indicate "keep iterating with them until a reasonable solution is
>> found". Instead, it states "a reviewer cannot block a group's
>> progress"
> 
>> The only requirement is that for every issue raised, a
>> substantive response (such as technical reasoning) and
>> acknowledgement of that response is all that is required.
> 
>> This seems to be further reflected in 
>> http://www.w3.org/2005/10/Process-20051014/tr.html#doc-reviews
> 
> 
> 
> 
> Working Group members can also "formally object" but luckily I
> don't think we have that situation.
> 
> 
>> Likewise, the process document doesn't seem to make it clear that
>> it's "only" WG members that can Formally Object.

That was was informal description of what WGs usually do, i.e. iterate
with the reviewer till a reasonable solution is found. If there is
real controversy, we can always invite the reviewer to a telecon if
needed. Sometimes that sorts things out quickly.

Upon checking - yes, the general public can formally object during
Last Call, but after Last Call we can note the time for review is over.

As stated earlier, we have to:

"formally address all issues raised by Working Group participants,
other Working Groups, the Membership, and the public about the Working
Draft." [1].

However, a reviewer cannot block the WG forever. The chair can decide
if the Editor and/or WG has done a reasonable job trying to address
the objection:

 This means that "If dissenters say they can live with a given
decision, this should be taken as an indication that the group can
move on to the next topic, but the inverse is not necessarily true:
dissenters cannot stop a group's work simply by saying that they
cannot live with the decision. When the Chair believes that the
legitimate concerns of the dissenters have received due consideration
as far as is possible and reasonable, then objections must be recorded
and the group should move on." [2].


That is uncommon but does happen. Yet, it often raises red flags from
the W3C and the Advisory Committee, so I'd suggest that we try to
iterate as long as the person is being reasonable and engaging
constructively as the archive of messages is what records whether the
formal objection has received "due consideration" or not. Obviously,
there is a difference between legitimate concerns and trolling-behavior.

It is worth clarifying with Rich if this is a formal objection or not
as the Bugzilla's status here is a bit unclear.

  yours,
        harry



> 
> 
> 
> Before we exit Last Call on the 20th, I'll make a document showing
> the status of the bugs and how we have resolved them.
> 
> yours, harry
> 
>>>> 
>>>> Cheers, Ryan
>>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Fri, May 9, 2014 at 6:12 AM, GALINDO Virginie < 
>>>>>> Virginie.GALINDO@gemalto.com> wrote:
>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> This is just to bring your attention on the fact that
>>>>>>> we received a “blocking bug” from Rich Salz and Kenny
>>>>>>> Patterson about the need to
>>>>> improve
>>>>>>> our security considerations in *Bug 25607* [1]
>>>>>>> 
>>>>>>> Ryan is working on it, but views/support from all 
>>>>>>> implementers would be helpful …
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Virginie
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> [1]
>>>>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ------------------------------ 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
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTcJbBAAoJEPgwUoSfMzqcfiMP/Auppmoyk+zPewhXv+7aRy1I
TAON2PG22NGwS/DMDAmgqG5Fd1J+bU8tMmrJYAnZW3BNArCR1oQSwJbqoZwZH9Ri
D7A18giwLofGzCzLADzVrpZHrdKdVamJ7i19vfyBKxIPiPWEurMD8ERTkHFGfOcq
EFku6Tx8xtWdO5hdQ1LXIe1Kzku4sxHZNbDQfSiMwGF/vXbUFBpuKYwWajSmOw9H
KWsNlW5HlmimDDUf4BCrxIz6lLIb7SLs6xVTzTKH2WxiCrniQlhLj3YRqizLFrdM
qCNVcs2sAksNRqVOOLuq+WYF/956t6gjt0jI1Z47l07VXkzsFim+1usfIzmhLYUl
yNCp/Am7fEIfnj/ksc4XaN8TxHAcVLHVFmKpLUP2a2iBr+FVKhVuyRntT/26rpxJ
SspQ7UNk7HcPJI5SyF4wwavNCMam52PGAgHWYDYhP7kIO7rn74mt7pcy4rK7vJs7
EzlkT53H6atll+WOzAVqkrqCkbn4zdE54nTS5oHSiwzMrTDwIcgM3bCD7yavmkpX
hcDGSxETdwj4gYqHWiLS0G+P2tibI3yhpoEkCSvXBz4itawR5MRNc+kiabumzPMJ
t9P6RTsAB8gj418Q8j4Hz+2ISW04QAkxxI8TcLOrx3FMQAOTaIB/6YghI0MCRzEX
snD3E557tl57js3eC+19
=zpFM
-----END PGP SIGNATURE-----
Received on Monday, 12 May 2014 09:39:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC