RE: On Registries

Thanks for your insightful reply, Mark.  A few comments inline below…

From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Thursday, August 07, 2014 6:02 PM
To: Mike Jones
Cc: Ryan Sleevi; public-webcrypto@w3.org
Subject: Re: On Registries

On Thursday, August 7, 2014, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote:
Simple.  In the first case, the algorithm is a data value.  In the second case, it’s encoded in an API.  Data values are easily extensible.  APIs are not.  That’s why extending the space of algorithms by registering new data values makes a world of sense.  Expending the algorithms by adding new APIs for each would be clunky, procedurally slow, and mostly unworkable.
I think what Ryan is saying is that it should be no easier to add an algorithm than it is to add a new API (or, more strongly, that a new algorithm *is* a new API and _therefore_ should be no easier to add).

I believe you’ve accurately identified the heart of the disagreement here, Mark.

IF we decided that it should be easier than this to add new algorithms and especially if we decided that groups other than W3C Working Groups should be able to do so, then a registry makes sense as a mechanism to coordinate that.

Agreed.

Otherwise (which is where we are now), then the definitive list of algorithms is to be found in the sum total of the output of the W3C WebCrypto Working Group and nowhere else.

If we decide that he definitive list of algorithms is only to be produced by the W3C WebCrypto Working Group, I believe that would be a significant missed opportunity.  The WebCrypto API is an exercise in packaging algorithms developed by cryptographers for use by Web developers, just like JOSE is.  Neither working group’s primary expertise is cryptography.  Cryptographers should be the ones to write the extensions specs defining new algorithms – not us.  Some of those may occur in the W3C but some may occur in the IETF and some may be individual drafts by people such as Dan Bernstein, David McGrew, and Brian LaMacchia.

We would be doing the WebCrypto API and the Web a significant disservice if we don’t enable people other than us to define and register new algorithms for use with WebCrypto.  We should be humble enough to recognize that defining new crypto algorithms is not our expertise and let those who are experts define them for use with our spec, no matter where they choose to do the work.

                                                            -- Mike

...Mark



Note that the kinds of errors you get back the two are very different as well.  In the first case, it would be “unsupported algorithm”.  In the second case, your code would be treated as having invalid syntax.  The code is much more straightforward to handle the first kind of errors, which are expected, than the second, which are unexpected.

                                                            -- Mike

From: Ryan Sleevi [mailto:sleevi@google.com<javascript:_e(%7B%7D,'cvml','sleevi@google.com');>]
Sent: Thursday, August 07, 2014 2:37 PM
To: public-webcrypto@w3.org<javascript:_e(%7B%7D,'cvml','public-webcrypto@w3.org');>
Subject: On Registries

Since it seems like this issue won't die, it's at least fruitful to discuss.

For the proponents of registries, can you please describe what difference, if any, there is for the web development community and user agent authors between

window.crypto.subtle.encrypt("AES-GCM", foo, bar)
and
window.crypto.subtle.aes_gcm.encrypt(foo, bar)

I assert that there fundamentally is none. Both, once implemented, are parts of the Web Platform. Like any other feature in the Web Platform, we want to see such work develop through consensus. Like any other feature of the Web Platform, it is extremely unlikely for two groups, let alone three or more, to develop competing definitions. The only historical precedents for this has been WHATWG vs W3C, or UA Vendor vs (WHATWG || W3C), and both are recognized as unfortunate failings, not desirable/normal outcomes.

Let's stick solely to discussing how things work in the W3C and the Web. What IETF does, while important, is not the same as what the W3C does - and that's OK.