- From: Dain Nilsson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Oct 2019 11:24:47 +0000
- To: public-webauthn@w3.org
We should clarify the consequence of a bad actor getting access to S. It's clear that anyone with access to S can forge a valid recovery credential, which potentially could be used to break the unlinkability aspect. One mitigating factor here would be if the client (browsers) UX is clear about distinguishing a call to `create()` with `action: "recover"` from the standard flow, which I think would be good practice purely for usability reasons as well. On ensuring E != point at infinity I fully agree, the requirement on enforcing this should be added. Regarding the use of HKDF, I'm not sure I see how invoking it twice to derive 2 keys is more clean than just doing so once. It's my understanding that deriving multiple keys is one of the stated purposes of HKDF (from RFC5869): ``` HKDF follows the "extract-then-expand" paradigm, where the KDF logically consists of two modules. The first stage takes the input keying material and "extracts" from it a fixed-length pseudorandom key K. The second stage "expands" the key K into several additional pseudorandom keys (the output of the KDF). ``` Am I missing some reason for why separate invocations of HKDF would be beneficial? On the addition of `S`, I would consider an alternative take on the non-malicious main authenticator: What if a flaw in either the destruction or the generation of `e` is found in the main authenticator (through compromise or other means)? I'd argue that if there is no need for the main authenticator to ever possess the private key, it would be desirable for it not to ever be exposed to it. -- GitHub Notification of comment by dainnilsson Please view or discuss this issue at https://github.com/w3c/webauthn/issues/931#issuecomment-542654676 using your GitHub account
Received on Wednesday, 16 October 2019 11:24:49 UTC