- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Nov 2017 17:51:19 +0000
- To: public-webauthn@w3.org
> For that to be of any value, aren't you assuming the RP will store the attestation statement? What's to say that an RP will store it if they don't care about authenticator attestation (since they sent attestation: "none", or left it at that default)? I believe the dominant practice at the moment, for sites using the U2F API in Chrome, is not to discriminate on attestation at registration time, but to store the certificate in case it's useful later for messaging users who might be affected by specific security issues. > However in the Privacy CA case, the authenticator's signature isn't passed on to the RP, correct? If so, the Privacy CA could alter the authenticator data - e.g., zero out the AAGUID - before signing it, without cooperation from the token. A Privacy CA is essentially signing statements to the effect: “I have seen a signature for the following hash made by a valid token”. If the client passes only the hash of the signed data, the Privacy CA can check the token's attestation signature and sign that same hash. However, that means that the AAGUID cannot be altered. The client could send the signed data itself to the Privacy CA, but then the Privacy CA learns the RP ID that the user is registering with, which is likely unacceptable. -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/pull/693#issuecomment-346426640 using your GitHub account
Received on Wednesday, 22 November 2017 17:51:21 UTC