LAMPS                                                        P. Liu, Ed.
Internet-Draft                                               X. Liu, Ed.
Intended status: Informational                              R. Yang, Ed.
Expires: 6 June 2025                                       Y. Zhang, Ed.
                                                    Pengcheng Laboratory
                                                         3 December 2024


  Technical guidelines of web server certification path validation for
                            Interent browser
            draft-liu-lamps-certification-path-validation-00

Abstract

   This document provides a technical guide for certification path
   validation of web server certificates during Internet SSL/TLS
   protocol communication, including the basic path verification
   process, as well as reference procedures, guidance and suggestions
   for input, initialization, and basic certificate processing in the
   verification process.  This document is applicable to the development
   and application of Internet browsers, as well as other similar
   digital certificate authentication systems requiring SSL/TLS security
   protocol secure communication.

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 6 June 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Liu, et al.                Expires 6 June 2025                  [Page 1]

Internet-Draft           RFC 5280 Clarifications           December 2024


   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.  Web server certification path validation for Interent
           browser . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Basic Path Validation . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Inputs  . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.2.  Initialization  . . . . . . . . . . . . . . . . . . .   7
       3.1.3.  Basic Certificate Processing  . . . . . . . . . . . .   8
       3.1.4.  Preparation for Certificate i+1 . . . . . . . . . . .   9
       3.1.5.  Wrap-Up Procedure . . . . . . . . . . . . . . . . . .   9
       3.1.6.  Outputs . . . . . . . . . . . . . . . . . . . . . . .  10
     3.2.  Using the Path Validation Algorithm . . . . . . . . . . .  10
     3.3.  CRL Validation  . . . . . . . . . . . . . . . . . . . . .  10
     3.4.  OCSP Validation . . . . . . . . . . . . . . . . . . . . .  10
       3.4.1.  OCSP Inputs . . . . . . . . . . . . . . . . . . . . .  11
       3.4.2.  Initialization and Revocation State Variables . . . .  11
       3.4.3.  CRL Processing  . . . . . . . . . . . . . . . . . . .  11
     3.5.  CT Validation . . . . . . . . . . . . . . . . . . . . . .  13
       3.5.1.  CT Inputs . . . . . . . . . . . . . . . . . . . . . .  14
       3.5.2.  Initialization and Revocation State Variables . . . .  14
       3.5.3.  CT Processing . . . . . . . . . . . . . . . . . . . .  15
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

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 certificating 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



Liu, et al.                Expires 6 June 2025                  [Page 2]

Internet-Draft           RFC 5280 Clarifications           December 2024


   history is not in line with existing practice of Interent browser,
   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
   anufacturers, 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 a unified reference procedure for the path verification
   process of SSL/TLS digital certificates in Internet browsers in
   combination with RFC5280 and the current latest practice, so as to
   provide reference for Internet browser manufacturers

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.  Web server certification path validation for Interent browser

   This section provides technical guidelines for certification path
   validation of website server certificates during SSL/TLS protocol
   communication, including basic path verification process, as well as
   reference procedures, guidance and suggestions for input,
   initialization, basic certificate processing, etc. in the
   verification process.

   Certification path validation procedures for the Internet PKI are
   based on the algorithm supplied in [X.509].  Certification path
   processing verifies the binding between the subject distinguished
   name and/or subject alternative name and subject public key.  The
   binding is limited by constraints that are specified in the
   certificates that comprise the path and inputs that are specified by
   the relying party.  The basic constraints and policy constraints
   extensions allow the certification path processing logic to automate
   the decision making process.









Liu, et al.                Expires 6 June 2025                  [Page 3]

Internet-Draft           RFC 5280 Clarifications           December 2024


   This section describes an algorithm for validating certification
   paths.  Conforming implementations of this specification are not
   required to implement this algorithm, but MUST provide functionality
   equivalent to the external behavior resulting from this procedure.
   Any algorithm may be used by a particular implementation so long as
   it derives the correct result.

   In Section 3.1, the text describes basic path validation.  Valid
   paths begin with certificates issued by a trust anchor.  The
   algorithm requires the public key of the CA, the CA’s name, and any
   constraints upon the set of paths that may be validated using this
   key.

   The selection of a trust anchor is a matter of policy: it could be
   the top CA in a hierarchical PKI, the CA that issued the verifier's
   own certificate(s), or any other CA in a network PKI.  The path
   validation procedure is the same regardless of the choice of trust
   anchor.  In addition, different applications may rely on different
   trust anchors, or may accept paths that begin with any of a set of
   trust anchors.

   Section 3.2 describes methods for using the path validation algorithm
   in specific implementations.

   Section 3.3 describes the steps necessary to determine if a
   certificate is revoked when CRLs are the revocation mechanism used by
   the certificate issuer.

   Section 3.4 describes the steps required by the relying party to
   determine whether a certificate has been revoked when OCSP is the
   revocation mechanism used by the certificate issuer.

   Section 3.5 describes the steps required for the relying party to
   determine the legitimacy and authority of a certificate through the
   CT mechanism.

3.1.  Basic Path Validation

   This text describes an algorithm for X.509 path processing.  A
   conforming implementation MUST include an X.509 path processing
   procedure that is functionally equivalent to the external behavior of
   this algorithm.  However, support for some of the certificate
   extensions processed in this algorithm are OPTIONAL for compliant
   implementations.  Clients that do not support these extensions MAY
   omit the corresponding steps in the path validation algorithm.






Liu, et al.                Expires 6 June 2025                  [Page 4]

Internet-Draft           RFC 5280 Clarifications           December 2024


   For example, clients are not required to support the policy mappings
   extension.  Clients that do not support this extension MAY omit the
   path validation steps where policy mappings are processed.  Note that
   clients MUST reject the certificate if it contains an unsupported
   critical extension.

   While the certificate and CRL profiles specified in RFC5280 specify
   values for certificate and CRL fields and extensions that are
   considered to be appropriate for the Internet PKI, the algorithm
   presented in this section is not limited to accepting certificates
   and CRLs that conform to these profiles.  Therefore, the algorithm
   only includes checks to verify that the certification path is valid
   according to X.509 and does not include checks to verify that the
   certificates and CRLs conform to this profile.  While the algorithm
   could be extended to include checks for conformance to the profiles
   in RFC5280, this profile RECOMMENDS against including such checks.

   The algorithm presented in this section validates the certificate
   with respect to the current date and time.  A conforming
   implementation MAY also support validation with respect to some point
   in the past.  Note that mechanisms are not available for validating a
   certificate with respect to a time outside the certificate validity
   period.

   The trust anchor is an input to the algorithm.  There is no
   requirement that the same trust anchor be used to validate all
   certification paths.  Different trust anchors MAY be used to validate
   different paths, as discussed further in Section 3.2.

   The primary goal of path validation is to verify the binding between
   a subject distinguished name or a subject alternative name and
   subject public key, as represented in the target certificate, based
   on the public key of the trust anchor.  In most cases, the target
   certificate will be an end entity certificate, but the target
   certificate may be a CA certificate as long as the subject public key
   is to be used for a purpose other than verifying the signature on a
   public key certificate.  Verifying the binding between the name and
   subject public key requires obtaining a sequence of certificates that
   support that binding.  The procedure performed to obtain this
   sequence of certificates is outside the scope of this specification.

   To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n
   certificates) satisfies the following conditions:

   1.  for all x in {1, ..., n-1}, the subject of certificate x is of
       certificate x+1;




Liu, et al.                Expires 6 June 2025                  [Page 5]

Internet-Draft           RFC 5280 Clarifications           December 2024


   2.  certificate 1 is issued by the trust anchor;

   3.  certificate n is the certificate to be validated (i.e., the
       target certificate); and

   4.  for all x in {1, ..., n}, the certificate was valid at the time
       in question.

   A certificate MUST NOT appear more than once in a prospective
   certification path.

   When the trust anchor is provided in the form of a self-signed
   certificate, this self-signed certificate is not included as part of
   the prospective certification path.  Information about trust anchors
   is provided as inputs to the certification path validation algorithm.

   A particular certification path may not, however, be appropriate for
   all applications.  Therefore, an application MAY augment this
   algorithm to further limit the set of valid paths.  The path
   validation process also determines the set of certificate policies
   that are valid for this path, based on the certificate policies
   extension, policy mappings extension, policy constraints extension,
   and inhibit anyPolicy extension.  To achieve this, the path
   validation algorithm constructs a valid policy tree.  If the set of
   certificate policies that are valid for this path is not empty, then
   the result will be a valid policy tree of depth n, otherwise the
   result will be a null valid policy tree.

   A certificate is self-issued if the same DN appears in the subject
   and issuer fields (the two DNs are the same if they match according
   to the rules specified in RFC5280).  In general, the issuer and
   subject of the certificates that make up a path are different for
   each certificate.  However, a CA may issue a certificate to itself to
   support key rollover or changes in certificate policies.  These self-
   issued certificates are not counted when evaluating path length or
   name constraints.

   This section presents the algorithm in four basic steps: (1)
   initialization, (2) basic certificate processing, (3) preparation for
   the next certificate, and (4) wrap-up.  Steps (1) and (4) are
   performed exactly once.  Step (2) is performed for all certificates
   in the path.  Step (3) is performed for all certificates in the path
   except the final certificate.  Figure 1 provides a high-level
   flowchart of this algorithm.







Liu, et al.                Expires 6 June 2025                  [Page 6]

Internet-Draft           RFC 5280 Clarifications           December 2024


                              +-------+
                              | START |
                              +-------+
                                  |
                                  V
                          +----------------+
                          | Initialization |
                          +----------------+
                                  |
                                  +<--------------------+
                                  |                     |
                                  V                     |
                          +----------------+            |
                          |  Process Cert  |            |
                          +----------------+            |
                                  |                     |
                                  V                     |
                          +================+            |
                          |  IF Last Cert  |            |
                          |    in Path     |            |
                          +================+            |
                            |            |              |
                       THEN |            | ELSE         |
                            V            V              |
                 +----------------+ +----------------+  |
                 |    Wrap up     | |  Prepare for   |  |
                 +----------------+ |   Next Cert    |  |
                         |          +----------------+  |
                         V               |              |
                     +-------+           +--------------+
                     | STOP  |
                     +-------+

   Figure 1: Certification Path Processing Flowchart

3.1.1.  Inputs

   This section references the Section "6.1.1.  Inputs" of RFC5280.

3.1.2.  Initialization

   This section references the Section "6.1.2.  Initialization" of
   RFC5280.








Liu, et al.                Expires 6 June 2025                  [Page 7]

Internet-Draft           RFC 5280 Clarifications           December 2024


3.1.3.  Basic Certificate Processing

   This section references the Section "6.1.3.  Basic Certificate
   Processing" of RFC5280, but with the following conditions added or
   modified:

   (2) The certificate validity period includes the current time. the
   validity period in the certificate is within a reasonable range.
   Expired certificates may be maliciously exploited, and website
   certificates may not be effective yet.  It is necessary to verify the
   validity field information of the certificate to see if the current
   date is within the validity period of the certificate.  In addition,
   according to the CA/Browser Forum certificate issuance and management
   baseline requirements, certificates issued on or after September 1,
   2020 shall not exceed a validity period of 398 days, certificates
   issued between March 1, 2018 and September 1, 2020 shall not exceed a
   validity period of 825 days, and certificates issued after July 1,
   2016 but before March 1, 2008 shall not exceed a validity period of
   39 months.  Certificates that do not meet this requirement are
   considered to have a risk of validity period setting, and the
   validity field information of the certificate needs to be checked to
   verify whether it meets the validity period setting requirements.

   (3) At the current time, the certificate is not revoked and is valid.
   The certificate status can be determined by obtaining appropriate
   protocol status information such as CRL (Section 3.3), OCSP
   (Section 3.4), and CT (Section 3.5), or by using out of band
   mechanisms.  If the revocation certificate status is queried through
   both CRL and OCSP, but the two query results are inconsistent, the
   worst result status shall prevail.  That is, if one of the two
   results is revoked, it is considered that the certificate has been
   revoked.

   (5) The signature algorithm of the certificate is valid, that is, the
   signatureAlgorithm field of the certificate must be consistent with
   the signature field in TBSCertificate.

   (6) The certificate does not use insecure weak keys, such as RSA,
   ECDSA, and SM2 public key cryptography algorithms.  This document
   recommends that the RSA algorithm has a key length of at least 2048
   bits, the ECDSA algorithm recommends elliptic curves such as NIST
   P-256, NIST P-384, and NIST P-521, and the ISO/IEC 14888-3/AMD1 SM2
   algorithm has a key length of at least 256 bits.

   (7) The certificate format should comply with the IETF RFC5280
   standard format for X.509 certificates and meet the relevant
   requirements for server certificates in the CA/Browser Forum
   certificate issuance and management baseline requirements.



Liu, et al.                Expires 6 June 2025                  [Page 8]

Internet-Draft           RFC 5280 Clarifications           December 2024


   (8) The website domain name included in the certificate is consistent
   with the website domain name.

   (9) The strength of the hash function used in the signature meets the
   requirements: it is recommended to use SHA256, SHA384, SHA512, or SM3
   hash algorithms, and check whether the hash algorithm of the
   signatureAlgorithm field is the recommended hash algorithm.

   (10) The domain name in the certificate is configured with CAA
   records: The domain owner can only issue the certificate by
   configuring CAA record values and specifying allowed trusted CAs.
   During the certificate issuance process, the CA will complete the
   certificate issuance process only after successful CAA verification.
   The CAA record information should be checked to see if there are
   valid CAA records.

   (11) The deployment configuration of certificates is secure: check
   whether insecure versions of protocols and encryption suites are
   used, and whether the server-side supports and enables HSTS.  Using
   insecure protocols and encryption suites can threaten private key
   security (for example, using certificates that support DH public key
   parameter reuse can pose a risk of Heartbleed site vulnerabilities).
   TLS protocols include SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2,
   and TLS 1.3; The security of certificate deployment configuration
   should be determined by checking the TLS version and encryption
   suite.  Regarding the judgment of TLS protocol, it is recommended to
   consider SSL 2.0 and SSL 3.0 as insecure and using algorithms with
   known security vulnerabilities, both of which have been abandoned;
   TLS 1.0 and TLS 1.1: Weak and risky, officially abandoned in 2021;
   TLS 1.2 and TLS 1.3: Security.The cipher suite used is secure: If any
   of the following situations occur in the cipher suite, it is
   considered a risk: RSA, DH, ECDH do not have forward encryption and
   have key recovery attack vulnerabilities; DSA is a weak asymmetric
   encryption algorithm; RC4 stream cipher, abandoned; CBC mode
   encryption is vulnerable to BEAST and Lucky 13 vulnerabilities; There
   is a risk of cracking the SHA1 algorithm; Algorithm suite using
   anonymous authentication; Algorithm suite using null encryption
   algorithm.

3.1.4.  Preparation for Certificate i+1

   This section references the Section "6.1.4.  Preparation for
   Certificate i+1" of RFC5280.

3.1.5.  Wrap-Up Procedure

   This section references the Section "6.1.5.  Wrap-Up Procedure" of
   RFC5280.



Liu, et al.                Expires 6 June 2025                  [Page 9]

Internet-Draft           RFC 5280 Clarifications           December 2024


3.1.6.  Outputs

   This section references the Section "6.1.6.  Outputs" of RFC5280.

3.2.  Using the Path Validation Algorithm

   This section references the Section "6.2.  Using the Path Validation
   Algorithm" of RFC5280.

3.3.  CRL Validation

   This section references the Section "6.3.  CRL Validation" of
   RFC5280.

3.4.  OCSP Validation

   In this section, this document describes the steps required to
   determine whether a certificate has been revoked when OCSP is the
   certificate status query mechanism used by certificate issuers.  The
   OCSP protocol is an online query service used to verify the validity
   of certificates, typically provided by the CA to which the
   certificate belongs.  Some clients will query the OCSP interface in
   real-time during further negotiation during the SSL/TLS handshake
   phase and block subsequent processes until the results are obtained.
   OCSP query is essentially a complete HTTP request/response operation.
   OCSP Stapling refers to the server actively obtaining the OCSP query
   results and sending them to the client along with the certificate,
   allowing the client to skip the verification process and improve the
   efficiency of SSL/TLS handshake.  For details, please refer to
   RFC6066 and RFC6961 standards.  OCSP protocol is mainly used to
   replace CRL in public key infrastructure (PKI) to query the status of
   digital certificates.  When a user attempts to access a website
   server through an Internet browser, the Internet browser sends a
   request for certificate status information through the online
   certificate status protocol.  The OCSP server responds with a
   "valid," "revoked," or "unknown.  OCSP is a relatively simple
   request/response protocol implemented in C/S mode, without specifying
   the transmission mechanism used by the protocol or the structure of
   the OCSP system.  The specific mechanism can be found in standard
   RFC6960, which is not limited in this document.  This document
   assumes that the Internet browser client has been configured with
   OCSP server, such as signature key pair, server address, etc.  The
   implementation of the consistency function supporting OCSP for
   specific scenarios does not require a one-to-one implementation of
   this algorithm, but when processing OCSP parameters, it must be
   functionally equivalent to the external behavior generated by the
   procedures described in this document.  Any algorithm can be used by
   a specific implementation as long as it produces the correct results.



Liu, et al.                Expires 6 June 2025                 [Page 10]

Internet-Draft           RFC 5280 Clarifications           December 2024


   The algorithm described in this section defines a set of inputs and
   processing steps for each certificate in the authentication path.
   The algorithm output is the revocation status of the certificate.



     +------------+           +-------------+           +------------+
     | OCSP client| request   |    OCSP     |  query    | Information|
     | Browser    |<--------->|   server    |<--------->| Database   |
     |            | response  | (responder) |  response |            |
     +------------+           +-------------+           +------------+

   Figure 2: OCSP Request/Response Service Mechanism

3.4.1.  OCSP Inputs

   To support OCSP revocation status query operations, the algorithm
   requires three inputs:

   1.  certificate: This algorithm requires the Hash algorithm
       identifier, the Hash value of the certificate issuer (CA) name
       (DN), the Hash value of the certificate issuer (CA) public key,
       and the certificate serial number to determine whether the
       certificate is valid.

   2.  use-signature: This input indicates whether to add a signature to
       the OCSP request, in order for the OCSP responder (server) to
       authenticate the requester's identity.

   3.  use-specified-server: This input indicates whether to include the
       specified response server URI in the OCSP request.

3.4.2.  Initialization and Revocation State Variables

   To support OCSP processing, the algorithm requires the following
   state variable:

   1.  cert_datus: This variable contains the status of the certificate.
       This variable can be assigned one of the following values:
       REVOKED, UNRREVOKED, or INSERTMINED.  This variable is
       initialized to the special value UNEVOKED.

3.4.3.  CRL Processing

   Before processing the revocation status query, the algorithm assumes
   that the target certificate has not been revoked, that is, the
   initial value of the variable 'Certificate Status' is UNREFOKED.  The
   algorithm performs the following operations:



Liu, et al.                Expires 6 June 2025                 [Page 11]

Internet-Draft           RFC 5280 Clarifications           December 2024


   1.  Analyze and extract the statis_request message extension field of
       the SSL/TLS protocol to obtain the ocsp response sent by the
       website server in a Staking manner.

   2.  If the website server does not send OCSP related message
       extensions, that is, does not support OCSP Stapling function,
       then construct an OCSP request OCSPRequest and send it to the
       OCSP server.  The request contains the target certificate CertID
       (certificate identifier) for querying the certificate, which
       includes the hash algorithm identifier, the hash value of the
       certificate issuer (CA) name (DN), the hash value of the
       certificate issuer (CA) public key, and the certificate serial
       number; Determine whether to use the specified OCSP server
       address based on input parameter use-specified-server and attach
       it to the ServiceLocator field in the singleRequestExtensions
       extension of the request; And based on the input parameter use-
       signature, decide whether to use the request signature to sign
       the message.

   3.  After receiving the signed response OCSPResponse from the OCSP
       server, whether through online queries or stapling, the OCSP
       response may be a definite response or an error message
       indicating an abnormal situation.  For each definite response,
       the responder must sign, and there is no need to sign for error
       messages.  The confirmed response includes the protocol version
       number, responder name, reply to each certificate to be queried,
       optional extensions, signature algorithm object identifier, and
       signature value.  The following verifications need to be
       performed.  If all verifications pass, the algorithm accepts this
       response; Otherwise, this response is considered invalid.

       (1) Is the certificate identified by the CertID in the received
       response consistent with the request; (2) Is the Signature
       signature in BasicOCSPResponse valid; (3) Whether the response
       signer is trusted by the client (whether the response certificate
       is in the client's trust list); (4) Is the response generation
       time in the response the current time.

       Only when the value of responsiveStatus is "successful", the
       value of responsiveBytes in the OCSPResponse response will be
       set.  There are six values for responsiveStatus response status:
       "successful" indicates that the response is valid and the query
       is successful; "malformedRequest" indicates that the received
       query request format is inconsistent with the OCSP standard
       syntax; "internalError" indicates that the OCSP responder is
       currently in an uncoordinated internal state, requiring the
       client to attempt the request again or try other responders;
       "trylater" is used to indicate that the OCSP service still exists



Liu, et al.                Expires 6 June 2025                 [Page 12]

Internet-Draft           RFC 5280 Clarifications           December 2024


       but is busy and temporarily unable to respond to client requests;
       "SigRequired" means that the OCSP server requires the current
       client to attach signature data when sending requests;
       "Unauthorized" means that the current client does not have
       permission to query the OCSP responder.  If the response status
       is a certain error situation, the response byte will not be set,
       and the client needs to determine the revocation status of the
       certificate based on the returned status:

       If the response field CertStatus is good, it indicates a positive
       response from the responder to the status query.  At a minimum,
       this positive response means that the certificate with the
       requested certificate serial number has not been revoked within
       the current validity period.  Set the variable "cert_status" to
       UNREFOKED; If the response field CertStatus is revoked, it
       indicates that the certificate has been revoked.  Set the
       variable "cert_status" to REVOKED and resolve the reason for
       revocation based on the CRLReason field in the RevokedInfo field
       (if this extension field exists) (the definition of revocation
       reason values can be found in Section 5.5); If the response field
       variable CertStatus is unknown, it means that the responder
       cannot determine the certificate status of the request.  Set the
       variable "cert_status" to UNDERTMINED.

3.5.  CT Validation

   In this section, this document describes the steps required for the
   relying party to determine the legitimacy and authority of a
   certificate through the certificate transparency CT mechanism.
   Certificate transparency is a mechanism used to monitor and audit the
   behavior of SSL/TLS certificate authorities (CAs), by recording and
   publicly issuing all SSL/TLS certificates, allowing third parties to
   verify the legitimacy and authority of certificates, preventing
   certificate abuse and fraud.  For the signature certificate timestamp
   SCT in the CT mechanism, the Internet browser client can obtain it in
   three ways: one is directly extended through the X509v3 certificate;
   After submitting the pre signed certificate to the log server, the
   certificate authority (CA) will return the SCT, and the CA will
   attach the SCT as an X.509v3 extension to the signed website server
   certificate; Another extension of the OCSP Stapling protocol during
   SSL/TLS negotiation; The third way is to directly extend the SSL/TLS
   protocol; The specific mechanism can be found in standard RFC6962,
   which is not limited in this document.  This document assumes that
   the Internet browser client has the relevant configuration of the log
   server, such as the signature key pair, server address, and so on.
   The implementation of consistency functionality for CT support in
   specific scenarios does not require a one-to-one implementation of
   this algorithm, but when processing CT parameters, the implementation



Liu, et al.                Expires 6 June 2025                 [Page 13]

Internet-Draft           RFC 5280 Clarifications           December 2024


   of various algorithms must be functionally equivalent to the external
   behavior generated by the procedures described in this document.  Any
   algorithm can be used by a specific implementation as long as it
   produces the correct results.  The algorithm described in this
   section defines a set of inputs and processing steps for each
   certificate in the authentication path.  The algorithm output is the
   validity status of the certificate.



     +------------+           +-------------+           +------------+
     | CT client  | request   |     CT      |  query    |            |
     | Browser    |<--------->|   server    |<--------->| Database   |
     |            | response  |             |  response |            |
     +------------+           +-------------+           +------------+

   Figure 3: CT Request/Response Service Mechanism

3.5.1.  CT Inputs

   To support CT status query operations, the algorithm requires three
   inputs:

   1.  certificate: This algorithm requires the SCT list in the
       certificate to determine if the certificate is valid.

   2.  OCSP_response: This algorithm requires the SCT list in OCSP
       Stapling to determine if the certificate is valid.

   3.  ServerHello: The ServerHello message on the server-side in SSL/
       TLS protocol, This algorithm requires the SCT list in the SSL/TLS
       protocol extension to determine whether the certificate is valid.

3.5.2.  Initialization and Revocation State Variables

   To support CT processing, the algorithm requires the following state
   variable:

   1.  cert_datus: This variable contains the status of the certificate.
       This variable can be assigned one of the following values:
       SCT_STATUS_OK, SCT_STATUS_INVALID, and SCT_STATUS_UNNOWN.  This
       variable is initialized to the special value SCT_STATUS_OK.









Liu, et al.                Expires 6 June 2025                 [Page 14]

Internet-Draft           RFC 5280 Clarifications           December 2024


3.5.3.  CT Processing

   Before querying the validity status of the certificate, the algorithm
   assumes that the target certificate is valid, that is, the initial
   value of the variable 'Certificate Status' is SCT_STATUS_OK.  The
   algorithm performs the following operations:

   1.  Analyze and extract the X509v3 extension field
       SignedCertificateTimestampList from the certificate to obtain the
       SCT list related to the certificate; Analyze and extract the
       OCSP_response extension in SSL/TLS protocol, and further extract
       the extension field SignedCertificateTimestampList contained in
       it to obtain the certificate related SCT list; Analyze and
       extract the SSL/TLS protocol extension field
       signed_certificate_timestamp from the ServerHello message sent by
       the server during handshake negotiation to obtain the certificate
       related SCT list.

   2.  As long as any of the above SCT list fields exist, parse and
       validate the SCT list; For each SCT record item, verify its
       record signature.  If the signature is incorrect, the certificate
       is considered invalid, and set the variable "cert_status" to'
       SCT_STATUS_INVALID '; Verify its timestamp,Verify the CT
       signature information contained in the certificate, requiring
       that the certificate must contain 2 SCT data for validity periods
       less than 180 days and 3 SCT data for validity periods greater
       than 180 days, to ensure sufficient transparency in certificate
       issuance; Determine the validity period of the certificate
       through validity, and then verify whether the number of SCTs
       meets the requirements through SCT field information.  If the
       timestamp is not reasonable and has not yet taken effect, it is
       considered that the certificate is invalid.  Set the variable
       "cert_status" to' SCT_STATUS_INVALID '; Otherwise, it is
       considered that the certificate is valid, and the variable
       "cert_status" is set to' SCT_STATUS_OK '; If the relevant log
       server cannot be found locally, set the variable "cert_status"
       to' SCT_STATUS_UNNOWN '.

4.  IANA Considerations

   This memo includes no request to IANA.










Liu, et al.                Expires 6 June 2025                 [Page 15]

Internet-Draft           RFC 5280 Clarifications           December 2024


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
   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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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/info/rfc8174>.

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,
              <https://www.rfc-editor.org/rfc/rfc5280>.

   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
              Infrastructure Online Certificate Status Protocol - OCSP",
              RFC 6960, DOI 10.17487/RFC6960, June 2013,
              <https://www.rfc-editor.org/rfc/rfc6960>.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <https://www.rfc-editor.org/rfc/rfc6962>.

Authors' Addresses




Liu, et al.                Expires 6 June 2025                 [Page 16]

Internet-Draft           RFC 5280 Clarifications           December 2024


   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


   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 6 June 2025                 [Page 17]