Re: [Secdispatch] Marking SPKAC as Historic

[Graham Leggett <[e-mail]>]

On 11 Nov 2022, at 21:48, Eric Rescorla <[e-mail]> wrote:

> This is not the only reason it was removed. For instance, here is the W3C TAG
> writeup of concerns around keygen:
> https://github.com/w3ctag/wiki/wiki/keygen <https://github.com/w3ctag/wiki/wiki/keygen>
The document above was source material for the draft. The key takeaways above are a) MD5 bad, and b) various concerns around user experience. What wasn’t shown was any concrete data to back up the claims around the user experience, given they were talking about something that had at the time been in production for twenty years. Weirdly, in all the analysis, “the format of the proof of possession message wasn’t written down anywhere” was never mentioned.

The focus on “is this supported in web browsers” is largely irrelevant in 2022, because web browsers now have Native Messaging Browser Extensions as part of Web Extensions, which allow a webpage to access native code on a given machine. In addition, the days of “the certificate store is in the browser” is now gone, with the browsers deferring to the operating system’s certificate store.

What this means is, a Web Extension can be built that solves the key distribution problem for all browsers today, and if the user experience is not up to scratch, someone else can write a better Web Extension. None of this needs cooperation from browser makers.

What is important is this Web Extension and the better one that might replace it need a standard to follow. Every certificate authority public and private coming up with their own protocol is awful, that’s why standards exist.

Which standard to follow? One that already exists, is already widely deployed, is already audited as part of crypto libraries, and has been in production on a wide range of operating systems for 25 years, or something brand new?

Or to put it another way, why does a certificate authority have to spend hundreds of thousands / millions of dollars coming up with something new when they can spend nothing and use what is already there?

This is why the question “if it is not recommended, why is it not recommended” is so important. If people are being asked to invest large amounts of money to replace something that already exists, it needs to be for a good reason.

The only issue we’ve seen to date is “MD5 bad” and that’s been fixed. Is there anything else?

> More broadly, WebAuthn is the preferred solution for many if not most of the
> applications for which TLS client auth with keygen was used.

WebAuthn appears to solve web login, which happens later.

Regards,
Graham
—