Ithy - Unveiling CA Secrets: Duplicate Public Keys and Revocation Mandates

The world of digital certificates and Public Key Infrastructure (PKI) is built on trust, underpinned by rigorous standards that Certificate Authorities (CAs) must follow. A critical aspect of this trust involves how CAs handle public keys, especially when duplicates arise or when private keys are compromised. Understanding these obligations is key to comprehending the security of our online interactions.

Key Insights: CA Obligations at a Glance

Issuance Checks: CAs are generally not explicitly required by baseline industry standards to cross-check every new certificate request's public key against all previously issued certificates to ensure absolute uniqueness across different subscribers. Their primary focus during issuance is validating the subscriber's control over the corresponding private key and their identity. However, nuances exist, particularly to avoid ambiguity for the same subscriber.
Revocation Due to Key Compromise: If a private key is compromised, CAs are required to revoke all certificates that utilize the corresponding public key. This is a critical security measure because the compromise of the private key invalidates the security of every certificate associated with it.
Governing Standards: These requirements, especially for revocation, primarily stem from the CA/Browser Forum Baseline Requirements (BRs). The obligation to revoke for "keyCompromise" effectively mandates the revocation of all associated certificates. Major root programs (Mozilla, Apple, Google, Microsoft) enforce compliance with these BRs.

The Issuance Process: Checking for Duplicate Public Keys

When a subscriber requests a new digital certificate, the issuing CA undertakes a series of validation steps. However, a universal, explicit mandate for CAs to check if the submitted public key is already present in *any other* existing certificate, particularly one issued to a *different* entity, is not a standard feature of the CA/Browser Forum Baseline Requirements (BRs).

Focus on Private Key Control and Identity

The primary responsibilities of a CA during issuance include:

Verifying the identity of the entity requesting the certificate.
Ensuring that the requester has legitimate control over the private key corresponding to the public key being submitted in the Certificate Signing Request (CSR). This is often done through a proof-of-possession challenge.

The BRs do contain provisions aimed at ensuring uniqueness and proper key management. For instance, they may require CAs to verify that a public key in a certificate request has not been previously issued in another certificate for the *same subscriber* in a way that would create ambiguity or unacceptable key reuse risks. However, this is different from a blanket requirement to check against all public keys ever issued by all CAs.

Operational Policies and Practical Limitations

Some CAs might implement their own operational policies that limit the issuance of "duplicate" certificates (e.g., certificates with the same public key and subject name) within a certain timeframe. For example, Let's Encrypt has rate limits that affect duplicate certificate issuance. However, these are often CA-specific operational controls rather than industry-wide mandates for public key uniqueness across all certificates and subscribers.

Furthermore, CAs do not typically maintain publicly searchable databases of all public keys they have issued, which would be necessary for a comprehensive pre-issuance check against all existing certificates. The focus remains on the integrity and validated control for each specific issuance request.

Diagram illustrating Public Key Infrastructure (PKI) architecture

A typical Public Key Infrastructure (PKI) involves Certificate Authorities, Registration Authorities, and End Entities.

Revocation Imperative: When a Private Key is Compromised

The situation changes dramatically when a private key is compromised. A compromised private key means that an unauthorized party may have access to it, allowing them to impersonate the legitimate key holder, decrypt sensitive information, or forge digital signatures. In such a scenario, the security assurances provided by any certificate associated with that private key are nullified.

Mandatory Revocation of All Affected Certificates

If a private key is confirmed to be compromised (e.g., stolen, lost, or otherwise exposed to unauthorized parties), the CA that issued certificates based on the corresponding public key is required to revoke all such certificates. This is not merely a best practice but a fundamental requirement for maintaining the trustworthiness of the PKI ecosystem.

The reasoning is straightforward: if the private key is compromised, then every certificate that shares the associated public key is equally compromised. Allowing these certificates to remain active would pose a significant security risk. The CA/Browser Forum Baseline Requirements, particularly Section 4.9 concerning certificate revocation, and the revocation reason codes defined in RFC 5280 (which the BRs mandate), underpin this obligation. The "keyCompromise" reason code (value 1 in RFC 5280) specifically addresses this scenario.

When a CA revokes a certificate, it adds it to a Certificate Revocation List (CRL) or updates its status via an Online Certificate Status Protocol (OCSP) responder. Relying parties (e.g., web browsers) then check these mechanisms to determine if a certificate is still valid before trusting it.

This video discusses various aspects of Certificate Services, including Certificate Authorities and Public Trusted Root CAs, providing context on the PKI environment where these rules apply.

Pinpointing the Requirements: Sources of Authority

The obligations for CAs, especially those issuing publicly trusted TLS/SSL certificates, are primarily defined in industry-standard documents and enforced by major software vendors.

CA/Browser Forum Baseline Requirements

The CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (BRs) are the cornerstone of these rules. While the BRs might not contain a single, isolated sentence explicitly stating, "CAs must check all issued public keys for duplicates before issuing a new certificate," or "CAs must revoke every certificate sharing a public key if one is compromised using these exact words," the cumulative effect of its provisions, especially regarding key compromise, leads to these outcomes.

Section 4.9 (Certificate Revocation and Status Checking): This section outlines the circumstances under which a CA must revoke a certificate. "Key Compromise" is a principal reason. If a private key is compromised, any certificate whose public key corresponds to that private key is, by definition, compromised.
RFC 5280: The BRs require CAs to use revocation reason codes as defined in RFC 5280. Reason code keyCompromise (1) indicates that the private key associated with the certificate's public key has been compromised. The logical extension is that all certificates tied to this specific compromised private key must be revoked.

Root Program Policies

Major "root programs" – operated by entities like Mozilla (Firefox), Apple (Safari/macOS/iOS), Google (Chrome/Android), and Microsoft (Windows/Edge) – maintain their own policies for CAs whose root certificates are embedded in their trust stores. These policies universally require CAs to adhere to the CA/Browser Forum Baseline Requirements. Furthermore, these root programs expect CAs to act diligently and holistically in response to security incidents, including key compromises, reinforcing the need to revoke all affected certificates.

Visualizing CA Obligations: A Comparative Overview

The following chart provides a conceptual overview of the strength and nature of requirements related to duplicate public keys and CA responses. The ratings are interpretative, reflecting the general consensus from industry standards, where '1' indicates a weak or non-existent explicit mandate and '10' indicates a very strong, clear requirement or implication.

This chart illustrates that while a direct, standalone sentence in the BRs explicitly mandating a universal check for duplicate public keys at issuance is low, the effective requirement to revoke all certificates tied to a compromised private key is very strong, driven by the "keyCompromise" provisions and enforced by root programs, aligning closely with security best practices.

Explicit vs. Implicit Requirements: Navigating the Nuances

Understanding the rules around duplicate public keys involves recognizing both explicit mandates and implicit expectations rooted in security principles.

Explicit Requirements

Revocation for Key Compromise: As detailed, the CA/B Forum BRs explicitly require CAs to revoke certificates when the associated private key is compromised. This effectively means all certificates sharing the public key tied to that compromised private key must be revoked.
Validation of Private Key Control: CAs are explicitly required to verify that an applicant for a certificate has control over the private key corresponding to the public key in the CSR.

Implicit Requirements and Best Practices

Discouragement of Key Reuse: While not always explicitly forbidden for *different* entities to (coincidentally or otherwise) request certificates for the same public key (if they can prove possession of the private key), general security best practices strongly discourage unnecessary key reuse. Reusing the same key pair across multiple distinct services or entities increases the "blast radius" if that single key pair is compromised – one compromise affects all.
Maintaining PKI Trust: The entire PKI system relies on trust. Any practice that could undermine this trust, such as failing to revoke all known certificates affected by a key compromise, is implicitly contrary to the goals of PKI.
Risk Management: From a risk management perspective, CAs and certificate subscribers should aim to minimize scenarios where multiple, unrelated certificates depend on the same private key. If such a situation exists, robust and swift action upon any sign of compromise is paramount.

The system is designed to handle the severe implications of a private key compromise by mandating the revocation of affected certificates, thereby protecting end-users and maintaining the integrity of secure communications.

Mapping CA Obligations for Duplicate Public Keys

This mind map provides a structured overview of the considerations and requirements surrounding Certificate Authority obligations when dealing with certificates that may share the same public key, particularly in the context of issuance and revocation due to private key compromise.

mindmap root["CA Obligations
Duplicate Public Keys"] id1["Issuance Phase"] id1a["No Universal Mandate
to Cross-Check All Public Keys"] id1b["Primary Focus:
Subscriber's Private Key Control & Identity Verification"] id1c["CA/B Forum BRs:
Address Uniqueness for *Same Subscriber*
to Prevent Ambiguity/Key Reuse Risks"] id1d["Operational Policies:
Some CAs May Limit Duplicate Certs (e.g., Rate Limits)"] id2["Revocation (Private Key Compromise)"] id2a["MANDATORY Revocation
of ALL Certificates Sharing the Public Key"] id2b["Reason: KeyCompromise (RFC 5280, BR Section 4.9)"] id2c["Security Impact:
Compromised Private Key Invalidates ALL Linked Certificates"] id2d["Action:
Update CRLs / OCSP Responders"] id3["Governing Documents & Bodies"] id3a["CA/Browser Forum
Baseline Requirements (BRs)"] id3a1["Central Authority for Publicly Trusted Certs"] id3a2["Section 4.9: Certificate Revocation"] id3b["RFC 5280
(Internet X.509 PKI Certificate and CRL Profile)"] id3b1["Defines Revocation Reason Codes (e.g., keyCompromise)"] id3c["Root Program Policies
(Mozilla, Apple, Google, Microsoft)"] id3c1["Enforce BR Compliance"] id3c2["Expect Diligent Incident Response from CAs"] id4["Nature of Requirements"] id4a["Explicit Mandates"] id4a1["Revocation due to Key Compromise"] id4a2["Proof-of-Possession of Private Key at Issuance"] id4b["Implicit Expectations & Best Practices"] id4b1["Discourage Widespread Key Reuse (Security Risk)"] id4b2["Maintain Overall Trust and Integrity of PKI"] id4b3["Swift Action on Any Compromise Indication"]

The mind map illustrates that while CAs have significant validation duties at issuance, the most stringent requirements concerning duplicate public keys manifest when a private key compromise occurs, necessitating the revocation of all associated certificates to protect the ecosystem.

Summary Table: CA Requirements for Public Keys

This table summarizes the core requirements for Certificate Authorities concerning the handling of public keys in certificates, particularly focusing on issuance checks and revocation obligations in the event of a private key compromise.

Aspect of CA Obligation	Requirement for CAs Issuing Publicly Trusted Certificates	Primary Source(s) of Requirement
Checking for Duplicate Public Keys During Certificate Issuance	There is no explicit universal mandate in the CA/Browser Forum Baseline Requirements (BRs) for CAs to check if a requested public key is already used in any other pre-existing certificate issued to a different entity. The focus is on validating the current requester's control over the private key and their identity. Nuances in the BRs address preventing ambiguity or risky key reuse for the same subscriber.	Generally not explicitly mandated as a universal check against all keys in the BRs or typical root program policies. CA operational policies may vary.
Revoking All Certificates with the Same Public Key if the Corresponding Private Key is Compromised	Yes, this is effectively required. If a private key is compromised, all certificates that utilize the corresponding public key are also considered compromised and must be revoked by the CA.	CA/Browser Forum Baseline Requirements (primarily through the "keyCompromise" revocation reason as per Section 4.9 and its link to RFC 5280), enforced by Root Program Policies.
Revocation of the Specific Certificate Directly Linked to a Known Compromise Event	Yes, unequivocally. The individual certificate known to be associated with a compromised key or other revocation-triggering event must be revoked.	CA/Browser Forum Baseline Requirements, Root Program Policies.