GB/T 19713-2005 PDF in English
GB/T 19713-2005 (GB/T19713-2005, GBT 19713-2005, GBT19713-2005)
Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
GB/T 19713-2005 | English | 150 |
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.
|