INTERNET-DRAFT D. Pinkas
Intended Status: Proposed Standard Bull SAS
Obsoletes: 2560, 6277 (if approved)
Expires: March 24, 2013 September 25, 2012
X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
draft-pinkas-rfc2560bis-03
Abstract
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents. This document obsoletes RFC 2560 and RFC 6277.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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.
Denis Pinkas Expires March 24, 2013 [Page 1]
INTERNET DRAFT PKIX OCSP September 25, 2012
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 Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Exception Cases . . . . . . . . . . . . . . . . . . . . . . 10
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 10
3.1. Requirements for certificate content . . . . . . . . . . . 10
3.1.1. Target certificate content . . . . . . . . . . . . . . 10
3.1.2. OCSP certificate content . . . . . . . . . . . . . . . 11
3.1.3. CA certificate content . . . . . . . . . . . . . . . . 11
3.2. Requirements for CAs supporting directly an OCSP service . 11
3.3. Requirements for CAs using OCSP Responders . . . . . . . . 11
3.3.1. Designation of a new OCSP Responder . . . . . . . . . . 11
3.3.2. CA key rollover . . . . . . . . . . . . . . . . . . . . 12
3.3.3. OCSP Responder key rollover . . . . . . . . . . . . . . 12
3.4. Requirements for OCSP clients . . . . . . . . . . . . . . . 13
4. Detailed Protocol . . . . . . . . . . . . . . . . . . . . . . .13
4.1. Request Syntax . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Response Syntax . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Processing of requests and responses . . . . . . . . . . . 18
4.3.1. Request processing by OCSP servers . . . . . . . . . . 18
4.3.1.1. Processing by a CA acting as an OCSP responder . . 18
4.3.1.2. Processing by an OCSP Responder . . . . . . . . . . 20
4.3.1.3. Processing by a locally trusted Responder . . . . . 21
4.3.2. Response processing by an OCSP client . . . . . . . . . 23
4.4. Mandatory and Optional Cryptographic Algorithms . . . . . . 26
4.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.5.2. CRL References . . . . . . . . . . . . . . . . . . . . 27
4.5.3. Acceptable Response Types . . . . . . . . . . . . . . . 27
4.5.4. Archive Cutoff . . . . . . . . . . . . . . . . . . . . 28
4.5.5. CRL Entry Extensions . . . . . . . . . . . . . . . . . 28
4.5.6. Service Locator . . . . . . . . . . . . . . . . . . . . 28
4.5.7. Preferred Signature Algorithms . . . . . . . . . . . . 29
4.5.7.1. Extension Syntax . . . . . . . . . . . . . . . . . 30
4.5.7.2. Responder Signature Algorithm Selection . . . . . . 30
4.5.7.2.1. Dynamic Response . . . . . . . . . . . . . . . 31
4.5.7.2.2. Static Response . . . . . . . . . . . . . . . . 31
Denis Pinkas Expires March 24, 2013 [Page 2]
INTERNET DRAFT PKIX OCSP September 25, 2012
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 31
5.1. Denial of service attack using false error responses . . . 31
5.2. Using CRLs as a fall-back mechanism . . . . . . . . . . . . 31
5.3. Different results when using OCSP and CRLs . . . . . . . . 32
5.4. Denial of service attack using a flood of queries . . . . . 32
5.5. Use of precomputed responses . . . . . . . . . . . . . . . 32
5.6. Preferred Signature Algorithms . . . . . . . . . . . . . . 33
5.6.1. Use of insecure algorithms . . . . . . . . . . . . . . 33
5.6.2. Man in the Middle Downgrade Attack . . . . . . . . . . 33
5.6.3. Denial of Service Attack . . . . . . . . . . . . . . . 34
5.7. Other replay attacks . . . . . . . . . . . . . . . . . . . 34
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 34
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1. Normative References . . . . . . . . . . . . . . . . . . . 34
7.2. Informative References . . . . . . . . . . . . . . . . . . 35
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.1 OCSP over HTTP . . . . . . . . . . . . . . . . . . . . . . . 36
A.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . . 36
A.1.2. Response . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 37
B.1. OCSP module which conforms to the 1988 syntax of ASN.1 . . 37
B.2. OCSP module which conforms to the 2002 syntax of ASN.1 . . 40
B.3. Preferred Signature Algorithms ASN.1 . . . . . . . . . . . 44
B.3.1. ASN.1 module using the 2002 syntax . . . . . . . . . . 44
B.3.2. ASN.1 module using the 1988 syntax . . . . . . . . . . 45
Appendix C. MIME registrations . . . . . . . . . . . . . . . . . . 45
C.1. application/ocsp-request . . . . . . . . . . . . . . . . . 46
C.2. application/ocsp-response . . . . . . . . . . . . . . . . . 46
Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 47
Denis Pinkas Expires March 24, 2013 [Page 3]
INTERNET DRAFT PKIX OCSP September 25, 2012
1. Introduction
This document specifies an on line protocol able to provide the
revocation status of a digital certificate. It also specifies
requirements for the entities concerned with this protocol:
OCSP clients, OCSP servers and CAs making use of OCSP servers.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This specification obsoletes [RFC2560] and [RFC6277]. The primary
reason for the publication of this document is to address ambiguities
that have been found since the publication of RFC 2560.
This document differs from RFC 2560 in the following areas:
All over the document the term "OCSP Responder" (with a capital R)
indicates an OCSP server which has received a delegation from at
least one CA and which has obtained at least one OCSP certificate,
whereas the terms "OCSP server" and "OCSP responder" are used to
designate either a CA providing itself an OCSP service or an OCSP
Responder.
The term "locally trusted Responder" is used to designate an OCSP
responder that is trusted by an OCSP client using local rules.
o Section 2 has been rephrased to indicate that the response may
provide fresher status than CRLs, but not necessarily.
o Section 2.1 has been rephrased to indicate that the request
may contain one or more target certificate identifiers.
o Section 2.2 has been rephrased, in particular to indicate that
the key used to sign an OCSP response MUST be either the key
from a CA or the key from an OCSP Responder. In the later
case, the certificate(s) issued to the OCSP Responder MUST be
directly issued by the CA that has issued a target certificate
and under the same key that was used to sign the target
certificate. In both cases, the validity of the signature over
the OCSP response MUST be evaluated for each target
certificate.
o Section 2.3 extends the use of the "unauthorized" error
response, as specified in [RFC5019].
o Section 2.4 has been removed and its material has been
incorporated into section 4.2.
o Section 2.5 has been removed and its material has been
incorporated at the end of section 4.2.
Denis Pinkas Expires March 24, 2013 [Page 4]
INTERNET DRAFT PKIX OCSP September 25, 2012
o Section 2.6 has been removed and its material has been
incorporated at the end of section 2.2.
o Section 2.7 has been removed since it did not solved the
issue of a CA key compromise correctly: the verification of
the certification path is the right way to solve the issue
and is in the usual procedure.
o Section 3 was only addressing the content of a target
certificate and signed response acceptance requirements. It
has been expanded to specify the content of a target
certificate, of an OCSP certificate and of a CA certificate.
It now addresses requirements for CAs with a locally hosted
OCSP service as well as with OCSP Responders. It addresses the
ways to perform key rollovers.
o Section 3 adds a requirement for an OCSP client to verify that
the current time is within the validity period of the target
certificate.
o Section 4.1 gathers text that was spread around RFC 2560 and
now details every parameter from the ASN.1 syntax.
o Section 4.1.2 has been incorporated into section 4.1.
o Section 4.2 gathers text that was spread around RFC 2560 and
now details every parameter from the ASN.1 syntax.
o Sections 4.2.1 and 4.2.2 have been incorporated into
section 4.2.
o Section 4.2 adds a requirement for the OCSP server to include
OCSP certificates in the certs field of BasicOCSPResponse when
the OCSP server is an authorized OCSP Responder.
o Section 4.2 specifies that the local system time is the local
UTC time.
o Section 4.2 states that a response may include revocation
status information for certificates that were not included in
the request, as permitted in [RFC5019].
o Section 4.3 has been remodeled to detail the processing of an
OCSP request and the construction of an OCSP response by an
OCSP server acting as an OCSP responder and by an OCSP
Responder, and the processing in three steps of an OCSP
response by an OCSP client or by a verifier.
o Section 4.3 addresses the verification of an OCSP response
both at the current time and at a time in the past.
Denis Pinkas Expires March 24, 2013 [Page 5]
INTERNET DRAFT PKIX OCSP September 25, 2012
o Section 4.3 changes the set of cryptographic algorithms that
clients MUST support and the set of cryptographic algorithms
that clients SHOULD support as specified in [RFC6277].
o Section 4.3.2 now indicates that the value of the nocheck
extension SHALL be NULL.
o Section 4.5.1 specifies the ASN.1 syntax for the nonce
extension, which was missing in RFC 2560.
o Section 4.5.7 incorporates the text which was originally
present in [RFC6277] and specifies an extension that may be
included in a request message to specify signature algorithms
the client would prefer the server use to sign the response.
o Section 5 adds a new warning: the root used by an OCSP
Responder to verified published CRLs is not necessarily the
same as the one that would be used by the OCSP client if it
were going to verify the CRLs itself. Hence the revocation
status may not be identical in both cases.
o Section 5 is now addressing a technique to limit a flood of
queries when a large number of certificates is supported by
the same OCSP Responder.
o Section 5 provides an alternative for archival applications
when the algorithm used to sign an OCSP request becomes weak:
the use of time-stamping.
o Annex B includes a new ASN.1 module using the 1988 syntax
since the syntax of nonce had been omitted. It also includes
a new ASN.1 module using the 2002 syntax since in the ASN.1
module which may be found in Section 4 of RFC5912 the nocheck
extension had been omitted.
An overview of the protocol is provided in section 2. Functional
requirements are specified in section 3. Details of the protocol
are in section 4. Security issues with the protocol are covered in
section 5. Appendix A defines OCSP over HTTP, appendix B
accumulates ASN.1 syntactic elements and appendix C specifies the
mime types for the messages.
Denis Pinkas Expires March 24, 2013 [Page 6]
INTERNET DRAFT PKIX OCSP September 25, 2012
2. Protocol Overview
The Online Certificate Status Protocol (OCSP) is a client-server
protocol which enables applications to obtain the revocation status
of one or more certificates either "good", "revoked", or "unknown".
The revocation status may be provided by the server either using a
real time access to a database of issued certificates, or using a
batch access to a database of issued certificates, or using a
real time access to a database of revocation statuses of issued
certificates, or using a batch access to a database of revocation
statuses of issued certificates, or using CRLs, or using a
combination of base CRLs and delta CRLs.
In the first case, it is possible to obtain timely revocation status
information, whereas in the other cases, the freshness of the
revocation status is not better than the mechanisms it is based on.
OCSP may also provide additional status information using
extensions.
When using OCSP, an OCSP client issues a certificate revocation
status request to an OCSP responder for one or more certificates and
then suspends acceptance of the certificate(s) in question until
the responder provides a response.
This document specifies the data that needs to be exchanged between
an application checking the status of a certificate and the server
providing that status. The document also specifies requirements for
CAs using OCSP servers, for OCSP clients and for OCSP servers.
2.1. Request
An OCSP request contains the following data:
-- a protocol version,
-- a service request,
-- one or more target certificate identifiers, and
-- optional extensions which MAY be processed by the OCSP server.
An OCSP request MAY be signed.
2.2. Response
Upon receipt of a request, an OCSP server determines if:
1. the message is well formed,
2. the OCSP responder is configured to provide the requested
service, and
3. the request contains the information needed by the responder.
Denis Pinkas Expires March 24, 2013 [Page 7]
INTERNET DRAFT PKIX OCSP September 25, 2012
If any one of the prior conditions is not met, the OCSP server
produces an error message; otherwise, it returns a definitive
response.
OCSP responses can be of various types. An OCSP response consists
of a response type and the bytes of the actual response. There is
one basic type of OCSP response that MUST be supported by all OCSP
servers and clients. The rest of this document pertains only to
this basic response type.
All definitive response messages SHALL be digitally signed.
A response message MUST be signed either by a certificate's issuer,
by an authorized OCSP Responder or according to local rules.
In the first case, the CA MUST use the same key as the one that was
used to issue the target certificate.
In the second case, the CA MUST explicitly designate the OCSP
Responder by issuing an OCSP certificate to the OCSP Responder.
OCSP signing delegation SHALL be indicated by the inclusion of
id-kp-OCSPSigning in an extendedKeyUsage certificate extension
included in the OCSP response signer's certificate. This
certificate MUST be issued directly by the CA and under the same key
that was used to issue the target certificate.
For these two cases, systems or applications that rely on OCSP
responses MUST be capable of detecting and enforcing use of the
id-ad-ocspSigning value as described above.
In the third case, the OCSP client uses a locally trusted Responder.
The key used to sign OCSP responses may be directly trusted or be a
key contained in an OCSP certificate which is verified according to
local rules, instead of the rules detailed in this document.
A definitive response message is composed of:
-- the version of the response syntax,
-- an identifier of the OCSP server,
-- the time at which the response was produced,
-- single responses for each of the target certificates,
-- optional extensions,
-- the signature algorithm OID,
-- the signature computed across hash of the response, and
-- optional certificates.
The single response for each of the target certificates in a request
consists of:
-- a target certificate identifier,
-- the certificate status value (good, revoked or unknown),
-- the response validity interval, and
-- optional extensions.
Denis Pinkas Expires March 24, 2013 [Page 8]
INTERNET DRAFT PKIX OCSP September 25, 2012
The purpose of the identifier of the OCSP server is to allow OCSP
clients to find whether the definitive response was signed by a CA
or by an OCSP Responder.
The identifier of the OCSP server SHOULD either be the name or the
key from a CA, or the name or the key from a OCSP Responder.
Unless there exist local rules (which are outside the scope of this
document) for verifying that a single response is correctly signed,
the following applies:
When the identifier matches with the name of the CA which has issued
the target certificate or corresponds to the key used to issue the
target certificate, then a single response is correctly signed
only if the digital signature of the OCSP response is valid using the
key used to sign the target certificate.
When the identifier does not match with the name of the CA which has
issued the target certificate or does not correspond to the key used
to issue the target certificate, then an single response is correctly
signed only if :
(a) there exists in the response an OCSP certificate issued by
the CA which has issued the target certificate which is
signed by the same key as the one used to issue the
target certificate, and
(b) the digital signature of the OCSP response is valid using
the subjectPublicKey contained in this OCSP certificate.
This specification defines the following definitive response
indicators for use in the certificate status value:
-- good,
-- revoked, or
-- unknown.
The "good" status indicates a positive response to the status
inquiry. At a minimum, this positive response indicates that the
certificate is not revoked, but does not necessarily mean that the
certificate was ever issued or that the time at which the response
was produced is within the certificate's validity interval.
Response extensions may be used to convey additional information on
assertions made by the server regarding the status of the
certificate such as positive statement about issuance, validity,
etc.
The "revoked" status indicates that the certificate has been revoked
(either permanently or temporarily (on hold)).
The "unknown" status indicates either that the server doesn't know
about the revocation status of the certificate being requested or
does not know about the certificate being requested.
Denis Pinkas Expires March 24, 2013 [Page 9]
INTERNET DRAFT PKIX OCSP September 25, 2012
2.3. Exception Cases
In case of errors, the OCSP Responder may return an error message.
These messages are not signed. Errors can be of the following types:
-- malformedRequest,
-- internalError,
-- tryLater,
-- sigRequired, or
-- unauthorized.
A server produces the "malformedRequest" response if the request
received does not conform to the OCSP syntax.
The response "internalError" indicates that the OCSP responder
reached an inconsistent internal state. The query should be retried,
potentially with another responder.
In the event that the OCSP server is operational, but unable to
return a status for the requested certificate, the "tryLater"
response can be used to indicate that the service exists, but is
temporarily unable to respond.
The response "sigRequired" is returned in cases where the server
requires the client to sign the request in order to construct a
response.
The response "unauthorized" is returned in cases where the client is
not authorized to make this query to this server or the server is not
capable of responding authoritatively (cf. [RFC5019], Section 2.2.3).
3. Functional Requirements
3.1. Requirements for certificate content
3.1.1. Target certificate content
In order to convey to OCSP clients a well-known point of information
access, CAs SHALL provide the capability to include the
AuthorityInfoAccess extension (defined in [RFC5280], section 4.2.2.1)
in certificates that can be checked using OCSP.
CAs that support an OCSP service, either hosted locally or provided
by an Authorized Responder, MUST provide for the inclusion of a value
for a uniformResourceIndicator (URI) accessLocation and the OID value
id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.
The value of the accessLocation field in the subject certificate
defines the transport (e.g. HTTP) used to access the OCSP server
and MAY contain other transport dependent information (e.g. a URL).
Denis Pinkas Expires March 24, 2013 [Page 10]
INTERNET DRAFT PKIX OCSP September 25, 2012
Note: accessLocation is mentioned in several places of this document.
It refers in all cases to the accessLocation field that is present
in an AIA extension field to designate the location of the OCSP
responder. In this case, the accessMethod field contains the
id-ad-ocsp OID.
3.1.2. OCSP certificate content
An OCSP certificate MUST contains the id-kp-OCSPSigning extended key
usage as defined in section 4.2.1.12 from RFC 5280. It indicates
that the certificate's issuer explicitly delegated OCSP signing
authority to an authorized OCSP Responder that is using its own key.
The digitalSignature bit in the keyUsage extension MUST also be set.
3.1.3. CA certificate content
CAs that delegate the issuance of OCSP responses to one or more
OCSP Responders MUST issue an OCSP certificate to each of these OCSP
Responders. Their CA certificate MUST allow them to sign these OCSP
certificates. Therefore the keyCertSign bit in the keyUsage
extension MUST be set.
If the CA supports CRLs, in particular to revoke the certificate of
the OCSP Responders, then both the cRLSign bit and the keyCertSig
bit MUST be set.
3.2. Requirements for CAs supporting directly an OCSP service
When a CA that directly supports an OCSP service performs a key
rollover:
- for certificates issued under the old key, the CA SHALL continue
to sign the revocation status of OCSP responses with that old key
at least until all these certificates are expired, and
- for certificates issued under the new key, the CA SHALL change the
accessLocation in the AIA extension field of these certificates
and sign the revocation status of OCSP responses with that new key
at least until all these certificates are expired.
Note: The change in accessLocation is necessary when the CA rekeys
to meet the following constraints imposed by this standard:
1) a BasicOCSPResponse can only be signed using a single
private key;
2) the response must be signed using the same CA key that
was used to sign the certificate in question; and
3) the OCSP response needs to cover all the certificates
queried in the OCSP request.
Denis Pinkas Expires March 24, 2013 [Page 11]
INTERNET DRAFT PKIX OCSP September 25, 2012
3.3. Requirements for CAs using OCSP Responders
3.3.1. Designation of a new OCSP Responder
When a CA designates a new OCSP Responder, then it SHALL change the
accessLocation in the AIA extension field for the newly issued
certificates and issue an OCSP certificate to the new OCSP Responder
using its current key.
3.3.2. CA key rollover
When a CA that uses OCSP Responders performs a key rollover, then
it MUST either designate a new OCSP Responder or keep the current
OCSP Responder(s).
If the CA designates a new OCSP Responder, then it SHALL change the
accessLocation in the AIA extension field for the newly issued
certificates and issue an OCSP certificate to the new OCSP Responder
using its new key.
If the CA keeps the same OCSP Responder(s), then it SHALL continue
to use the same accessLocation(s) in the AIA extension field for the
newly issued certificates and issue an OCSP certificate to the
appropriate OCSP Responder(s) using its new key.
Note: The CA may need to continue issuing certificates to the OCSP
Responder(s) using the old CA key until all the certificates issued
under the CA' old key for which the OCSP Responder(s) are
authoritative have expired.
3.3.3. OCSP Responder key rollover
When an OCSP Responder performs a key rollover (asynchronously from
a CA key rollover), then each CA which has designated an OCSP
Responder SHALL issue a new certificate for that OCSP Responder and
for each of its issuing keys which meets the following property:
- the issuing key has been used to sign at least one certificate
which contains an AIA extension designating that OCSP Responder
and that certificate is not yet expired.
An OCSP Responder key rollover does not affect the values of the
URIs that are placed in the accessLocation field from the target
certificates. One or more OCSP Responder MAY respond to an OCSP
request addressed at a given URI picked from the accessLocation
field from a target certificate. Each OCSP Responder MAY use a
different signing key, as long as it got an OCSP certificate
appropriate for that signing key and for the target certificate.
Denis Pinkas Expires March 24, 2013 [Page 12]
INTERNET DRAFT PKIX OCSP September 25, 2012
3.4. Requirements for OCSP clients
An OCSP request allows getting in a single response the revocation
status of one or more certificates. In order to request the
status of one or more certificates in a single request, OCSP
clients SHALL follow the following rules :
For each candidate certificate, OCSP clients SHALL verify
whether there exists a locally defined rule for the certificate in
question which indicates the URI where the OCSP responder is
located. If this rule exists, it SHALL be followed.
Otherwise, OCSP clients SHALL determine whether the candidate
certificate contains an AIA extension with an accessMethod which
contains the id-ad-ocsp OID. If it is the case, the accessLocation
contains a uniformResourceIdentifier (URI) which indicates the
location of the OCSP server for that certificate.
Certificates that contain the same URI MAY be grouped in a single
request.
Note: For each candidate certificate, when performing the path
validation algorithm, the OCSP client SHOULD verify that the
current time is within the validity period of the target
certificate. Thus, certificates which are outside their
validity period SHOULD NOT be included in the request or will
be rejected later on by the OCSP responder.
4. Detailed Protocol
The ASN.1 syntax imports terms defined in [RFC5280]. For signature
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 specified
otherwise.
The terms imported from elsewhere are: Extensions,
CertificateSerialNumber, SubjectPublicKeyInfo, Name,
AlgorithmIdentifier, CRLReason.
4.1. Request syntax
This section specifies the ASN.1 specification for a request.
The actual formatting of the message could vary depending on
the transport mechanism used (HTTP, SMTP, LDAP, etc.).
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
Denis Pinkas Expires March 24, 2013 [Page 13]
INTERNET DRAFT PKIX OCSP September 25, 2012
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 }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber }
requestorName is optional and MAY be used by the server for access
control and audit purposes.
requestList contains one or more single requests.
requestExtensions is OPTIONAL. Any specific extension is OPTIONAL.
The critical flag SHOULD NOT be set for any of them. Section 4.5
suggests several useful extensions. Additional extensions MAY be
defined in additional RFCs. Unrecognized extensions MUST be ignored
(unless they have the critical flag set and are not understood).
reqCert contains the identifier of a target certificate.
issuerNameHash is the hash of the Issuer's distinguished name. The
hash shall be calculated over the DER encoding of the issuer's name
field in the certificate being checked.
issuerKeyHash is the hash of the Issuer's public key. The hash
shall be calculated over the value (excluding tag and length) of the
subject public key field in the issuer's certificate. The hash
algorithm used for both these hashes, is identified in
hashAlgorithm.
serialNumber is the serial number of the certificate for which
status is being requested.
Denis Pinkas Expires March 24, 2013 [Page 14]
INTERNET DRAFT PKIX OCSP September 25, 2012
Note: The primary reason to use the hash of the CA's public key in
addition to the hash of the CA's name, to identify the issuer,
is that it is possible that two CAs may choose to use the same
Name (uniqueness in the Name is a recommendation that cannot be
enforced).
However, it is statistically infeasible that two CAs use the same
public key unless the CAs either explicitly decided to share
their private key, or the key of one of the CAs was compromised.
singleRequestExtensions is OPTIONAL. Any specific extension is
OPTIONAL. The critical flag SHOULD NOT be set for any of them.
The requestor MAY choose to sign the OCSP request. In that case, the
signature is computed over the tbsRequest structure. If the request
is signed, the requestor SHALL specify its name in the requestorName
field. Also, for signed requests, the requestor MAY include
certificates that help the OCSP responder verify the requestor's
signature in the certs field of Signature.
4.2 Response Syntax
This section specifies the ASN.1 specification for a confirmation
response. The actual formatting of the message could vary depending
on the transport mechanism used (HTTP, SMTP, LDAP, etc.).
An OCSP response at a minimum consists of a responseStatus field
indicating the processing status of the prior request. If the value
of responseStatus is one of the error conditions, responseBytes are
not set.
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), --Response has valid confirmations
malformedRequest (1), --Illegal confirmation request
internalError (2), --Internal error in issuer
tryLater (3), --Try again later
--(4) is not used
sigRequired (5), --Must sign the request
unauthorized (6) --Request unauthorized
}
The value for responseBytes consists of an OBJECT IDENTIFIER and a
response syntax identified by that OID encoded as an OCTET STRING.
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
Denis Pinkas Expires March 24, 2013 [Page 15]
INTERNET DRAFT PKIX OCSP September 25, 2012
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 }
OCSP responders SHALL be capable of producing responses of the id-
pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL
be capable of receiving and processing responses of the
id-pkix-ocsp-basic response type.
The value for response SHALL be the DER encoding of
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 DER
encoding ResponseData.
If the responder is not a CA, it SHALL include OCSP certificates in
the certs field of BasicOCSPResponse that allow the OCSP client
verifying the responder's signature. If no certificates are
included then certs SHOULD be absent.
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 key
(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 }
Denis Pinkas Expires March 24, 2013 [Page 16]
INTERNET DRAFT PKIX OCSP September 25, 2012
RevokedInfo ::= SEQUENCE {
revocationTime GeneralizedTime,
revocationReason [0] EXPLICIT CRLReason OPTIONAL }
UnknownInfo ::= NULL
responderID indicates either the name or the key from a CA, or the
name or the key from a OCSP Responder.
producedAt indicates the time at which this response was signed.
responses contains one or more single responses.
responseExtensions is OPTIONAL. Any specific extension is OPTIONAL.
The critical flag may or may not be set.
certID is usually a copy of the same field which was placed in the
request, but for OCSP responders which pre-produce signed responses
certID may be the identifier of a target certificate that was not
present in the request (see the end of section 4.2).
certStatus indicates the status of the certificate: either good,
revoked or unknown.
thisUpdate indicates the time at which the status being indicated
is known to be correct.
nextUpdate indicates the time at or before which newer information
will be available about the status of the certificate. If
nextUpdate is not set, the server is indicating that newer
revocation information is available all the time.
If nextUpdate is set, it often corresponds to the {thisUpdate,
nextUpdate} interval in CRLs. Responses whose nextUpdate value is
earlier than the local UTC time value SHOULD be considered
unreliable. Responses whose thisUpdate time is later than the local
UTC time SHOULD be considered unreliable.
singleExtensions is OPTIONAL. Any specific extension is OPTIONAL.
The critical flag SHOULD NOT be set for any of them.
revocationTime indicates the time at which the certificate was
revoked.
revocationReason is OPTIONAL. It is defined in section 5.3.1 from
RFC 5280 [RFC5280].
The response MUST include a SingleResponse for each certificate in
the request and SHOULD NOT include any additional SingleResponse
elements. There is however one exception:
Denis Pinkas Expires March 24, 2013 [Page 12]
INTERNET DRAFT PKIX OCSP September 25, 2012
OCSP responders MAY pre-produce signed responses specifying the
status of certificates at a specified time. The time at which
the status was known to be correct SHALL be reflected in the
thisUpdate field of the response.
OCSP responders that pre-generate status responses MAY return
responses that include additional SingleResponse elements if
necessary to improve response pre-generation performance or cache
efficiency (as permitted in [RFC5019]).
4.3. Processing of requests and responses
This section describes various processing algorithms. Conforming
implementations of this specification are not required to implement
these processing algorithms, but MUST provide functionality
equivalent to the external behavior resulting from these algorithms.
Any algorithm may be used by a particular implementation so long as
it produces the correct result.
4.3.1. Request processing by OCSP servers
The behavior of an OCSP server will be different whether the OCSP
server is a CA acting as an OCSP responder, is an OCSP Responder
which received a delegation from one or more CAs, or is a locally
trusted Responder.
4.3.1.1. Processing by a CA acting as an OCSP responder
The OCSP responder SHALL maintain a list of entries. Each entry
SHALL contain:
- the URI associated to the OCSP responder, from which the OCSP
requests are received,
- the DN from that CA,
- an issuing public key from that CA,
- the method(s) used to know for which subset of certificates
issued by the CA it is responsible for,
- the method(s) used to obtain the revocation status of that
subset of certificates issued under that CA issuing public key,
and
- the method used to gain access and sign with the private key
corresponding to the issuing public key.
For a given URI value, the OCSP responder SHALL only use one CA
key pair value.
When it receives an OCSP request on that URI, the OCSP responder
SHALL handle exceptions according to section 2.3.
Denis Pinkas Expires March 24, 2013 [Page 18]
INTERNET DRAFT PKIX OCSP September 25, 2012
If the OCSP request contains the name of a requestor, the OCSP
responder SHALL verify whether there exists a locally defined rule
which regulates access control. If this rule exists, it SHALL be
followed.
Then, for each target certificate, the OCSP responder SHALL verify
whether both the hash of the issuer's DN and the hash of the issuer
public key which are present in the request are eligible to a
locally defined rule which indicates that the OCSP responder is
responsible to provide the revocation status of that target
certificate. If this rule exists, it SHALL be followed.
Otherwise, the OCSP responder SHALL determine whether it is
responsible to provide the revocation status of that target
certificate according to the following rule.
For each target certificate, the OCSP responder SHALL verify whether
both the hash of the issuer's DN and the hash of the issuer public
key which are present in the request match respectively with the DN
and the hash of the public key of contained in an entry from the
list of entries maintained by this OCSP responder.
When there is no match, then the OCSP responder SHALL indicate the
"unknown" status and proceed with the next target certificate from
the OCSP request.
When there is a match, then the OCSP responder SHALL use the serial
number of the target certificate that is present in the request and
determine the revocation status of that certificate according to
the method(s) defined in the entry.
When the revocation status is provided by the server using a real
time access to a database of revocation statuses of issued
certificates, then the thisUpdate field SHALL be present in the
SingleResponse response whereas the nextUpdate field SHALL be
missing.
Otherwise, both the thisUpdate and the nextUpdate fields SHALL be
present in the SingleResponse.
The time at which this response will be signed MUST be indicated in
the producedAt field from the SingleResponse.
If a singleRequestExtensions is present in the request it MUST be
processed.
If there is another target certificate present in the request, it
SHALL be processed in the same way.
If a requestExtensions is present in the request it MUST be
processed.
The OCSP response MUST be signed using the CA issuing private key.
Denis Pinkas Expires March 24, 2013 [Page 19]
INTERNET DRAFT PKIX OCSP September 25, 2012
The certs field SHOULD be kept empty.
4.3.1.2. Processing by an OCSP Responder
For each CA from which the OCSP Responder has received a delegation,
the OCSP Responder SHALL maintain a list of entries.
Each entry SHALL contain:
- the URI associated to this OCSP Responder, from which the OCSP
requests are received,
- the DN from that CA,
- an issuing public key from that CA,
- the method(s) used to know for which subset of certificates
issued by the CA it is responsible for,
- the method(s) used to obtain the revocation status of that
subset of certificates issued under that CA issuing public key,
- an OCSP certificate,
- the OCSP public key contained in that OCSP certificate, and
- the method used to gain access and sign with the OCSP private
key corresponding to that OCSP certificate.
For a given URI value, the OCSP Responder SHALL only use one OCSP
key pair value. Therefore there cannot be two entries with the
same URI value and a different OCSP public key value.
NOTE: a BasicOCSPResponse can only be signed using a single private
key.
The OCSP certificate SHALL be signed by the CA issuing private key
which corresponds to the issuing CA public key that is in this
entry.
When it receives an OCSP request, the OCSP responder SHALL handle
exceptions according to section 2.3.
If the OCSP request contains the name of a requestor, the OCSP
responder SHALL verify whether there exists a locally defined rule
which regulates access control. If this rule exists, it SHALL be
followed.
For each target certificate, the OCSP Responder SHALL verify
whether both the hash of the issuer's DN and the hash of the issuer
public key which are present in the OCSP request match with those
from an entry.
Denis Pinkas Expires March 24, 2013 [Page 20]
INTERNET DRAFT PKIX OCSP September 25, 2012
When there is no match, then the OCSP Responder SHALL indicate the
"unknown" status and proceed with the next target certificate from
the OCSP request.
When there is a match, the OCSP Responder SHALL use the serial
number of the target certificate this is present in the OCSP
request to determine the revocation status of that certificate
according to the method(s) indicated in the entry.
When the revocation status is provided by the server using a real
time access to a database of revocation statuses of issued
certificates, then the thisUpdate field SHALL be present in the
SingleResponse response whereas the nextUpdate field SHALL be
missing.
Otherwise, both the thisUpdate and the nextUpdate fields SHALL be
present in the SingleResponse.
The time at which this response will be signed MUST be indicated in
the producedAt field from the SingleResponse.
If a singleRequestExtensions is present in the request it MUST be
processed.
If there is another target certificate present in the request, it
SHALL be processed in the same way.
If a requestExtensions is present in the request it SHALL be
processed.
The OCSP response MUST be signed using the OCSP private key.
Unless there is a local rule which states differently, for every
target certificate which matches both with the hash of a CA DN and an
issuing public key from an entry, the OCSP certificate of that entry
SHALL be placed in the certs field.
It may happen, that none of the target certificates from the OCSP
request matches both with the hash of a CA DN and an issuing public
key from an entry. In that case and unless a local rule states
differently, the certs field from the BasicOCSPResponse SHOULD be
kept empty (to limit the disclose of the names of the CAs from which
the OCSP Responder received a delegation from).
4.3.1.3. Processing by a locally trusted Responder
For each CA for which the locally trusted Responder is
authoritative, the OCSP Responder SHALL maintain a list of entries.
Each entry SHALL contain:
- the URI associated to this OCSP Responder, from which the OCSP
requests are received,
Denis Pinkas Expires March 24, 2013 [Page 21]
INTERNET DRAFT PKIX OCSP September 25, 2012
- the DN from that CA,
- an issuing public key from that CA,
- the method(s) used to know for which subset of certificates
issued by the CA it is responsible for,
- the method(s) used to obtain the revocation status of that
subset of certificates issued under that CA issuing public key,
- the method used to gain access to the private key in order to
sign the OCSP response.
For a given URI value, the OCSP Responder SHALL only use one private
key. Therefore there cannot be two entries with the same URI value
and a different method to gain access to the appropriate private key.
NOTE: a BasicOCSPResponse can only be signed using a single private
key.
When it receives an OCSP request, the OCSP responder SHALL handle
exceptions according to section 2.3.
If the OCSP request contains the name of a requestor, the OCSP
responder SHALL verify whether there exists a locally defined rule
which regulates access control. If this rule exists, it SHALL be
followed.
For each target certificate, the OCSP Responder SHALL verify
whether both the hash of the issuer's DN and the hash of the issuer
public key which are present in the OCSP request match with those
from an entry.
When there is no match, then the OCSP Responder SHALL indicate the
"unknown" status and proceed with the next target certificate from
the OCSP request.
When there is a match, the OCSP Responder SHALL use the serial
number of the target certificate this is present in the OCSP
request to determine the revocation status of that certificate
according to the method(s) indicated in the entry.
When the revocation status is provided by the server using a real
time access to a database of revocation statuses of issued
certificates, then the thisUpdate field SHALL be present in the
SingleResponse response whereas the nextUpdate field SHALL be
missing.
Otherwise, both the thisUpdate and the nextUpdate fields SHALL be
present in the SingleResponse.
The time at which this response will be signed MUST be indicated in
the producedAt field from the SingleResponse.
Denis Pinkas Expires March 24, 2013 [Page 22]
INTERNET DRAFT PKIX OCSP September 25, 2012
If a singleRequestExtensions is present in the request it MUST be
processed.
If there is another target certificate present in the request, it
SHALL be processed in the same way.
If a requestExtensions is present in the request it SHALL be
processed.
The OCSP response MUST be signed using the OCSP private key.
The certs field may contain no, one or several OCSP certificates
according to local rules followed by the locally trusted Responder.
4.3.2. Response processing by an OCSP client
OCSP responses can be verified at the current time by an OCSP client
when receiving a response, whereas old responses can be verified at
a time in the past by a verifier. The algorithm below addresses
both cases.
Prior to processing a basic response, OCSP clients MUST determine
the checking time, which may be either the current time or a time
in the past.
OCSP clients or verifiers SHALL check if the response contains a
critical responseExtensions. If such an extension is found and is
recognized, it MUST be processed. If such an extension is found and
is not recognized, the whole OCSP response MUST be considered as
invalid.
If the checking time is the current time, and if a nonce extension
has been used in the request and is recognized (see section 4.5.1),
OCSP clients MUST check whether the same nonce is present in the
response. If the nonce is not present or is different, then the
OCSP response MUST be discarded.
Only the single response(s) which are/is of interest SHALL be
checked.
STEP 1
OCSP clients or verifiers SHALL verify that the certificate
identified in a single response is of interest. Otherwise, proceed
to step 3.
If the certificate status included in a single certificate response
is "unknown", then the revocation status of that certificate is
"unknown", and proceed to step 3.
Denis Pinkas Expires March 24, 2013 [Page 23]
INTERNET DRAFT PKIX OCSP September 25, 2012
If the certificate status from the single certificate response is
either "good" or "revoked", OCSP clients or verifiers SHALL check
that the checking time is within the validity period of the target
certificate. If it is not the case, then the revocation status of
that certificate is "unknown" and proceed to step 3.
If the checking time is the current time, and if a nonce has been
used in the request, then proceed to step 2.
If the checking time is the current time, and if no nonce has been
used in the request, OCSP clients MUST check that the producedAt
field is within a time window that is "close enough" to the current
time.
Note: the notion of "close enough" is a local matter. It can be set
to a few minutes to allow for small UTC time differences
between the client and the server or to a few hours in case
the server is producing pre-computed responses.
If the checking time is a time in the past, verifiers MUST check
that the producedAt field is in accordance with the verification
rules (e.g. close and/or after the date of a time-stamp token).
In addition, if the nextUpdate field is present, OCSP clients MUST
check that the time which is indicated is greater than the checking
time, otherwise the single response MUST be discarded.
If checks are successful, then OCSP clients MUST process the
singleExtensions field, if it is present.
If the criticality flag is set and the extension is not understood,
then the status of the certificate shall be "unknown" and proceed to
step 3. Otherwise, proceed to step 2.
If the extension is understood, then the extension MUST be
processed. According to its content proceed either to step 2 or to
step 3.
STEP 2
OCSP clients or verifiers MUST build and verify a certification path
for that certificate up to a trusted root, so that they have the
knowledge of the CA public key value that was used to sign the
target certificate. The revocation status of each certificate of
that certification path (except the target certificate) SHALL be
checked.
If no path can be built or if one of the certificates of the path is
revoked, then the revocation status of that certificate is "unknown",
and proceed to step 3.
Denis Pinkas Expires March 24, 2013 [Page 24]
INTERNET DRAFT PKIX OCSP September 25, 2012
If the certification path (except the target certificate) is valid,
then two cases need to be considered:
a) If the responderID matches with the name or the key from the CA
which has issued the target certificate, then check whether the
OCSP response is signed by the same key that was used to sign
the target certificate.
If it is the case, then the revocation status of that
certificate as indicated in the certStatus field is
accepted and proceed to step 3.
If it is not the case, then the revocation status of that
certificate is "unknown" and proceed to step 3.
b) If the responderID does not match with the name or the key from
the CA which has issued the target certificate, then it indicates
the name or the key from an OCSP Responder. Check whether there
exists a local rule which applies to this target certificate to
verify that the signature of the BasicOCSPResponse is valid for
that single response. If this rule exists, it SHALL be followed.
Otherwise check whether there is an OCSP certificate (i.e. which
has both the ocspSigning OID in the extended key usage extension
and the digitalSignature bit in the key usage extension) signed
by the same key that was used to sign the target certificate.
This certificate MUST be present in the certs field from the
BasicOCSPResponse.
If such certificate is not found or is invalid, then the
revocation status of that certificate is "unknown" and
proceed to step 3.
If such certificate exists and if the checking time is
within the validity period of this certificate, then it MUST
be verified whether the OCSP response can be verified using
the public key that is present in the OCSP Certificate.
If it is not the case, then the revocation status of that
certificate is "unknown" and proceed to step 3.
If it is the case, then it MUST be verified that the OCSP
Certificate has not been revoked.
CAs may choose to deal with this problem in one of three ways:
- A CA may specify that an OCSP client can trust a responder for the
lifetime of the responder's certificate.
The CA does so by including the extension id-pkix-ocsp-nocheck.
This SHOULD be a non-critical extension. The value of the
extension SHALL be NULL.
Denis Pinkas Expires March 24, 2013 [Page 25]
INTERNET DRAFT PKIX OCSP September 25, 2012
NoCheck ::= NULL
CAs issuing such a certificate should realize that a compromise of
the responder's key is as serious as the compromise of a CA key used
to sign CRLs, at least for the validity period of this certificate.
CA's may choose to issue this type of certificate with a very short
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 for
revocation. This can be done using CRL Distribution Points if the
check should be done using CRLs, or Authority Information Access
if the check should be done in some other way. Details for
specifying either of these two mechanisms are available in
[RFC5280].
- A CA may choose not to specify any method of revocation checking
for the responder's certificate, in which case, it would be up to
the OCSP client's local security policy to decide whether that
certificate should be checked for revocation or not.
If one of these conditions is met, then the status for the target
certificate as indicated in the certStatus field is accepted,
otherwise the revocation status is "unknown".
STEP 3
If there exists another single certificate status response for a
target certificate that is of interest, then proceed to step 1.
Otherwise the basic response is now processed.
4.4. Mandatory and Optional Cryptographic Algorithms
Clients that request OCSP services SHALL be capable of processing
responses signed using RSA with SHA-1 (identified by
sha1WithRSAEncryption OID specified in [RFC3279]) and RSA with
SHA-256 (identified by sha256WithRSAEncryption OID specified in
[RFC4055]).
Clients SHOULD also be capable of processing responses signed using
DSA keys (identified by the id-dsa-with-sha1 OID specified in
[RFC3279]). Clients MAY support other algorithms.
4.5. Extensions
This section defines some standard extensions, based on the
extension model employed in X.509 version 3 certificates see
[RFC5280]. Support for all extensions is optional for both clients
and responders.
Denis Pinkas Expires March 24, 2013 [Page 26]
INTERNET DRAFT PKIX OCSP September 25, 2012
For each extension, the definition indicates its syntax, processing
performed by the OCSP Responder, and any extensions which are
included in the corresponding response.
4.5.1. Nonce
The nonce cryptographically binds a request and a response to prevent
replay attacks. The nonce is included as one of the
requestExtensions in requests, while in responses it would be
included as one of the responseExtensions. In both the request and
the response, the nonce will be identified by the object identifier
id-pkix-ocsp-nonce, while the extnValue is the value of the nonce.
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
Nonce ::= OCTET STRING
4.5.2. CRL References
It may be desirable for the OCSP responder to indicate the CRL on
which a revoked or onHold certificate is found. This can be useful
where OCSP is used between repositories, and also as an auditing
mechanism. The CRL may be specified by a URL (the URL at which the
CRL is available), a number (CRL number) or a time (the time at
which the relevant CRL was created). These extensions will be
specified as 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 which
the CRL is available. For crlNum, the INTEGER will specify the
value of the CRL number extension of the relevant CRL. For crlTime,
the GeneralizedTime will indicate the time at which the relevant CRL
was issued.
4.5.3 Acceptable Response Types
An OCSP client MAY wish to specify the kinds of response types it
understands. To do so, it SHOULD use an extension with the OID
id-pkix-ocsp-response, and the value AcceptableResponses.
Denis Pinkas Expires March 24, 2013 [Page 27]
INTERNET DRAFT PKIX OCSP September 25, 2012
This extension is included as one of the requestExtensions in
requests. The OIDs included in AcceptableResponses are the OIDs of
the various response types this client can accept (e.g.,
id-pkix-ocsp-basic).
id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
As noted in section 4.2.1, OCSP responders SHALL be capable of
responding with responses of the id-pkix-ocsp-basic response type.
Correspondingly, OCSP clients SHALL be capable of receiving and
processing responses of the id-pkix-ocsp-basic response type.
4.5.4 Archive Cutoff
An OCSP responder MAY choose to retain revocation information beyond
a certificate's expiration. The date obtained by subtracting this
retention interval value from the producedAt time in a response is
defined as the certificate's "archive cutoff" date.
OCSP-enabled applications would use an OCSP archive cutoff date to
contribute to a proof that a digital signature was (or was not)
reliable on the date it was produced even if the certificate needed
to validate the signature has long since expired.
OCSP servers that provide support for such historical reference
SHOULD include an archive cutoff date extension in responses. If
included, this value SHALL be provided as an OCSP singleExtensions
extension identified by id-pkix-ocsp-archive-cutoff and of syntax
GeneralizedTime.
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
ArchiveCutoff ::= GeneralizedTime
To illustrate, if a server is operated with a 7-year retention
interval policy and status was produced at time t1 then the value
for ArchiveCutoff in the response would be (t1 - 7 years).
4.5.5. CRL Entry Extensions
All the extensions specified as CRL Entry Extensions - in
Section 5.3 of [RFC5280] - are also supported as singleExtensions.
4.5.6. Service Locator
An OCSP server may be operated in a mode whereby the server receives
a request and routes it to the OCSP server which is known to be
authoritative for the identified certificate. The serviceLocator
request extension is defined for this purpose. This extension is
included as one of the singleRequestExtensions in requests.
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }
Denis Pinkas Expires March 24, 2013 [Page 28]
INTERNET DRAFT PKIX OCSP September 25, 2012
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax OPTIONAL }
Values for these fields are obtained from the corresponding fields
in the subject certificate.
4.5.7. Preferred Signature Algorithms
Since algorithms other than the mandatory to implement algorithms
are allowed, and since a client currently has no mechanism to
indicate it's algorithm preferences, there is always a risk that a
server choosing a non-mandatory algorithm, will generate a response
that the client may not support.
While an OCSP responder may apply rules for algorithm selection,
e.g., using the signature algorithm employed by the CA for signing
CRLs and certificates, such rules may fail in common situations:
o The algorithm used to sign the CRLs and certificates may not be
consistent with key pair being used by the OCSP responder to sign
responses.
o A request for an unknown certificate provides no basis for a
responder to select from among multiple algorithm options.
The last criterion cannot be resolved through the information
available from in-band signaling using the RFC 2560 [RFC2560]
protocol, without modifying the protocol.
In addition, an OCSP responder may wish to employ different
signature algorithms than the one used by the CA to sign
certificates and CRLs for several reasons:
o The responder may employ an algorithm for certificate status
response that is less computationally demanding than for signing
the certificate itself.
o An implementation may wish to guard against the possibility of a
compromise resulting from a signature algorithm compromise by
employing two separate signature algorithms.
This section describes:
o An extension that allows a client to indicate the set of
preferred signature algorithms.
o Rules for signature algorithm selection that maximizes the
probability of successful operation in the case that no supported
preferred algorithm(s) are specified.
Denis Pinkas Expires March 24, 2013 [Page 29]
INTERNET DRAFT PKIX OCSP September 25, 2012
4.5.7.1. Extension Syntax
A client MAY declare a preferred set of algorithms in a request by
including a preferred signature algorithms extension in
requestExtensions of the OCSPRequest.
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
pubKeyAlgIdentifier SMIMECapability OPTIONAL
}
The syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of
RFC 5280 [RFC5280]. The syntax of SMIMECapability is defined in
RFC 5751 [RFC5751].
sigIdentifier specifies the signature algorithm the client prefers,
e.g. algorithm=ecdsa-with-sha256. Parameters are absent for most
common signature algorithms.
pubKeyAlgIdentifier specifies the subject public key algorithm
identifier the client prefers in the server's certificate used to
validate the OCSP response. e.g. algorithm=id-ecPublicKey and
parameters= secp256r1.
pubKeyAlgIdentifier is OPTIONAL and provides means to specify
parameters necessary to distinguish among different usages of a
particular algorithm, e.g. it may be used by the client to specify
what curve it supports for a given elliptic curve algorithm.
The client MUST support each of the specified preferred signature
algorithms and the client MUST specify the algorithms in the order
of preference, from the most preferred to the least preferred.
Section 4.4.7.1 of this document describes how a server selects an
algorithm for signing OCSP responses to the requesting client.
4.5.7.2. Responder Signature Algorithm Selection
RFC 2560 [RFC2560] did not specify a mechanism for deciding the
signature algorithm to be used in an OCSP response. This does not
provide a sufficient degree of certainty as to the algorithm
selected to facilitate interoperability.
Denis Pinkas Expires March 24, 2013 [Page 30]
INTERNET DRAFT PKIX OCSP September 25, 2012
4.5.7.2.1. Dynamic Response
A responder MAY maximize the potential for ensuring interoperability
by selecting a supported signature algorithm using the following
order of precedence, as long as the selected algorithm meets all
security requirements of the OCSP responder, where the first method
has the highest precedence:
1. Select an algorithm specified as a preferred signing algorithm
in the client request.
2. Select the signing algorithm used to sign a certificate
revocation list (CRL) issued by the certificate issuer providing
status information for the certificate specified by CertID.
3. Select the signing algorithm used to sign the OCSPRequest.
4. Select a signature algorithm that has been advertised as being
the default signature algorithm for the signing service using an
out of band mechanism.
5. Select a mandatory or recommended signing algorithm specified
for the version of the OCSP protocol in use.
A responder SHOULD always apply the lowest numbered selection
mechanism that results in the selection of a known and supported
algorithm that meets the responder's criteria for cryptographic
algorithm strength.
4.5.7.2.2. Static Response
For purposes of efficiency, an OCSP responder is permitted to
generate static responses in advance of a request. The case may not
permit the responder to make use of the client request data during
the response generation, however the responder SHOULD still use the
client request data during the selection of the pre-generated
response to be returned. Responders MAY use the historical client
requests as part of the input to the decisions of what different
algorithms should be used to sign the pre-generated responses.
5. Security Considerations
5.1. Denial of service attack using false error responses
Unsigned error responses open up the protocol to another denial of
service attack, where the attacker sends false error responses.
5.2. Using CRLs as a fall-back mechanism
For this service to be effective, certificate-using systems must
connect to the certificate status service provider. In the event
such a connection cannot be obtained, certificate-using systems
could implement CRL processing logic as a fall-back position.
Denis Pinkas Expires March 24, 2013 [Page 31]
INTERNET DRAFT PKIX OCSP September 25, 2012
5.3. Different results when using OCSP and CRLs
OCSP clients or verifiers must build and verify a certification path
for each target certificate up to a trusted root. When an OCSP
Responder is using published CRLs, it must also build and verify a
certification path for the CRLs it uses up to a trusted root.
However, it should be realized that the root used by an OCSP
Responder to verified these CRLs is not necessarily the same as the
one that would be used by the OCSP client if it were going to verify
the CRLs itself. Hence the revocation status may not be identical
in both cases.
5.4. Denial of service attack using a flood of queries
A denial of service vulnerability is evident with respect to a flood
of queries. The production of a cryptographic signature
significantly affects response generation cycle time, thereby
exacerbating the situation.
The flood of queries may either come from a flood attack or from the
fact that there are too many certificates supported by the same OCSP
responder. In the later case, the number of queries can be
diminished by using a technique similar to the splitting of CRLs:
When a block of certificates have been issued with the same
accessLocation in the AIA extension field of these certificates,
then the accessLocation should be changed. In this way, a given
OCSP server will only serve one block of certificates.
5.5. Use of precomputed responses
The use of precomputed responses allows replay attacks in which an
old (good) response is replayed prior to its expiration date but
after the certificate has been revoked. Deployments of OCSP should
carefully evaluate the benefit of precomputed responses against the
probability of a replay attack and the costs associated with its
successful execution.
Requests do not contain the responder they are directed to. This
allows an attacker to replay a request to any number of OCSP
responders.
The reliance of HTTP caching in some deployment scenarios may result
in unexpected results if intermediate servers are incorrectly
configured or are known to possess cache management faults.
Implementors are advised to take the reliability of HTTP cache
mechanisms into account when deploying OCSP over HTTP.
Denis Pinkas Expires March 24, 2013 [Page 32]
INTERNET DRAFT PKIX OCSP September 25, 2012
5.6. Preferred Signature Algorithms
The mechanism used to choose the response signing algorithm MUST be
considered to be sufficiently secure against cryptanalytic attack for
the intended application.
In most applications it is sufficient for the signing algorithm to be
at least as secure as the signing algorithm used to sign the original
certificate whose status is being queried. This criterion may not
hold in long term archival applications however in which the status
of a certificate is being checked for a date in the distant past,
long after the signing algorithm has ceased being considered
trustworthy.
5.6.1 Use of insecure algorithms
It is not always possible for a responder to generate a response that
the client is expected to understand and that meets contemporary
standards for cryptographic security. In such cases an OCSP
responder operator MUST balance the risk of employing a compromised
security solution and the cost of mandating an upgrade, including the
risk that the alternative chosen by end users will offer even less
security or no security.
In archival applications it is quite possible that an OCSP responder
might be asked to report the validity of a certificate on a date in
the distant past. Such a certificate might employ a signing method
that is no longer considered acceptably secure. In such
circumstances either the responder SHOULD NOT generate a signature
using a signing mechanism that is not considered acceptably secure
or SHOULD time-stamp the OCSP response.
A client MUST accept any signing algorithm in a response that it
specified as a preferred signing algorithm in the request. It
follows therefore that a client MUST NOT specify as a preferred
signing algorithm any algorithm that is either not supported or not
considered acceptably secure.
5.6.2. Man in the Middle Downgrade Attack
The mechanism to support client indication of preferred signature
algorithms is not protected against a man in the middle downgrade
attack. This constraint is not considered to be a significant
security concern since the OCSP responder MUST NOT sign OCSP
Responses using weak algorithms, even if requested by the client.
In addition, the client can reject OCSP responses that do not meet
its own criteria for acceptable cryptographic security no matter what
mechanism is used to determine the signing algorithm of the response.
Denis Pinkas Expires March 24, 2013 [Page 33]
INTERNET DRAFT PKIX OCSP September 25, 2012
5.6.3. Denial of Service Attack using the algorithm agility mechanisms
Algorithm agility mechanisms defined in this document introduces a
slightly increased attack surface for Denial-of-Service attacks where
the client request is altered to require algorithms that are not
supported by the server. Denial-of-Service considerations from RFC
4732 [RFC4732] are relevant for this document.
5.7. Other replay attacks
As already mentioned in section 5.5, replay attacks are possible
using precomputed responses. Replay attacks are also possible when
no nonce is being used in the OCSP request and the time window
mentioned in section 4.3.2 (STEP 1)is too large.
6. IANA Considerations
Appendix C (MIME registrations) already contains the information
which is necessary for this RFC. No further action is necessary.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005.
[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, May 2008.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC6277] Santesson, S. and P. Hallam-Baker, "Online Certificate
Status Protocol Algorithm Agility", RFC 6277, June 2011.
Denis Pinkas Expires March 24, 2013 [Page 34]
INTERNET DRAFT PKIX OCSP September 25, 2012
[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), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
7.2. Informative References
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4732] Handley, M., Rescorla, E., "Internet Denial-of-Service
Considerations" RFC 4732, November 2006.
[RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online
Certificate Status Protocol (OCSP) Profile for High-Volume
Environments", RFC 5019, September 2007.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
June 2010.
8. Acknowledgements
This document is based on RFC 2560 for which the authors were
M. Myers, R. Ankney, A. Malpani and S. Galperin.
It capitalizes on an original draft from S. Santesson.
The initial draft of this document has been reviewed and commented
by D. Rouger, R. Santini, B. Sevellec while the published drafts
have been reviewed and commented in detail by S. Chokhani.
Denis Pinkas Expires March 24, 2013 [Page 35]
INTERNET DRAFT PKIX OCSP September 25, 2012
Appendix A.
A.1 OCSP over HTTP
This section describes the formatting that will be done to the
request and response to support HTTP [RFC2616].
A.1.1 Request
HTTP based OCSP requests can use either the GET or the POST method to
submit their requests. To enable HTTP caching, small requests (that
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 is
a requirement, OCSP transactions exchanged using HTTP MAY be
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 of
the OCSPRequest}
where {url} may be derived from the value of AuthorityInfoAccess or
other local configuration of the OCSP client.
An OCSP request using the POST method is constructed as follows: The
Content-Type header has the value "application/ocsp-request" while
the body of the message is the binary value of the DER encoding of
the OCSPRequest.
A.1.2 Response
An HTTP-based OCSP response is composed of the appropriate HTTP
headers, followed by the binary value of the DER encoding of the
OCSPResponse. The Content-Type header has the value
"application/ocsp-response". The Content-Length header SHOULD specify
the length of the response. Other HTTP headers MAY be present and MAY
be ignored if not understood by the requestor.
Denis Pinkas Expires March 24, 2013 [Page 36]
INTERNET DRAFT PKIX OCSP September 25, 2012
Appendix B. ASN.1 Modules
This appendix includes the ASN.1 modules for OCSP.
Appendix B.1 includes an ASN.1 module that conforms to the 1998
version of ASN.1 for all syntax elements of OCSP other than the
preferred signature algorithms extension.
Appendix B.2 includes an ASN.1 module that conforms to the 2002
version of ASN.1 for all syntax elements of OCSP other than the
preferred signature algorithms extension.
Note: the ASN.1 module that conforms to the 2002 version of ASN.1
which may be found in Section 4 of [RFC5912] has an omission
since the nocheck extension is undefined.
Appendix B.3 includes two ASN.1 modules for the preferred signature
algorithms extension, one that conforms to the 1998 version of ASN.1
and one that conforms to the 2002 version of ASN.1.
B.1. OCSP module which conforms to the 1988 syntax of ASN.1
OCSP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-xx(XX)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
-- PKIX Certificate Extensions
AuthorityInfoAccessSyntax, CRLReason, GeneralName
FROM PKIX1Implicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit(19) }
Name, CertificateSerialNumber, Extensions,
id-kp, id-ad-ocsp, Certificate, AlgorithmIdentifier
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) };
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 }
Denis Pinkas Expires March 24, 2013 [Page 37]
INTERNET DRAFT PKIX OCSP September 25, 2012
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 }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuers public key
serialNumber CertificateSerialNumber }
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), -- Response has valid confirmations
malformedRequest (1), -- Illegal confirmation request
internalError (2), -- Internal error in issuer
tryLater (3), -- Try again later
-- (4) is not used
sigRequired (5), -- Must sign the request
unauthorized (6) -- Request unauthorized
}
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 }
Denis Pinkas Expires March 24, 2013 [Page 38]
INTERNET DRAFT PKIX OCSP September 25, 2012
KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key
-- (i.e., the SHA-1 hash of the value of the
-- BIT STRING subjectPublicKey [excluding
-- the tag, length, and number of unused
-- bits] in the responder's certificate)
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
ArchiveCutoff ::= GeneralizedTime
AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
Nonce ::= OCTET STRING
NoCheck ::= NULL
-- Object Identifiers
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 }
END
Denis Pinkas Expires March 24, 2013 [Page 39]
INTERNET DRAFT PKIX OCSP September 25, 2012
B.2. OCSP module which conforms to the 2002 syntax of ASN.1
OCSP-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-yy(YY)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
Extensions{}, EXTENSION, ATTRIBUTE
FROM PKIX-CommonTypes-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}
AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM
FROM AlgorithmInformation-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions
FROM PKIX1Implicit-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
Name, CertificateSerialNumber, id-kp, id-ad-ocsp, Certificate
FROM PKIX1Explicit-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}
sa-dsaWithSHA1, sa-rsaWithMD2, sa-rsaWithMD5, sa-rsaWithSHA1
FROM PKIXAlgs-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56)};
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 {{re-ocsp-nonce |
re-ocsp-response, ...}} OPTIONAL }
Denis Pinkas Expires March 24, 2013 [Page 40]
INTERNET DRAFT PKIX OCSP September 25, 2012
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier
{ SIGNATURE-ALGORITHM, {...}},
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions
{ {re-ocsp-service-locator,
...}} OPTIONAL }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
{DIGEST-ALGORITHM, {...}},
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuer's public key
serialNumber CertificateSerialNumber }
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
OCSPResponseStatus ::= ENUMERATED {
successful (0), --Response has valid confirmations
malformedRequest (1), --Illegal confirmation request
internalError (2), --Internal error in issuer
tryLater (3), --Try again later
-- (4) is not used
sigRequired (5), --Must sign the request
unauthorized (6) --Request unauthorized
}
RESPONSE ::= TYPE-IDENTIFIER
ResponseSet RESPONSE ::= {basicResponse, ...}
ResponseBytes ::= SEQUENCE {
responseType RESPONSE.
&id ({ResponseSet}),
response OCTET STRING (CONTAINING RESPONSE.
&Type({ResponseSet}{@responseType}))}
basicResponse RESPONSE ::=
{ BasicOCSPResponse IDENTIFIED BY id-pkix-ocsp-basic }
Denis Pinkas Expires March 24, 2013 [Page 41]
INTERNET DRAFT PKIX OCSP September 25, 2012
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier{SIGNATURE-ALGORITHM,
{sa-dsaWithSHA1 | sa-rsaWithSHA1 |
sa-rsaWithMD5 | sa-rsaWithMD2, ...}},
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
{{re-ocsp-nonce, ...}} OPTIONAL }
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key
-- (excluding the tag and length fields)
SingleResponse ::= SEQUENCE {
certID CertID,
certStatus CertStatus,
thisUpdate GeneralizedTime,
nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,
singleExtensions [1] EXPLICIT Extensions{{re-ocsp-crl |
re-ocsp-archive-cutoff |
CrlEntryExtensions, ...}
} 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
CRLReason ::= INTEGER
ArchiveCutoff ::= GeneralizedTime
AcceptableResponses ::= SEQUENCE OF RESPONSE.&id({ResponseSet})
Denis Pinkas Expires March 24, 2013 [Page 42]
INTERNET DRAFT PKIX OCSP September 25, 2012
ServiceLocator ::= SEQUENCE {
issuer Name,
locator AuthorityInfoAccessSyntax }
CrlID ::= SEQUENCE {
crlUrl [0] EXPLICIT IA5String OPTIONAL,
crlNum [1] EXPLICIT INTEGER OPTIONAL,
crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }
-- Request Extensions
re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED
BY id-pkix-ocsp-nonce }
re-ocsp-response EXTENSION ::= { SYNTAX AcceptableResponses IDENTIFIED
BY id-pkix-ocsp-response }
re-ocsp-service-locator EXTENSION ::= { SYNTAX ServiceLocator
IDENTIFIED BY
id-pkix-ocsp-service-locator }
-- Response Extensions
re-ocsp-crl EXTENSION ::= { SYNTAX CrlID IDENTIFIED BY
id-pkix-ocsp-crl }
re-ocsp-archive-cutoff EXTENSION ::= { SYNTAX ArchiveCutoff
IDENTIFIED BY
id-pkix-ocsp-archive-cutoff }
-- Certificate Extension
ocsp-nocheck EXTENSION ::= { SYNTAX NULL
IDENTIFIED BY
id-pkix-ocsp-nocheck }
-- Object Identifiers
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 }
END
Denis Pinkas Expires March 24, 2013 [Page 43]
INTERNET DRAFT PKIX OCSP September 25, 2012
B.3. Preferred Signature Algorithms ASN.1
B.3.1. ASN.1 module using the 2002 syntax
OCSP-AGILITY-2009 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ocsp-agility-2009-93(66) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
EXPORTS ALL; -- export all items from this module
IMPORTS
id-pkix-ocsp
FROM OCSP-2009 -- From [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) }
AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, PUBLIC-KEY
FROM AlgorithmInformation-2009 -- From [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
EXTENSION
FROM PKIX-CommonTypes-2009 -- From [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} ;
-- Add re-preferred-signature-algorithms to the set of extensions
-- for TBSRequest.requestExtensions
preferred-signature-algorithms EXTENSION ::= {
SYNTAX PreferredSignatureAlgorithms
IDENTIFIED BY id-pkix-ocsp-pref-sig-algs }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
certIdentifier AlgorithmIdentifier{PUBLIC-KEY, {...}} OPTIONAL
}
END
Denis Pinkas Expires March 24, 2013 [Page 44]
INTERNET DRAFT PKIX OCSP September 25, 2012
B.3.2. ASN.1 module using the 1988 syntax
OCSP-AGILITY-88 { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ocsp-agility-2009-88(67) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL;
IMPORTS
id-pkix-ocsp
FROM OCSP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)}
AlgorithmIdentifier
FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) };
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
certIdentifier AlgorithmIdentifier OPTIONAL }
END
Denis Pinkas Expires March 24, 2013 [Page 45]
INTERNET DRAFT PKIX OCSP September 25, 2012
Appendix C. MIME registrations
C.1 application/ocsp-request
To: ietf-types@iana.org Subject: Registration of MIME media type
application/ocsp-request
MIME media type name: application
MIME subtype name: ocsp-request
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a request for information. This
request may optionally be cryptographically signed.
Interoperability considerations: None
Published specification: IETF PKIX Working Group Draft on Online
Certificate Status Protocol - OCSP
Applications which use this media type: OCSP clients
Additional information:
Magic number(s): None
File extension(s): .ORQ
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani <ambarish@valicert.com>
Intended usage: COMMON
Author/Change controller:
Ambarish Malpani <ambarish@valicert.com>
C.2. application/ocsp-response
To: ietf-types@iana.org
Subject: Registration of MIME media type application/ocsp-response
MIME media type name: application
MIME subtype name: ocsp-response
Required parameters: None
Denis Pinkas Expires March 24, 2013 [Page 46]
INTERNET DRAFT PKIX OCSP September 25, 2012
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a cryptographically signed response
Interoperability considerations: None
Published specification: IETF PKIX Working Group Draft on Online
Certificate Status Protocol - OCSP
Applications which use this media type: OCSP servers
Additional information:
Magic number(s): None
File extension(s): .ORS
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Ambarish Malpani <ambarish@valicert.com>
Intended usage: COMMON
Author/Change controller:
Ambarish Malpani <ambarish@valicert.com>
Authors' Address
Denis Pinkas
Bull SAS
BP 78
78340 Les Clayes sous bois
France
EMail: denis.pinkas@bull.net
Denis Pinkas Expires March 24, 2013 [Page 47]
