A Mechanism for X.509 Certificate Discovery
draft-lamps-okubo-certdiscovery-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tomofumi Okubo , Corey Bonnell , John Gray | ||
| Last updated | 2024-04-23 | ||
| 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-01
Network Working Group T. Okubo
Internet-Draft C. Bonnell
Intended status: Standards Track DigiCert, Inc.
Expires: 25 October 2024 J. Gray
Entrust
23 April 2024
A Mechanism for X.509 Certificate Discovery
draft-lamps-okubo-certdiscovery-01
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 25 October 2024 [Page 1]
Internet-Draft TODO - Abbreviation April 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 25 October 2024.
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 25 October 2024 [Page 2]
Internet-Draft TODO - Abbreviation April 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 plays 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 25 October 2024 [Page 3]
Internet-Draft TODO - Abbreviation April 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 algortihm 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 algrithm 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 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 25 October 2024 [Page 4]
Internet-Draft TODO - Abbreviation April 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 25 October 2024 [Page 5]
Internet-Draft TODO - Abbreviation April 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
relatedCertificateLocation which is a GeneralName that has the
pointer to the Secondary Certificate. The
relatedCertificateSignatureAlgorithm which indicates the signature
algorithm used in the Secondary Certificate. Finally, the
relatedCertificatePublicKeyAlgorithm 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
relatedCertificateSignatureAlgorithm and
relatedCertificatePublicKeyAlgorithm to determine whether the
Secondary Certificate has the signature algorithm and certificate
public key algorthm it can process. If the software understands the
signature algorithm and certificate public key algorthm, the software
fetches the certificate from the URI specified in the
relatedCertificateLocation and attempt 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 25 October 2024 [Page 6]
Internet-Draft TODO - Abbreviation April 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 {
relatedCertificateLocation GeneralName,
relatedCertificateSignatureAlgorithm [0] IMPLICIT AlgorithmIdentifier OPTIONAL,
relatedCertificatePublicKeyAlgorithm [1] IMPLICIT AlgorithmIdentifier OPTIONAL
}
The semantics of other id-ad-certDiscovery accessLocation name forms
are not defined.
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 certificate, 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 it allows in one validation.
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.
Okubo, et al. Expires 25 October 2024 [Page 7]
Internet-Draft TODO - Abbreviation April 2024
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 25 October 2024 [Page 8]
Internet-Draft TODO - Abbreviation April 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 {
relatedCertificateLocation GeneralName,
relatedCertificateSignatureAlgorithm [0] IMPLICIT AlgorithmIdentifier OPTIONAL,
relatedCertificatePublicKeyAlgorithm [1] IMPLICIT AlgorithmIdentifier OPTIONAL
}
END
Authors' Addresses
Tomofumi Okubo
DigiCert, Inc.
Okubo, et al. Expires 25 October 2024 [Page 9]
Internet-Draft TODO - Abbreviation April 2024
Email: tomofumi.okubo+ietf@gmail.com
Corey Bonnell
DigiCert, Inc.
Email: corey.bonnell@digicert.com
John Gray
Entrust
Email: john.gray@entrust.com
Okubo, et al. Expires 25 October 2024 [Page 10]