Re: Registries and Interoperability

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?

>
> 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.
>
> 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:01:13 UTC