Embedded Alternate Issuer Certificates

2.1. Terminology

Subject:

The entity being described by a certificate.¶

Issuer:

The CA that certified the information in a certificate.¶

Outer certificate:

A certificate that embeds one or more alternate certificates using the mechanism defined in this document.¶

Certification Authority (CA):

The (name, key) tuple representing a certificate issuer.¶

Outer CA:

The CA that issues the outer certificate.¶

Alternate certificate:

One of the certificates embedded in the outer certificate. An alternate certificate certifies the same subject information as the outer certificate, but via a different issuer.¶

Alternate CA:

A CA that issues one of the alternate certificates.¶

Post-quantum opt-out certificate:

An end-entity certificate with a traditional subject key and post-quantum issuer. [PQ-AUTH-ROADMAP] embeds post-quantum opt-out certificates as alternate certificates in a fully traditional outer certificate. Other applications might issue and deploy them independently, without using this specification.¶

3.1. Issuing Certificates

After subject information is validated according to the policies of each CA involved, the certificates are issued in the following process:¶

1. The outer CA constructs an initial TBSCertificate with the validated subject information and issuer fields reflecting the outer CA. It sets notBefore and notAfter such that the certificate validity would be compatible with each alternate CA.¶

2. For each alternate CA, run the following steps. The steps for each alternate CA MAY run in parallel.¶

   1. The alternate CA constructs a TBSCertificate based on the outer CA's initial TBSCertificate. The outer CA's issuer-specific fields are removed and replaced with ones reflecting the alternate CA.¶

   2. The alternate CA appends an outer certificate binding extension to its TBSCertificate, containing all fields removed or modified from the initial TBSCertificate, above. This authenticates the removed fields to a relying party that only trusts the alternate CA.¶

   3. The alternate CA signs its TBSCertificate to issue an alternate certificate. This TBSCertificate MUST satisfy the policies of the alternate CA.¶

   4. The alternate CA extracts the alternate certificate's issuer-specific fields and signature. It returns these to the outer CA as an AlternateIssuerInfo. This contains enough information for the relying party to reconstruct the alternate certificate.¶

3. If the outer CA participates in CT, run the following steps. These steps MAY run in parallel with step 2. If the outer CA does not participate in CT, skip these steps.¶

   1. The outer CA signs a precertificate for its initial TBSCertificate, including the critical poison extension, as described in Section 3.1 of [RFC6962].¶

   2. The outer CA then requests Signed Certificate Timestamps (SCTs) from CT logs.¶

4. The outer CA appends an id-ce-embeddedSCT-CTv1 (OID 1.3.6.1.4.1.11129.2.4.2) extension to its initial TBSCertificate. The extension contains the AlternateIssuerInfo and, if applicable, SCTs collected above.¶

5. The outer CA signs its final TBSCertificate to issue the outer certificate. This TBSCertificate MUST satisfy the policies of the outer CA.¶

Figure 1 illustrates this process. Although the two issuance processes are now integrated, from the outer CA's perspective, it is analogous to embedding SCTs in CT. From the alternate CA's perspective, this is issuing a certificate with a specific extension added.¶

While these are two distinct CAs, their policies and certificate issuance have to be sufficiently aligned to issue these closely related certificates. Often the two CAs will be operated by the same entity.¶

Section 4 discusses certificate issuance in more detail.¶

3.2. Verifying Certificates

When the certificate subject presents the outer certificate to a relying party, relying parties will attempt to validate one of several certificates:¶

• Relying parties that are not aware of this protocol will ignore the unrecognized SCT type of alternate_issuer_info and validate the outer certificate as usual. Section 6.2 discusses this further.¶

• Upgraded relying parties will reconstruct the alternate certificates and use them as candidate target certificates when building certification paths [RFC4158]. If a relying party finds some valid certification path from some target certificate, outer or alternate, it proceeds with that certification path. This specification does not impose a preference for whether outer or alternate is used in a case where both have a valid certification path.¶

This allows the same certificate to serve both older relying parties that expect the outer CA, and newer relying parties that expect one of the alternate CAs.¶

Section 5 discusses this in more detail.¶

4.1. Certificate Constraints

Although outer and alternate certificates are conceptually separate, with relying parties accepting one or the other, they are constrained to both share subject information and incorporate parts of each other. Alternate certificates are incorporated into the outer certificate to transmit them. The outer certificate is also partially incorporated into the alternate certificate to mitigate a class of security risks in relying parties. These are described in more detail in Section 7.2.¶

This means outer and alternate CAs are expected to coordinate their certificate profiles and issuance processes, as outlined in Section 3.1. Concretely, the certificates are constrained as follows:¶

The outer and alternate certificates MUST have a version of v3 and MUST omit issuerUniqueID and subjectUniqueID. These are preexisting requirements from Sections 4.1.2.1 and 4.1.2.8 of [RFC5280].¶

The outer and alternate certificates MUST have the same validity, subject, and subjectPublicKeyInfo values.¶

The outer and alternate certificates' extensions lists MUST each consist of, in order, zero or more common extensions, zero or more issuer-specific extensions, and a single final extension. These MUST satisfy the following:¶

• The common extensions across all certificates MUST be equal and appear in the same order.¶

• The issuer-specific extensions MUST NOT contain any of the following extensions:¶

  • id-ce-subjectKeyIdentifier, Section 4.2.1.2 of [RFC5280]¶

  • id-ce-keyUsage, Section 4.2.1.3 of [RFC5280]¶

  • id-ce-subjectAltName, Section 4.2.1.6 of [RFC5280]¶

  • id-ce-subjectDirectoryAttributes, Section 4.2.1.8 of [RFC5280]¶

  • id-ce-basicConstraints, Section 4.2.1.9 of [RFC5280]¶

  • id-ce-nameConstraints, Section 4.2.1.10 of [RFC5280]¶

  • id-ce-extKeyUsage, Section 4.2.1.12 of [RFC5280]¶

  • id-pe-subjectInfoAccess, Section 4.2.2.2 of [RFC5280]¶

  • id-CABFOrganizationIdentifier, [CABF-EV]¶

• PKI deployments MAY impose additional restrictions on issuer-specific extensions by policy. In particular, deployments SHOULD forbid extensions which would change the certificate's subject information in ways which would risk the issues described in Section 7.2. The following is a non-exhaustive list of extensions which would be safe to permit as issuer-specific in most applications:¶

  • id-ce-authorityKeyIdentifier, Section 4.2.1.1 of [RFC5280]¶

  • id-ce-certificatePolicies, Section 4.2.1.4 of [RFC5280]¶

  • id-ce-issuerAltName, Section 4.2.1.7 of [RFC5280]¶

  • id-ce-cRLDistributionPoints, Section 4.2.1.13 of [RFC5280]¶

  • id-ce-freshestCRL, Section 4.2.1.15 of [RFC5280]¶

  • id-pe-authorityInfoAccess, Section 4.2.2.1 of [RFC5280]¶

  • id-pe-qcStatements, Section 3.2.6 of [RFC3739]¶

• The outer certificate's final extension MUST have type id-ce-embeddedSCT-CTv1, with contents as described in Section 4.2. This embeds each alternate certificate in the outer certificate.¶

• Each alternate certificate's final extension MUST have type id-pe-outerCertificateBinding, with contents as described in Section 4.3. This authenticates most of the outer certificate from the alternate certificate.¶

4.2. Alternate Certificate Information

Each alternate certificate is described as differences from the outer certificate in an AlternateIssuerInfo structure. An AlternateIssuerInfo is defined as follows:¶

AlternateIssuerInfo ::= SEQUENCE {
    serialNumber         CertificateSerialNumber,
    signatureAlgorithm   AlgorithmIdentifier{SIGNATURE-ALGORITHM,
                             {SignatureAlgorithms}},
    issuer               Name,
    commonExtensionCount INTEGER (0..MAX),
    issuerExtensions     SEQUENCE OF Extension{{CertExtensions}},
    signatureValue       BIT STRING
}

An AlternateIssuerInfo's fields are defined as follows:¶

• serialNumber is the alternate certificate's serial number.¶

• signatureAlgorithm is the alternate certificate's signature algorithm. This value appears in both the TBSCertificate and Certificate structures.¶

• issuer is the alternate certificate's issuer name.¶

• commonExtensionCount is the number of common extensions, as defined in Section 4.1. This value MUST be strictly less than the number of extensions in the outer certificate, to exclude the outer certificate's final extension.¶

• issuerExtensions is the alternate certificate's issuer-specific extensions, as defined in Section 4.1.¶

• signatureValue is the alternate certificate's signature value. This is a signature over the reconstructed TBSCertificate, not the AlternateIssuerInfo.¶

opaque SerializedSCT<1..2^16-1>;

struct {
    SerializedSCT sct_list<1..2^16-1>;
} SignedCertificateTimestampList;

enum {
    alternate_issuer_info(TBD3), (0xFFFF)
} VersionedTransType;

struct {
    VersionedTransType versioned_type;
    select (versioned_type) {
        case alternate_issuer_info:
            opaque contents<1..2^16-1>;
    } data;
} TransItem;

4.3. Outer Certificate Binding

Each alternate certificate contains an outer certificate binding extension, defined below:¶

OuterCertificateBinding ::= SEQUENCE {
    serialNumber         CertificateSerialNumber,
    signatureAlgorithm   AlgorithmIdentifier{SIGNATURE-ALGORITHM,
                            {SignatureAlgorithms}},
    issuer               Name,
    commonExtensionCount INTEGER (0..MAX),
    issuerExtensions     SEQUENCE OF Extension{{CertExtensions}}
}

id-pe-outerCertificateBinding OBJECT IDENTIFIER ::= {
    iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) pe(1) TBD2 }

ext-outerCertificateBinding EXTENSION ::= {
    SYNTAX OuterCertificateBinding
    IDENTIFIED BY id-pe-outerCertificateBinding
    CRITICALITY FALSE
}

The OuterCertificateBinding structure is similar to the AlternateIssuerInfo, except that it does not contain a signatureValue field. It describes the outer certificate, relative to the alternate certificate.¶

• serialNumber is the outer certificate's serial number.¶

• signatureAlgorithm is the outer certificate's signature algorithm. This value appears in both the TBSCertificate and Certificate structures.¶

• issuer is the outer certificate's issuer name.¶

• commonExtensionCount is the number of common extensions, as defined in Section 4.1. This value MUST be strictly less than the number of extensions in the alternate certificate, to exclude the outer certificate binding extension itself.¶

• issuerExtensions is the outer certificate's issuer-specific extensions, as defined in Section 4.1.¶

The outer certificate binding extension MUST be the final extension in the alternate certificate and MUST be non-critical. It contains enough information to reconstruct the outer CA's initial TBSCertificate (see Section 3.1). CAs MUST NOT issue an outer certificate binding extension if this reconstructed TBSCertificate violates the constraints in Section 4.1, or is otherwise inconsistent with applicable policies. In particular, the issuerExtensions field MUST NOT contain any issuer-specific extensions forbidden by Section 4.1 or applicable policies.¶

This binding mitigates the security risks described in Section 7.2 by authenticating most of the replaced outer certificate by the alternate CA.¶

Note that the design of this mechanism precludes nested alternate certificates since both the outer certificate's id-ce-embeddedSCT-CTv1 extension, and the alternate certificate's id-pe-outerCertificateBinding extension must be last, thereby precluding a certificate from simultaneously being both an outer and alternate certificate. This does not preclude the alternate certificate from embedding SCTs because [RFC6962] does not have an ordering requirement.¶

5.1. Reconstructing the Alternate Certificate

The following procedure reconstructs an alternate certificate from the outer certificate and an AlternateIssuerInfo.¶

1. Check each of the following. If any check fails, abort this procedure.¶

   • The outer certificate's version is v3.¶

   • The outer certificate's signatureAlgorithm and its TBSCertificate's signature fields are equal.¶

   • The outer certificate has no subjectUniqueID or issuerUniqueID field.¶

   • The outer certificate has at least commonExtensionCount + 1 extensions and the final extension is id-ce-embeddedSCT-CTv1.¶

2. Make a copy of the outer certificate as a Certificate structure.¶

3. Replace the TBSCertificate's serialNumber field with the AlternateIssuerInfo's serialNumber. Let outerSerialNumber be the replaced value.¶

4. Replace the Certificate's signatureAlgorithm field and the TBSCertificate's signature field with the AlternateIssuerInfo's signatureAlgorithm. Let outerSignatureAlgorithm be the replaced value.¶

5. Replace the TBSCertificate's issuer field with the AlternateIssuerInfo's issuer. Let outerIssuer be the replaced value.¶

6. Remove the TBSCertificate's final extension. The processing steps in Section 5 ensure this extension has type id-ce-embeddedSCT-CTv1 and contains the AlternateIssuerInfo, formatted as described in Section 4.2.1.¶

7. Remove all but the first commonExtensionCount extensions in the TBSCertificate. Let outerIssuerExtensions be the removed extensions.¶

8. Check outerIssuerExtensions and the AlternateIssuerInfo's issuerExtensions as described in Section 5.2. If rejected, abort this procedure.¶

9. Append the AlternateIssuerInfo's issuerExtensions to the TBSCertificate.¶

10. Append a non-critical outer certificate binding extension (Section 4.3) to the TBSCertificate such that:¶

    • serialNumber is outerSerialNumber.¶

    • signatureAlgorithm is outerSignatureAlgorithm.¶

    • issuer is outerIssuer.¶

    • commonExtensionCount is the AlternateIssuerInfo's commonExtensionCount value.¶

    • issuerExtensions is outerIssuerExtensions.¶

11. Replace the Certificate's signatureValue field with the AlternateIssuerInfo's signatureValue.¶

5.2. Checking Issuer-Specific Extensions

Section 4.1 aims to forbid outerIssuerExtensions and issuerExtensions above from containing any extensions that would change the certificate's subject information. However, X.509 is extensible, so a relying party cannot enforce this restriction in full. In particular, relying parties MUST accept unrecognized issuer-specific extensions in this procedure. (If the unrecognized issuer-specific extension is critical, it will likely be rejected later during path validation.)¶

The relying party SHOULD check for and reject the forbidden issuer-specific extensions listed in Section 4.1 and other issuer-specific extensions known to be forbidden by local policy. The relying party MAY skip this check for any extension that its path verifier does not recognize. It also MAY skip this check if all subsequent access checks reliably inspect the correct certificate, as described in Section 7.2.¶

5.3. Input Certificates and Validated Certificates

For this section, we define the input certificate to be the entire certificate being processed (typically the outer certificate), and the validated certificate to be the one for which the certification path was checked, which may be the outer certificate or an alternate certificate. Note that the input certificate will always contain the validated target certificate, but does not specify which one it is. This section considers potential impacts of the input certificate and the validated certificate being different.¶

In contexts that are defined based on the certificate that was sent over the wire, the input certificate is used. For example:¶

• The TLS transcript hash (Section 4.1 of [RFC9846]) is computed from the Certificate message and thus the bytes of the input certificate.¶

• The tls-server-end-point channel binding (Section 4 of [RFC5929]) is computed from the bytes of the input certificate.¶

In contexts that are defined based on the certificate that was validated, notably access control checks, the validated certificate SHOULD be used. Section 7.2 discusses this case in more detail.¶

This distinction is a generalization of an existing distinction in path-building X.509 applications. The input list of certificates may differ from the final certification path that was built. Applications are already expected to separate these cases, but they were not previously required to consider different target certificates.¶

6.1. Legacy Services

This document defines a temporary transitionary mechanism for deployments where some legacy services do not support multiple certificates. Services that support multiple certificates directly SHOULD NOT use this mechanism. Deployments are RECOMMENDED to enforce this in CAs and relying parties.¶

For example, in a post-quantum transition for TLS, this mechanism is only applicable to unmodified legacy services that only have traditional end-entity keys. Once a service has a post-quantum end-entity key, it can be assumed to be relatively up-to-date and necessarily maintains separate end-entity keys for both legacy and post-quantum relying parties. The service also necessarily has sufficient certificate selection capabilities (Section 4.5.1.2 of [RFC9846]) to select between its supported relying parties. Such a service would have no need for this document. Accordingly, in a TLS deployment using this mechanism for a post-quantum transition:¶

• CAs SHOULD NOT embed alternate certificates if the end-entity key is post-quantum.¶

• Relying parties SHOULD ignore alternate certificates if the end-entity key is post-quantum.¶

This ensures that, when the post-quantum transition is completed, services will no longer rely on this mechanism and implementations can remove the supporting logic.¶

A given deployment SHOULD only deploy this mechanism once, for only one transition. After that transition has completed, the deployment SHOULD have transitioned to a state where certificate holders support multiple certificates.¶

6.2. Legacy Relying Parties

The primary backwards compatibility goal of this specification is that a relying party that is unaware of this specification will process the outer certificate as if the alternate was not present. This assumes that existing certificate parsers will ignore unrecognized SCTs of type alternate_issuer_info and continue processing the rest of the certificate as usual.¶

This is believed to be the behavior of all existing parsers, and is supported by both [RFC6962] and [RFC9162]:¶

Section 3.3 of [RFC6962] says:¶

• This encoding ensures that TLS clients can decode each SCT individually (i.e., if there is a version upgrade, out-of-date clients can still parse old SCTs while skipping over new SCTs whose versions they don't understand).¶

Section 6.3 of [RFC9162] says:¶

• This encoding ensures that TLS clients can decode each TransItem individually (so, for example, if there is a version upgrade, out-of-date clients can still parse old TransItem structures while skipping over new TransItem structures whose versions they don't understand).¶

6.3. Certificate Transparency Log Sizes

In deployments that use CT [RFC6962], a direct post-quantum transition risks significantly increasing the sizes of CT logs. [IETF124-PLANTS] estimated an 8.3x size increase from migrating to ML-DSA-44.¶

Merkle Tree Certificates [I-D.ietf-plants-merkle-tree-certs] provide a quantum-resistant transparency construction that avoids this size increase. However, when post-quantum Merkle Tree Certificates are embedded as alternate certificates, the resulting large AlternateIssuerInfo structures will instead be logged with the outer certificate. The traditional CT logs would increase in size during the transition to Merkle Tree Certificates.¶

Section 4.2.1 partially mitigates this new increase by embedding AlternateIssuerInfo structures in SCTs. When the outer certificate's precertificate is logged, the precertificate will omit these SCTs and thus the added structures.¶

This is only a partial mitigation because the AlternateIssuerInfo will still be logged when the final certificate with embedded SCTs is logged. Deployments using this document to transition away from a CT-based PKI thus SHOULD permit CT logs to reject logging of any certificates with embedded SCTs of type alternate_issuer_info. This will not impact other embedded SCTs, which refer to logged precertificates rather than logged final certificates.¶

7.1. Separate Certificates

Although each alternate certificate is ultimately encoded relative to the outer certificate, the alternate CA's signature is on the reconstructed alternate TBSCertificate, so it is still considered to have separately issued the reconstructed alternate certificate. In particular:¶

• The alternate TBSCertificate MUST satisfy the policies of the alternate CA, including any domain validation. Misissuance of an alternate certificate remains misissuance.¶

• Revocation of each certificate is independent. Revoking the outer certificate does not revoke the alternate certificates and vice versa.¶

When relying parties evaluate candidate certification paths, they likewise treat each possible target certificate separately. If the relying party accepts an alternate certificate, it does not verify the outer certificate or even necessarily trust the outer CA. In particular, in the post-quantum transition, the outer CA is a traditional CA, so its key could be compromised by a CRQC.¶

7.2. Certificate Mismatch

Access checks in the relying party SHOULD act on the certification path that was ultimately validated, failing to do so can result in access control bypass vulnerabilities. In support of this, APIs that return the validated certification path SHOULD reflect the correct target certificate.¶

However, this breaks an application invariant. Previously, the target certificate would never change as a result of path building. Which trust anchor it chains to and via which path might change, but the end entity certificate would not. An existing application might assume this invariant and inspect the original target certificate for some access check. If the application's X.509 implementation is updated independently from the rest of the application, it may inadvertently use the wrong certificate, which could carry security implications if the content of the alternate and outer certificate differ. In some cases, the X.509 implementation's APIs might not even return the validated path, only a success or failure status.¶

X.509 implementations MAY further mitigate the risk by limiting alternate certificate support to applications that opt in. However, this might undesirably slow down PKI transitions that depend on alternate certificates. Additionally, a large application might opt in, yet forget to update some component.¶

This document further mitigates this risk in two ways:¶

1. Where possible, limiting alternate certificates to encoding the same subject information as the outer certificate.¶

2. Requiring the alternate CA to sign over removed or replaced outer certificate fields, via the outer certificate binding extension.¶

This contrasts with [I-D.bonnell-lamps-chameleon-certs] and [I-D.ietf-lamps-certdiscovery], which allow the second certificate to differ significantly. There, the application is expected to be fully aware of the second certificate.¶

If a more general protocol were instead used in this document, path validation might, for example, authenticate an alternate certificate's public key, while the rest of the application acts on a different, unverified public key in the outer certificate. This could allow an attacker to bypass certificate-based authentication. However, alternate certificates cannot replace the subjectPublicKeyInfo field in this document, so a public key mismatch is not possible.¶

X.509 extensions complicate this mitigation. X.509 does not structurally distinguish between subject and issuer extensions, in a way that would allow a relying party to classify unrecognized extension types. If the relying party rejects unknown issuer-specific extensions, it is not possible to define new such extensions. However, if it accepts unknown extensions, it could allow an extension that downstream components depend on being the same between the alternate and outer certificate.¶

Instead, the outer certificate binding extension mitigates this risk more generally. Except for id-ce-embeddedSCT-CTv1, extensions replaced or removed from the outer certificate are still signed by the alternate CA. This prevents an arbitrary attacker from manipulating those fields. Section 4.3 additionally holds the alternate CA responsible for meeting the requirements in Section 4.1 and other deployment-specific policies, to forbid the alternate CA itself from enabling an attack. CAs are expected to not sign unknown extensions, so this does not conflict with extensibility.¶

Ultimately, the alternate CA is responsible for ensuring that any extensions removed or modified will not cause interoperability or security problems among the target relying party base.¶

However, there are some cases where this is complicated by relying-party-imposed constraints on the CA. If the alternate CA were under, say, a name constraint (Section 4.2.1.10 of [RFC5280]), the relying party could not rely on the alternate CA alone to mitigate subjectAltName mismatches. If the alternate certificate contained a permitted subjectAltName, while the outer certificate contained an excluded one, a mismatch could bypass the name constraint. Section 5.2 recommends that the relying party check replaced extensions in a more limited way. Though the relying party might not recognize all extensions, its path validator necessarily recognizes all extensions that it incorporates into path validation.¶

8.1. PKIX Module Identifier

IANA is requested to add the following entry in the "SMI Security for PKIX Module Identifier" registry [RFC7299]:¶

8.2. PKIX Certificate Extension

IANA is requested to add the following entry in the "SMI Security for PKIX Certificate Extension" registry [RFC7299]:¶

8.3. Versioned Transparency Item Types

IANA is requested to add the following entry in the "VersionedTransTypes" registry [RFC9162]:¶

9.1. Normative References

[CABF-EV]

CA/Browser Forum, "Guidelines for the Issuance and Management of Extended Validation Certificates", 13 August 2026, <https://cabforum.org/working-groups/server/extended-validation/documents/CA-Browser-Forum-EV-Guidelines-2.0.4.pdf>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC5912]

Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/rfc/rfc5912>.

[RFC6962]

Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/rfc/rfc6962>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9162]

Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.

[RFC9846]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, <https://www.rfc-editor.org/rfc/rfc9846>.

9.2. Informative References

[I-D.bonnell-lamps-chameleon-certs]

Bonnell, C., Gray, J., Hook, D., Okubo, T., and M. Ounsworth, "A Mechanism for Encoding Differences in Paired Certificates", Work in Progress, Internet-Draft, draft-bonnell-lamps-chameleon-certs-07, 18 October 2025, <https://datatracker.ietf.org/doc/html/draft-bonnell-lamps-chameleon-certs-07>.

[I-D.ietf-lamps-certdiscovery]

Okubo, T., Bonnell, C., Gray, J., Ounsworth, M., and J. Mandel, "A Mechanism for X.509 Certificate Discovery", Work in Progress, Internet-Draft, draft-ietf-lamps-certdiscovery-05, 1 November 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-certdiscovery-05>.

[I-D.ietf-plants-merkle-tree-certs]

Benjamin, D., O'Brien, D., Westerbaan, B., Valenta, L., and F. Valsorda, "Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-ietf-plants-merkle-tree-certs-07, 7 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-plants-merkle-tree-certs-07>.

[IETF124-PLANTS]

Benjamin, D., "PLANTS BoF: Solution Space and Dispatched Work", 4 November 2025, <https://datatracker.ietf.org/meeting/124/materials/slides-124-plants-solution-space-and-dispatched-work-00.pdf>.

[IETF126-PQ-AUTH]

Benjamin, D., "Post-Quantum Authentication: Beating the S-Curve", 24 July 2026, <https://datatracker.ietf.org/meeting/126/materials/slides-126-saag-post-quantum-authentication-beating-the-s-curve-00>.

[PQ-AUTH-ROADMAP]

Benjamin, D. and J. DeBlasio, "Post-Quantum HTTPS Authentication Roadmap", 27 February 2026, <https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/>.

[RFC3739]

Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 Public Key Infrastructure: Qualified Certificates Profile", RFC 3739, DOI 10.17487/RFC3739, March 2004, <https://www.rfc-editor.org/rfc/rfc3739>.

[RFC4158]

Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. Nicholas, "Internet X.509 Public Key Infrastructure: Certification Path Building", RFC 4158, DOI 10.17487/RFC4158, September 2005, <https://www.rfc-editor.org/rfc/rfc4158>.

[RFC5929]

Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, <https://www.rfc-editor.org/rfc/rfc5929>.

[RFC7299]

Housley, R., "Object Identifier Registry for the PKIX Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, <https://www.rfc-editor.org/rfc/rfc7299>.

[RFC9618]

Benjamin, D., "Updates to X.509 Policy Validation", RFC 9618, DOI 10.17487/RFC9618, August 2024, <https://www.rfc-editor.org/rfc/rfc9618>.