Re: WebCrypto edits on key material (Option 2)

On 01/18/2016 01:28 PM, Ryan Sleevi wrote:
>
>
> On Mon, Jan 18, 2016 at 2:01 AM, GALINDO Virginie
> <Virginie.Galindo@gemalto.com <mailto:Virginie.Galindo@gemalto.com>>
> wrote:
>
>     Ryan,
>
>     When you say “we don’t have interoperable implementations”.
>
>     Does this apply still if we remove the key material format as
>     offered by option 2, as announced [1]?
>
>     Regards,
>
>     Virginie
>
>     [1]
>     https://lists.w3.org/Archives/Public/public-webcrypto/2015Dec/0031.html
>
>
> Yes.
>
> I thought this was clear to the chairs and staff contacts, but we
> really, really don't have interoperability, and the discussion of key
> formats shows a lack of interest by other UAs to work towards a solution.
>
> Here's two examples just because I've run into them in the past few weeks:
> - Firefox doesn't support WorkerCrypto (and it's unclear whether
> Safari does either)
> - Firefox accepts keys that Safari/Chrome reject (non-minimal encodings)
>
> Both of these issues caused interop issues when people working on code
> for Chrome, and ended up surfacing as Chrome issues. And while it
> sounds like I'm picking on Firefox, it's been clear that Safari
> doesn't support a number of the algorithm's spec'd and, given that
> it's been two years since those files were last touched, is unclear
> whether they will.
>
> We also know that the W3C's recommended path (which I would suggest
> doesn't really have browser support so much as no comments by
> browsers, a very important distinction) will cause real
> interoperability with sites, and so browsers are unlikely to take the
> spec-recommended path. At best, we're fragmenting the spec in order to
> satisfy an arbitrary timeline, which itself is being missed because
> user agents are non-responsive towards implementation.
>
> And this is setting aside that there are undoubtedly a host of hidden
> interoperability issues that have yet to be discovered, simply because
> we lack any form of consistent testing (where consistent I mean with
> respect to the spec's claims). As such, it's unclear whether the spec
> is overly specific or overly general, nor what the correct course of
> action is. Heck, there was still ambiguity with respect to how error
> messages are propogated to developers.
>
> I want to see forward progress on this spec, but I don't think forward
> progress is measured by publication timelines. If other user agents
> have lost an interest to work on this spec, then hopefully they'll
> make it clear. Otherwise, what we have in the spec isn't reflective of
> reality, and we should just try to spec the few bits of
> interoperability we already have and shut down the WG, since it's
> clear no further forward progress will be made. But that's not just
> "removing key formats" from the spec, that's a vastly different thing
> entirely.

However, note that we can't simply have the spec sit around forever in
an un-finished state while we wait for UA implementers to regain
interest. We owe it to developers who read the spec to have the spec
reflect the underlying reality of implementation. If there's features
where we don't have interop, the path forward is to remove those
features, not wait indefinitely.

From your comments, it seems the other part of the spec that should be
removed is WorkerCrypto. Is that correct?

Again, if the interop issue are PKCS/SPKI key formats and WorkerCrypto,
then we simply *remove* them from the spec and put interop on them into
a new 'maintenance mode' charter.

In terms of Safari, Safari has not removed their vendor prefix and so is
not included in *any* interop discussions yet. Hopefully they'll catch up.

We will not be able to ask for a new charter without going through this
step of pruning non-interoperable features from the spec. We've been
asking poitely for interest from browser vendors to help with interop
and fixing this for the last few months, but given the lack of a
response the way forward is simply to remove non-interopable features
from the spec. We can always return to the spec if interest re-ignites.
Again, a 'maintenance mode' will allow us to update the spec as
implementations move.

         cheers,
              harry