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:01:38 +0200
Message-ID: <53708DF2.7070807@w3.org>
To: Ryan Sleevi <sleevi@google.com>
CC: GALINDO Virginie <Virginie.GALINDO@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Hash: SHA1

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

Working Group members can also "formally object" but luckily I don't
think we have that situation.

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.


> 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
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

Received on Monday, 12 May 2014 09:01:47 UTC

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