| Internet-Draft | RFC 5280 Clarifications | November 2024 |
| Liu, et al. | Expires 30 May 2025 | [Page] |
The updates to RFC 5280 described in this document provide alignment with the 2013 specification for the X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP [RFC6960], and add support for Certificate Transparency [RFC6962].¶
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 30 May 2025.¶
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.¶
For the relying parties of Web PKI, certificate path construction and certificate validation are necessary security review processes. With regard to the implementation of certificate validation process for Internet browsers, the mainstream Internet browser implementation generally follows "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280] standard formulated in 2008. This version of the standard has a long history is not in line with existing practice, and with the development of technology and new features, such as the invention and standardization of certificate transparency system CT [RFC6962] and online certificate status protocol OCSP [RFC6960], browser manufacturers have not fully followed or enabled them. These new features of check are very helpful for building practical certificate security; In addition, considering the needs of manufacturers, the implementation of Internet browsers inevitably includes various private code implementations, and the certificate validation process in the Internet browser industry is relatively messy and arbitrary. In view of this situation, this document proposes some updates of the latest reference of certificate status information mechanism description for the RFC5280 in line with existing practice, to provide reference for Internet browser manufacturers.¶
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.¶
This section provides updates to several paragraphs of RFC 5280 [RFC5280]. For clarity, if the entire section is not replaced, then the original text and the replacement text are shown.¶
This update provides references for OCSP and CT¶
OLD:¶
* Operational protocols are required to deliver certificates and CRLs (or status information) to certificate-using client systems. Provisions are needed for a variety of different means of certificate and CRL delivery, including distribution procedures based on LDAP, HTTP, FTP, and X.500. Operational protocols supporting these functions are defined in other PKIX specifications. These specifications may include definitions of message formats and procedures for supporting all of the above operational environments, including definitions of or references to appropriate MIME content types.¶
NEW:¶
* Operational protocols are required to deliver certificates and status information (CRLs or OCSP and CT etc.,) to certificate-using client systems. Provisions are needed for a variety of different means of certificate and CRL or OCSP and CT status delivery, including distribution procedures based on LDAP, HTTP, FTP, and X.500. Operational protocols supporting these functions are defined in other PKIX specifications. These specifications may include definitions of message formats and procedures for supporting all of the above operational environments, including definitions of or references to appropriate MIME content types.¶
This update provides references for OCSP and CT¶
OLD:¶
* CRL issuers issue CRLs. The CRL issuer is either the CA or an entity that has been authorized by the CA to issue CRLs. CAs publish CRLs to provide status information about the certificates they issued. However, a CA may delegate this responsibility to another trusted authority.¶
NEW:¶
* CRL issuers issue CRLs. The CRL issuer is either the CA or an entity that has been authorized by the CA to issue CRLs. CAs publish CRLs or OCSP and CT to provide status information about the certificates they issued. However, a CA may delegate this responsibility to another trusted authority.¶
This update provides references for OCSP and CT¶
OLD:¶
* (3) At the current time, the certificate is not revoked. This may be determined by obtaining the appropriate CRL (Section 6.3), by status information, or by out-of-band mechanisms.¶
NEW:¶
* At the current time, the certificate is not revoked. This may be determined by obtaining the appropriate CRL (Section 6.3), or by status information from OCSP, or by out-of-band mechanisms, such as CT.¶
This update provides references for OCSP¶
OLD:¶
* Representation of internationalized names in distinguished names is covered in Sections 4.1.2.4, Issuer Name, and 4.1.2.6, Subject Name. Standard naming attributes, such as common name, employ the DirectoryString type, which supports internationalized names through a variety of language encodings. Conforming implementations MUST support UTF8String and PrintableString. RFC 3280 required only binary comparison of attribute values encoded in UTF8String, however, this specification requires a more comprehensive handling of comparison. Implementations may encounter certificates and CRLs with names encoded using TeletexString, BMPString, or UniversalString, but support for these is OPTIONAL.¶
NEW:¶
* Representation of internationalized names in distinguished names is covered in Sections 4.1.2.4, Issuer Name, and 4.1.2.6, Subject Name. Standard naming attributes, such as common name, employ the DirectoryString type, which supports internationalized names through a variety of language encodings. Conforming implementations MUST support UTF8String and PrintableString. RFC 3280 required only binary comparison of attribute values encoded in UTF8String, however, this specification requires a more comprehensive handling of comparison. Implementations may encounter certificates and CRLs or OCSP with names encoded using TeletexString, BMPString, or UniversalString, but support for these is OPTIONAL.¶
This update provides references for OCSP¶
OLD:¶
* Internationalized Domain Names (IDNs) may be included in certificates and CRLs in the subjectAltName and issuerAltName extensions, name constraints extension, authority information access extension, subject information access extension, CRL distribution points extension, and issuing distribution point extension. Each of these extensions uses the GeneralName type; one choice in GeneralName is the dNSName field, which is defined as type IA5String.¶
NEW:¶
* Internationalized Domain Names (IDNs) may be included in certificates and CRLs and OCSP etc,. in the subjectAltName and issuerAltName extensions, name constraints extension, authority information access extension, subject information access extension, CRL distribution points extension, and issuing distribution point extension, TBSRequest field. Each of these extensions uses the GeneralName type; one choice in GeneralName is the dNSName field, which is defined as type IA5String.¶
This update provides references for OCSP¶
OLD:¶
* Electronic Mail addresses may be included in certificates and CRLs in the subjectAltName and issuerAltName extensions, name constraints extension, authority information access extension, subject information access extension, issuing distribution point extension, or CRL distribution points extension. Each of these extensions uses the GeneralName construct; GeneralName includes the rfc822Name choice, which is defined as type IA5String. To accommodate email addresses with internationalized domain names using the current structure, conforming implementations MUST convert the addresses into an ASCII representation.¶
NEW:¶
* Electronic Mail addresses may be included in certificates and CRLs or OCSP in the subjectAltName and issuerAltName extensions, name constraints extension, authority information access extension, subject information access extension, issuing distribution point extension, or CRL distribution points extension, or TBSRequest field. Each of these extensions uses the GeneralName construct; GeneralName includes the rfc822Name choice, which is defined as type IA5String. To accommodate email addresses with internationalized domain names using the current structure, conforming implementations MUST convert the addresses into an ASCII representation.¶
This memo includes no request to IANA.¶
This mechanism defines the reference specification for the Internet browser to locally preserve and manage the customized Web PKI certificate resources, and provides a simple mechanism to enable the Internet browser (in its implementation form, it may also be a browser proxy) to establish a local customized management view of the Web PKI certificate resources, and to overwrite the certificate data or verification results published by certain certification authority CAs when necessary. This mechanism addresses the security issues of domain name certificate resources in network infrastructure, namely the risk of unilateral suspension and revocation of certificate ownership due to the mismatch between ownership and management rights of certificate resources; Cleverly resolving the contradiction between unity and autonomy, key infrastructure improvement and stability, compatible with the contradiction between existing and smooth substitution, compatible with existing authentication systems, enabling stakeholders in the network to smoothly replace existing authentication, cope with the impact of malicious revocation of important industry certificates, and ensure the safe and normal operation of important industry systems. For this reason, Internet browsers (relying parties or their agents) conforming to this mechanism can autonomously decide and process any certificate and its verification results asserted by the local certificate preservation database according to local management requirements. This mechanism is applicable to the implementation and application of the Internet browser certificate resource preservation system based on Web PKI, and it is applicable to ensuring the smooth operation of the secure network access related to the business of an organization, without being subject to the management and control of other organizations that may have competitive interests; The Internet browser local certificate preservation specifications defined in this section are universal, and can also be applied to other similar network security applications and environments of different types based on PKI mechanism.¶