W3C home > Mailing lists > Public > public-webcrypto@w3.org > February 2013

Re: Registries and Interoperability

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 6 Feb 2013 16:15:30 -0800
Message-ID: <CACvaWvZ=xKK3TOLhWq4MjQbwjRpJVNQynBdD41tVFMRsh==Myw@mail.gmail.com>
To: Harry Halpin <hhalpin@w3.org>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Wed, Feb 6, 2013 at 1:57 AM, Harry Halpin <hhalpin@w3.org> wrote:
> On 02/04/2013 10:55 PM, Ryan Sleevi wrote:
>>
>> On Mon, Feb 4, 2013 at 1:22 PM, Harry Halpin <hhalpin@w3.org> wrote:
>>>
>>> Quick note,
>>>
>>> I agree with Ryan's concerns as regards registries not allowing
>>> interoperability and possibly being dangerous from an IRP perspective.
>>> However, from W3C's perspective we we're not planning on running the
>>> Working
>>> Group in an open-ended manner like the WebApps Working Group (see below
>>> for
>>> reasoning). Thus, it seems we should determine:
>>>
>>> 1) If we want any extensibility in algorithm identifiers, which requires
>>> either a very low-bar approach (wiki) or a high-bar approach (IANA)
>>> 2) If we don't want any extensibility in algorithm identifiers, so they
>>> essentially "freeze" when we go to Last Call, and adding new ones
>>> requires
>>> rechartering the Working Group
>>>
>>> I think there's the situation where there's a new algorithm people may
>>> want
>>> to use, but we don't have enough industry momentum to reopen the Working
>>> Group.
>>
>> If there's not industry momentum and within implementors, what value
>> does it serve the broader web community of users, authors, and
>> developers? If there is broad consensus, then what's the challenge?
>
>
> There may be momentum to add a new algorithm or tweak an existing algorithm
> from within two or more implementers without the momentum needed to
> re-charter a new Working Group. Or if the registry includes security
> considerations, there may be an update to security considerations We would
> not want to recharter internally at W3C for a new single algorithm or a
> change in the security status of an algorithm, as we would have to identify
> editors, chairs, and go through IPR process all over again.

It's unclear when you talk about "security considerations" which you intend
1) Security considerations of the API
2) Security considerations of the algorithms

I don't see how #1 is different than any other API that has ever been
standardized in the W3C, so I think it's a wrong to suggest this is
somehow a new problem.

For #2, we've already solved this by agreeing NOT to list the security
considerations of the algorithms, for exactly this reason to begin
with! Plus, if the security considerations for an algorithm change
(eg: SHA1 becomes as 'trivial' to exploit as MD5), then I think
updating a doc that few people (but implementers) read is a far less
pressing or time-sensitive concern. Again though, and from the start,
I've maintained a position that these sorts of algorithm security
considerations do not belong in an API document. Protocols? Sure. If
we were doing them. But we're not.

>
>
> Again, from W3C processs point of view, we just need to determine 1) when
> working group ends and 2) if it ends, is a maintenance policy necessary and
> 3) is there a clear well-specified way to maintain, and can that be done
> outside the spec for minor changes via a principled extensibility point?
>
> It seems given the crypto landscape does change on occasion, a maintenance
> policy makes sense. IANA was suggested by W3C internally as a principled
> extensibility point, as we have a long history of working with them. I'm
> open to other suggestions. Do people agree that no maintenance policy on
> algorithm specifiers are necessary?

Harry,

I still don't understand why this is. Again, as I explained on our
last call, I don't see how this is any different than suggesting that
IANA should be the API extensibility point for the DOM.

This is not a protocol or a format (like XML enc) - this is an
application API. What matters - for users/developers, authors, and
implementors - is NOT having some registry, but having industry
consensus on implementing this.

Look, any browser today can go introduce any arbitrary tag to HTML and
roll with it. We've seen it in the past. And I think we universally
recognize that as bad for an open web, bad for users, and bad for site
authors. If we believe in standards at all, we should be trying to
standardize things.

And in that model, either there's a group to standardize things
(whether it be this WG, WebApps WG, or it requires implementers going
outside the W3C to get things done, such as the WHATWG), or there's
not. If there is not, then having arbitrary algorithm X is useless,
because it's not viable for the web - and there's no point in us
talking about it. Otherwise, it is, and we charter and deliver on
this.

>
> In fact, we could even broaden the scope and also allow the registry to, in
> conjunction with the work CRFG is doing already, make sure that algorithm's
> particular security considerations can be updated and noted on a per
> identifier basis. This deals with the "ever-changing" world of crypto, as
> you put it earlier. I do think crypto actually changes quite slowly, but
> sometimes there are dramatic new changes that happen very fast. This would
> address CRFG's comments I believe re the use of "broken crypto" in the spec.

I absolutely do not think we should have the sort of 'living API'
you're proposing, because it does absolutely nothing for security.

If I read the API at version 1.0, and it says "SHA1 is great", and I
write my app, when am I ever going to read version 2.0 that says "SHA1
is horrible". I'm not. The API has not changed at all. There's no
value to the developer community to do that.


>
>
> I am bringing this up a bit early insofar as that it can take some time to
> go through getting a new IANA regsitry, and I don't want that holding up
> Last Call.
>>
>>
>>> As I understand it (and Wendy's a lawyer, so she can correct re IPR), the
>>> real advantage of process is testing and IPR RF commitments.
>>>
>>>  From a W3C Process point, the IPR is assigned at the Recommendation
>>> phase,
>>> with initial commitments made to charter. The advantage is that features
>>> of
>>> the W3C Rec for Web Cryptography will have a high assurance of
>>> royalty-free
>>> implementation, regardless of the test-cases.
>>
>> We should be clear here: royalty-free with respect to participants.
>> There's always the possibility of external factors here, which is part
>> of why having the WG process works, to identify and find solutions to
>> these factors.
>>
>>> The disadvantage of that is to
>>> add a new algorithm via adding a new identifier, we'd have to re-open the
>>> Working Group and start the IPR process all over again.  However, any
>>> registry would not have W3C RFF IPR policy, although we could apply an
>>> IETF
>>> policy to it (which I would strongly suggest).
>>>
>>>  From a testing standpoint, another strong point is that W3C requires
>>> demonstrated interoperability. However, *running* the test suite and
>>> adding
>>> new tests does not require re-opening the Working Group, unlike making
>>> modifications to the specification. The test-suite can be stored using
>>> Git
>>> in order to allow merges, and will be maintained by W3C after the
>>> lifetime
>>> of the Working Group. We can add our test-suite to be part of a larger
>>> test-suite (I would think HTML WG's test suite would make sense) so it
>>> can
>>> be easily added to by others and maintained after the lifetime of the
>>> Working Group.
>>>
>>> My suggestion for a process is then:
>>>
>>> 1) Keep algorithm identifiers in the specification up until we go to Last
>>> Call, and that the test-cases for Rec status test each of them. Thus, no
>>> text is removed from spec. We clearly specify that algorithms in the spec
>>> have RFF status, demonstrated interoperability (via test-suite), and are
>>> to
>>> be preferred by WebApp developers.
>>>
>>> 2) Then after that period, people proposing new algorithms are asked to
>>> go
>>> to the IANA registry, which will have some explanatory text referenced in
>>> the spec.
>>
>> As mentioned, this remains a troubling proposal.
>
>
> In what regard in detail?
>
> The alternative seems to be:
>
> 1) We keep the WG running forever to maintain the spec (which is difficult)
> 2) We recharter whenever even minor changes to algorithm identifiers or
> security considerations are needed (again, very difficult to recharter - the
> process itself just to start takes about 6 months at least usually due to
> IPR considerations).

As I described above, we're not talking about "changes to security
considerations".

We're talking about "changes to algorithm identifiers".

And if we as a web community cannot agree that Algorithm X is good, or
we as a community cannot get to a point where we're confident that
"exposing algorithm X via a crypto API" is not IPR-encumbered, then we
shouldn't be specifying "Algorithm X".

>
>
> I think that address the interop concerns, and also gives us a clear process
> for when we need to reopen the Working Group. We can set some specific
> criteria to formally suggest to the W3C to re-open, such as when we have
> say, X implementers for more than X algorithms. At the same point, we get to
> have a place where new identifiers  can go.

We already have that place, as we've seen with every single other web
technology. Implementers implement - either under prefixes or under
flags. I think there's consensus in the community that prefixes are
"bad", which is why you see most switching to some variant of flags,
which sets a reasonable barrier of difficulty, while still allowing
implementers the ability to implement and authors the ability to
experiment.

>
>>
>>> 3) The IANA registry have a fairly stringent requirement of at least two
>>> interoperable user-agents as well as the "Well-Specified" text given by
>>> Ryan
>>> in the spec already in order to get in registry.
>>
>> As I mentioned, this text was certainly not intended to be a long-term
>> text. I would propose this be removed, as it was more of an editorial
>> note (before I discovered the "ednote" attribute of the tools)
>>
>> I think it's demonstrably harmful to the spec and the process to
>> include this text going forward.
>
>
>
> Note that "this text" was the text in you added to the specification about a
> registry, to be clear.  That's what caused the internal discussion at W3C in
> our review at our last "heartbeat" publication. Again, can you explain why
> its demonstrably harmful and what a clear alternative is?

Because it suggests, as you've repeatedly highlighted, that an IANA
registry is somehow a consensus-forming activity that makes standards
work.

It's not.

Somewhere, some specification of the algorithm needs to be developed
and built in consensus. An IANA registry does not make that happen -
and yet, your whole argument seems to fall on the idea that the IANA
registry frees us from needing to build consensus or specification. It
doesn't! It is, at best, a point of documentation, and even that is
unnecessary - the API should BE the documentation. Otherwise, we've
got a bad API.

As I explained on the phone, the text has been carried over the the
very first strawman as an editorial note to explain to our WG how
people should propose algorithms, since the first drafts were notably
sparse and hand-wavey. We've since added a variety of algorithms, and
the text is no longer necessary.

>
> I have suggested a wiki as well (which is what HTML/WHAT WG does re link
> registry) but that's even more likely to be messy than an IANA registry with
> a well-defined policy.

"well-defined policy" should be a/the WG.


>
>>
>>> 4) The W3C/IANA contact for the registry check new requests for algorithm
>>> identifiers by demanding test-cases. These can get added to an
>>> "experimental" branch of the HTML test-suite.
>>>
>>> 5) If we get to the point where we have lots of new algorithms and
>>> momentum
>>> is clear, the contact recommends re-opening/re-chartering the Working
>>> Group
>>> to the W3C. The W3C/IANA can reject spurious new identifiers (including
>>> ones
>>> that make only minor modifications to those in spec) or one's that are
>>> known
>>> to have IPR issues.
>>>
>>> Ryan, does that address the your concerns?
>>
>> No
>
>
> OK. What's your alternative?

That's not a fair question. You presume that I agree that we need an
alternative. I don't. I'm saying that just like every other modern web
API that is being developed, it should be developed through
implementation experience and a consensus-driven approach that sees
adoption and agreement on the specification and details.

There is absolutely no value to specifying an algorithm nobody will
implement. Surely the W3C recognizes this. As such, there's no point
in discussing algorithms unless we've got a place to discuss. The
question shouldn't be "how do I hold all these awesome algorithms I
want", it's "How do we as implementors agree to implement all these
awesome algorithms authors/users/implementers want" - and that's
certainly not IANA, so it's either the W3C, or "elsewhere".

>
>>
>>> Any thoughts?
>>>
>>> The W3C and IANA have a fairly close relationship, and we are used to
>>> dealing with IANA in this way in other WGs, so the mechanics aren't an
>>> issue. We just need to figure out what's best for the WG - to have an
>>> extensibility point or not, and if so, what are the requirements that we
>>> at
>>> W3C (and any volunteers!) can maintain after the lifetime of the WG. We
>>> do
>>> prefer to close WGs as it helps get us the IPR closed, and in general
>>> increases the chances of interoperability by demanding implementation by
>>> a
>>> given date.
>>>
>>>     cheers,
>>>       harry
>>>
>>>
>>>
>>>
>>>
>>>
>
Received on Thursday, 7 February 2013 00:15:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 February 2013 00:15:59 GMT