None hardware/device option - as for ssl client certificates

[pRiVi]

We are currently securing websites via client certificates; without any hardware at all.

https://www.cryptomagic.eu/cryptoweb/

We are very satisfied with this solution, but get problems on the currently browser vendors by removing "keygen"-Tag and other client ssl certification-features without replacement. Some told us the replacement should be webauthn - but the currently implementations forces the existance of hardware, which is just inaceptable for our solutions and is just not a replacement for the currently possibilities of client certificates without hardware binding.

We just donnot want hardware binding at all, and request the possibility to specify in the generation of a public key that

• no hardware(-token) should be used and optional
• the user should not be questioned about a hardware token

The examples on https://webauthn.bin.coffee/ just donnot work without u2f hardware.... Did I just miss something in the docs, or is there no option mentioned to be able to just skip a hardware binding at all? If not: Could you please allow this to be integrated, so you have a real replacement for "keygen"-Tag and client certificates?

I also think that it is just unethical to force users to buy hardware to get security - also if its may limited security without hardware. In my eyes you are just abusing your power, if you are not going to make this possible and force users to do so.

[yackermann]

Hey @pRiVi. It looks like you want authenticator that supports self-attestation https://w3c.github.io/webauthn/#self-attestation

[pRiVi]

@herrjemand: I do not think so, the authenticator is not touching the hardware/device aspect.

I think the definition of Client Platform is the problem:

4. Terminology
   ...
   Client Platform

   A client device and a client together make up a client platform.
   ...

The Web Authentication API is only defined to be used on a client platform, not on a client itself:

5. Web Authentication API
   ...
   All such operations are performed in the authenticator and are mediated by the client platform on the user’s behalf.
   ...

[emlun]

The spec is indeed written with hardware-backed authenticators (external or built-in) as the main concern, but WebAuthn does not in any way forbid integration of purely software-based authenticators. The "client platform" terminology mentioned above has nothing to do with this, it's just a term that allows us to concisely refer to the browser, OS and client computer as a whole.

It's perfectly possible for browsers or browser plugins to provide support for software authenticators, although WebAuthn provides no standardised API for doing that. For example you could implement a "bridge" that uses a TLS certificate/key file as its backend - although such an implementation would likely break the privacy expectations on authenticators since a minimal implementation would likely use the same public key for every RP.

I also think that it is just unethical to force users to buy hardware to get security [...]

Again, note that we expect that TPMs and secure enclaves built into laptops, mobile devices etc. will be usable as WebAuthn authenticators. We do not expect every user to buy an external authenticator - most will likely just use the ones already built into their iPhones and Android devices.

The main drawback of software authenticators is that they cannot produce meaningful attestation statements, since they cannot acquire and store an attestation key without exposing it to the operating system (unless the software authenticator itself is part of the OS, of course). Be it external or built-in hardware, but some hardware that can safely transport an attestation key is required for attestation to work, and attestation is required for use cases where the RP must fulfill certain security guarantees - for example government and financial institutions, which may have such requirements imposed upon them by law.

[pRiVi]

I also think that it is just unethical to force users to buy hardware to get security [...]

Again, note that we expect that TPMs and secure enclaves built into laptops, ...

The main drawback of software authenticators ...

Its a non-evidenced claim that there will be TPMs or anything like that at a users. The current design of the document and the implementations currently still means:

Everybody needs to buy a token for at least 15$ to get again security!

Yeah, software protection is less good then hardware protection. But this is not the point!

This is just abuse of the power of 99% of the browser vendors against the users.

You are removing working featues without need to force the people to do as you want!

This is not the first thing arbitrary get changes against the users, Google is generating in Chrome big problems with QUIC against traffic shaping via its own fq-codel mechanisms, so we must install provider wide a filter against Port UDP 443 and UDP 80. Firefox is removing the keygen tag - the last useable way to import client certificates to firefox on windows, without a repacement and forcing users to buy hardware. For more examples see https://blog.fefe.de/?ts=a598205d where this is just named war against users.

You just are breaking the internet down, and violate standards and established protocols - cause you can.

This means to be evil.

[emlun]

Its a non-evidenced claim that there will be TPMs or anything like that at a users.

On the contrary - Lenovo is shipping laptops with built-in U2F support, Google is working on adding WebAuthn platform authenticator support to the Android OS, and Apple is working on integrations for MacOS and iOS.

I suggest you bring your complaints against Chrome and Firefox to those respective teams; there's nothing we can do about that here. If you want to continue discussing the politics of those decisions, please move that discussion to the mailing list public-webauthn@w3c.org instead of this issue tracker.

[pRiVi]

Or I just give up and let it be as is its.

I think we all must accept that decisions will be made by big players in their interests, and that the open structure for everyone is just over.

[filips123]

@emlun @pRiVi So, will SSL client certificates be supported?

[emlun]

No, I don't think it's likely that SSL/TLS certificates will ever be usable as WebAuthn credentials. My reasoning for this is that a certificate is a stable global identity that is correlatable between RPs, while a WebAuthn credential is bound to a particular RP and not correlatable.

That said, WebAuthn as a protocol is compatible with pure-software authenticators, but there currently is no standardised API for implementing them. You're welcome to open a new issue requesting standardising support for software authenticators, but of course I can't promise the browsers will be willing to implement it.

[filips123]

@emlun Ok, I will probably open a new issue until the end of this week.

[filips123]

@emlun I created issue #1175.