LAMPS P. Liu, Ed. Internet-Draft X. Liu, Ed. Intended status: Informational Pengcheng Laboratory Expires: 17 September 2025 R. Chen, Ed. China Mobile R. Fu, Ed. China Unicom Y. Zhang, Ed. Pengcheng Laboratory 16 March 2025 Simple Local Web PKI Certificate Resource Preservation Management for Internet Browser draft-liu-lamps-browser-webpki-cert-preservation-03 Abstract The management of Web PKI certificate resources presents a challenge when the misalignment of ownership and management rights over certificate resources of one organization creating a risk of unilateral suspension and revocation by another competing organizations. This situation undermines the stability of critical infrastructure and affects the integrity of authentication systems. To address these concerns, this document proposes a mechanism that allows Internet browsers to create a customized management view of certificate resources, enabling them to override verification results from specific certification authorities as needed. This approach enhances security, facilitates stakeholder collaboration, and preserves the operational integrity of essential industry systems. 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 17 September 2025. Liu, et al. Expires 17 September 2025 [Page 1] Internet-Draft Certificate Preservation for Internet Br March 2025 Copyright Notice Copyright (c) 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 4. The local Web PKI certificate resource preservation mechanism based on Internet browser . . . . . . . . . . . . . . . . 3 4.1. Local Web PKI Certificate Resource Preservation Process in Internet Browser Certificate Verification . . . . . . . . 4 4.2. Local certificate preservation repository . . . . . . . . 5 5. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The current SSL/TLS certificate architecture faces challenges due to the increasing centralization of major certificate authorities (CAs), which are controlled by a few institutions. Many critical systems worldwide depend on these centralized CAs, making their verification processes vulnerable to external influences from OCSP, CRL, and CT systems that may have competing interests. This reliance can lead to malicious revocation of certificates, rendering important industry services inaccessible and impacting the national economy. The misalignment of ownership and management rights over certificate resources of one organization (can be a nation or a large group) creates a risk of unilateral suspension and revocation by another competing organizations (can be also a nation or a large group). Addressing this issue requires developing a certificate resource Liu, et al. Expires 17 September 2025 [Page 2] Internet-Draft Certificate Preservation for Internet Br March 2025 management technology that is compatible with existing authentication systems while allowing organizations to replace the certificate verification results provided by certain certification authority CAs when necessary. Currently, no specific standards exist for these scenarios, some Internet browsers may provide related configurations that ignore all certificate errors or are similar to whitelists. However, generally ignoring all SSL/TLS certificate verification errors is considered unsecure and poses serious security risks. This document proposes a straightforward mechanism for Internet browsers to create a local customized management view of Web PKI certificate resources. It enables organizations to overwrite certificate data or verification results from certain CAs when needed, thus retaining control over their critical certificates. By implementing this local preservation mechanism, organizations can mitigate the risks associated with malicious revocation or the failure to reissue expired certificates. Users can independently assess the validity of certificates, ensuring the stable operation of essential systems and enhancing overall network security across various industries. 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. Design Goals The local Web PKI certificate resource preservation mechanism aims to achieve two main goals. 1. After the basic certificate verification process defined in RFC5280 is completed, if a specified error occurs, such as a certificate being revoked or expired, the organizational user (can be nation or a large group) can autonomously decide which certificates are valid. 2. As needed, organizational user can define their own untrusted certificates, regardless of whether they are verified as legitimate or not during the standard verification process. 4. The local Web PKI certificate resource preservation mechanism based on Internet browser Liu, et al. Expires 17 September 2025 [Page 3] Internet-Draft Certificate Preservation for Internet Br March 2025 4.1. Local Web PKI Certificate Resource Preservation Process in Internet Browser Certificate Verification +------------+ +-------------+ +------------+ +-------------+ |certificate | | basic | |certificate | | verification| |chain |<-->| verification|<-->|preservation|<-->| result | | | | (RFC5280) | | | | | +------------+ +-------------+ +------------+ +-------------+ Figure 1: the certificate preservation process based on Internet Browser The process of Web PKI certificate resource preservation based on Internet Browser is shown in Figure 1. After completing basic certificate verification following [RFC5280] in the browser, the browser uses the "LocalCertWhiteFilters" defined in section 3.2 to verify whether the serial number "SerialNumber" of the target leaf certificate exists in the whitelist certificate filter item "CertWhiteFilters" of the current local certificate preservation repository, or whether the subject name "subjectName" of the target leaf certificate exists in the whitelist certificate filter item "CertWhiteFilters" of the current local certificate preservation repository, or if the subject alternative name extension "subjectAltName" of the target leaf certificate exists, to verify whether the subject alternative name exists in the whitelist certificate filter item "WhiteCertFilters" of the current local certificate preservation repository. As long as one of the conditions is met, it is matched to the whitelist certificate filter item "CertWhiteFilters" of the current local certificate preservation repository. If a specific error number "ErrorNo" is found during the basic certificate verification process, such as the target leaf certificate being revoked or expired, the current target leaf certificate should be considered valid. According to the definition of "LocalCertBlackAssertions" in Section 3.2 of the local certificate preservation repository, verify whether the serial number "SerialNumber" of the target leaf certificate exists in the blacklist certificate assertion item "CertBlackAssertions" of the current local certificate preservation repository, or verify whether the subject name "subjectName" of the target leaf certificate exists in the blacklist certificate assertion item "CertBlackAssertions" of the current local certificate preservation repository, or if the subject alternative name extension of the target leaf certificate exists, verify whether the "subjectAltName" exists in the blacklist certificate assertion item "CertBlackAssertions" of the current local certificate preservation repository, or verify whether the issuer name "Issuer" exists in the Liu, et al. Expires 17 September 2025 [Page 4] Internet-Draft Certificate Preservation for Internet Br March 2025 current local certificate preservation repository's blacklist certificate assertion item "CertBlackAssertions", Alternatively, if the issuer alternative name extension of the target leaf certificate exists, verify whether the "issuerAltName" exists in the current local certificate preservation repository's blacklist certificate assertion item "CertBlackAssertions". As long as one of the conditions is met, regardless of whether any errors occur during the basic certificate verification process, the current target leaf certificate should be considered invalid and the browser user should be given a corresponding network certificate status prompt. 4.2. Local certificate preservation repository This mechanism defines and introduces the format of the certificate preservation repository based on JSON files. The local Web PKI certificate resource preservation mechanism or service in the certificate verification process of Internet browsers that comply with this mechanism shall comply with the format specification defined in this section. This mechanism uses ASN. 1 Specific Encoding Rules (DER) to encode the basic fields of the following certificate parameter items and form specific certificate parameter data structures. ASN. 1 DER encoding is an encoding system for the tag, length, and value of each element. For certificate preservation repository based on JSON format files, their local whitelist certificate filters "LocalCertWhiteFilters" and blacklist certificate assertions "LocalCertBlackAssertions" members are specified in JSON format [RFC8259]. JSON members not defined here are not allowed to be used in certificate preservation repository files. The implementation of Internet browsers must treat any deviation from this specification as an error. For the functional version updates related to the specifications in this document, this mechanism increments the "Version" field in the JSON file to indicate the version and functional differences of the local certificate preservation repository. The certificate preservation repository file format based on JSON format is as follows: Liu, et al. Expires 17 September 2025 [Page 5] Internet-Draft Certificate Preservation for Internet Br March 2025 { “Version”：1, “LocalCertWhiteFilters”：{ “ErrorNo”：ERR_CERT_REVOKED， “CertWhiteFilters”：[], }, “LocalCertBlackAssertions”：{ “CertBlackAssertions”：[], } } The "Version" member is set to 1 and encoded as a number in this standard version. For the local white list certificate filter "LocalCertWhiteFilters" in the certificate preservation repository file, Internet browser users can configure zero or more white list certificate filter items "CertWhiteFilters" that have passed the basic certificate verification logic, where each white list certificate filter item "CertWhiteFilters" can include the "SerialNumber" of the certificate, the "SerialNumber" of the certificate, and/or the "subjectName" of the certificate. This mechanism suggests that each white list certificate filter item should contain an explanatory note "comment", so as to explain the relevant matching information to Internet browser users as much as possible and facilitate their understanding. In file format, the content of the local whitelist certificate filter "LocalCertWhiteFilters" is represented as the values of the members "ErrorNo" and "CertWhiteFilters". The member "ErrorNo" describes the type of certificate error that occurs in the basic certificate verification logic, which is a positive integer with a value of a number in JSON format. Its default value is ERR_CERT_REVOKED (value 201, the types and value definitions of basic certificate errors defined in this mechanism can be found in Appendix A). Any algorithm implementation that complies with this mechanism can extend and define its own error types. The member CertWhiteFilters is represented by an array of zero or more objects, each object must contain at least one of the following members, or a combination of these members. 1. "serialNumber", the serial number, is of type INTEGER, and in JSON format, its value is a number. Liu, et al. Expires 17 September 2025 [Page 6] Internet-Draft Certificate Preservation for Internet Br March 2025 2. "subjectName", the subject name, is of type Name. In JSON format, its value is the Base64 encoding of the certificate's subject name, without the trailing character '='. This means that the value of this member is an ASN. 1 byte string (OCTET STRING) without an ASN. 1 tag and length field. 3. "subjectAltName", the alternative name for the subject, is of type GeneralNames. In JSON format, its value is the Base64 encoding of the certificate's subject alternative name, with no trailing character '=', meaning that the value of this member is an ASN. 1 byte string (OCTET STRING) without an ASN. 1 tag and length field. 4. "comment", a configuration item related annotation, whose value is a string in JSON format, used to explain the annotation of this configuration item. For the local blacklist certificate assertion "LocalCertBlackAssertions" in the certificate security repository file, Internet browser users can configure zero or more blacklist certificate assertion device entries "CertBlackAssertions" that have passed the basic certificate verification logic, where each blacklist certificate assertion entry "CertBlackAssertions" can include the "SerialNumber" of the certificate, the "subjectName" of the certificate, the "subjectAltName" of the certificate, the "issuer" name of the certificate, and/or the issuer alternative name "issuerAltName" of the certificate. This mechanism recommends that each blacklist certificate assertion item contain an explanatory not "comment", so as to explain relevant matching information to Internet browser users as much as possible and facilitate users' understanding. In terms of format, the content of "LocalCertBlackAssertions", a local blacklist certificate assertion, is represented as the value of a "CertBlackAssertions" member, which is an array of zero or more objects. Each object must contain at least one of the following members, or a combination of the following members. 1. "serialNumber", the serial number, is of type INTEGER, and in JSON format, its value is a number. 2. "subjectName", the subject name, is of type Name. In JSON format, its value is the Base64 encoding of the certificate's subject name, without the trailing character '='. This means that the value of this member is an ASN. 1 byte string (OCTET STRING) without an ASN. 1 tag and length field. Liu, et al. Expires 17 September 2025 [Page 7] Internet-Draft Certificate Preservation for Internet Br March 2025 3. "subjectAltName", the alternative name for the subject, is of type GeneralNames. In JSON format, its value is the Base64 encoding of the certificate's subject alternative name, with no trailing character '=', meaning that the value of this member is an ASN. 1 byte string (OCTET STRING) without an ASN. 1 tag and length field. 4. "issuerName" is of type Name, and in JSON format, its value is the Base64 encoding of the certificate issuer's name, without the trailing character '=', meaning that the value of this member is an ASN. 1 byte string (OCTET STRING) without an ASN. 1 tag and length field. 5. "issuerAltName" is of type GeneralNames, with field formats specified in RFC 5280. In JSON format, its value is the Base64 encoding of the certificate issuer's alternative name, followed by no trailing character '=', meaning that the value of this member is an ASN. 1 byte string (OCTET STRING) without an ASN. 1 tag and length field. 6. "comment", a configuration item related annotation, whose value is a string in JSON format, used to explain the annotation of this configuration item. It should be noted that in actual systems, multiple local certificate preservation repository files based on JSON format may be supported for simultaneous use. To ensure consistency in local functionality, the configuration of multiple local certificate preservation repository files must ensure that there are no conflicts. In other words, the Internet browser should check the local white list certificate filter "LocalCertWhiteFilters" field and the local black list certificate assertion "LocalCertBlackAssertions" field in each local certificate preservation repository file to ensure that there are no overlapping configuration entries, and also ensure that there are no overlapping configuration entries in the local white list certificate filter "LocalCertWhiteFilters" field and the local black list certificate assertion "LocalCertBlackAssertions" field between different local certificate preservation repository files. If a conflict is detected, an error should be reported to the user who created the relevant local certificate preservation repository file. Internet browsers should de duplicate multiple local certificate preservation repository files as a collection. If there is any overlap between the local white list certificate filter “LocalCertWhiteFilters” field and the local black list certificate assertion “LocalCertBlackAssertions” field between the local certificate preservation repository files, the entire collection must be rejected. Liu, et al. Expires 17 September 2025 [Page 8] Internet-Draft Certificate Preservation for Internet Br March 2025 The summary of all members and types supported by the JSON format local certificate preservation repository file in this mechanism is as follows: { “Version”：Type Int， “LocalCertWhiteFilters”: { “ErrorNo”: Type Int, “CertWhiteFilters”[ { “serialNumber”: Type Int, “subjectName”: "", “subjectAltName”: "", “comment”: Type String, } ], }, “LocalCertBlackAssertions”：{ “CertBlackAssertions”：[ { “serialNumber”: Type Int, “subjectName”: "", “subjectAltName”: "", “issuerName”: "", “issuerAltName”: "", “comment”: Type String, } ], } } 5. Appendix A The meaning of the following errors can be literally seen from common browsers. 1. ERR_CERT_INVALID:201, The certificate is invalid, such as incorrect format, unsupported fields, etc. 2. ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN:202, The certificate used on the website does not match the HTTP public key of the built- in certificate, which may cause the website to be hijacked. It is necessary to check the website's DNS analysis to restore normal HTTPS access; It is also possible that the HPKP Google Chrome error is due to incorrect settings. Liu, et al. Expires 17 September 2025 [Page 9] Internet-Draft Certificate Preservation for Internet Br March 2025 3. ERR_CERT_REVOKED:203, The certificate used by the website has been revoked. The certificate issuing authority has revoked the certificate due to changes in enterprise information or violations of website content. The certificate has been added to the certificate revocation list CRL. We need to reapply for the certificate and deploy it correctly. 4. ERR_CERT_AUTHORITY_INVALID:204, The website is using a certificate issued by an invalid certificate authority. This error indicates that the root certificate of the certificate used by the website is not trusted by the browser, which may be due to the user using a self-signed certificate or the root certificate of the certificate being revoked. The solution is to reapply for a certificate issued by a certificate authority trusted by the browser. 5. ERR_CERT_COMMON_NAME_INVALID:205, The certificate used by the website does not match the domain name, and the domain name supported by the certificate does not match the website domain name. In other words, the website used the wrong certificate. The solution is to reapply for a new SSL certificate with the same domain name as the website. 6. ERR_CERT_WEAK_SIGNATURE_ALGORITHM:206, The website certificate uses an insecure signature algorithm, and the digital signature algorithm is used for identity verification between communication parties. If the insecure SHA-1 signature algorithm is used, the browser will report an error, and the SHA-256 signature algorithm should be used. 7. ERR_CERT_DATE_INVALID:207, SSL certificate has expired. The certificate has expired and been deleted. Applying for a new certificate and installing it correctly can solve the error. Liu, et al. Expires 17 September 2025 [Page 10] Internet-Draft Certificate Preservation for Internet Br March 2025 8. ERR_CERT_VALIDITY_TOO_LONG:208, The validity period of the website certificate is too long. As time goes by, the longest lifespan of public trust certificates gradually shortens. These dates are derived from the transition mentioned in Section 1.2.2 (Relevant Dates) of the baseline requirements.Certificates issued before BR takes effect have a maximum validity period of ten years for Chrome, not exceeding July 1, 2019, and may expire on July 1, 2019. Certificates issued on or after the effective date of BR on July 1, 2012: 60 months, last possible expiration date: April 1, 2015+60 months=2020-04-01.Certificates issued on or after April 1, 2015: 39 months, last possible expiration date: March 1, 2018+39 months=2021-06-01. Certificates issued on or after March 1, 2018: 825 days, last possible expiration date: September 1, 2020+825 days=2022-12-05. The current limit in Chrome's root certificate policy is 398 days for certificates issued on or after September 1, 2020. 9. ERR_CERT_NO_REVOCATION_MECHANISM:209, The certificate does not have a revocation mechanism, meaning there is no CRL or OCSP reference. This error may pose a security risk as the browser cannot verify whether the certificate has been revoked. Mainly, some CAs issue short-term certificates, so they do not provide a method to revoke them. Some intermediate boxes (such as Palo Alto Networks or Cisco firewalls) or antivirus software on computers are used on the network, which will intercept HTTPS and replace certificates with their own certificates. 10. ERR_CERT_UNABLE_TO_CHECK_REVOCATION:210, If the local browser has enabled the Required Online Revocation ChecksForLocalAnchors policy and the CRL of the website certificate does not comply with the requirements of RFC 5280. 11. ERR_CERTIFICATE_TRANSPARENCY_REQUIRED:211, It is specific to Google Chrome, mainly because the website certificate has not yet been added to the transparency log by the issuing authority. There are two situations where the certificate is not added to the transparent log. The first scenario is that the issuing authority did not add the certificate, possibly due to their negligence. The second scenario is that the website owner may have requested the certificate authority not to add their certificate to the log. 12. ERR_CERT_SYMANTEC_LEGACY:212, Google Chrome no longer trusts Symantec certificates issued before June 1, 2016. Symantec has sold its CA business to Digicol and no longer issues SSL certificates, so the likelihood of encountering this error is very low. Liu, et al. Expires 17 September 2025 [Page 11] Internet-Draft Certificate Preservation for Internet Br March 2025 13. ERR_CERT_NAME_CONSTRAINT_VIOLATION:213, The domain name of the certificate does not comply with the rules and violates the name constraints in the certificate. This error may occur when the name constraint of the certificate is not met, which may be due to configuration errors or unauthorized use. 14. ERR_CERT_KNOWN_INTERCEPTION_BLOCKED:214, This error indicates that a known SSL/TLS interception attempt has been blocked. When a third party attempts to intercept a secure connection, this situation may occur, endangering the user's privacy and security. You need to investigate the potential security software or network configuration that caused this interception and ensure a secure connection. 15. ERR_CERT_WEAK_KEY:215, It indicates that using weak keys for encryption in certificates poses a security risk. This vulnerability may expose users to potential security risks. To address this error, website administrators need to update their certificates with more powerful key algorithms to improve security. 16. ERR_CERT_STATUS_NON_UNIQUE_NAME:216, When the website certificate is missing a unique theme name, it indicates that it does not have a unique name and is generally not mapped to an error. It is considered a warning to downgrade SSL UI. 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations 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 Liu, et al. Expires 17 September 2025 [Page 12] Internet-Draft Certificate Preservation for Internet Br March 2025 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. 8. References 8.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, . 8.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 Liu, et al. Expires 17 September 2025 [Page 13] Internet-Draft Certificate Preservation for Internet Br March 2025 Xiang Liu (editor) Pengcheng Laboratory No.2 Xingke 1 Street Shenzhen 518055 China Email: liux15@pcl.ac.cn Meiling Chen (editor) China Mobile No.32 Xuanwumen West Street Beijing 100000 China Email: chenmeiling@chinamobile.com Yu Fu (editor) China Unicom No.1 Zhonghe Street Beijing 100000 China Email: fuy186@chinaunicom.cn Yu Zhang (editor) Pengcheng Laboratory No.2 Xingke 1 Street Shenzhen 518055 China Email: zhangy08@pcl.ac.cn Liu, et al. Expires 17 September 2025 [Page 14]