Re: Agenda: <keygen> being destroyed when we need it

>
> Compare this with the security and ease of use of the actual
> implementations
> of keygen. One click and the public/private key is generated under the
> user's
> control, and the certificate is installed under the user's control.


To make things abundantly clear: Even if Chromium decides to continue to
support <keygen>:

1) Keys will not be generated in any OS, system, or
multi-application/multi-origin store
2) Certificates will not be automatically installed in any storage
whatsoever
3) Keys and certificates brought in this way will not be available for TLS
connections

These three behaviours are unacceptable from security, privacy, and
performance, and will be changing, and soon. That's an implementation
decision independent of any deprecation. Luckily, none of these behaviours
are specified in anything the W3C or WHATWG has produced, and so depending
on these behaviours - knowing that they were _intentionally_ not specified
- is and has always been problematic.

#1 is explicitly not required of <keygen>, as you can already see via
existing implementations (such as Firefox, which doesn't use the OS store
but per-application, or in Android, where it's a per-application store)
#2 - which you present as a core feature of <keygen> - is not. That's part
of application/x-x509-*-cert handling, to which the only "specification" is
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Certificate_Download_Specification
, and is otherwise neither widely implemented nor part of any SDO efforts.
#3 will not be done because even in the resolution of #1/#2, it conflicts
with how the Chrome network stack is implemented and designed, and would
interfere with the performance of the network stack to resolve the privacy
issues such a solution would present. The implementation cost versus
usability is such that it's an exceptionally high implementation burden,
for demonstrably low benefits, and as all code has a cost to implement and
maintain, and offers new security and privacy attack surfaces, the calculus
is clear that it's not worth it.

Your arguments for "keeping <keygen>" are 'keep the current behaviour of
implementations' - but I cannot stress enough, the current behaviour cannot
and will not be continued.

So, in light of this, does <keygen> (in its modified, future form, where #1
- #3 hold) provide any advantages? You can quickly realize that everything
you described as a limitation of Web Crypto would apply to future-<keygen>,
but, conversely, that means that Web Crypto is a fully equivalent
replacement for future-<keygen>. If your objections are that there's no
replacement for present-<keygen> and present-application/x-x509-user-cert
(which you continue to conflate with <keygen>, but is entirely separate),
well, yes, that's intentional, because present-<keygen> and
present-application/x-x509-user-cert are too problematic to keep.

It's also clear that in resolving #1/#2, every non-WebID usecase for
<keygen> will go away, and by #3, makes the WebID usecase for <keygen> go
away, such that there is zero utility for future-<keygen> - which is the
only possible secure implementation of <keygen>, whereas there's still
significant usecases that can be accomplished by Web Crypto.