Summary

  • RFC 9763 lets a requester prove control of an existing certificate’s private key while requesting a new certificate; the issuing CA can then place a hash of the entire existing certificate in the new certificate.
  • That relationship is an issuance assertion, not a live authentication result. The RFC neither requires the two certificates to be used together nor decides whether a verifier should require one successful authentication or both.
  • A defensible migration record must therefore keep registration proof, CA policy, exact certificate bytes, current private-key actions, path validation, negotiation and the endpoint’s final decision as separate evidence.

At a migration desk, an operator presents an existing credential and asks for a second one using a different cryptographic algorithm. The desk verifies a signature made by the old key. The new request has its own signature. The authority then issues a certificate containing a digest of the old certificate. On paper, the pair is now related.

Later, a connection arrives carrying those certificates. One hash comparison succeeds. Nothing in that success shows that both private keys signed the current exchange. Nothing says the verifier trusts both certification paths. Nothing says the stronger algorithm survived negotiation. Nothing says the application should continue.

That distance between the registration desk and the live endpoint is the real subject of RFC 9763. Its title, Related Certificates for Use in Multiple Authentications within a Protocol, can sound like a complete hybrid-authentication system. The standard is more restrained. It defines a CSR attribute named relatedCertRequest and an X.509 extension named RelatedCertificate. Together they provide additional assurance that two end-entity certificates belong to the same end entity. They do not themselves perform a security function.

Two proofs arrive at different doors

Call the existing credential Cert A and the requested credential Cert B. A transition from traditional cryptography to post-quantum cryptography is the motivating case, though the mechanism is not limited to one algorithm pair.

The ordinary request for Cert B carries its new public key. In the PKCS#10 model defined by RFC 2986, the subject signs the request information, binding the subject name, public key and attributes and demonstrating possession of the corresponding private key. RFC 9763 adds a second, deliberately different act. Its relatedCertRequest attribute identifies Cert A by issuer and serial number, records a request time, tells the authority where Cert A can be obtained and contains a signature made with Cert A’s private key.

The signed value is not a vague statement such as “these credentials are ours.” It is the concatenation of the DER-encoded issuer-and-serial identifier and the BinaryTime value. RFC 6019 defines that time as an integer count of seconds after the start of 1 January 1970 UTC, excluding leap seconds. The field supports freshness, but the acceptable freshness window is not universal. RFC 9763 leaves it to local CA policy.

That detail matters. The format is common; the risk decision is local. Two authorities can parse the same signed bytes and adopt different maximum ages without contradicting the certificate relationship syntax. Auditors should therefore capture both the time and the policy version used to judge it. A later reader cannot reconstruct “sufficiently fresh” from the integer alone.

The CA’s work is a sequence, not a badge

A CA that supports the attribute has work to do before it can issue Cert B with the relationship extension. It must retrieve or receive the certificate identified by the location field and validate its certification path using RFC 5280. It must compare the retrieved certificate’s issuer and serial number with certID. It must decide that the request time is fresh enough. It must verify the attribute signature with the public key in Cert A.

Each verb produces a different result. Retrieval says which bytes arrived. Path validation says those bytes reached a locally accepted trust anchor under stated inputs. Identifier comparison says the certificate found is the one named. Freshness applies a policy to a time. Signature verification says Cert A’s private key produced the proof bound to that request value. Compressing the sequence into “related certificate verified” destroys the ability to diagnose the failure that matters.

RFC 5280 reinforces the distinction. Path validation accepts trust-anchor information, policy inputs and application constraints. Its algorithm defines minimum conditions for a valid path, while an application can impose narrower requirements. A certificate path that validates in one administrative environment is not automatically acceptable in another.

The CA may then issue Cert B with a RelatedCertificate extension. For the extension to be meaningful, it must reference only the certificate named by the request. Cert A must contain the key-usage bits and extended-key-usage OIDs asserted in Cert B. The CA should determine that Cert A is valid at issuance. Yet the usable overlap between Cert A’s lifetime and Cert B’s lifetime is expressly left to the subscriber.

The last point prevents another false promotion. “Valid when B was issued” is not “available and acceptable throughout B’s life.” Renewal schedules can diverge. Revocation can end one path. A transition team can accidentally deploy the new certificate after the old one has expired. The relationship remains a historical issuance fact even when the operational pair has ceased to be usable.

The hash names one certificate, not one identity

The extension in Cert B contains a digest algorithm identifier and a hash value calculated over the entire Cert A. It does not merely hash Cert A’s public key. It does not point to every certificate with the same subject name. It does not create a durable abstract identity independent of issuance.

That precision has an operational advantage. When a verifier receives Cert A and Cert B, it can calculate the specified digest over the exact Cert A bytes and compare the result with Cert B’s extension. A match is deterministic and local. No online authority needs to answer which old certificate the new one meant.

The precision also carries lifecycle consequences. A reissued Cert A with the same public key and subject but a different serial number, validity interval or extension set will have different bytes and therefore a different digest. It is not the related certificate named by Cert B. Teams that inventory relationships only by subject or key identifier can report a pair that the wire artifact does not actually bind.

The extension should not be critical because critical marking would severely damage interoperability with implementations that do not understand it. It belongs only in end-entity certificates, not CA certificates in a chain. These design choices let the association coexist with older software, but coexistence is not adoption. An endpoint that ignores a non-critical extension has not performed the relationship check.

A match still leaves the endpoint in charge

RFC 9763 describes the live check narrowly. If a protocol endpoint supports non-composite hybrid authentication and receives the appropriate authentication material, it should look for the extension. If Cert B names Cert A, the endpoint computes the required hash of the received Cert A and confirms that it matches.

Then the RFC stops. How the endpoint proceeds is outside scope. One peer may require both authentications to succeed. Another may accept at least one. A protocol in which the signer chooses what to send, such as CMS or S/MIME, has a different control surface from a protocol in which peers negotiate authentication, such as TLS or IKEv2. RFC 5652 supplies Cryptographic Message Syntax and its certificate structures; RFC 8551 supplies the S/MIME certificate packaging referenced by RFC 9763. Neither turns a certificate relationship into an application authorization decision.

The standard states the limit twice in unusually useful language. The CA assurance is neither a requirement nor a mandate that either certificate be used with the other. And the relationship mechanisms do not by themselves effect any security function.

This is not a gap that an executive should ask an engineer to “fix” with a generic allow rule. It is the allocation of authority. The CA can speak about what it checked at registration and what it asserted at issuance. The live verifier bears the consequences of accepting the peer. It must decide which trust anchors, algorithms, identities, key usages and authentication combinations satisfy its current risk.

Registration control is not time-of-use control

The strongest sentence in RFC 9763’s security considerations separates two clocks. A hybrid system needs evidence that the same entity controls all relevant private keys at registration time, to the CA, and at time of use, to the verifier.

The relatedCertRequest signature answers a registration question about Cert A. The ordinary request signature answers the issuance process’s question about the new key. The resulting extension preserves the CA’s association between exact certificates. But a session hours or years later needs current acts by the credentials the protocol actually requires.

If only the traditional key signs the live transcript, the presence of a related post-quantum certificate does not make the post-quantum key a participant. If both signatures arrive but only one is validated, the unchecked half is not assurance. If both cryptographic checks pass but one certification path terminates at a trust anchor the verifier does not accept, the relationship hash cannot repair that trust decision. If negotiation was downgraded before the stronger method was offered, the extension cannot recover the missing offer.

This is also why RFC 9763 must not be confused with RFC 9883. RFC 9883 permits an already-certified signing key to carry a policy-accepted statement about possession of a distinct key-establishment private key without technically proving possession of that second key. RFC 9763 uses a real signature by Cert A’s private key and, in the ordinary request model, a separate request signature for Cert B, then records the relationship. One article is about an acknowledged substitution of statement for proof; this one is about keeping proved registration association separate from future protocol use.

Nor is the extension a hybrid-signature combiner. RFC 9955 discusses properties such schemes may seek, including hybrid authentication and forms of compatibility. RFC 9763 does not choose a universal verification rule. It gives protocols and endpoints an exact relationship signal they may use when applying their own rule.

Cross-CA trust is an arrangement, not a hash result

The easy deployment is one CA organization that can already retrieve and validate Cert A while issuing Cert B. The harder deployment crosses CA organizations. A public-facing CA may not be configured to validate certificates from another organization. RFC 9763 says recognition may require pre-arrangement: contracts, configured trust anchors, and agreements about certificate application, issuance and acceptance.

That list is the institutional surface hiding behind a compact extension. Cert A may have been issued under a different certification policy, subscriber agreement, identity-proofing process, hardware requirement or incident practice. The issuing organization for Cert B should determine which of its policies will make the new key’s protection comparable to Cert A’s. The relationship attribute and extension are solely intended to assure control by the same end entity; they do not declare two policy regimes equivalent.

RFC 5280 makes the same structural point from the relying side. Trust anchors are explicit inputs. Certificate policies can restrict acceptable paths. Key usage and extended key usage are processed independently, and the certificate may be used only for a purpose consistent with both. A digest match cannot enlarge those purposes.

This is where audit language must remain exact. “Same entity” does not mean “same assurance level.” “Valid path” does not mean “accepted for this application.” “Comparable policy” is a CA organization’s accountable determination, not a mathematical property emitted by the extension.

Retrieval creates its own evidence and exposure

The request tells the CA where to obtain Cert A. When the same organization issued both certificates, RFC 9763 recommends an HTTP or HTTPS location carrying a CMS certificate-only message. When different CA organizations are involved, it recommends a data: URL containing the certificates and revocation material needed to validate Cert A. RFC 2397 defines the data-URL scheme; CMS supplies the carrier.

The URI is not a grant of trust. A URL can lead to malicious content. The implementation must check that the material is well formed and validate it fully. Network retrieval can also be observed, revealing that one authority is processing a relationship with a particular existing certificate. Inline carriage can reduce that observation channel, though it increases request size and does not remove the need for validation.

An operational record should therefore preserve the retrieval mode, URL class, retrieved object hash, parser result, path and revocation inputs, trust-anchor set and network outcome. Recording only the final Cert B serial number makes it impossible to show which Cert A bytes the CA actually evaluated.

Downgrade remains outside the certificate

All hybrid implementations face a downgrade risk when a malicious peer withholds support for the stronger algorithm, leaving an exchange that depends only on the weaker one. The RelatedCertificate extension cannot prove that a capability was offered, carried intact or selected. It is present only after a certificate has arrived for processing.

The required evidence sits elsewhere: authenticated negotiation transcripts where the protocol provides them, configured minimum algorithms, telemetry for selected authentication modes, failure reasons, and alerts when a peer that previously used both methods returns to one. A certificate inventory can show readiness. Only traffic evidence can show use.

This follows the doctrine in Heng Lu’s Running-Code Primacy and Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption. The common layer should state the deterministic facts required for interoperability and proof of control. The future decision belongs to participants running code. Publication, registration and recommendation do not create deployment.

The relationship extension is a good common artifact precisely because it is narrow. It tells a verifier which exact certificate to compare and how. It does not appoint the CA to decide every future connection. The endpoint can adopt the mechanism, require both authentications, retain an older compatibility mode, or reject the pair under local policy.

Heng Lu’s reality-layer analysis adds the final discipline. A registration proof, an issuance assertion, a hash match, a live signature, a path decision, an authorization decision and an observed service effect are not interchangeable descriptions of one green state. They occupy different layers and are produced by different actors.

The evidence chain leadership should demand

A mature deployment should be able to reconstruct the transition without asking one database field to tell the whole story. At registration, retain the exact CSR, Cert A identifier, request time, location information, signed bytes, signature result and Cert A retrieval and validation evidence. At issuance, retain the Cert A bytes and digest, Cert B bytes, policy mapping, key-usage comparison and validity-overlap calculation.

At use, retain the certificates actually received, both path results, the relationship-digest calculation, the authentication operations that actually occurred, the negotiated mode and downgrade protections, local policy version, endpoint decision and resulting connection state. Each record should carry its producer and time.

The objective is not maximal logging without purpose. It is minimum sufficient separation. If an incident occurs, the organization must know whether the failure was false registration, wrong-certificate retrieval, stale policy, broken hash comparison, missing live proof, unacceptable trust path, downgrade, or a deliberate local refusal. “Hybrid authentication failed” is not an actionable cause.

Sources