Deprecate <keygen> and appcache

[annevk]

is not supported by Edge and Chrome and Firefox want to remove
it. Appcache is superseded by service workers.

[domenic]

LGTM

[domenic]

Hmm maybe we want to add an informative reference to service workers as an alternative?

[domenic]

Keygen works in Chrome, but is being deprecated. Maybe update commit message to reflect that.

[annevk]

1b43806

[bblfish]

Check out issue #67, as this PR is controversial, even if it was pushed through.

[domenic]

This PR is not controversial among the editors, to be clear.

[ABISprotocol]

I ask that this issue be reopened. This requires more time and public comment.

[annevk]

This is a PR, it can't be reopened.

[ABISprotocol]

Tired. ( @annevk ) Then it's a shame the commit has been made and someone should work to revert the situation. As noted elsewhere, "removing keygen removes the only currently existing way for browsers to have strong symmetric key based crypto identity."

[annevk]

Browsers are not interested in keygen. Keeping it in the standard is not helping anyone.

[ABISprotocol]

@annevk You mean it's not helping Google and Mozilla who are under pressure to remove it.

I wonder who has the ability to push to this repository? Whoever does, could change this back.

[annevk]

Neither Google nor Mozilla are under pressure, I can assure you. They both consider this feature problematic, as should be evident from their (public) debates.

The editors have push access. See near the end of https://html.spec.whatwg.org/multipage/acknowledgements.html#acknowledgments for a list. And we could change this back, except we won't as we are agreed about this.

[rektide]

I'm new to the Keygen feature, but if I understand it right, it enables a very important use case: link-local secure networking. I would like to see a future where I and other people about me advertise HTTP services, for example "Top 5 albums of the week" or some such. Keygen would let me also advertise a self-signed certificate on the HTTP page, that when installed would let me upgrade the viewer to HTTPS. Previously it was a nice to have, but now that getUserMedia only works over secure origin, I consider this (a means to agree to a non browser-blessed-CA certificate) a must have feature.

I'm sorry the editors don't favor it, but what do you think is an appropriate way to allow a link-local web? Does everyone wanting to share ambiently with other people need to purchase a cert from a centralized, controlled CA? Do you have any other affordances in the pipeline? I don't know how else to interpret this deprecation as anything but pushing us from a place where users can connect with each other, to a scary, centralized web. This idea seems first raised less than two months ago, and the frank "we don't like it, it's a mess, we're just going to drop it" image being put up feels injurious and injudicious. I'm not a fan of this spec, but based on this one use case, it seems vital to peer to peer scenarios, and it has no replacements lined up. I'd like this PR reverted, and a genuine discussion on what should happen to occur if the existed feature was found inadequate .

Just make sure the connections stay wired, I've filed a Chrome issue on getUserMedia() being unusable over link-local,
http://code.google.com/p/chromium/issues/detail?id=531675&thanks=531675&ts=1442264648

And I've replied to the pre-intent to deprecate that seems to have started this rapidly moving rip out,
https://groups.google.com/a/chromium.org/forum/#!msg/security-dev/pX5NbX0Xack/DnCGahWvLgAJ

[annevk]

Browser vendors are actively removing <keygen>, the feature is broken by design, and has poor interoperability. Even if the editors did favor it, that would not change the status quo.

[bblfish]

The claim that it is poorly implemented is refuted by @dirkx who wrote today in the blink-dev forum. That it is broken by design seems pretty odd statement for something that has been around for 15 years.

So today, Chrome (Firefox, MSIE, etc) are able to use keygen/enroll(); in the background store the private key somewhere (for Chrome on OSX that is the login keychain of the OS); send the server some spkac - and if; at some later point a signed cert with the matching key is returned - it will happily connect the two. Then, later, also after restarts, Chrome will flash the x509 client cert to any side that claims it wants to see it i the first step of the TLS/SSL exchange.

And that is pretty much the only thing you can do with keygen; and that has been the behaviour across a wide range of browsers and operating systems for nearly 20 years.

So I guess, that means there is running code, rough consensus - and implementors have about enough information/specification to implement, maintain and evolve this in a interoperable way. Despite a lot of it sucking and odd design and threat/actor modelling flaws. And despite the lack of spkac submit control and the promiscuous flashing of the credential to any sites that asks.

I'll point out that in an earlier thread yesterday he also wrote

But at the same time - people have gotten this to work rather reliable; over very long periods of time; sometimes at a fairly large scale; across quite a few generations of browsers & servers - in a very wide range of settings. With little control over their environments; environments that evolved.

Now arguably a lot of that is thanks to PKCS; a lot of ‘hardcoded’ assumptions in OpenSC and downright cargo culting between the various implementations UI wise. So, while often as badly documented as keygen, they keep the backbone common & stable.

Some of the oldest ones I can think off date back to ’98*; and are still operable enough for enterprises; across over 15 years of windows, Solaris, and later OSX and Linux; and have been able to move along the various key lengths and algorithms as well.

So despite the crappy docs & specs - folks have kept it all working.

*: The oldest commercial deployment I still have docs for was with Netscape Gold 3.0.1 though.

[annevk]

I meant that it has poor interoperability since Internet Explorer/Edge do not support it. Anyway, I'm going to lock this since there already is an issue and it makes no sense to discuss this here.