Merge pull request #1680 from agl/noselfsign

Tighten requirements for rejecting duplicate credential IDs.

index.bs

@@ -4508,11 +4508,11 @@ In order to perform a [=registration ceremony=], the [=[RP]=] MUST proceed as fo
         - Otherwise, use the X.509 certificates returned as the [=attestation trust path=] from the [=verification procedure=]
             to verify that the attestation public key either correctly chains up to an acceptable root certificate, or is itself an acceptable certificate (i.e., it and the root certificate obtained in Step 19 may be the same).
 
-1. Check that the <code>[=credentialId=]</code> is &le; 1023 bytes. Credential IDs larger than this many bytes SHOULD cause the RP to fail this [=registration ceremony=].
+1. Verify that the <code>[=credentialId=]</code> is &le; 1023 bytes. Credential IDs larger than this many bytes SHOULD cause the RP to fail this [=registration ceremony=].
 
-1. Check that the <code>[=credentialId=]</code> is not yet registered to any other user. If registration
-    is requested for a credential that is already registered to a different user, the [=[RP]=] SHOULD
-    fail this [=registration ceremony=], or it MAY decide to accept the registration, e.g. while deleting the older registration.
+1. Verify that the <code>[=credentialId=]</code> is not yet registered for any user. If the <code>[=credentialId=]</code> is already known then the [=[RP]=] SHOULD fail this [=registration ceremony=].
+
+    NOTE: The rationale for [=[RPS]=] rejecting duplicate [=credential IDs=] is as follows: [=credential IDs=] contain sufficient entropy that accidental duplication is very unlikely. However, [=attestation types=] other than [=self attestation=] do not include a self-signature to explicitly prove possession of the [=credential private key=] at [=registration=] time. Thus an attacker who has managed to obtain a user's [=credential ID=] and [=credential public key=] for a site (this could be potentially accomplished in various ways), could attempt to register a victim's credential as their own at that site. If the [=[RP]=] accepts this new registration and replaces the victim's existing credential registration, and the [=discoverable credentials|credentials are discoverable=], then the victim could be forced to sign into the attacker's account at their next attempt. Data saved to the site by the victim in that state would then be available to the attacker.
 
 1. If the attestation statement |attStmt| verified successfully and is found to be trustworthy, then register the new
     credential with the account that was denoted in <code>|options|.{{PublicKeyCredentialCreationOptions/user}}</code>: