Merge pull request #747 from emlun/fix-step-references

Fix outdated step references in RP registration algorithm

index.bs

@@ -2814,7 +2814,7 @@ When registering a new credential, represented by a {{AuthenticatorAttestationRe
 
 1. Verify that |attStmt| is a correct [=attestation statement=], conveying a valid [=attestation signature=], by using the
     [=attestation statement format=] |fmt|'s verification procedure given |attStmt|, |authData| and the [=hash of the serialized
-    client data=] computed in step 6.
+    client data=] computed in step 7.
 
     Note: Each [=attestation statement format=] specifies its own verification procedure. See [[#defined-attestation-formats]] for
     the initially-defined formats, and [[!WebAuthn-Registries]] for the up-to-date list.
@@ -2824,10 +2824,10 @@ When registering a new credential, represented by a {{AuthenticatorAttestationRe
     example, the FIDO Metadata Service [[FIDOMetadataService]] provides one way to obtain such information, using the
     <code>[=aaguid=]</code> in the <code>[=attestedCredentialData=]</code> in |authData|.
 
-1. Assess the attestation trustworthiness using the outputs of the verification procedure in step 10, as follows:
+1. Assess the attestation trustworthiness using the outputs of the verification procedure in step 11, as follows:
         - If [=self attestation=] was used, check if [=self attestation=] is acceptable under [=[RP]=] policy.
         - If [=ECDAA=] was used, verify that the [=identifier of the ECDAA-Issuer public key=] used is included in the set of
-            acceptable trust anchors obtained in step 11.
+            acceptable trust anchors obtained in step 12.
         - Otherwise, use the X.509 certificates returned by the verification procedure to verify that the attestation public key
             correctly chains up to an acceptable root certificate.
 
@@ -2842,7 +2842,7 @@ When registering a new credential, represented by a {{AuthenticatorAttestationRe
     <code>[=credentialPublicKey=]</code> in the <code>[=attestedCredentialData=]</code> in |authData|, as appropriate for the
     [=[RP]=]'s system.
 
-1. If the attestation statement |attStmt| successfully verified but is not trustworthy per step 12 above, the [=[RP]=] SHOULD fail
+1. If the attestation statement |attStmt| successfully verified but is not trustworthy per step 13 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
@@ -2851,7 +2851,7 @@ When registering a new credential, represented by a {{AuthenticatorAttestationRe
         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 11 above. Also, if certificates are being used, the [=[RP]=] MUST have access to certificate status information for the
+in step 12 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.
 
@@ -2896,7 +2896,7 @@ When verifying a given {{PublicKeyCredential}} structure (|credential|) as part
 
 1. Let |hash| be the result of computing a hash over the |cData| using SHA-256.
 
-1. Using the credential public key looked up in step 1, verify that |sig| is a valid signature over the binary concatenation of
+1. Using the credential public key looked up in step 3, verify that |sig| is a valid signature over the binary concatenation of
     |aData| and |hash|.
 
 1. If the [=signature counter=] value |adata|.<code>[=signCount=]</code> is nonzero or the value stored