Skip to main content

A Mechanism for X.509 Certificate Discovery
draft-lamps-okubo-certdiscovery-05

Document Type Active Internet-Draft (individual)
Authors Tomofumi Okubo , Corey Bonnell , John Gray , Mike Ounsworth , Joe Mandel
Last updated 2024-11-04
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-lamps-okubo-certdiscovery-05
Network Working Group                                           T. Okubo
Internet-Draft                              Penguin Securities Pte. Ltd.
Intended status: Standards Track                              C. Bonnell
Expires: 8 May 2025                                       DigiCert, Inc.
                                                                 J. Gray
                                                            M. Ounsworth
                                                                 Entrust
                                                               J. Mandel
                                                            AKAYLA, Inc.
                                                         4 November 2024

              A Mechanism for X.509 Certificate Discovery
                   draft-lamps-okubo-certdiscovery-05

Abstract

   This document specifies a method to discover a secondary X.509
   certificate associated with an X.509 certificate to enable efficient
   multi-certificate handling in protocols.  The objective is threefold:
   to enhance cryptographic agility, improve operational availability,
   and accommodate multi-key/certificate usage.  The proposed method
   aims to maximize compatibility with existing systems and is designed
   to be legacy-friendly, making it suitable for environments with a mix
   of legacy and new implementations.  It includes mechanisms to provide
   information about the target certificate's signature algorithm,
   public key algorithm and the location of the secondary X.509
   certificate, empowering relying parties to make informed decisions on
   whether or not to fetch the secondary certificate.

   The primary motivation for this method is to address the limitations
   of traditional certificate management approaches, which often lack
   flexibility, scalability, and seamless update capabilities.  By
   leveraging this mechanism, subscribers can achieve cryptographic
   agility by facilitating the transition between different algorithms
   or X.509 certificate types.  Operational redundancy is enhanced by
   enabling the use of backup certificates and minimizing the impact of
   primary certificate expiration or CA infrastructure failures.

   The approach ensures backward compatibility with existing systems and
   leverages established mechanisms, such as the subjectInfoAccess
   extension, to enable seamless integration.  It does not focus on
   identity assurance between the primary and secondary certificates,
   deferring such considerations to complementary mechanisms.

About This Document

   This note is to be removed before publishing as an RFC.

Okubo, et al.              Expires 8 May 2025                   [Page 1]
Internet-Draft             TODO - Abbreviation             November 2024

   The latest revision of this draft can be found at
   https://tomofumiokubo.github.io/certificatediscovery/draft-lamps-
   okubo-certdiscovery.html.  Status information for this document may
   be found at https://datatracker.ietf.org/doc/draft-lamps-okubo-
   certdiscovery/.

   Source for this draft and an issue tracker can be found at
   https://github.com/tomofumiokubo/certificatediscovery.

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 8 May 2025.

Copyright Notice

   Copyright (c) 2024 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Use Case 1: Cryptographic Agility . . . . . . . . . . . .   4
     1.2.  Use Case 2: Operational Redundancy  . . . . . . . . . . .   4
     1.3.  Use Case 3: Dual Use  . . . . . . . . . . . . . . . . . .   5
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   5

Okubo, et al.              Expires 8 May 2025                   [Page 2]
Internet-Draft             TODO - Abbreviation             November 2024

   3.  Certificate Discovery Access Method Certificates  . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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

Okubo, et al.              Expires 8 May 2025                   [Page 3]
Internet-Draft             TODO - Abbreviation             November 2024

   It's important to note that this specification does not aim to solve
   or assure the identity (subject) binding between the primary and
   secondary certificates.  Instead, it focuses on providing a mechanism
   for efficient certificate discovery, while identity assurance can be
   addressed through complementary mechanisms such as draft-becker-
   guthrie-cert-binding-for-multi-auth-02.

   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.

1.1.  Use Case 1: Cryptographic Agility

   The first use case is improving cryptographic agility.  For example,
   the Primary Certificate uses a widely adopted cryptographic algorithm
   while the Secondary Certificate uses the algorithm that is new and
   not widely adopted yet.  The relying party will be presented with the
   opportunity to try the new algorithms and certificate types.  This
   will be particularly useful when transitioning from one algorithm to
   another or to a new certificate/credential type.

   In addition, the server may look at the logs to determine how ready
   the client side is to shift to completely rollover to the new
   algorithm.  This allows the subscriber to gather the metrics
   necessary to make an informed decision on the best timing to do an
   algorithm rollover without relying on third parties or security
   researchers.  This is particularly useful for PKIs that have a wide
   array of client software and requires careful considerations.
   #fintech #IoT

1.2.  Use Case 2: Operational Redundancy

   The second use case is where the Primary and Secondary Certificate
   adopts the same cryptographic algorithms but for instance, uses
   certificates issued by two different CAs or two certificates that has
   different validity periods.  The Secondary Certificate may be used as
   a backup certificate in case the Primary Certificate validity is
   about to expire.

Okubo, et al.              Expires 8 May 2025                   [Page 4]
Internet-Draft             TODO - Abbreviation             November 2024

   A common issue is when the intermediate CA certificate expires and
   the subscriber forgets to update the intermediate CA configured on
   the server.  Similar to when some software collects the parent
   certificate through authorityInfoAccess CA Issuer access method when
   the intermediate certificate is absent, the peer certificate can be
   obtained.

   Due to increased adoption of the ACME protocol, the burden of
   maintaining the availability of a service is shifted to the CA
   issuance infrastructure and the availability would be dependent on
   the CA infrastructure.  To increase the operational redundancy, this
   mechanism can be used to point to another set of certificates that
   are independent from the Primary Certificate to minimize the chance
   of a failed transaction.

1.3.  Use Case 3: Dual Use

   The third use case is where one certificate is used by the named
   subject for a particular cryptographic operation and a relying party
   wishes to obtain the public key of the named subject for a different
   cryptographic operation.  For example, the recipient of an email
   message which was signed using a key that is certified by a single-
   use signing S/MIME certificate may wish to send an encrypted email to
   the sender.  In this case, the recipient will need the sender's
   public key used for encryption.  A pointer to the named subject's
   encryption certificate will permit the recipient to send an encrypted
   reply.

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.

2.1.  Definitions

   For conciseness, this section defines several terms that are
   frequently used throughout this specification.

   Primary Certificate: The X.509 certificate that has the
   subjectInfoAccess extension with the certDiscovery accessMethod
   pointing to a Secondary Certificate.

   Secondary Certificate: The X.509 certificate that is referenced by
   the Primary Certificate in the subjectInfoAccess extension
   certDiscovery accessMethod

Okubo, et al.              Expires 8 May 2025                   [Page 5]
Internet-Draft             TODO - Abbreviation             November 2024

3.  Certificate Discovery Access Method Certificates

   This document specifies the new certDiscovery access method for X.509
   Subject Information Access (SIA) extension defined in [RFC5280].  The
   certDiscovery access method has 3 components.  The
   uniformResourceIdentifier which is an IA5String that has the URL
   reference to the Secondary Certificate.  The signatureAlgorithm which
   indicates the signature algorithm used in the Secondary Certificate.
   Finally, the publicKeyAlgorithm which indicates the public key
   algorithm used in the Secondary Certificate.

   When the validation of the Primary Certificate fails, the software
   that understands the SIA extension and the certDiscovery access
   method uses the information to determine whether or not to fetch the
   Secondary Certificate.  The software will look at the
   signatureAlgorithm and publicKeyAlgorithm to determine whether the
   Secondary Certificate has the signature algorithm and certificate
   public key algorithm it can process.  If the software understands the
   signature algorithm and certificate public key algorithm, the
   software fetches the certificate from the URI specified in the
   relatedCertificateLocation and attempts another validation.
   Otherwise, the validation simply fails.

   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  }

   The syntax of the related certificate descriptor is as follows:

Okubo, et al.              Expires 8 May 2025                   [Page 6]
Internet-Draft             TODO - Abbreviation             November 2024

   id-ad  OBJECT IDENTIFIER  ::= {
     iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) ad(48) }
    id-ad-certDiscovery OBJECT IDENTIFIER ::= { id-ad TBD }

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

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

   RelatedCertificateDescriptor ::= SEQUENCE {
           uniformResourceIdentifier IA5String,
           signatureAlgorithm   [0] IMPLICIT AlgorithmIdentifier OPTIONAL,
           publicKeyAlgorithm   [1] IMPLICIT AlgorithmIdentifier OPTIONAL
   }

   The semantics of other id-ad-certDiscovery accessLocation name forms
   are not defined.

   Note: For a description of uniformResourceIdentifier consult section
   4.2.2.1 of [!RFC5280].

4.  Security Considerations

   This mechanism does not assure the binding of the identity of the
   subject in the Primary Certificate and the Secondary Certificate.  To
   assure the binding of identities of the two certificates, a
   confirming CA should adopt a separate mechanism such as draft-becker-
   guthrie-cert-binding-for-multi-auth-02 for to explicitly express the
   binding of identities.

   There is a chance 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.

Okubo, et al.              Expires 8 May 2025                   [Page 7]
Internet-Draft             TODO - Abbreviation             November 2024

   The same security considerations for CAIssuer 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

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

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

Okubo, et al.              Expires 8 May 2025                   [Page 8]
Internet-Draft             TODO - Abbreviation             November 2024

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) } ;

   -- Access descriptor OID --

   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 TBD2 }

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

   RelatedCertificateDescriptor ::= SEQUENCE {
           uniformResourceIdentifier IA5String,
           signatureAlgorithm   [0] IMPLICIT AlgorithmIdentifier OPTIONAL,
           publicKeyAlgorithm   [1] IMPLICIT AlgorithmIdentifier OPTIONAL
   }

   END

Authors' Addresses

   Tomofumi Okubo
   Penguin Securities Pte. Ltd.

Okubo, et al.              Expires 8 May 2025                   [Page 9]
Internet-Draft             TODO - Abbreviation             November 2024

   Email: tomofumi.okubo+ietf@gmail.com

   Corey Bonnell
   DigiCert, Inc.
   Email: corey.bonnell@digicert.com

   John Gray
   Entrust
   Email: john.gray@entrust.com

   Mike Ounsworth
   Entrust
   Email: mike.ounsworth@entrust.com

   Joe Mandel
   AKAYLA, Inc.
   Email: joe@akayla.com

Okubo, et al.              Expires 8 May 2025                  [Page 10]