Move RP security consideration out from authenticators section

index.bs

@@ -5804,17 +5804,10 @@ manufactured [=[WAA]s=], if the exposure was due to a firmware flaw. (The proces
 scope for this specification.) If the [=[WAA]=] manufacturer does not have this capability, then it may not be
 possible for [=[RPS]=] to trust any further attestation statements from the affected [=[WAA]s=].
 
-If attestation certificate validation fails due to a revoked intermediate attestation CA certificate, and the [=[RP]=]'s policy
-requires rejecting the registration/authentication request in these situations, then it is RECOMMENDED that the [=[RP]=] also
-un-registers (or marks with a trust level equivalent to "[=self attestation=]") [=public key credentials=] that were registered
-after the CA compromise date using an attestation certificate chaining up to the same intermediate CA. It is thus RECOMMENDED
-that [=[RPS]=] remember intermediate attestation CA certificates during Authenticator registration in order to un-register
-related [=public key credentials=] if the registration was performed after revocation of such certificates.
-
 If an [=ECDAA=] attestation key has been compromised, it can be added to the RogueList (i.e., the list of revoked
-authenticators) maintained by the related ECDAA-Issuer. The [=[RP]=] SHOULD verify whether an authenticator belongs to the
-RogueList when performing ECDAA-Verify (see section 3.6 in [[!FIDOEcdaaAlgorithm]]). For example, the FIDO Metadata Service
-[[FIDOMetadataService]] provides one way to access such information.
+authenticators) maintained by the related ECDAA-Issuer.
+
+See also the related security consideration for [=[RPS]=] in [[#sctn-revoked-attestation-certificates]].
 
 
 ## Security considerations for [=clients=] ## {#sctn-security-considerations-client}
@@ -5899,6 +5892,23 @@ Note: All variants of [=man-in-the-middle attacks=] described above are more dif
 than a [=man-in-the-middle attack=] against conventional password authentication.
 
 
+### Revoked Attestation Certificates ### {#sctn-revoked-attestation-certificates}
+
+If attestation certificate validation fails due to a revoked intermediate attestation CA certificate, and the [=[RP]=]'s policy
+requires rejecting the registration/authentication request in these situations, then it is RECOMMENDED that the [=[RP]=] also
+un-registers (or marks with a trust level equivalent to "[=self attestation=]") [=public key credentials=] that were registered
+after the CA compromise date using an attestation certificate chaining up to the same intermediate CA. It is thus RECOMMENDED
+that [=[RPS]=] remember intermediate attestation CA certificates during Authenticator registration in order to un-register
+related [=public key credentials=] if the registration was performed after revocation of such certificates.
+
+If an [=ECDAA=] attestation key has been compromised, it can be added to the RogueList (i.e., the list of revoked
+authenticators) maintained by the related ECDAA-Issuer. The [=[RP]=] SHOULD verify whether an authenticator belongs to the
+RogueList when performing ECDAA-Verify (see section 3.6 in [[!FIDOEcdaaAlgorithm]]). For example, the FIDO Metadata Service
+[[FIDOMetadataService]] provides one way to access such information.
+
+See also the related security consideration for [=authenticators=] in [[#sctn-ca-compromise]].
+
+
 ### Credential Loss and Key Mobility ### {#sctn-credential-loss-key-mobility}
 
 This specification defines no protocol for backing up [=credential private keys=], or for sharing them between [=authenticators=].