Merge pull request #1664 from agl/credidlimit

Define 1023 bytes to be the maximum credential ID length.

index.bs

@@ -1052,7 +1052,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
     given in this specification, and handling communication between [=authenticators=] and [=[RPS]=].
 
 : <dfn>Credential ID</dfn>
-:: A probabilistically-unique [=byte sequence=] identifying a [=public key credential source=] and its [=authentication assertions=].
+:: A probabilistically-unique [=byte sequence=] identifying a [=public key credential source=] and its [=authentication assertions=]. At most 1023 bytes long.
 
     Credential IDs are generated by [=authenticators=] in two forms:
     1. At least 16 bytes that include at least 100 bits of entropy, or
@@ -4125,7 +4125,7 @@ object=] for a given credential. Its format is shown in <a href="#table-attested
         <tr>
             <td><dfn>credentialIdLength</dfn></td>
             <td>2</td>
-            <td>Byte length <strong>L</strong> of Credential ID, 16-bit unsigned big-endian integer.</td>
+            <td>Byte length <strong>L</strong> of [=credentialId=], 16-bit unsigned big-endian integer. Value MUST be &le; 1023.</td>
         </tr>
         <tr>
             <td><dfn>credentialId</dfn></td>
@@ -4271,7 +4271,7 @@ calling {{CredentialsContainer/create()|navigator.credentials.create()}} they se
 [=attestation type=] as a part of [=verification procedure|verification=]. See the "Verification procedure" subsections of
 [[#sctn-defined-attestation-formats]]. See also [[#sctn-attestation-privacy]]. For all [=attestation types=] defined in this
 section other than [=self attestation|Self=] and [=None=], [=[RP]=] [=verification procedure|verification=] is followed by
-matching the [=attestation trust path|trust path=] to an acceptable root certificate per step 21 of [[#sctn-registering-a-new-credential]].
+matching the [=attestation trust path|trust path=] to an acceptable root certificate per step 20 of [[#sctn-registering-a-new-credential]].
 Differentiating these [=attestation types=] becomes useful primarily as a means for determining if the [=attestation=] is acceptable
 under [=[RP]=] policy.
 
@@ -4483,8 +4483,9 @@ In order to perform a [=registration ceremony=], the [=[RP]=] MUST proceed as fo
         - If [=None|no attestation=] was provided, verify that [=None=] attestation is acceptable under [=[RP]=] policy.
         - If [=self attestation=] was used, verify that [=self attestation=] is acceptable under [=[RP]=] policy.
         - 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 20 may be the same).
+            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. 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
@@ -4508,7 +4509,7 @@ In order to perform a [=registration ceremony=], the [=[RP]=] MUST proceed as fo
         of the {{PublicKeyCredentialRequestOptions/allowCredentials}} option in future {{CredentialsContainer/get()}} calls
         to help the [=client=] know how to find a suitable [=authenticator=].
 
-1. If the attestation statement |attStmt| successfully verified but is not trustworthy per step 21 above, the [=[RP]=] SHOULD fail
+1. If the attestation statement |attStmt| successfully verified but is not trustworthy per step 20 above, the [=[RP]=] SHOULD fail
     the [=registration ceremony=].
 
     NOTE: However, if permitted by policy, the [=[RP]=] MAY register the [=credential ID=] and credential public key but treat the
@@ -4517,7 +4518,7 @@ In order to perform a [=registration ceremony=], the [=[RP]=] MUST proceed as fo
         See [[FIDOSecRef]] and [[UAFProtocol]] for a more detailed discussion.
 
 Verification of [=attestation objects=] requires that the [=[RP]=] has a trusted method of determining acceptable trust anchors
-in step 20 above. Also, if certificates are being used, the [=[RP]=] MUST have access to certificate status information for the
+in step 19 above. Also, if certificates are being used, the [=[RP]=] MUST have access to certificate status information for the
 intermediate CA certificates. The [=[RP]=] MUST also be able to build the attestation certificate chain if the client did not
 provide this chain in the attestation information.