RE: removing keygen from HTML

>> That being said, since the only browser that supports <keygen> currently is Mozilla, who plans to deprecate regardless of what the TAG says, then it can also be justified to remove from the standard today as there is no interoperability.

With my HTML-editor’s hat on: there is a strong desire for the HTML5.1 spec to represent the feature set that is interoperable in browsers. Setting utility of the feature itself aside, lack of interop is the primary driving motive for removal. The above statement seems to support this.

Aside: the minting and return of the client cert is not technically part of the HTML5.1 specification, which only has this to say:

Note: This specification does not specify how the private key generated is to be used. It is expected that after receiving the SignedPublicKeyAndChallenge (SPKAC) structure, the server will generate a client certificate and offer it back to the user for download; this certificate, once downloaded and stored in the key store along with the private key, can then be used to authenticate to services that use TLS and certificate authentication. For more information, see e.g., this MDN article<https://wiki.mozilla.org/CA:Certificate_Download_Specification#content>.

With TAG hat on: WebAuthn does look like a promising alternative to keygen, though it [by design] uses the SoP restrictions, meaning you can’t mint a client cert for use broadly across multiple origins. Some folks see this as a security issue with the <keygen> model, while others see it as a feature. I’m more inclined towards the former viewpoint.