Individual Certificate Authority for credential management and recovery

[EliRibble]

Description

My current understanding of WebAuthn is that signing material is generated on a per-browser, per-origin basis. This puts the onus for handling key recovery on the user with a scheme like webauthn-recovery-extension using backup keys or on the RP themselves and designing a backup flow into the application. I am not aware of a current WebAuthn mechanism for handling multi-device credentials. I'd like to suggest one.

It seems to me that the problem of multi-device credentials is isomorphic to the problem of multi-server credentials in TLS. We traditionally think of certificate authorities related to cryptographically proving that a server represents a particular entity we would like to communicate with. We could turn it around and individuals could have root certificate authorities and intermediate certificates and sign WebAuthn keypairs on registration. This signature could be included through CredentialsContainer.create(). In the case where the per-site keys are lost or the user wishes to authorize a second device to the same RP they could generate a new keypair that has a signature chained to their personal certificate authority. This would identify the user as the same entity.

This also adds the ability to prove that a given user is the same across RPs, if that's what the user wants. Think of this sort of like what Keybase used to do in providing a mechanism to prove that an email address, Twitter account, and GitHub user are all the same person. Or at least controlled by an entity with access to the same keys.

Thoughts?

Related Links

• webauthn-recovery-extension
• FIDO use cases whitepaper

[timcappalli]

signing material is generated on a per-browser, per-origin basis

A passkey / WebAuthn credential is unique per origin and authenticator (some authenticators may be virtual and span multiple devices).

they could generate a new keypair that has a signature chained to their personal certificate authority.

How would an average end user manage a "personal certificate authority"? Most users don't even use a password manager.

[EliRibble]

signing material is generated on a per-browser, per-origin basis

A passkey / WebAuthn credential is unique per origin and authenticator (some authenticators may be virtual and span multiple devices).

Thanks for the additional detail. Just to make sure I understand, an authenticator here could be Touch ID for iOS, or the Authenticator app on a phone, or a USB device, or a retina scanner. I was under the impression that the private key generated during CredentialsContainer.create() was generated by the browser and stored by the browser, but that only the complimentary public half was made available to the authenticator for attestation. Is the private half also made available so that virtual authenticators could pass both the private and public keys to another device?

they could generate a new keypair that has a signature chained to their personal certificate authority.

How would an average end user manage a "personal certificate authority"? Most users don't even use a password manager.

Similar arguments were used against things like TLS on the majority of websites. That's a technology for banks! Most users also don't use USB 2-factor devices, yet clearly there's desire to support that within the standard. If we argue against innovation based on history or popularity we make little progress.

That said, I think password manager use has grown with time. I think the logical conclusion of a password manager is to eventually became a store of keys. These keys may start out as random strings for filling out web forms, but grow to include WebAuthN credentials. The bag of keys could be totally unrelated cryptographic material. Eventually, though, users will want to group these keys together. Keys shared with coworkers, keys shared with significant others, keys for different persona an individual uses online. It's a small step from grouping keys together to use cross-signed chains within a "password manager".

Personally, I self-host my password manager and access it on several devices I own. I'm willing to manage my own certificate authority.

My employer also manages a certificate authority, and likely a feature of this nature would be as useful to a large organization as it would be to individuals.

I think there's no reason in the long run for users to have to know about "certificate authorities". Users could subscribe to an online business that handles their online identity. It would work similar to how email addresses work now - users register with an email address and as long as they can prove control of that email they can log in. Instead, though, the browser gives a registration system their "persona" which under the covers is a certificate chain rooted to a personal CA managed by the business the user subscribes to. The business provides mobile apps, web apps, notifications, and other parts of the user experience that makes it easy to manage registrations, logins, and identities. It's all just certificates and key material under the covers.

[Firstyear]

they could generate a new keypair that has a signature chained to their personal certificate authority.

How would an average end user manage a "personal certificate authority"? Most users don't even use a password manager.

Similar arguments were used against things like TLS on the majority of websites. That's a technology for banks! Most users also don't use USB 2-factor devices, yet clearly there's desire to support that within the standard. If we argue against innovation based on history or popularity we make little progress.

We aren't talking about banks or your company. We are talking about people. People like single mothers, or veterinarians, accountants, people who may be disabled in some way.

These people are unlikely to have the operational knowledge or experience to run a certificate authority - let alone the time to maintain, backup and protect their own CA. This is not to say they are stupid, but that running a CA is hard, and most people in tech can't even do it correctly. How do we expect people outside of tech circles to do it correctly, if we can't?

That said, I think password manager use has grown with time. I think the logical conclusion of a password manager is to eventually became a store of keys. These keys may start out as random strings for filling out web forms, but grow to include WebAuthN credentials.

And password managers are growing to support webauthn credentials. See dashlane for example.

I'm not really sure what you are asking for her to be honest, because this is already solved in multiple ways (password managers support webauthn credentials, apple/google accounts with roaming authenticators, people with security keys, etc).

We don't need people to be able to run their own CA's.

[Firstyear]

PS: It feels a lot more like you have some other motive or goal in mind for this suggestion, but I'm not sure what it is ....

[EliRibble]

And password managers are growing to support webauthn credentials. See dashlane for example.

Thanks, I haven't heard of it, I'll take a look.

I'm not really sure what you are asking for her to be honest, because this is already solved in multiple ways (password managers support webauthn credentials, apple/google accounts with roaming authenticators, people with security keys, etc).

Specifically what I'm looking for is a discussion from people who know more than me about WebAuthN. I think it could be useful to include a chain of signatures as part of the API for registering new credentials. It's possible I'm wrong on lots of fronts. It may be bad for security. It may be contrary to stated desirable use-cases. It may be inappropriate for that part of a credential flow and that sort of information should be handled by the authenticator. It may be that there is already some field that allows for supplying arbitrary metadata about the generated keys, and one could just leverage that field to do what I'm suggesting. I don't know what I don't know. Maybe it's a great idea that could solve some problems.

PS: It feels a lot more like you have some other motive or goal in mind for this suggestion, but I'm not sure what it is ....

My motivation for this suggestion is essentially this: I think WebAuthN is an amazing technology and could solve many, many problems for billions of people. Yet, as far as I can tell, adoption is incredibly slow. And not speeding up. I personally think that part of this is because there are no recommended solutions (that I know of) for basic usability like "how do I use multiple devices and maintain a consistent identity with a service using WebAuthN?" and "what happens when I upgrade my phone?" Certainly when I have considered WebAuthN for my own projects this has come up. I want to contribute toward solving that.

[Firstyear]

Specifically what I'm looking for is a discussion from people who know more than me about WebAuthN.

I'm not sure this is the best place for it then, given this is meant to be an issue tracker about the specification. Feel free to email me directly if you want to discuss more and have questions, or join the webauthn-rs community in https://gitter.im/kanidm/community if you want to chat.

I think the considerations you are raising and asking though are solved already by synchronised multi-device credentials such as apple/google passkeys, or by password managers acting as webauthn authenticators. Additionally there is a responsibility for RP's to ensure that users do have credentials that are Backup Eligible and Backup State = true, or that multiple authenticators are enrolled.

[EliRibble]

Thank you, I appreciate your engagement.