Re: Registries and Interoperability

On Fri, Feb 8, 2013 at 2:52 PM, Richard Barnes <rbarnes@bbn.com> wrote:
> Ok, thanks for clarifying.  I certainly agree that the flavor of interop problem you're talking about is bad.  However, that seems like a fairly straightforward issue to address, basically deduplication.  Has someone already defined AES-CBC?  If so, then you don't get an identifier for yours unless the actual algorithm differs (as opposed to the API parameter formatting).  This raises the question of whether the parameter format gets defined by the first guy that shows up, but I think you could clarify that with some guidelines.
>
> It is very common for IANA registries to have an "expert reviewer" applies before allowing registration.  (Ryan?)  It seems like you could set up a few general rules that a expert would follow to ensure some consistency in the API.  For example:
>
> -- Each algorithm gets only one identifier
> -- Parameters and outputs are subject to the following constraints:
>     -- Octet strings MUST be represented as ArrayBufferView
>     -- Keys (public or private) MUST be represented as Key objects, not in an encoded form
>     -- Integers (outside of keys) MUST be represented as integer or BigInteger values
>
> Basically, it seems like for a given algorithm, there's only a couple of more or less obvious ways to represent the algorithm and its parameters under those constraints (or something like them, to be agreed by the group).  So it seems unnecessary to re-engage the WG machinery.  Especially if, as Arun suggested, the *-public mailing list can be kept alive for discussions.

An expert reviewer is not consensus, nor is it a consensus-based
process, nor does it lead to actual agreement for interop.

I feel like this is all being caught up in the machinery of 'process',
without any consideration with what is actually good for the web -
authors or implementors.

Yes, being able to evolve the API is very useful, and something that
MUST be seen as inevitable (the world stands still for no one...). But
we must not pretend that we can both have our cake and eat it too -
work out consensus and deployment, and then just 'toss it over the
wall' for a devil-may-care approach, whether it's
first-come/first-serve or expert-review/benevolent-dicatatorship.

Yes, implementors will certainly experiment with vendor
prefixes/experimental algorithms. We see this all the time. Even as I
think the vast majority of vendors have realized prefixes are "Bad"
for the Web (webkit-foo being the same as opera-foo being the same as
mozilla-foo helps no one, certainly not developers), at the same time,
the need to experiment, iterate, and deploy is all the more important
in working out standards that work and actually engaging the
community. So I certainly expect we WILL see implementors
experimenting with new algorithms to put forward as proposals, and
exposing those to the web - whether it be in Beta versions (as IE has
done) or through command-line flags (as Firefox has done) or through
'release channels' (as Chrome has done). So if the fear is that if we
say 'no registry', it means none of that experimentation - well, then
that's flawed too - there will be experimentation REGARDLESS of what
we say in the spec. Just look at the activities of every other Web WG
to see this in action.

My concern remains first and foremost that we not pretend that any
algorithm has 'legitimacy' or is 'ready for the web', simply by virtue
of inclusion in some registry. That requires consensus - and it
requires the fortitude to say, for algorithms that fail to reach
consensus or get stuck in monoculture (eg: as WebSQL did) - that we
must move on and NOT implement the algorithm.

>
>
>
>
> On Feb 8, 2013, at 4:48 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> On Fri, Feb 8, 2013 at 1:04 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>> Ryan,
>>>
>>> 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?
>>
>> You misrepresent my position and the arguments.
>>
>> As mentioned during Mountain View, MTI is troublesome from an API
>> perspective, which is what you put as (A). This was specifically in
>> the context of supporting arbitrary Keys (for which not algorithms are
>> possible, due to the underlying storage requirements, whatever they
>> may be), and in acknowledgement of the complex regulatory frameworks
>> surrounding crypto and strong crypto (c.f., France, as an example).
>> That said, in a pure-software-only mode (eg: now that the Netflix
>> requirements are separate), it MAY be worth revisiting - but even if
>> we end up with MTIs now, we'll be back in the situation of non-MTIs
>> within X years, as we support different versions of the spec.
>>
>> However, I'm also a strong believer in interop, which you put as (B).
>> What this specifically means is a strong objection to seeing
>> vendor1-AES-CBC, vendor2-AES-CBC, and vendor3-AES-CBC, all of which
>> are incompatible in their own wonderfully and stupendously stupid
>> ways. This is not an idle concern - we see it time and time again with
>> web registries.
>>
>> I'm not talking about purely naming concerns - I'm talking about the
>> functionality exposed, parameters, the handling of inputs and the
>> resulting outputs. Consider, for example, your ECDH concerns. Vendor 1
>> may "register" an algorithm in the registry that uses a Key object,
>> while Vendor 2 may register an algorithm that uses an ArrayBufferView.
>>
>> A web developer MUST NOT be required to test some n-number of
>> potential interpretations of what "ECDH" means, in addition to any
>> necessary polyfill. There should be a single, consensus-driven
>> agreement on the necessary parameters, inputs, and outputs that define
>> it. A registry does not define that process.
>>
>> So then, if the registry doesn't define the process, doesn't define
>> the requirements - eg, the registry behaves like many IANA registries
>> that require "WG approval" (c.f. "IETF consensus"), then we're back to
>> the situation that Harry claims we'll somehow be able to avoid -
>> needing the WG to be open and review.
>>
>> (A) and (B) are not in conflict.
>>
>>
>>>
>>> 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. caniuse.com), 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.
>>>
>>> --Richard
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Feb 8, 2013, at 3:48 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>>
>>>> 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 23:11:15 UTC