LAMPS P. Liu, Ed. Internet-Draft X. Liu, Ed. Intended status: Informational R. Yang, Ed. Expires: 30 May 2025 Y. Zhang, Ed. Pengcheng Laboratory 26 November 2024 Certificate Status Information Mechanism Description Updates to RFC 5280 draft-liu-lamps-mechanism-updates-to-rfc-5280-01 Abstract 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]. 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 30 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. Liu, et al. Expires 30 May 2025 [Page 1] Internet-Draft RFC 5280 Clarifications November 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Updates to RFC 5280 . . . . . . . . . . . . . . . . . . . . . 3 3.1. Update in the Operational Protocols (Section 3.4) . . . . 3 3.2. Update in CRL and CRL Extensions Profile (Section 5) . . 3 3.3. Update in the Basic Certificate Processing (Section 6.1.3) . . . . . . . . . . . . . . . . . . . . . 4 3.4. Update in the Internationalized Names in Distinguished Names (Section 7.1) . . . . . . . . . . . . . . . . . . . 4 3.5. Update in the Internationalized Domain Names in GeneralName (Section 7.2) . . . . . . . . . . . . . . . . . . . . . . 5 3.6. Update in the Internationalized Electronic Mail Addresses (Section 7.5) . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 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. Liu, et al. Expires 30 May 2025 [Page 2] Internet-Draft RFC 5280 Clarifications November 2024 2. Requirements Language 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. Updates to RFC 5280 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. 3.1. Update in the Operational Protocols (Section 3.4) 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. 3.2. Update in CRL and CRL Extensions Profile (Section 5) This update provides references for OCSP and CT Liu, et al. Expires 30 May 2025 [Page 3] Internet-Draft RFC 5280 Clarifications November 2024 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. 3.3. Update in the Basic Certificate Processing (Section 6.1.3) 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. 3.4. Update in the Internationalized Names in Distinguished Names (Section 7.1) 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 Liu, et al. Expires 30 May 2025 [Page 4] Internet-Draft RFC 5280 Clarifications November 2024 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. 3.5. Update in the Internationalized Domain Names in GeneralName (Section 7.2) 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. Liu, et al. Expires 30 May 2025 [Page 5] Internet-Draft RFC 5280 Clarifications November 2024 3.6. Update in the Internationalized Electronic Mail Addresses (Section 7.5) 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. 4. IANA Considerations This memo includes no request to IANA. 5. Security Considerations For the relying parties of Web PKI, certificate path construction and certificate validation are necessary security review processes.The quality of implementations that process certificates also affects the degree of assurance provided. The path validation algorithm described in Section 6 relies upon the integrity of the trusted CA information, and especially the integrity of the status information associated with the certificate. By providing multiple checking mechanisms, an attacker cannot trick the user into accepting false certificates.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 security Liu, et al. Expires 30 May 2025 [Page 6] Internet-Draft RFC 5280 Clarifications November 2024 reference for Internet browser manufacturers. 6. References 6.1. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [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, . Authors' Addresses Penghui Liu (editor) Pengcheng Laboratory No.2 Xingke 1 Street Shenzhen 518055 China Email: liuph@pcl.ac.cn Xiang Liu (editor) Pengcheng Laboratory No.2 Xingke 1 Street Shenzhen 518055 China Email: liux15@pcl.ac.cn Liu, et al. Expires 30 May 2025 [Page 7] Internet-Draft RFC 5280 Clarifications November 2024 Rongwei Yang (editor) Pengcheng Laboratory No.2 Xingke 1 Street Shenzhen 518055 China Email: yangrw@pcl.ac.cn Yu Zhang (editor) Pengcheng Laboratory No.2 Xingke 1 Street Shenzhen 518055 China Email: zhangy08@pcl.ac.cn Liu, et al. Expires 30 May 2025 [Page 8]