A Mechanism for X.509 Certificate Discovery

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 January 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The efficient discovery of X.509 certificates play a critical role in modern cryptographic systems. Traditional certificate management approaches often face challenges in terms of flexibility, scalability, and seamless updates. To address these limitations, this document proposes a novel approach to certificate discovery utilizing the Subject Information Access extension within X.509 certificates.¶

The primary objective of this approach is to enable efficient multi-certificate handling in protocols, offering several key benefits. First, it enhances cryptographic agility by facilitating smooth transitions between different algorithms or X.509 certificate types. This is particularly valuable in scenarios where subscribers need to upgrade their cryptographic algorithms or adopt new certificate types while maintaining backward compatibility with existing systems.¶

Second, the proposed method improves operational availability by introducing redundancy in certificate usage. It enables the use of secondary certificates that can serve as backups, ensuring seamless continuity of services even in the event of Primary Certificate expiration or disruptions in the CA infrastructure.¶

Finally, the approach accommodates multi-key/certificate usage, allowing for a relying party to obtain certificates to perform cryptographic operations that are not certified by a single certificate.¶

The proposed method is designed to maximize compatibility with existing systems, including legacy implementations. It leverages the subjectInfoAccess extension, which is already established in X.509 certificates, and does not require modifications to the referring certificates. This ensures ease of adoption and avoids disruptions to current certificate management practices.¶

In the following sections, we will outline the details of the proposed approach, including the structure of the SIA extension, the modes of operation, and the considerations for secure implementation and deployment.¶

By leveraging the capabilities of the SIA extension for certificate discovery, organizations can enhance cryptographic agility, improve operational availability, and accommodate complex multi-key/certificate scenarios, leading to more secure and resilient cryptographic systems.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Certificate Discovery Access Method

This document specifies the new certDiscovery access method for X.509 Subject Information Access (SIA) extension defined in [RFC5280].¶

The syntax of subject information access extension syntax is repeated here for convenience:¶

   SubjectInfoAccessSyntax  ::=
           SEQUENCE SIZE (1..MAX) OF AccessDescription

   AccessDescription  ::=  SEQUENCE {
           accessMethod          OBJECT IDENTIFIER,
           accessLocation        GeneralName  }

This document defines a new access method id-ad-certDiscovery which is an OBJECT IDENTIFIER that indicates the accessMethod is for certificate discovery.¶

id-ad-certDiscovery OBJECT IDENTIFIER ::= { id-ad TBD }

The 'accessLocation' is a GeneralName otherName type as defined in [RFC5280]. Recall that the otherName type is defined as AnotherName:¶

AnotherName ::= SEQUENCE {
     type-id    OBJECT IDENTIFIER,
     value      [0] EXPLICIT ANY DEFINED BY type-id }

Which this document defines as:¶

-- Other Name OID Arc --
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }

-- Certificate Discovery Access Descriptor --
id-on-relatedCertificateDescriptor OBJECT IDENTIFIER ::= { id-on TBD }

on-RelatedCertificateDescriptor OTHER-NAME ::= {
      RelatedCertificateDescriptor IDENTIFIED BY id-on-relatedCertificateDescriptor
   }

Where id-on-relatedCertificateDescriptor is the OBJECT IDENTIFIER (type-id) and the value is RelatedCertificateDescriptor¶

RelatedCertificateDescriptor is defined as follows:¶

 RelatedCertificateDescriptor ::= SEQUENCE {
      certref CertReference,
      purpose DiscoveryPurposeId,
      signatureAlgorithm [0] IMPLICIT AlgorithmIdentifier OPTIONAL,
      publicKeyAlgorithm [1] IMPLICIT AlgorithmIdentifier OPTIONAL }

RelatedCertificateDescriptor is composed of 4 components which are defined below.¶

CertLocation ::= IA5String

 CertReference ::= CHOICE {
      direct Certificate,
      indirect [0] IMPLICIT CertIndirectReference
   }

CertIndirectReference ::= SEQUENCE {
         location CertLocation,
         certHash [0] IMPLICIT CertHash OPTIONAL
      }

CertHash ::= SEQUENCE {
   value OCTET STRING,
   -- TODO Add IssuerAndSerialNumber?
   hashAlgorithm AlgorithmIdentifier DEFAULT {algorithm sha-256}
}

 -- Purpose OJBECT IDENTIFIER
id-rcd-alg-agility OBJECT IDENTIFIER ::=
                               {id-on-relatedCertificateDescriptor 1}

id-rcd-redundancy OBJECT IDENTIFIER ::=
                               {id-on-relatedCertificateDescriptor 2}

id-rcd-dual OBJECT IDENTIFIER ::=
                               {id-on-relatedCertificateDescriptor 3}

id-rcd-priv-key-stmt OBJECT IDENTIFIER ::=
                               {id-on-relatedCertificateDescriptor 4}

id-rcd-self OBJECT IDENTIFIER ::=
                               {id-on-relatedCertificateDescriptor 5}

4. Security Considerations

Retrieval of the Secondary Certificate is not sufficient to consider the Secondary Certificate trustworthy. The certification path validation algorithm as defined in section 6 of [RFC5280] MUST be performed for the Secondary Certificate.¶

The use of the self-reference purpose can be used to provide a subject binding between the Primary and Secondary Certificates. However, the procedure for validating subject equivalance MUST be defined by policy. As a result, validation of subject equivalence is out of scope of this document.¶

The Secondary Certificate may also have the certDiscovery access method. In order to avoid cyclic loops or infinite chaining, the validator should be mindful of how many fetching attempts it allows in one validation.¶

The same security considerations for caIssuers access method outlined in [RFC5280] applies to the certDiscovery access method. In order to avoid recursive certificate validations which involve online revocation checking, untrusted transport protocols (such as plaintext HTTP) are commonly used for serving certificate files. While the use of such protocols avoids issues with recursive certification path validations and associated online revocation checking, it also enables an attacker to tamper with data and perform substitution attacks. Clients fetching certificates using the mechanism specified in this document MUST treat downloaded certificate data as untrusted and perform requisite checks to ensure that the downloaded data is not malicious.¶

5. IANA Considerations

TBD¶

6. Normative References

[I-D.ietf-lamps-private-key-stmt-attr]

Housley, R., "An Attribute for Statement of Possession of a Private Key", Work in Progress, Internet-Draft, draft-ietf-lamps-private-key-stmt-attr-09, 26 June 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-private-key-stmt-attr-09>.

[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>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[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>.

[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>.

Acknowledgments

TODO acknowledge.¶

Appendix A. ASN.1 Module

The following ASN.1 module provides the complete definition of the Certificate Discovery access descriptor.¶

CertDiscovery { iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-CertDiscovery(TBD1) }

   DEFINITIONS EXPLICIT TAGS ::=

   BEGIN

-- EXPORTS ALL --

   IMPORTS
    OTHER-NAME
    FROM PKIX1Implicit-2009
      { iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) }

    id-pkix, id-ad
    FROM PKIX1Explicit-2009
      { iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ;

   id-ad-certDiscovery OBJECT IDENTIFIER ::= { id-ad TBD }

   -- Other Name OID Arc --

   id-on OBJECT IDENTIFIER ::= { id-pkix 8 }

   -- Certificate Discovery Access Descriptor --

   id-on-relatedCertificateDescriptor OBJECT IDENTIFIER ::= { id-on TBD }

   on-RelatedCertificateDescriptor OTHER-NAME ::= {
      RelatedCertificateDescriptor IDENTIFIED BY id-on-relatedCertificateDescriptor
   }

   -- Purpose OJBECT IDENTIFIER
   id-rcd-agility OBJECT IDENTIFIER ::= {id-on-relatedCertificateDescriptor 1}
   id-rcd-redundency OBJECT IDENTIFIER ::= {id-on-relatedCertificateDescriptor 2}
   id-rcd-dual OBJECT IDENTIFIER ::= {id-on-relatedCertificateDescriptor 3}
   id-rcd-priv-key-stmt OBJECT IDENTIFIER ::= {id-on-relatedCertificateDescriptor 4}
   id-rcd-self OBJECT IDENTIFIER ::= {id-on-relatedCertificateDescriptor 5}

   DiscoveryPurposeId ::= OBJECT IDENTIFIER

   RelatedCertificateDescriptor ::= SEQUENCE {
      certref CertReference,
      purpose DiscoveryPurposeId,
      signatureAlgorithm [0] IMPLICIT AlgorithmIdentifier OPTIONAL,
      publicKeyAlgorithm [1] IMPLICIT AlgorithmIdentifier OPTIONAL
   }

    CertReference ::= CHOICE {
      direct Certificate,
      indirect [0] IMPLICIT CertIndirectReference
   }

   CertIndirectReference ::= SEQUENCE {
      uniformResourceIdentifier IA5String,
      certHash [0] IMPLICIT CertHash OPTIONAL
   }

   CertHash ::= SEQUENCE {
      value OCTET STRING,
      -- TODO Add IssuerAndSerialNumber?
      hashAlgorithm AlgorithmIdentifier DEFAULT {algorithm sha-256}
   }

   END

Authors' Addresses