- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Jun 2020 13:18:24 +0000
- To: public-webauthn@w3.org
> #### AAGUID transmission > > Doesn't seem necessary to leak this to RPs? RP learn and, if they demand, can judge attestation for recovery authenticators when a recovery is attempted. It seems that the motivation is just to follow the existing structure? Indeed it's not strictly necessary, but if we don't have it the user will have no warning before the RP rejects the backup authenticator after they've already lost the primary authenticator and potentially have no other way to access their account. Transmitting the AAGUID early (although unsigned) allows the RP to fail faster and prevent the user from inadvertently getting locked out. > #### Algorithm transition > > I don't believe that the group tricks for establishing the recovery authenticator's public key are needed. I think all you need is to asymmetrically encrypt a seed to the recovery authenticator and thus only scalarmults are needed. It does mean that the primary authenticator transiently has the recovery private key but, in this context, the primary authenticator is trusted — it's getting enrolled as an authenticator after all! Good points; this was also asked [here](https://github.com/w3c/webauthn/issues/931#issuecomment-542617838) and replied to [here](https://github.com/w3c/webauthn/issues/931#issuecomment-542654676). We want to as much as possible avoid sharing private keys, but maybe it's not too big a deal if it's a single-use key like we have here (the shared key isn't actually imported and used long-term). >[...] this does mean that [...] a post-quantum transition is possible. Good observation, that should indeed work. As long as all information that needs to be passed between authenticators can be embedded into a credential ID, this can even be done without any change to RPs' code. > But there's no algorithm negotiation, i.e. the RP should be able to say what algorithms it can support for `generate`. This is in part because the key generation scheme is opaque to the RP - the primary authenticator only needs to supply some kind of COSE public key for the backup credential. So it's not a matter of the RP _supporting_ different algorithms (other than the COSE pubkey algs already used), but maybe the RP should have a say in which are acceptable. In that case we might need to make the algorithm identification a bit more sophisticated and/or standardized than the single byte we have now. > #### UX > > UX seems complex? Do you envision selling pre-setup packs of authenticators? As Shane points out, they could just be clones in that case (although with different security properties). At this point we don't, but it's something we could consider. Our first step would rather be implementing support for this in YubiKey Manager. We have no plans to offer authenticators with cloned keys. That doesn't play well with signature counters, and it also doesn't solve the problem of having to manually re-register everywhere (since the backup must then also be replaced, as you can't associate a new backup with it). > Otherwise, the UX of pairing two authenticators, making sure that the user knows which is primary and which is backup, listing backup devices (how are they named?), letting the user manage this etc, seems daunting. And, of course, RPs would have a bunch more stuff to manage. I'm confident the setup process can be made pretty straightforward in YubiKey Manager, for example. Naming is a good point, though. We've thought about it but decided it gets a bit too complicated for now, but it's probably worth reconsidering. I guess the backup names would have to be stored in the primary authenticator and delivered to the RP along with the public keys. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1425#issuecomment-636856125 using your GitHub account
Received on Monday, 1 June 2020 13:18:28 UTC