Re: Registries and Interoperability

On 02/07/2013 01:15 AM, Ryan Sleevi wrote:
> 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 mean security considerations of the algorithms, not the API.

Obviously, the security considerations of the API should be in the API 
document. We have agreed not to list security considerations on a per 
algorithm basis, as *those may change in the future* and we don't want 
to provide misleading information.

However, not having security considerations for algorithms did raise 
serious concerns from CFRG (and likely will raise wider concerns at the 
IETF) as well as concerns internally and from Ron Rivest at MIT from a 
brief look at the API he took (I can try to get him to email that out).

So, I am suggesting we need a hyperlink from the spec to a place where 
web app developers can determine the security considerations of the 
algorithms.

I am not OK with simply shipping the spec out without having a link to 
somewhere web app developers can determine the latest in security 
considerations. I also agree with you insofar as I don't think this WG 
is the place to do security considerations on a per algorithm basis, and 
this WG will have a finite lifespan. A group such CFRG does not have a 
finite lifespan, and they could likely maintain such a list of security 
considerations.  All we'd need to change in the spec is to point to 
their security considerations.

I'm pretty sure that would also address their formal review, which we 
need to address to get through Last Call anyways.

>
> 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.

See above.

Actually, many web developers read W3C API recs. Thus, we should assume 
an intelligent web app designer, who may have a good understanding of 
crypto but may not be aware of the latest security considerations on a 
per algorithm basis, is reading the spec.


>
>>
>> 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.

There is a fundamental confusion here between the API and a registry 
that maintains either (or both): 1) a list of proposed spec identifiers 
not in the spec because they were proposed after the spec finished with 
Last Call and 2) a list of security considerations done on a per 
algorithm basis.

Thus, the question is "what to do with a sensible request for a new 
algorithm identifier after the WG has closed."

Both you and Virginie have said "re-open the WG". I am suggesting, based 
on past experience, that is unlikely to happen.

So, is what you are saying "I don't think we need any algorithm 
identifiers except those currently listed in the spec for the indefinite 
future?"

  I think some people might disagree. For example, we've already had 
requests for new ECC curves and SEED for Korea.

I'm OK with limiting the algorithm identifiers to those in the spec and 
having a place for them to be defined as experimental identifiers. 
However, I can see the utility in a principled extensibility point for 
new algorithm identifers. Otherwise, if say the German govt. needs a new 
ECC curve and it gets implemented in NSS etc., there is no way the spec 
to handle such an extension.

Again, we can determine jointly with IANA whatever requirements the 
group thinks are sensible for such a registry. Thus, we can define any 
interop requirements. Test-cases can be maintained after the lifetime of 
the Working Group much easier than changing the Rec spec, as the IPR 
commitments are to the Rec spec, not to the test-suite.


>
> 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.

Again, I think you are underestimating how difficult it is to re-open a 
WG. You are also confusing the API with an extensibility point for 1) 
security considerations and 2) algorithm identifiers. Obviously the spec 
is much larger than a list of algorithm identifiers.
>
>> 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.

How does having text that Web app developers can go to determine if 
there are any security flaws in a particular algorithm doing nothing for 
security?

I agree that text should not be the spec. But the spec should point to 
such a document that has such text.
>
> 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.
Which is why the text "SHA1 is great/horrible" should not be in the API. 
It will change independently of the lifespan of the API. But it should 
be "findable" form the API.
Since our API version 1.0 does not say "SHA1 is great" or "SHA1 is 
horrible", there is no way for a developer to know. Again, the point of 
the registry as regards security considerations is simply a place for 
developers to go.

>
>
>>
>> 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 can easily imagine a case where some mobile devices expose a new 
implemented ECC curve and there is not enough momentum to re-open the 
WG, but there is none the less momentum enough for the mobile vendors 
who would want such an ECC curve to re-use the API with a new algorithm 
identifier for that ECC curve.
>
>>
>> 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.

If you want to add 'flags' for experimental algorithm specifiers, that's 
sensible. But we have to agree first if we want experimental algorithm 
specifiers and if we a list of them anywhere.

If we did have flags, a registry pointed to in the spec with a clear 
process to list experimental algorithm identifiers that need such a flag 
could be useful for developers and prevent fragmentation.

>
>>>> 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.

No, I have not. IANA maintains registries, not standards.

Again, please do not confuse "the API itself" with "having a registry 
outside the spec for up-to-date security considerations" and "a registry 
for experimental algorithm identifiers". These would all be 
non-normative.  We can determine whatever criteria we think is sensible 
for such a registry. If you think interop isn't useful for experimental 
algorithm identifiers, then that's a separate thread.

> 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.

Yes, its a point of documentation.

However, the API already puts lots of documentation, such as per 
algorithm identifiers, out of scope. Thus, it cannot be the only 
documentation. If we  admit the cryptography landscape changes then, 
given that the Working Group has a finite lifespan, how do we deal with 
this?

One answer is an IANA registry. Another might be a wiki. Or anther is 
that we simply do not deal with the possibility of the crypto landscape 
changing. However, in the last case I can imagine a number of reasonable 
objections at Last Call.

>
> 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.

See point above re finite lifespan of 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.

Then your alternative is we end the Working Group and

1) be happy to just have this sentence "Application developers should 
take care to review the appropriate cryptographic literature before 
making use of certain algorithms" in the final version and not point to 
anywhere in the cryptographic literature in particular.

2) then remove Section 20.2, "Defining an algorithm" so that in order to 
add a new algorithm identifier after the lifetime of the WG, developers 
need to wait for a new Working Group to open - which may or may not happen.

If that's what you want, I'm OK with 2) (although I'm sure there some 
objections from folks) but worried that 1) is not enough since I'm 
pretty sure we'll hit formal objections around the kind of "why are you 
encouraging developers to use bad crypto"? I'd also like to hear other 
WG members opinion on this.
>
> 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 17:18:18 UTC