R2r Root Certificate ^new^ Site

Consider validation: A path-building algorithm, when faced with an R2R, must be careful not to loop forever. Standard X.509 path validation (RFC 5280) expects a monotonic chain toward a single trust anchor. R2R violates that assumption. Implementations must introduce or explicit policy mappings to cut the cycle. Without them, the validator could theoretically walk from Root A to Root B and back to Root A, ad infinitum.

An R2R violates this solitude. It says: “I, Root A, vouch for Root B’s existence and legitimacy.” And Root B, in turn, may vouch for Root A. The loop closes. Now, a client that trusts only Root A will accept any certificate signed by Root B, because the chain of trust resolves: Leaf → B (signed by A) → A (self-signed). Conversely, a client trusting only Root B sees a different path: Leaf → A (signed by B) → B (self-signed). r2r root certificate

More troubling is the . If two roots cross-certify each other directly, an attacker compromising one root can now impersonate the other. Because the compromised root can issue a certificate that chains to the honest root (via the R2R), the honest root’s name and key material are now effectively co-signed by the adversary. The two roots’ security postures merge. Trust becomes the weakest link multiplied. The R2R in the Wild: Case Study of an Ageing Internet The most famous example is the VeriSign Class 1 – Thawte Roots cross-certification from the early 2000s, though those were typically CA-to-CA, not pure root-to-root. A purer example exists in the Federal Bridge Certificate Authority (U.S. government), where multiple agency roots cross-certify with the Bridge, creating a mesh. At the extreme, two agency roots could directly cross-certify — a true R2R. It says: “I, Root A, vouch for Root