Re: Registries and Interoperability

On Fri, Feb 8, 2013 at 12:00 PM, Harry Halpin <hhalpin@w3.org> wrote:
> On 02/08/2013 08:45 PM, Ryan Sleevi wrote:
>>
>> On Fri, Feb 8, 2013 at 11:30 AM, Harry Halpin <hhalpin@w3.org> wrote:
>>>
>>> On 02/07/2013 10:48 PM, Arun Ranganathan wrote:
>>>
>>>
>>> On Feb 7, 2013, at 12:27 PM, Harry Halpin wrote:
>>>
>>> No, the process I suggested generally would involve handing off after the
>>> lifetime of a WG the following two items:
>>>
>>> 1) maintaining security considerations per identifier to the CFRG, which
>>> operate on a public list
>>> 2) maintaining requests for a new algorithm identifiers in a public
>>> registry, with requests on a public list and the test-cases being
>>> publican
>>> accessible.
>>>
>>> Some may consider this sensible as the crypto landscape does change and
>>> will
>>> thus likely change after the lifespan of this WG.
>>>
>>>
>>>
>>> It is true that much of the process behind WebApps and HTML is bolstered
>>> by
>>> the fact that we don't envision these WGs as ever really "closing" (which
>>> might be like saying the web's done).  I'm wondering if W3C might be
>>> amenable to another model that doesn't involve re-chartering a WG, but
>>> does
>>> allow for spec and/or document maintenance, which is what draws me to the
>>> WHATWG, which is another option, if there's a willing editor.
>>>
>>> For instance, new identifiers (2. above) reminds me of the potentially
>>> ongoing problem of DOMException and DOMError.  Both WHATWG DOM Spec [1]
>>> and
>>> the DOM4 [2] specification in W3C cite the W3C Bug Database as a way of
>>> adding new exception codes, if necessary (the latest added one comes from
>>> File API, namely EncodingError).   I'm not sure we can totally classify
>>> DOMException and DOMError as "done" for all time.  I think it's likely to
>>> be
>>> the same with Web Crypto, since saying anything security related is
>>> "done"
>>> is unwise, as is the assumption that further algorithms won't
>>> proliferate.
>>>
>>> Instead of a registry, can we do something like active bug discussions,
>>> and
>>> keep *public active?  This is what makes WHATWG attractive, but I
>>> understand
>>> that patent considerations might limit the merits of merely migrating
>>> there.
>>>
>>>
>>> When a WG closes, public-webcrypto@w3.rg closes as the WG is closed. The
>>> comments list can stay open.
>>>
>>> My feeling here is that of course we can keep the Bug Database open, and
>>> I
>>> hope we do so, as well as the test-suite.
>>>
>>> However, that's not the cases that have been brought up. The two cases
>>> are:
>>>
>>> 1) A web developer wants to see if a new experimental algorithm
>>> identifier
>>> can be added. That could be done in the Bugzilla, but that might be hard
>>> to
>>> discover/reference amongst other bugs - and then text needs to be clear
>>> about that as a use of the Bugzilla. A registry might be easier. But
>>> maybe
>>> not.
>>>
>>> 2) A web developer needs to know the security considerations for an
>>> algorithm identifier. I think CFRG should handle that rather than our
>>> API,
>>> and we should explicitly point to them in our API documents as well as
>>> the
>>> "larger cryptographic literature".
>>
>> As I pointed out on our last call and on the list in the past, I do
>> not believe our API documents should have any considerations on the
>> algorithms. This solves your problem, does it not?
>
>
> No that doesn't as that does not resolve CFRG's comment, which will come up
> at Last Call. I *agree* our API documents will not have considerations on
> the algorithms. I do think its reasonable that we point people to a document
> not maintained by us that does maintain security considerations. Do you
> think we should not point to anything about the security considerations of
> algorithms at all?

Harry,

Professor Paterson is the member from the CFRG who made the comment.

It seems like you're pushing this point based on your understanding of
the feedback, but what's really clear is that we're in disagreement
about the feedback received. If you look at the feedback received,
you'll see the integrated changes ARE consistent with the
recommendation.

And you're now talking about something entirely different from a
registry for algorithms, which I think muddies the waters even more.
At best, it becomes a 'registry for security considerations', which is
something that is well and truly wholly independent and unrelated to
this work.

>
>
>>
>> In discussing with a variety of people in the cryptographic community,
>> the discussion has been less about enumerating every algorithm's
>> considerations and more about highlighting the fact that these are
>> low-level primitives that MAY be deployed incorrectly, and thus care
>> and caution must be exercised.
>>
>> In discussing with people like Professors Kenny Paterson and Dan
>> Boneh, along with people from Microsoft and Mozilla, the consensus
>> seems to be that if we're going to include low-level primitives (which
>> has been the ongoing momentum since FPWD), it is sufficient to mark
>> them as 'subtle', with language to indicate that unless you're part of
>> the crypto-priesthood, or implementing something that the
>> crypto-priesthood has deigned acceptable (eg: any of the protocols out
>> there that are desirable to implement), then that's a "sufficient"
>> consideration.
>
>
> That was not the response from Ron Rivest or the CFRG. Note that MIT is a
> member of the W3C, and if IESG has concerns, we have to address them.
> Addressing them in a way that causes no or minimal changes to the text in
> the API is I think the best way.

And that's why we should not include algorithm-specific considerations
in the text, because the literature will always evolve and the
algorithms will always get weaker over time. That's true for any
developer who were to use this API to write code today, the same as it
would be for any developer who reviewed the API 10 years from now.

I don't see any of your concern of 'living spec because of security
considerations' precisely because we should not be including security
considerations that need to be 'living spec'.

>
>>
>> This has already been incorporated in the latest ED - see
>> https://dvcs.w3.org/hg/webcrypto-api/rev/17347680f504 . While I
>> certainly don't know whether that will satisfy Dr. Rivest, everyone I
>> talked to about the subtle proposal was satisfied from a
>> considerations point of view.
>>
>>
>>> Again, having W3C liason with CFRG, IANA, and so on takes time, which is
>>> why
>>> this is being brought up now :) W
>>>
>>>     cheers,
>>>      harry
>>>
>>>
>>>
>>>
>>>
>>> -- A*
>>>
>>> [1] "Note: If an error name is not listed here, please file a bug as
>>> indicated at the top of this specification and it will be addressed
>>> shortly.
>>> Thanks!" http://dom.spec.whatwg.org/#error-names-0
>>>
>>> [2] "If an error name is not listed here, please file a bug as indicated
>>> at
>>> the top of this specification and it will be addressed shortly. Thanks!"
>>>
>>> https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#exception-domexception
>>>
>>>
>>>
>>>
>>>
>

Received on Friday, 8 February 2013 20:48:38 UTC