Re: Registries and Interoperability

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?

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.

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 19:46:11 UTC