HOME   Cart(0)   Quotation   About-Us Tax PDFs Standard-List Powered by Google www.ChineseStandard.net Database: 189759 (27 Oct 2024)

GB/T 19713-2005 PDF in English


GB/T 19713-2005 (GB/T19713-2005, GBT 19713-2005, GBT19713-2005)
Standard IDContents [version]USDSTEP2[PDF] delivered inName of Chinese StandardStatus
GB/T 19713-2005English150 Add to Cart 0-9 seconds. Auto-delivery. Information technology -- Security techniques -- Public key infrastructure -- Online certificate status protocol Valid
Standards related to (historical): GB/T 19713-2005
PDF Preview

GB/T 19713-2005: PDF in English (GBT 19713-2005)

GB/T 19713-2005 NATIONAL STANDARD OF THE PEOPLE’S REPUBLIC OF CHINA ICS 35.100.70 L 79 Information Technology - Security Techniques - Public Key Infrastructure - Online Certificate Status Protocol ISSUED ON: APRIL 19, 2005 IMPLEMENTED ON: OCTOBER 01, 2005 Issued by: General Administration of Quality Supervision, Inspection and Quarantine; Standardization Administration of PRC. Table of Contents Foreword ... 3 1 Scope ... 4 2 Normative References ... 4 3 Terms and Definitions ... 5 4 Abbreviations ... 5 5 General Rules ... 6 5.1 Overview ... 6 5.2 Request ... 6 5.3 Response ... 6 5.4 Anomalies ... 8 5.5 Semantics of thisUpdate, nextUpdate, and producedAt ... 8 5.6 Pre-generated response ... 9 5.7 OCSP signature agency’s commission ... 9 5.8 CA key leakage ... 9 6 Functional Requirements ... 9 6.1 Certificate content ... 9 6.2 Receiving requirements for signature response ... 10 7 Specific Protocol ... 10 7.1 Convention ... 10 7.2 Request ... 10 7.3 Response ... 12 7.4 Mandatory/optional cryptographic algorithms ... 15 7.5 Extension ... 15 8 Security Consideration ... 17 Appendix A (Informative) OCSP on the HTTP ... 19 Appendix B (Normative) OCSP Defined by ASN.1 ... 21 Information Technology - Security Techniques - Public Key Infrastructure - Online Certificate Status Protocol 1 Scope This Standard specifies a mechanism (i.e. Online Certificate Status Protocol - OSCP) for querying the status of a digital certificate without requesting a Certificate Revocation List (CRL). This mechanism can replace CRL or be used as a supplement to periodically check CRL; so that timely get the information about the status of the certificate revocation. This Standard mainly describes as follows: a) Specify the request form for the online certificate status protocol; b) Specify the response form for the online certificate status protocol; c) Analyze various anomalies that may occur when processing response to the online certificate status protocol; d) Illustrate the application of the online certificate status protocol based on the Hypertext Transfer Protocol (HTTP); e) Adopt the Abstract Syntax Notation 1 (ASN.1) to describe the online certificate status protocol. This Standard is applicable to all types of applications and computing environments based on the public key infrastructure. 2 Normative References The provisions in following documents become the provisions of this Standard through reference in this Standard. For dated references, the subsequent amendments (excluding corrigendum) or revisions do not apply to this Standard, however, parties who reach an agreement based on this Standard are encouraged to study if the latest versions of these documents are applicable. For undated references, the latest edition of the referenced document applies. ISO/IEC 8824-1:2002 Abstract Syntax Notation One (ASN.1) – Part 1: Specification of Basic Notation RFC 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile 5 General Rules 5.1 Overview As an alternative or complementary method for periodically checking CRL, OCSP is essential in cases where information about the status of certificate revocation must be obtained in a timely manner. OCSP enables an application to determine the (revocation) status of an identity certificate. OCSP can be used to meet operational requirements that require more timely revocation information than checking CRL; it can also be used to obtain additional status information. The OCSP requester issues a status request to the OCSP responder, defers accepting the certificate to be queried until the responder provides a response. This Standard specifies the data that needs to be exchanged between the application that checks the status of the certificate and the server that provides the certificate status query. 5.2 Request The OCSP request contains the following data: a) The version of the protocol; b) A service request; c) The target certificate identifier; d) The optional extensions that the OCSP responder can handle, such as OCSP requester’s signature, random number. In response to a request, the OCSP responder shall determine: a) Whether the message format is correct; b) Whether the responder is configured with the required service; c) Where the request contains the information needed by the responder. If any of the above conditions are not satisfied, the OCSP responder shall issue an error message; otherwise, an explicit response shall be returned. 5.3 Response The OCSP response can be of different types; the response consists of the two parts: response type and response entity. This Standard only specifies one type of OCSP b) Revoked: indicates that the certificate has been revoked (permanently or temporarily). c) Unknown: indicates that the responder can’t authenticate the certificate to be verified (including OSCP responder certificate and the certificate to be verified are not issued by the same CA). 5.4 Anomalies When an error occurs, the OCSP responder returns an error message. These messages can’t be signed. The error can be the following categories: a) MalformedRequest (incomplete application): the request received by the OCSP responder (server) does not follow the OCSP syntax; b) InternalError: The OCSP responder is in an uncoordinated working state and shall query to another responder again; c) TryLater: The OCSP responder is in running state; can’t return the status of the requested certificate indicating that the required service exists, but temporarily unable to respond; d) SigRequired: The responder requires the requester to sign the request; e) Unauthorized: The query was submitted to the responder by an unauthorized requester. 5.5 Semantics of thisUpdate, nextUpdate, and producedAt Each response can contain three time-fields, namely, thisUpdate, nextUpdate and ProducedAt. The semantics of these fields indicate as follows: a) thisUpdate: this update time; the state that requires to be indicated is correct time; b) nextUpdate: next update time; indicate that certificate state is correct before this time; and the certificate status update information can be obtained again at this time; c) producedAt: the time of issue; the OCSP responder signs the response time. If the nextUpdate is not set, the responder shall indicate that the revocation information for the update is available at any time. Given that OCSP updates the status of certificates in real time; this Standard recommends not setting the field of nextUpdate; thisUpdate is defined as the time at which the CA issues the certificate status; producedAt is the time at which the OCSP issues the response. 6.2 Receiving requirements for signature response a) The OCSP client shall acknowledge that OCSP response before it is considered valid; b) The certificate identified in the response received shall be consistent with the certificate in the request; c) The signature of the responder is valid; d) The responder’s signer identity shall be consistent with the intended receiver of the request; e) The signer has been authorized to sign the response; f) The time (thisUpdate) indicating the status of the certificate shall be the current most recent time; g) If the field nextUpdate is set, then it shall be later than the current time of the client. 7 Specific Protocol 7.1 Convention This Standard uses abstract syntax notation 1 (ASN.1) to describe the specific protocol content; the syntax of ASN.1 refers to some terms defined by RFC 2459; the complete OCSP protocol description is given in Appendix B. The OCSP request format and response format for HTTP are described in RFC 2616 and see Appendix A. For signature calculation, the data to be signed is encoded using the Distinguished Encoding Rules (DER) of ASN.1. If not specified, the default value is the ASN.1 display mark. Other terms cited are: 7.2 Request This Subclause specifies the ASN.1 specification for determining the request. Depending on the used transport mechanism (HTTP, SMTP, LDAP, etc.), the actual message format may change accordingly. 7.2.1 Request syntax or applied to certificate that verifies the response signature. 7.3.2.2.1 Revocation check of the authorized responder Since an authorized authority OCSP responder can provide status information for one or more CAs, the OCSP client needs to know how to check whether the certificate of authorized authority responder has been revoked. CA can choose one of the following three methods to solve this problem: a) The CA can specify that he OCSP client trusts the responder for the entire lifetime of the responder certificate. The CA does this by including the id-pkix-ocsp- nocheck extension in the responder certificate. It shall be a non-critical extension. The extension value shall remain empty. At least for the validity period of the certificate, the CA issuing such a certificate shall recognize that the leakage of the responder key has the same serious consequence with the leakage of the CA key used to sign CRL. The CA can choose to issue a certificate at is short- lived and frequently updated, which is a short-lived certificate. b) The CA can specify how to check whether the responder certificate has been revoked. If using CRLs or CRL distribution points to check, it can be finished by using CRL distribution points; if using other methods to check, it shall use the authority information access (AuthorityInfoAccess extension). A detailed description of these two mechanisms is available in RFC2459. c) The CA may choose not to specify the method to check whether the responder certificate has been revoked. In this case, the local security policy of the OCSP client shall be followed to decide whether to this check. 7.4 Mandatory/optional cryptographic algorithms The client requesting OCSP service shall be able to handle the signed response; the response shall be signed by the DSA key identified by DSA sig-alg-oid (specified in 7.2.2 of RFC2459). The OCSP responder shall support a hash algorithm. When applying domestically, the relevant algorithms approved by the national cryptographic management authority shall be used. 7.5 Extension This Subclause defines some standard extensions; these extensions are based on the extension mode used in the V.3 certificate of X.509(see RFC2459). For the client and responder, the support to all extensions is optional. For each extension, the definition points out the syntax when it is processed by the OCSP responder, and any extensions that are contained in the corresponding response. 7.5.4 Archive deadline The OCSP responder can choose to retain the corresponding revocation information after the certificate expires. The time obtained by subtracting the interval guarantee value from the producedAt time of the response id defined as the “archive deadline” time of the certificate. Even if the certificate for which a valid signature is to be verified expires long ago, the activated OCSP application can use the OCSP archive deadline to provide proof that the digital signature is valid. The OCSP server that provides historical reference support shall include the archive deadline extension in the response packet. If an archive deadline extension is included, this value shall be used as an OCSP singleExtensions extension and shall be identified by the syntax of id-pkix-ocsp-cutoff and Generalized Time. For example, if the operation of the server has a policy with a 7-year retention period, and the value of produceAt [Translator Note: here it should be producedAt] is t1; then the value of ArchiveCutoff in the response is (t1~7 years) 7.5.5 CRL entry extension domain All extensions specified as CRL entry extensions are found in 5.3 of RFC2459. 7.5.6 Service locator An OCSP server might operate in a mode where the server receives a request and forwards the request to an OCSP server that can identify the certificate to be verified. Thus, the serviceLocator request extension is defined. Such extension is included in the request as a singleRequestExtensions. The values of these fields are available from the corresponding fields of the principal certificate. 8 Security Consideration In order to make the service valid, the certificate usage system must connect to the Appendix A (Informative) OCSP on the HTTP This Appendix describes the OCSP request format and OCSP response format that support HTTP. A.1 Request The HTTP-based OCSP requests can be submitted by using the GET or POST methods. In order to make HTTP cache valid, the smaller requests (less than 255 bytes after encoding) can be submitted by using the GET method. If the HTTP cache is not important, or if the request is greater than or equal to 255 bytes, then the request shall be submitted by POST method. When privacy is an important requirement, the HTTP- based OCSP sessions can be secured with TLS/SSL or other underlying protocols. An OCSP request using the GET method is constructed as follows: Where {url} can be obtained from the value of AuthorityInfoAccess or the local configuration of the OCSP client. An OCSP request using the POST method is constructed as follows: Content-Type header has the value: “application/ocsp-request”; while the message body is the DER-encoded binary value of OCSPRequest. This Standard recommends that the implanter only use the POST method, and the POST method can also avoid the trouble caused by the HTTP caching mechanism. The client must sign the request. A.2 Response An HTTP-based OCSP response is defined as follows: Content-Type header has the value: “application/ocsp-response”; Content-Length header shall specify the length of the response; the message body shall be DER- encoded binary value of the OCSPResponse. Other HTTP headers that can’t be recognized by the client may exist in the response and can be ignored. NOTE: Due to business needs, there may be cases where a Party-A user accesses the OCSP service of the Party-B user, and the protocol on the cross-certification can be incorporated into it. For the convenience of implementation, the visitor certificate shall have the issuer’s KeyID, ......
 
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.