As per Relevance of the word explicit, we have this rfc below:
Network Working Group M.
Request for Comments: 2560
Category: Standards Track R.
A.
S.
My
C.
Entrust
June 1999
X.509 Internet Public Key
Online Certificate Status Protocol -
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
1.
This document specifies a protocol useful in determining the
status of a digital certificate without requiring CRLs.
mechanisms addressing PKIX operational requirements are specified
separate documents
An overview of the protocol is provided in section 2.
requirements are specified in section 4. Details of the protocol
in section 5. We cover security issues with the protocol in
6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
syntactic elements and appendix C specifies the mime types for
messages
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document (in uppercase, as shown) are to be interpreted as
in [RFC2119].
Myers, et al. Standards Track [Page 1]
RFC 2560 PKIX OCSP June 1999
2. Protocol
In lieu of or as a supplement to checking against a periodic CRL,
may be necessary to obtain timely information regarding
revocation status of a certificate (cf. [RFC2459], Section 3.3).
Examples include high-value funds transfer or large stock trades
The Online Certificate Status Protocol (OCSP) enables applications
determine the (revocation) state of an identified certificate.
may be used to satisfy some of the operational requirements
providing more timely revocation information than is possible
CRLs and may also be used to obtain additional status information.
OCSP client issues a status request to an OCSP responder and
acceptance of the certificate in question until the
provides a response
This protocol specifies the data that needs to be exchanged
an application checking the status of a certificate and the
providing that status
2.1
An OCSP request contains the following data
-- protocol
-- service
-- target certificate
-- optional extensions which MAY be processed by the OCSP
Upon receipt of a request, an OCSP Responder determines if
1. the message is well
2. the responder is configured to provide the requested service
3. the request contains the information needed by the responder
any one of the prior conditions are not met, the OCSP
produces an error message; otherwise, it returns a
response
2.2
OCSP responses can be of various types. An OCSP response consists
a response type and the bytes of the actual response. There is
basic type of OCSP response that MUST be supported by all
servers and clients. The rest of this section pertains only to
basic response type
Myers, et al. Standards Track [Page 2]
RFC 2560 PKIX OCSP June 1999
All definitive response messages SHALL be digitally signed. The
used to sign the response MUST belong to one of the following
-- the CA who issued the certificate in
-- a Trusted Responder whose public key is trusted by the
-- a CA Designated Responder (Authorized Responder) who holds
specially marked certificate issued directly by the CA,
that the responder may issue OCSP responses for that
A definitive response message is composed of
-- version of the response
-- name of the
-- responses for each of the certificates in a
-- optional
-- signature algorithm
-- signature computed across hash of the
The response for each of the certificates in a request consists
-- target certificate
-- certificate status
-- response validity
-- optional
This specification defines the following definitive
indicators for use in the certificate status value
--
--
--
The "good" state indicates a positive response to the status inquiry
At a minimum, this positive response indicates that the
is not revoked, but does not necessarily mean that the
was ever issued or that the time at which the response was
is within the certificate's validity interval. Response
may be used to convey additional information on assertions made
the responder regarding the status of the certificate such
positive statement about issuance, validity, etc
The "revoked" state indicates that the certificate has been
(either permanantly or temporarily (on hold)).
The "unknown" state indicates that the responder doesn't know
the certificate being requested
Myers, et al. Standards Track [Page 3]
RFC 2560 PKIX OCSP June 1999
2.3 Exception
In case of errors, the OCSP Responder may return an error message
These messages are not signed. Errors can be of the following types
--
--
--
--
--
A server produces the "malformedRequest" response if the
received does not conform to the OCSP syntax
The response "internalError" indicates that the OCSP
reached an inconsistent internal state. The query should be retried
potentially with another responder
In the event that the OCSP responder is operational, but unable
return a status for the requested certificate, the "tryLater
response can be used to indicate that the service exists, but
temporarily unable to respond
The response "sigRequired" is returned in cases where the
requires the client sign the request in order to construct
response
The response "unauthorized" is returned in cases where the client
not authorized to make this query to this server
2.4 Semantics of thisUpdate, nextUpdate and
Responses can contain three times in them - thisUpdate,
and producedAt. The semantics of these fields are
- thisUpdate: The time at which the status being indicated is
to be
- nextUpdate: The time at or before which newer information will
available about the status of the
- producedAt: The time at which the OCSP responder signed
response
If nextUpdate is not set, the responder is indicating that
revocation information is available all the time
Myers, et al. Standards Track [Page 4]
RFC 2560 PKIX OCSP June 1999
2.5 Response Pre-
OCSP responders MAY pre-produce signed responses specifying
status of certificates at a specified time. The time at which
status was known to be correct SHALL be reflected in the
field of the response. The time at or before which newer
will be available is reflected in the nextUpdate field, while
time at which the response was produced will appear in the
field of the response
2.6 OCSP Signature Authority
The key that signs a certificate's status information need not be
same key that signed the certificate. A certificate's
explicitly delegates OCSP signing authority by issuing a
containing a unique value for extendedKeyUsage in the OCSP signer'
certificate. This certificate MUST be issued directly to
responder by the cognizant CA
2.7 CA Key
If an OCSP responder knows that a particular CA's private key
been compromised, it MAY return the revoked state for
certificates issued by that CA
3. Functional
3.1 Certificate
In order to convey to OCSP clients a well-known point of
access, CAs SHALL provide the capability to include
AuthorityInfoAccess extension (defined in [RFC2459], section 4.2.2.1)
in certificates that can be checked using OCSP. Alternatively,
accessLocation for the OCSP provider may be configured locally at
OCSP client
CAs that support an OCSP service, either hosted locally or
by an Authorized Responder, MUST provide for the inclusion of a
for a uniformResourceIndicator (URI) accessLocation and the OID
id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE
The value of the accessLocation field in the subject
defines the transport (e.g. HTTP) used to access the OCSP
and may contain other transport dependent information (e.g. a URL).
Myers, et al. Standards Track [Page 5]
RFC 2560 PKIX OCSP June 1999
3.2 Signed Response Acceptance
Prior to accepting a signed response as valid, OCSP clients
confirm that
1. The certificate identified in a received response corresponds
that which was identified in the corresponding request
2. The signature on the response is valid
3. The identity of the signer matches the intended recipient of
request
4. The signer is currently authorized to sign the response
5. The time at which the status being indicated is known to
correct (thisUpdate) is sufficiently recent
6. When available, the time at or before which newer information
be available about the status of the certificate (nextUpdate)
greater than the current time
4. Detailed
The ASN.1 syntax imports terms defined in [RFC2459]. For
calculation, the data to be signed is encoded using the ASN.1
distinguished encoding rules (DER) [X.690].
ASN.1 EXPLICIT tagging is used as a default unless
otherwise
The terms imported from elsewhere are: Extensions
CertificateSerialNumber, SubjectPublicKeyInfo, Name
AlgorithmIdentifier,
4.1
This section specifies the ASN.1 specification for a
request. The actual formatting of the message could vary depending
the transport mechanism used (HTTP, SMTP, LDAP, etc.).
4.1.1 Request
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
Myers, et al. Standards Track [Page 6]
RFC 2560 PKIX OCSP June 1999
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL
requestList SEQUENCE OF Request
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier
signature BIT STRING
certs [0] EXPLICIT SEQUENCE OF
OPTIONAL
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
issuerNameHash OCTET STRING, -- Hash of Issuer's
issuerKeyHash OCTET STRING, -- Hash of Issuers public
serialNumber CertificateSerialNumber }
issuerNameHash is the hash of the Issuer's distinguished name.
hash shall be calculated over the DER encoding of the issuer's
field in the certificate being checked. issuerKeyHash is the hash
the Issuer's public key. The hash shall be calculated over the
(excluding tag and length) of the subject public key field in
issuer's certificate. The hash algorithm used for both these hashes
is identified in hashAlgorithm. serialNumber is the serial number
the certificate for which status is being requested
4.1.2 Notes on the Request
The primary reason to use the hash of the CA's public key in
to the hash of the CA's name, to identify the issuer, is that it
possible that two CAs may choose to use the same Name (uniqueness
the Name is a recommendation that cannot be enforced). Two CAs
never, however, have the same public key unless the CAs
explicitly decided to share their private key, or the key of one
the CAs was compromised
Support for any specific extension is OPTIONAL. The critical
SHOULD NOT be set for any of them. Section 4.4 suggests
useful extensions. Additional extensions MAY be defined
additional RFCs. Unrecognized extensions MUST be ignored (unless
have the critical flag set and are not understood).
Myers, et al. Standards Track [Page 7]
RFC 2560 PKIX OCSP June 1999
The requestor MAY choose to sign the OCSP request. In that case,
signature is computed over the tbsRequest structure. If the
is signed, the requestor SHALL specify its name in the
field. Also, for signed requests, the requestor MAY
certificates that help the OCSP responder verify the requestor'
signature in the certs field of Signature
4.2 Response
This section specifies the ASN.1 specification for a
response. The actual formatting of the message could vary
on the transport mechanism used (HTTP, SMTP, LDAP, etc.).
4.2.1 ASN.1 Specification of the OCSP
An OCSP response at a minimum consists of a responseStatus
indicating the processing status of the prior request. If the
of responseStatus is one of the error conditions, responseBytes
not set
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), --Response has valid
malformedRequest (1), --Illegal confirmation
internalError (2), --Internal error in
tryLater (3), --Try again
--(4) is not
sigRequired (5), --Must sign the
unauthorized (6) --Request
}
The value for responseBytes consists of an OBJECT IDENTIFIER and
response syntax identified by that OID encoded as an OCTET STRING
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER
response OCTET STRING }
For a basic OCSP responder, responseType will be id-pkix-ocsp-basic
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
Myers, et al. Standards Track [Page 8]
RFC 2560 PKIX OCSP June 1999
OCSP responders SHALL be capable of producing responses of the id
pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL
capable of receiving and processing responses of the id-pkix-ocsp
basic response type
The value for response SHALL be the DER encoding
BasicOCSPResponse
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData
signatureAlgorithm AlgorithmIdentifier
signature BIT STRING
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
The value for signature SHALL be computed on the hash of the
encoding ResponseData
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID
producedAt GeneralizedTime
responses SEQUENCE OF SingleResponse
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
ResponderID ::= CHOICE {
byName [1] Name
byKey [2] KeyHash }
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public
(excluding the tag and length fields
SingleResponse ::= SEQUENCE {
certID CertID
certStatus CertStatus
thisUpdate GeneralizedTime
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL
singleExtensions [1] EXPLICIT Extensions OPTIONAL }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL
revoked [1] IMPLICIT RevokedInfo
unknown [2] IMPLICIT UnknownInfo }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
UnknownInfo ::= NULL -- this can be replaced with an
Myers, et al. Standards Track [Page 9]
RFC 2560 PKIX OCSP June 1999
4.2.2 Notes on OCSP
4.2.2.1
The thisUpdate and nextUpdate fields define a recommended
interval. This interval corresponds to the {thisUpdate, nextUpdate
interval in CRLs. Responses whose nextUpdate value is earlier
the local system time value SHOULD be considered unreliable
Responses whose thisUpdate time is later than the local system
SHOULD be considered unreliable. Responses where the nextUpdate
is not set are equivalent to a CRL with no time for nextUpdate (
Section 2.4).
The producedAt time is the time at which this response was signed
4.2.2.2 Authorized
The key that signs a certificate's status information need not be
same key that signed the certificate. It is necessary however
ensure that the entity signing this information is authorized to
so. Therefore, a certificate's issuer MUST either sign the
responses itself or it MUST explicitly designate this authority
another entity. OCSP signing delegation SHALL be designated by
inclusion of id-kp-OCSPSigning in an extendedKeyUsage
extension included in the OCSP response signer's certificate.
certificate MUST be issued directly by the CA that issued
certificate in question
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
Systems or applications that rely on OCSP responses MUST be
of detecting and enforcing use of the id-ad-ocspSigning value
described above. They MAY provide a means of locally configuring
or more OCSP signing authorities, and specifying the set of CAs
which each signing authority is trusted. They MUST reject
response if the certificate required to validate the signature on
response fails to meet at least one of the following criteria
1. Matches a local configuration of OCSP signing authority for
certificate in question;
2. Is the certificate of the CA that issued the certificate
question;
3. Includes a value of id-ad-ocspSigning in an
extension and is issued by the CA that issued the certificate
question."
Myers, et al. Standards Track [Page 10]
RFC 2560 PKIX OCSP June 1999
Additional acceptance or rejection criteria may apply to either
response itself or to the certificate used to validate the
on the response
4.2.2.2.1 Revocation Checking of an Authorized
Since an Authorized OCSP responder provides status information
one or more CAs, OCSP clients need to know how to check that
authorized responder's certificate has not been revoked. CAs
choose to deal with this problem in one of three ways
- A CA may specify that an OCSP client can trust a responder for
lifetime of the responder's certificate. The CA does so by
the extension id-pkix-ocsp-nocheck. This SHOULD be a non-
extension. The value of the extension should be NULL. CAs
such a certificate should realized that a compromise of
responder's key, is as serious as the compromise of a CA key used
sign CRLs, at least for the validity period of this certificate. CA'
may choose to issue this type of certificate with a very
lifetime and renew it frequently
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
- A CA may specify how the responder's certificate be checked
revocation. This can be done using CRL Distribution Points if
check should be done using CRLs or CRL Distribution Points,
Authority Information Access if the check should be done in
other way. Details for specifying either of these two mechanisms
available in [RFC2459].
- A CA may choose not to specify any method of revocation
for the responder's certificate, in which case, it would be up to
OCSP client's local security policy to decide whether
certificate should be checked for revocation or not
4.3 Mandatory and Optional Cryptographic
Clients that request OCSP services SHALL be capable of
responses signed used DSA keys identified by the DSA sig-alg-
specified in section 7.2.2 of [RFC2459]. Clients SHOULD also
capable of processing RSA signatures as specified in section 7.2.1
[RFC2459]. OCSP responders SHALL support the SHA1 hashing algorithm
4.4
This section defines some standard extensions, based on the
model employed in X.509 version 3 certificates see [RFC2459].
for all extensions is optional for both clients and responders.
Myers, et al. Standards Track [Page 11]
RFC 2560 PKIX OCSP June 1999
each extension, the definition indicates its syntax,
performed by the OCSP Responder, and any extensions which
included in the corresponding response
4.4.1
The nonce cryptographically binds a request and a response to
replay attacks. The nonce is included as one of the
in requests, while in responses it would be included as one of
responseExtensions. In both the request and the response, the
will be identified by the object identifier id-pkix-ocsp-nonce,
the extnValue is the value of the nonce
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
4.4.2 CRL
It may be desirable for the OCSP responder to indicate the CRL
which a revoked or onHold certificate is found. This can be
where OCSP is used between repositories, and also as an
mechanism. The CRL may be specified by a URL (the URL at which
CRL is available), a number (CRL number) or a time (the time at
the relevant CRL was created). These extensions will be specified
singleExtensions. The identifier for this extension will be id-pkix
ocsp-crl, while the value will be CrlID
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL
crlNum [1] EXPLICIT INTEGER OPTIONAL
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
For the choice crlUrl, the IA5String will specify the URL at
the CRL is available. For crlNum, the INTEGER will specify the
of the CRL number extension of the relevant CRL. For crlTime,
GeneralizedTime will indicate the time at which the relevant CRL
issued
4.4.3 Acceptable Response
An OCSP client MAY wish to specify the kinds of response types
understands. To do so, it SHOULD use an extension with the OID id
pkix-ocsp-response, and the value AcceptableResponses.
extension is included as one of the requestExtensions in requests
The OIDs included in AcceptableResponses are the OIDs of the
response types this client can accept (e.g., id-pkix-ocsp-basic).
Myers, et al. Standards Track [Page 12]
RFC 2560 PKIX OCSP June 1999
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
AcceptableResponses ::= SEQUENCE OF OBJECT
As noted in section 4.2.1, OCSP responders SHALL be capable
responding with responses of the id-pkix-ocsp-basic response type
Correspondingly, OCSP clients SHALL be capable of receiving
processing responses of the id-pkix-ocsp-basic response type
4.4.4 Archive
An OCSP responder MAY choose to retain revocation information
a certificate's expiration. The date obtained by subtracting
retention interval value from the producedAt time in a response
defined as the certificate's "archive cutoff" date
OCSP-enabled applications would use an OCSP archive cutoff date
contribute to a proof that a digital signature was (or was not
reliable on the date it was produced even if the certificate
to validate the signature has long since expired
OCSP servers that provide support for such historical
SHOULD include an archive cutoff date extension in responses.
included, this value SHALL be provided as an OCSP
extension identified by id-pkix-ocsp-archive-cutoff and of
GeneralizedTime
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
ArchiveCutoff ::=
To illustrate, if a server is operated with a 7-year
interval policy and status was produced at time t1 then the value
ArchiveCutoff in the response would be (t1 - 7 years).
4.4.5 CRL Entry
All the extensions specified as CRL Entry Extensions - in Section 5.3
of [RFC2459] - are also supported as singleExtensions
4.4.6 Service
An OCSP server may be operated in a mode whereby the server
a request and routes it to the OCSP server which is known to
authoritative for the identified certificate. The
request extension is defined for this purpose. This extension
included as one of the singleRequestExtensions in requests
Myers, et al. Standards Track [Page 13]
RFC 2560 PKIX OCSP June 1999
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
ServiceLocator ::= SEQUENCE {
issuer Name
locator AuthorityInfoAccessSyntax OPTIONAL }
Values for these fields are obtained from the corresponding fields
the subject certificate
5. Security
For this service to be effective, certificate using systems
connect to the certificate status service provider. In the event
a connection cannot be obtained, certificate-using systems
implement CRL processing logic as a fall-back position
A denial of service vulnerability is evident with respect to a
of queries. The production of a cryptographic signature
affects response generation cycle time, thereby exacerbating
situation. Unsigned error responses open up the protocol to
denial of service attack, where the attacker sends false
responses
The use of precomputed responses allows replay attacks in which
old (good) response is replayed prior to its expiration date
after the certificate has been revoked. Deployments of OCSP
carefully evaluate the benefit of precomputed responses against
probability of a replay attack and the costs associated with
successful execution
Requests do not contain the responder they are directed to.
allows an attacker to replay a request to any number of
responders
The reliance of HTTP caching in some deployment scenarios may
in unexpected results if intermediate servers are
configured or are known to possess cache management faults
Implementors are advised to take the reliability of HTTP
mechanisms into account when deploying OCSP over HTTP
Myers, et al. Standards Track [Page 14]
RFC 2560 PKIX OCSP June 1999
6.
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "
X.509 Public Key Infrastructure Certificate and
Profile", RFC 2459, January 1999.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
2068, January 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[URL] Berners-Lee, T., Masinter, L. and M. McCahill, "
Resource Locators (URL)", RFC 1738, December 1994.
[X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995,
Information Technology - ASN.1 encoding rules
Specification of Basic Encoding Rules (BER),
Encoding Rules (CER) and Distinguished Encoding
(DER).
Myers, et al. Standards Track [Page 15]
RFC 2560 PKIX OCSP June 1999
7. Authors'
Michael
VeriSign, Inc
1350 Charleston
Mountain View, CA 94043
EMail: mmyers@verisign.
Rich
CertCo,
13506 King Charles Dr
Chantilly, VA 20151
EMail: rankney@erols.
Ambarish
ValiCert, Inc
1215 Terra Bella Ave
Mountain View, CA 94043
Phone: 650.567.5457
EMail: ambarish@valicert.
Slava
My CFO, Inc
1945 Charleston
Mountain View,
EMail: galperin@mycfo.
Carlisle
Entrust
750 Heron Road, Suite E08
Ottawa,
K1V 1A
EMail: cadams@entrust.
Myers, et al. Standards Track [Page 16]
RFC 2560 PKIX OCSP June 1999
Appendix A
A.1 OCSP over
This section describes the formatting that will be done to
request and response to support HTTP
A.1.1
HTTP based OCSP requests can use either the GET or the POST method
submit their requests. To enable HTTP caching, small requests (
after encoding are less than 255 bytes), MAY be submitted using GET
If HTTP caching is not important, or the request is greater than 255
bytes, the request SHOULD be submitted using POST. Where privacy
a requirement, OCSP transactions exchanged using HTTP MAY
protected using either TLS/SSL or some other lower layer protocol
An OCSP request using the GET method is constructed as follows
GET {url}/{url-encoding of base-64 encoding of the DER encoding
the OCSPRequest
where {url} may be derived from the value of AuthorityInfoAccess
other 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"
the body of the message is the binary value of the DER encoding
the OCSPRequest
A.1.2
An HTTP-based OCSP response is composed of the appropriate
headers, followed by the binary value of the DER encoding of
OCSPResponse. The Content-Type header has the
"application/ocsp-response". The Content-Length header SHOULD
the length of the response. Other HTTP headers MAY be present and
be ignored if not understood by the requestor
Myers, et al. Standards Track [Page 17]
RFC 2560 PKIX OCSP June 1999
Appendix B. OCSP in ASN.1
OCSP DEFINITIONS EXPLICIT TAGS::=
-- Directory Authentication Framework (X.509)
Certificate, AlgorithmIdentifier,
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 }
-- PKIX Certificate
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
Name, GeneralName, CertificateSerialNumber, Extensions
id-kp, id-ad-
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)};
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL
requestList SEQUENCE OF Request
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier
signature BIT STRING
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
Myers, et al. Standards Track [Page 18]
RFC 2560 PKIX OCSP June 1999
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
issuerNameHash OCTET STRING, -- Hash of Issuer's
issuerKeyHash OCTET STRING, -- Hash of Issuers public
serialNumber CertificateSerialNumber }
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), --Response has valid
malformedRequest (1), --Illegal confirmation
internalError (2), --Internal error in
tryLater (3), --Try again
--(4) is not
sigRequired (5), --Must sign the
unauthorized (6) --Request
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER
response OCTET STRING }
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData
signatureAlgorithm AlgorithmIdentifier
signature BIT STRING
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID
producedAt GeneralizedTime
responses SEQUENCE OF SingleResponse
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
ResponderID ::= CHOICE {
byName [1] Name
byKey [2] KeyHash }
KeyHash ::= OCTET STRING --SHA-1 hash of responder's public
--(excluding the tag and length fields
SingleResponse ::= SEQUENCE {
certID CertID
certStatus CertStatus
thisUpdate GeneralizedTime
Myers, et al. Standards Track [Page 19]
RFC 2560 PKIX OCSP June 1999
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL
singleExtensions [1] EXPLICIT Extensions OPTIONAL }
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL
revoked [1] IMPLICIT RevokedInfo
unknown [2] IMPLICIT UnknownInfo }
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
UnknownInfo ::= NULL -- this can be replaced with an
ArchiveCutoff ::=
AcceptableResponses ::= SEQUENCE OF OBJECT
ServiceLocator ::= SEQUENCE {
issuer Name
locator AuthorityInfoAccessSyntax }
-- Object
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
Myers, et al. Standards Track [Page 20]
RFC 2560 PKIX OCSP June 1999
Appendix C. MIME
C.1 application/ocsp-
To: ietf-types@iana.
Subject: Registration of MIME media type application/ocsp-
MIME media type name:
MIME subtype name: ocsp-
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations: Carries a request for information.
request may optionally be cryptographically signed
Interoperability considerations:
Published specification: IETF PKIX Working Group Draft on
Certificate Status Protocol -
Applications which use this media type: OCSP
Additional information
Magic number(s):
File extension(s): .
Macintosh File Type Code(s):
Person & email address to contact for further information
Ambarish Malpani
Intended usage:
Author/Change controller
Ambarish Malpani
C.2 application/ocsp-
To: ietf-types@iana.
Subject: Registration of MIME media type application/ocsp-
MIME media type name:
Myers, et al. Standards Track [Page 21]
RFC 2560 PKIX OCSP June 1999
MIME subtype name: ocsp-
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations: Carries a cryptographically signed
Interoperability considerations:
Published specification: IETF PKIX Working Group Draft on
Certificate Status Protocol -
Applications which use this media type: OCSP
Additional information
Magic number(s):
File extension(s): .
Macintosh File Type Code(s):
Person & email address to contact for further information
Ambarish Malpani
Intended usage:
Author/Change controller
Ambarish Malpani
Myers, et al. Standards Track [Page 22]
RFC 2560 PKIX OCSP June 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Myers, et al. Standards Track [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
