A Mechanism for X.509 Certificate Discovery
draft-lamps-okubo-certdiscovery-05
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
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]