Related Certificates for Use in Multiple Authentications within a Protocol
Extracted elements (26)
The mechanism is designed specifically to support non-composite hybrid authentication, enabling an entity to use two separate certificates (e.g., one traditional, one post-quantum) that can be presented together or independently in protocols like TLS and IKEv2, without requiring a composite certificate format. This minimizes changes to the certificate format and existing PKI best practices.
The RelatedCertificate extension stores a hash of the related certificate rather than its full content or IssuerAndSerialNumber, because hashing the entire certificate provides a tamper-evident binding that also commits to all fields (public key, subject, validity) of the related certificate, ensuring a stronger linkage.
The signature field in RequesterCertificate signs the concatenation of DER-encoded IssuerAndSerialNumber and BinaryTime rather than the full certificate to provide proof-of-possession (POP) with freshness. The BinaryTime field ensures the signed data cannot be replayed, binding the assertion to the specific CSR request time.
A CA organization may not be configured to validate certificates issued by a different CA organization. Cross-CA use of relatedCertRequest may require pre-arrangement (e.g., contractual agreements and pre-configured trust anchors from the other CA organization) before the CA can process the attribute.
The RA MAY send the CA a CSR containing a relatedCertRequest attribute that includes the IssuerAndSerialNumber of a certificate issued by a different CA. This cross-CA scenario requires the data URL option in locationInfo (containing inline degenerate PKCS#7 with all validation material) so the receiving CA can validate without external lookups.
A CA issuing a certificate with the RelatedCertificate extension MUST only include a certificate that was listed in the relatedCertRequest attribute of the CSR, and MUST ensure that the related certificate contains the key usage (KU) bits and extended key usage (EKU) OIDs being asserted in the new certificate.
After validation, the CA SHOULD issue the new certificate containing the RelatedCertificate extension referencing the IssuerAndSerialNumber from the relatedCertRequest attribute. The CA may also apply local policy (e.g., remaining validity period of the related certificate).
If a CA receives a CSR including the relatedCertRequest attribute and supports it, the CA MUST retrieve the certificate identified via the UniformResourceIdentifier, validate it per RFC 5280 path validation rules, and compare the IssuerAndSerialNumber extracted from the retrieved certificate against the certID field in the attribute.
The CA MUST check that the BinaryTime in the requestTime field of the relatedCertRequest attribute is sufficiently fresh; the definition of 'sufficient freshness' is a matter of local policy and outside the scope of this document.
The CA MUST verify the signature field of the relatedCertRequest attribute using the public key from the certificate identified by the attribute. This confirms that the CSR requester also controls the private key of the related certificate.
The RA MUST only allow a previously issued certificate (not a certificate being concurrently requested) to be indicated in the relatedCertRequest attribute, so that the CA can perform the required signature verification.
The RelatedCertificate extension MUST only be included in the end-entity certificate, not in CA or intermediate certificates in a certificate chain.
The RelatedCertificate extension SHOULD NOT be marked critical; marking it critical would severely impact interoperability because implementations that do not recognize the extension would reject the certificate.
When the request for new Cert B goes to the same CA organization that issued existing Cert A, the UniformResourceIdentifier in locationInfo SHOULD be an HTTP(S) URL to a CMS 'certs-only' message (DER-encoded). When the request goes to a different CA organization, the URI SHOULD be a data URL containing inline degenerate PKCS#7 with all certificates and CRLs needed to validate Cert A.
Endpoint protocol multiple authentication processing: when non-composite hybrid authentication is in use, an endpoint that receives Cert A and Cert B should check Cert B for the RelatedCertificate extension, compute the appropriate hash of Cert A, and confirm the hash matches the hashValue in the extension. Policy on how to proceed (e.g., require both or one authentication to succeed) is outside the scope of this document.
The RelatedCertificate X.509 certificate extension (id-pe-relatedCert, OID 1.3.6.1.5.5.7.1.36) is an ASN.1 SEQUENCE containing hashAlgorithm (DigestAlgorithmIdentifier) and hashValue (OCTET STRING), where hashValue is the digest of the entire related end-entity certificate. It creates an association between two certificates owned by the same end entity.
The relatedCertRequest CSR attribute (id-aa-relatedCertRequest, OID arc id-aa 60) allows an RA to attest that the owner of the public key in a CSR also owns the public key in a previously issued end-entity certificate. It is of type RequesterCertificate and is identified by id-aa-relatedCertRequest.
IANA has registered OID decimal 115 (id-mod-related-cert-2023) in the 'SMI Security for PKIX Module Identifier' registry (1.3.6.1.5.5.7.0) for the ASN.1 module defined in Appendix A of this document.
IANA has registered OID decimal 36 (id-pe-relatedCert) in the 'SMI Security for PKIX Certificate Extension' registry (1.3.6.1.5.5.7.1) for the RelatedCertificate X.509 certificate extension defined in this document. Registration procedure: Specification Required.
IANA has registered OID decimal 60 (id-aa-relatedCertRequest) in the 'SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2)' registry for the relatedCertRequest CSR attribute defined in this document.
All hybrid authentication implementations are vulnerable to a downgrade attack in which a malicious peer does not express support for the stronger algorithm, resulting in an exchange that can only rely upon a weaker algorithm for security. Protocol designers using this mechanism must account for this risk.
CAs should be aware that retrieval of existing certificates via the provided URI may be subject to observation (traffic analysis). If this is a concern, the data URL option (inline PKCS#7) described in Section 3.1 should be used instead of an HTTP(S) URL to avoid leaking information about the related certificate.
Implementors must be aware of risks from retrieving a related certificate via the UniformResourceIdentifier in relatedCertRequest, as a URL can point to malicious content. Implementations must ensure the retrieved data is properly formed and fully validated before use.
The RelatedCertificate extension and relatedCertRequest attribute provide only a means to express that multiple certificates are related; they do not by themselves effect any security function. The mechanisms are intended for interpretation by the recipient (verifier or CA) and must be used within a broader authentication and authorization framework.
RelatedCertificate ::= SEQUENCE { hashAlgorithm DigestAlgorithmIdentifier, hashValue OCTET STRING }. The hashAlgorithm field identifies the algorithm used to compute hashValue, which is the hash of the entire related certificate (DER-encoded). If the related certificate's signature OID explicitly indicates a hash algorithm (e.g., ecdsa-with-SHA512), that same algorithm SHOULD be used.
RequesterCertificate is an ASN.1 SEQUENCE with four fields: certID (IssuerAndSerialNumber identifying the previously issued certificate), requestTime (BinaryTime for freshness), locationInfo (UniformResourceIdentifier pointing to the existing certificate via HTTP(S) or data URL), and signature (BIT STRING over DER-encoded IssuerAndSerialNumber concatenated with BinaryTime, signed by the private key of the identified certificate).