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

> I'd like to understand more deeply why key generation via Web Crypto
isn't functional.

I believe many in this thread have already hit on the main points and I
have made some points in the Blink dev thread similar to this, but let me
leave a fairly simple story here:

I wish to register myself with a server for future public key
authentication, but I do not trust the server with my private key. In what
way could this truly be done in browser using the Web Crypto APIs in place
of <keygen>/TLS Client Auth or a browser plugin?

I do not think this is a far-fetched story.

The WebCrypto API, at least as it stands, can never work in favor of the
user. The opaque CryptoKeys and the immutability of the crypto instance on
the window and the actual CSPRG are all great steps forward in plugging the
holes in-browser crypto once presented but they do no solve the overarching
issue that the server is in control of the code, not the user. Therefore
the server can sidestep all of these locked backdoors because there was
never even a wall to begin with.

The server may be compromised, malicious, or simply required to make
guarantees in good faith, but as the server I can simply set all private
CryptoKeys to extractable or even just use a non-native key generation
implementation and tell you that I am using Web Crypto securely while
grabbing your private keys. As long as the server has control over key
generation and usage, the keys are worthless to the client. The client does
not have control over their key and/or what it is used for which makes it
worthless as a private key.

Now you might wonder what the problem with all this is if you are
approaching it from the perspective of "the server just needs to make sure
the client is actually the client". If this is all that is required, then
it seems Web Crypto solves the case. As long as you know you are not
serving corrupted code, then the opaqueness of the keys and the
immutability of the the crypto instance guarantees third party code won't
be able to get it's hands on the private key.

However, from the user perspective, they are no longer in control of their
private key and in various use cases, this offers some level of repudiation
because there is no reason why the server couldn't have just stolen their
private keys and used them illicitly.

I recognize that in the following I am moving away from TLS Client Auth and
into WebCrypto feature request territory. The use case I envision is
browser assisted authentication and signing in such a way that signatures
and authentication logs could be public record and independently
verifiable, with an implicit guarantee that a server could not have forged
any user transactions. I believe the solution to this is UI tweaks as well
as non-subtle crypto operations made publicly available. Perhaps a subset
of browser assisted crypto operations (crypto.friendly ?) that are
non-subtle and trigger browser chrome interaction. I was in the process of
trying to figure out whether something like this would be doable with
<keygen> and client authentication when I stumbled across these recents
developments. So I am not even actually sure the use case I desire was
delivered with keygen, but you can sympathize that it is the only browser
driven way to do anything public key oriented and so I was looking into it
out of necessity.

---
Samuel