Re: Registries and Interoperability


I've missed several of the intermediate messages in this thread, so maybe I'm missing context.  But it seems to me like you're arguing on both sides here.

(A) On the one hand, you argued strenuously at the Mountain View F2F that the API spec should not specify which algorithms a UA is required to implement.  Among other reasons, a UA that uses an OS-provided crypto library might not have control over which algorithms.  

(B) On the other hand, you are now saying that we need a consistent set of algorithms for there to be a coherent web API.  Just like we have a consistent set of HTML tags, and discourage UA vendors from adding custom tags.

These two positions are fundamentally in conflict.  If there is going to be a consistent set of algorithms, then the API will have to have requirements for UAs.  If there are no requirements for UAs, there is no guarantee of consistency.  Which side are you on?

This question is fundamental to the identifier/registry question.  (A) If there are no requirements, then web developers will have to check that algorithms are present anyway (cf., so an IANA registry with fairly liberal requirements makes sense.  (B) If there are requirements, then UA developers will have to coordinate which algorithms are required, so it makes sense to go through the W3C process to update the list.


On Feb 8, 2013, at 3:48 PM, Ryan Sleevi <> wrote:

> On Fri, Feb 8, 2013 at 12:00 PM, Harry Halpin <> wrote:
>> On 02/08/2013 08:45 PM, Ryan Sleevi wrote:
>>> On Fri, Feb 8, 2013 at 11:30 AM, Harry Halpin <> 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
>>> . 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!"
>>>> [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!"

Received on Friday, 8 February 2013 21:05:17 UTC