X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
draft-ietf-pkix-rfc2560bis-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6960.
Expired & archived
|
|
|---|---|---|---|
| Authors | David Cooper , Stefan Santesson | ||
| Last updated | 2012-04-05 (Latest revision 2011-10-03) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-15)
by David Black
Ready w/issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 6960 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-pkix-rfc2560bis-04
Network Working Group D. Cooper
Internet-Draft NIST
Obsoletes: 2560 (if approved) S. Santesson
Intended Status: Proposed Standard 3xA Security
Expires: April 5, 2012 October 3, 2011
X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
draft-ietf-pkix-rfc2560bis-04
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) 2011 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. 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
Cooper Expires April 5, 2012 [Page 1]
INTERNET-DRAFT PKIX OCSP October 3, 2011
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Abstract
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. OCSP Responder Architectures . . . . . . . . . . . . . . . 5
1.2.1. Integrated OCSP Responders . . . . . . . . . . . . . . 5
1.2.2. Designated OCSP Responders . . . . . . . . . . . . . . 5
1.2.3. Locally Trusted OCSP Responders . . . . . . . . . . . 6
1.3. Dynamic Versus Static Responses . . . . . . . . . . . . . 6
2. Detailed Protocol . . . . . . . . . . . . . . . . . . . . . . 6
2.1. OCSP Requests . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Request Extensions . . . . . . . . . . . . . . . . . . 8
2.1.1.1. Nonce . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1.2. Acceptable Response Types . . . . . . . . . . . . 9
2.1.1.3. Preferred Signature Algorithms . . . . . . . . . . 9
2.1.2. Service Locator Single Request Extension . . . . . . . 10
2.2. OCSP Responses . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1. Error Responses . . . . . . . . . . . . . . . . . . . 11
2.3. Basic Response Type . . . . . . . . . . . . . . . . . . . 12
2.3.1. Certificate Revocation Status . . . . . . . . . . . . 14
2.3.2. thisUpdate, nextUpdate, and producedAt . . . . . . . . 15
2.3.3. Nonce Response Extension . . . . . . . . . . . . . . . 15
2.3.4. Single Response Extensions . . . . . . . . . . . . . . 16
2.3.4.1. CRL References . . . . . . . . . . . . . . . . . . 16
2.3.4.2. Archive Cutoff . . . . . . . . . . . . . . . . . . 16
2.3.4.3. Invalidity Date . . . . . . . . . . . . . . . . . 17
2.3.5. Response Signatures . . . . . . . . . . . . . . . . . 17
2.3.5.1. Authorized Responders . . . . . . . . . . . . . . 17
Cooper Expires April 5, 2012 [Page 2]
INTERNET-DRAFT PKIX OCSP October 3, 2011
2.3.5.2. Revocation Information for OCSP Responder's
Certificate . . . . . . . . . . . . . . . . . . . 18
2.3.5.3. Responder Signature Algorithm Selection . . . . . 19
2.3.5.3.1. Dynamic Response . . . . . . . . . . . . . . . 19
2.3.5.3.2. Static Response . . . . . . . . . . . . . . . 20
2.3.6. Response Verification . . . . . . . . . . . . . . . . 20
2.3.6.1. Mandatory and Optional Cryptographic Algorithms . 20
2.3.6.2. Verifying Responder's Authorization . . . . . . . 21
3. OCSP Responder Discovery . . . . . . . . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . . 22
4.1. Use of Insecure Algorithms . . . . . . . . . . . . . . . . 23
4.2. Man in the Middle Downgrade Attack . . . . . . . . . . . . 24
4.3. Denial of Service Attack . . . . . . . . . . . . . . . . . 24
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Normative References . . . . . . . . . . . . . . . . . . . 25
7.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 26
Appendix B. OCSP over HTTP . . . . . . . . . . . . . . . . . . . 26
B.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix C. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 28
C.1. OCSP in ASN.1 . . . . . . . . . . . . . . . . . . . . . . 28
C.2. Preferred Signature Algorithms ASN.1 . . . . . . . . . . . 31
C.2.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 31
C.2.2. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . 32
Appendix D. Media Types . . . . . . . . . . . . . . . . . . . . . 33
D.1. application/ocsp-request . . . . . . . . . . . . . . . . . 33
D.2. application/ocsp-response . . . . . . . . . . . . . . . . 34
Appendix E. Example PKIs With OCSP Responders . . . . . . . . . . 35
E.1. Integrated OCSP Responders . . . . . . . . . . . . . . . . 35
E.2. Designated OCSP Responders . . . . . . . . . . . . . . . . 37
E.3. Locally Trusted OCSP Responder . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
Cooper Expires April 5, 2012 [Page 3]
INTERNET-DRAFT PKIX OCSP October 3, 2011
1. Introduction
In lieu of or as a supplement to checking against a periodic CRL, it
may be necessary to obtain timely information regarding the
revocation status of a certificate (cf. [RFC5280], Section 3.3).
Examples include high-value funds transfer or large stock trades.
The Online Certificate Status Protocol (OCSP) enables applications to
determine the (revocation) state of an identified certificate. OCSP
may be used to satisfy some of the operational requirements of
providing more timely revocation information than is possible with
CRLs and may also be used to obtain additional status information.
An OCSP client issues a status request to an OCSP responder and
suspends acceptance of the certificate in question until the
responder provides a response.
This protocol specifies the data that needs to be exchanged between
an application checking the status of a certificate and the server
providing that status.
An overview of the protocol is provided in this section. Details of
the protocol are in Section 2. Section 3 specifies how information
about the access location of an OCSP responder needs to be
distributed. Security issues with the protocol are covered in
Section 4. Appendix A includes some implementation notes, Appendix B
defines OCSP over HTTP, Appendix C accumulates ASN.1 syntactic
elements, Appendix D specifies the media types for the messages, and
Appendix E provides some examples of architectures of public key
infrastructures (PKI) that include OCSP responders.
This specification obsoletes [RFC2560]. 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 only a few areas:
o Section 2.1.1.1 specifies the ASN.1 syntax for the nonce
extension, which was missing in RFC 2560.
o Section 2.1.1.3 specifies a new 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 2.2.1 extends the use of the "unauthorized" error
response, as specified in [RFC5019].
o Section 2.3 states that a response may include revocation
status information for certificates that were not included in
the request, as permitted in [RFC5019].
Cooper Expires April 5, 2012 [Page 4]
INTERNET-DRAFT PKIX OCSP October 3, 2011
o Section 2.3.6.1 changes set of cryptographic algorithms that
clients must support and the set of cryptographic algorithms
that clients should support.
1.1. Terminology
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].
1.2. OCSP Responder Architectures
In order for an OCSP client to accept a response from a responder,
the responder MUST be authorized to provide the response. The
responder may either be authorized by the certification authority
(CA) that issued the certificate for which status information is
being requested (the target certificate) or by the OCSP client
itself. Authorized OCSP responders fall into one of three
categories: integrated, designated, or locally trusted. The category
into which an OCSP responder falls is based on the perspective of the
OCSP client and depends upon the issuer of the target certificate.
1.2.1. Integrated OCSP Responders
When a CA provides revocation status information for its own
certificates, it is an integrated OCSP responder. If a responder is
an integrated OCSP responder then the subject distinguished name (DN)
in the certificate containing the public key required to verify the
signature on the OCSP response will be the same as the issuer DN in
the target certificate(s). An integrated OCSP responder may sign
certificates and OCSP responses using the same private key or may use
different keys to sign certificates and OCSP responses.
1.2.2. Designated OCSP Responders
Most CAs do not act as OCSP responders themselves, but provide OCSP
services by designating a separate OCSP responder as being authorized
to provide revocation status information for the certificates that
they issue. A responder is a designated OCSP responder if subject DN
in the certificate containing the public key required to verify the
signature on the OCSP response is not the same as the issuer DN in
the target certificate(s), but the certificate was issued by the
issuer of the target certificate(s) and includes a unique value in
the extended key usage extension that indicates that the issuing CA
has authorized the OCSP responder to provide revocation status
information for the certificates that it has issued. Designated OCSP
responders are frequently operated by the same organization as the
CA(s) for which they provide revocation status information.
Cooper Expires April 5, 2012 [Page 5]
INTERNET-DRAFT PKIX OCSP October 3, 2011
1.2.3. Locally Trusted OCSP Responders
Systems or applications that rely on OCSP responses MAY provide a
means of locally configuring one or more OCSP signing authorities,
and specifying the set of CAs for which each signing authority is
trusted. Just as a relying party may choose which CAs to use as
trust anchors for certification path validation, an OCSP client may
choose to accept responses from an OCSP responder even if no CA has
designated that responder as authorized to sign OCSP responses.
Systems and applications may also be designed to only accept OCSP
responses from integrated and designated OCSP responders.
Locally trusted OCSP responders are usually set up by an organization
(or on behalf of an organization) for use by OCSP clients within that
organization. The OCSP responder collects revocation information
(e.g., certificate revocation lists (CRL)) from all CAs within a PKI
and uses this information to generate OCSP responses for its clients.
1.3. Dynamic Versus Static Responses
OCSP responders may generate fresh OCSP responses for each OCSP
request they receive, but they are also permitted to generate static
responses in advance of a request. Pre-generating OCSP responses can
improve efficiency, which may be necessary in high-volume
environments [RFC5019]. Pre-generated responses will generally be
the same as freshly generated responses, but can be identified since
non-error response messages specify the time at which the response
was generated. In addition, an OCSP responder that can only provide
pre-generated responses may send an "unauthorized" error response
when it does not have a pre-generated response that corresponds to
the request.
2. Detailed Protocol
This section presents the OCSP protocol. Section 2.1 presents the
format for OCSP requests, Section 2.2 presents the generic syntax for
OCSP responses, and Section 2.3 presents the syntax for the basic
response type. The ASN.1 syntax in this section imports terms
defined in [RFC5280]. The terms imported from RFC 5280 are:
AlgorithmIdentifier, Certificate, CertificateSerialNumber, CRLReason,
Extensions, GeneralName, id-ad-ocsp, id-kp, Name, and
SubjectPublicKeyInfo.
OCSP requests and responses MAY include extensions. Extensions in
OCSP requests and responses are based on the extension model employed
in X.509 version 3 certificates [RFC5280]. This document specifies
some standard extensions that MAY appear in requests and/or
responses. Additional extensions MAY be defined in additional RFCs.
Cooper Expires April 5, 2012 [Page 6]
INTERNET-DRAFT PKIX OCSP October 3, 2011
Support for any specific extension is OPTIONAL for both clients and
responders. The critical flag SHOULD NOT be set for any of the
extensions defined in this document. Unrecognized extensions MUST be
ignored (unless they have the critical flag set).
For signature calculation, the data to be signed is encoded using the
ASN.1 distinguished encoding rules (DER) [X.690]. The actual
formatting of the request and response messages could vary depending
on the transport mechanism used (HTTP, SMTP, LDAP, etc.).
ASN.1 EXPLICIT tagging is used as a default unless specified
otherwise.
2.1. OCSP Requests
The ASN.1 for an OCSP request message is as follows:
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 }
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuer's public key
serialNumber CertificateSerialNumber }
An OCSP request contains the following data:
o the protocol version, which MUST be v1 (value is 0) for this
version of the protocol;
Cooper Expires April 5, 2012 [Page 7]
INTERNET-DRAFT PKIX OCSP October 3, 2011
o a list of the certificates for which status information is
being requested; and
o optional extensions, which MAY be processed by the OCSP
responder.
Each certificate for which status information is being requested is
identified by:
o issuerNameHash - the hash of the issuer's distinguished name.
The hash MUST be calculated over the DER encoding of the
issuer's name field in the certificate being checked.
o issuerKeyHash - the hash of the issuer's public key. The hash
MUST be calculated over the value of the BIT STRING
subjectPublicKey (excluding tag, length, and number of unused
bits) in the issuer's certificate.
o serialNumber - the serial number of the certificate for which
status is being requested.
The hash algorithm used for both issuerNameHash and issuerKeyHash is
identified in hashAlgorithm.
The requestor MAY choose to sign the OCSP request. In that case, the
signature SHALL be computed over the DER encoding of tbsRequest. If
the request is signed, the requestor MUST specify its name in the
requestorName field. Also, for signed requests, the requestor MAY
include certificates in the certs field of Signature that help the
OCSP responder verify the requestor's signature. If no certificates
are included then certs SHOULD be absent.
2.1.1. Request Extensions
This section defines some standard extensions that may appear in the
requestExtensions field of an OCSP request message. For each
extension, the definition indicates its syntax, processing performed
by the OCSP responder, and any extensions that are included in the
corresponding response.
2.1.1.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 contains an OCTET STRING,
Cooper Expires April 5, 2012 [Page 8]
INTERNET-DRAFT PKIX OCSP October 3, 2011
which 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
2.1.1.2. 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. 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 2.3, OCSP clients MUST be capable of receiving
and processing responses of the id-pkix-ocsp-basic response type.
Thus, when the id-pkix-ocsp-response extension is included in an OCSP
request, the id-pkix-ocsp-basic OID MUST be included as one of the
AcceptableResponses.
2.1.1.3. Preferred Signature Algorithms
A client MAY declare a preferred set of algorithms in a request by
including a preferred signature algorithms extension.
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
certIdentifier AlgorithmIdentifier OPTIONAL }
The syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of
[RFC5280].
sigIdentifier specifies the signature algorithm the client prefers,
e.g., algorithm=ecdsa-with-sha256. Parameters are absent for most
common signature algorithms. [Editor's note: This should be
clarified with respect to RSA (both PKCS #1 v1.5 and PSS) where
parameters are required.]
Cooper Expires April 5, 2012 [Page 9]
INTERNET-DRAFT PKIX OCSP October 3, 2011
certIdentifier 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.
certIdentifier is OPTIONAL and provides a 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.
The server SHOULD use one of the preferred signature algorithms for
signing OCSP responses to the requesting client.
2.1.2. Service Locator Single Request Extension
This document specifies one standard extension that may appear in the
singleRequestExtensions field of an OCSP request message, the service
locator extension.
An OCSP server may be operated in a mode whereby the server receives
a request and routes it to the OCSP server that is known to be
authoritative for the identified certificate. The serviceLocator
request extension is defined for this purpose.
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 in
the subject certificate.
[Editor's note: I don't understand how this extension works. Is the
client telling the OCSP server where to route the request? Can a
single request include multiple certificates, each with a different
value for the service locator field? If so, which responder signs
the response? Is the response always signed by the server that
directly received the request from the client, even though that
server is just routing the request to the authoritative server(s)?
Can anyone provide text for this section that provides more clarity
on the semantics of this extension?]
Cooper Expires April 5, 2012 [Page 10]
INTERNET-DRAFT PKIX OCSP October 3, 2011
2.2. OCSP Responses
The ASN.1 for a response message is as follows:
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 }
Upon receipt of a request, an OCSP responder determines if:
1. the message is well formed;
2. the responder is configured to provide the requested service;
and
3. the request contains the information needed by the responder.
If any one of the prior conditions are not met, the OCSP responder
produces an error message consisting of a responseStatus of
"malformedRequest", "internalError", "tryLater", "sigRequired", or
"unauthorized", and with responseBytes absent. If all of the prior
conditions are met, the OCSP responder produces a response with a
responseStatus of "successful" and with the responseBytes field
present. The value for responseBytes consists of an OBJECT
IDENTIFIER and a response syntax identified by that OID, encoded as
an OCTET STRING.
2.2.1. Error Responses
An error response message consists of an OCSPResponse in which only
the responseStatus field is present. These messages are not signed.
For error responses, responseStatus MUST be one of the following:
Cooper Expires April 5, 2012 [Page 11]
INTERNET-DRAFT PKIX OCSP October 3, 2011
o malformedRequest: the request received does not conform to the
OCSP syntax.
o internalError: the OCSP responder reached an inconsistent
internal state. The query should be retried, potentially with
another responder.
o tryLater: the OCSP responder is operational, but is temporarily
unable to return a status for one or more of the requested
certificates.
o sigRequired: the request is unsigned, but the server requires
the client to sign the request in order to construct a
response.
o unauthorized: 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).
2.3. Basic Response Type
While OCSP responses may be of various types, this document specifies
only one response type, the basic response type, which MUST be
supported by all OCSP servers and clients. This section describes
the basic response type.
The basic response type is identified by the id-pkix-ocsp-basic OID:
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }
When the responseType is id-pkix-ocsp-basic the response field SHALL
contain 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 DER encoding of
tbsResponseData. The responder MAY include certificates in the certs
field of BasicOCSPResponse that help the OCSP client verify the
responder's signature. If no certificates are included then certs
SHOULD be absent.
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
Cooper Expires April 5, 2012 [Page 12]
INTERNET-DRAFT PKIX OCSP October 3, 2011
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
-- (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
The basic response type contains:
o the version of the response syntax, which MUST be v1 (value is
0) for this version of the basic response syntax;
o either the name of the responder or a hash of the responder's
public key;
o the time at which the response was generated;
o responses for each of the certificates in a request;
o optional extensions;
o a signature computed across a hash of the response; and
Cooper Expires April 5, 2012 [Page 13]
INTERNET-DRAFT PKIX OCSP October 3, 2011
o the signature algorithm OID.
The responder MAY include certificates in the certs field of
BasicOCSPResponse that help the OCSP client verify the responder's
signature.
The response for each of the certificates in a request consists of:
o an identifier of the certificate for which revocation status
information is being provided (i.e., the target certificate);
o the revocation status of the certificate (good, revoked, or
unknown);
o the validity interval of the response; and
o optional extensions.
The response MUST include a SingleResponse for each certificate in
the request and SHOULD NOT include any additional SingleResponse
elements. 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. [Editor's note: From Section 2.2.1 of RFC 5019.]
2.3.1. Certificate Revocation Status
For each of the certificates identified, the response message MUST
indicate a status of "good", "revoked", or "unknown".
A status of "good" indicates that the certificate has not been
revoked. It does not indicate that the certificate was ever issued
or that it is in its validity interval.
A status of "revoked" indicates that the certificate has been revoked
(either permanently or temporarily (on hold)). When the "revoked"
status is returned the response MUST indicate the time at which
revocation occurred and MAY indicate the reason for the revocation.
If an OCSP responder knows that a particular CA's private key has
been compromised, it MAY return the "revoked" status for all
certificates issued by that CA.
A status of "unknown" indicates that the responder doesn't know about
the certificate being requested.
Response extensions may be used to convey additional information on
assertions made by the responder regarding the status of the
Cooper Expires April 5, 2012 [Page 14]
INTERNET-DRAFT PKIX OCSP October 3, 2011
certificate such as a positive statement about issuance, expiry, etc.
2.3.2. thisUpdate, nextUpdate, and producedAt
Responses can contain three times in them - thisUpdate, nextUpdate,
and producedAt. The semantics of these fields are:
o thisUpdate: The time at which the status being indicated is
known to be correct.
o nextUpdate: The time at or before which newer information will
be available about the status of the certificate.
o producedAt: The time at which the OCSP responder signed this
response.
The thisUpdate and nextUpdate fields define a recommended validity
interval. This interval corresponds to the {thisUpdate, nextUpdate}
interval in CRLs. Responses whose thisUpdate time is later than the
local system time SHOULD be considered unreliable. Responses whose
nextUpdate value is earlier than the local system time value SHOULD
be considered unreliable. If nextUpdate is not set, the responder is
indicating that newer revocation information is available all the
time.
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. The time at or before which newer information
will be available is reflected in the nextUpdate field, while the
time at which the response was produced will appear in the producedAt
field of the response.
2.3.3. Nonce Response Extension
This document defines one standard extension that may appear in the
responseExtensions field of OCSP response messages. The nonce
cryptographically binds a request and a response to prevent replay
attacks. The nonce extension in the response is identified using the
same object identifier as is used in the request, id-pkix-ocsp-nonce.
If the request included a nonce extension (Section 2.1.1.1) then the
response MUST either omit the nonce extension or include a nonce
extension that has the same value as the nonce extension in the
request.
An OCSP responder MAY include a nonce extension in a response even if
no nonce extension was included in the corresponding request.
Cooper Expires April 5, 2012 [Page 15]
INTERNET-DRAFT PKIX OCSP October 3, 2011
Clients that do not include a nonce in the request MUST ignore any
nonce that may be present in the response.
2.3.4. Single Response Extensions
This section defines some standard extensions that may appear in the
singleExtensions field of OCSP response messages. Each extension in
this section provides additional information about a single
certificate in the response.
2.3.4.1. CRL References
It may be desirable for the OCSP responder to indicate the CRL on
which a revoked or on hold 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). 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 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.
2.3.4.2. 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 responders that provide support for such historical reference
SHOULD include an archive cutoff date extension in responses. The
identifier for this extension will be id-pkix-ocsp-archive-cutoff,
Cooper Expires April 5, 2012 [Page 16]
INTERNET-DRAFT PKIX OCSP October 3, 2011
while the value will be ArchiveCutoff.
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).
Note that when an OCSP response includes status information for more
than one certificate, the server may choose to include the archive
cutoff extension for only some of the certificates and may specify
different ArchiveCutoff values for different certificates.
2.3.4.3. Invalidity Date
For certificates with a revocation status of "revoked", OCSP
responders may include the invalidity date CRL entry extension, as
described in Section 5.3.2 of [RFC5280], in singleExtensions to
provide the date on which it is known or suspected that the private
key was compromised or that the the certificate otherwise became
invalid.
2.3.5. Response Signatures
All responses of the basic response type MUST be digitally signed.
This section addresses the means by which OCSP responders determine
which key and signature algorithm to use to ensure that OCSP clients
can verify the signatures on OCSP response messages.
2.3.5.1. Authorized Responders
As described in Section 1.2, in order for an OCSP client to accept a
response from a responder for which it is not locally configured to
accept OCSP responses, the responder MUST be authorized by the issuer
of the target certificate(s). This section provides additional
information about the requirements for a CA to designate an OCSP
responder as authorized to provide revocation status information for
the certificates that it issues.
o Integrated OCSP responder
CAs that sign OCSP responses implicitly authorize themselves to
provide revocation status information for the certificates that
they issue. When a CA signs OCSP responses to provide revocation
status information for its own certificates, it may sign the
responses using the same key as was used to sign the target
Cooper Expires April 5, 2012 [Page 17]
INTERNET-DRAFT PKIX OCSP October 3, 2011
certificate(s) or using a different key. One reason that a CA may
sign an OCSP response using a different key would be if the CA had
performed a key rollover since it issued the target
certificate(s).
Note: Some OCSP clients, when accepting responses from an
integrated OCSP responder, will only accept responses that are
signed using the same key as the target certificate(s).
o Designated OCSP responder
In order for a CA to designate an OCSP responder other than itself
as authorized to provide revocation status information for the
certificates that it issues, the CA MUST issue a certificate to
the OCSP responder that:
o contains the public key required to validate the signatures
on OCSP responses signed by the responder; and
o has an extended key usage extension that includes the
id-kp-OCSPSigning OID.
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
The CA does not need to sign this certificate using the same key
as was used to sign the target certificate(s), but the certificate
MUST be issued to the OCSP responder directly by the CA that
issued the target certificate(s).
Note: Some OCSP clients, when accepting responses from a
designated OCSP responder, will only accept responses if the
certificate required to validate the signature on the response
was signed using the same key as the target certificate(s).
2.3.5.2. Revocation Information for OCSP Responder's Certificate
Since an authorized OCSP responder provides revocation status
information for one or more CAs, OCSP clients need to know how to
check that an authorized responder's certificate has not been
revoked. CAs may choose to deal with this problem in one of three
ways:
o 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.
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
Cooper Expires April 5, 2012 [Page 18]
INTERNET-DRAFT PKIX OCSP October 3, 2011
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.
[Editor's note: I changed "should be NULL" to "SHALL be NULL".]
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
o A CA may specify how to check the responder's certificate 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].
o 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.
2.3.5.3. Responder Signature Algorithm Selection
This section describes rules for the OCSP responder to use to select
the algorithm to use to sign the response.
2.3.5.3.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 signature algorithm
in the client request.
2. Select the signature algorithm used to sign a CRL issued by the
certificate issuer providing status information for the
certificate specified by CertID.
3. Select the signature algorithm used to sign the OCSP request.
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 (see Section 2.3.6.1).
Cooper Expires April 5, 2012 [Page 19]
INTERNET-DRAFT PKIX OCSP October 3, 2011
A responder SHOULD always apply the lowest numbered selection
mechanism that is known, supported, and that meets the responder's
criteria for cryptographic algorithm strength.
2.3.5.3.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.
2.3.6. Response Verification
Prior to accepting a response of the basic response type as valid,
OCSP clients MUST confirm that:
1. the certificates identified in the response correspond to the
certificates that were identified in the corresponding
request;
2. the signature on the response is valid;
3. the signer is currently authorized to sign the response (see
Section 2.3.6.2);
4. the time at which the status being indicated is known to be
correct (thisUpdate) is sufficiently recent; and
5. when nextUpdate is set in the response, it is greater than the
current time.
2.3.6.1. Mandatory and Optional Cryptographic Algorithms
Clients that request OCSP services MUST be capable of processing
responses signed using RSA with SHA-1 (identified by the
sha1WithRSAEncryption OID specified in [RFC3279]) and RSA with
SHA-256 (identified by the 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.
Cooper Expires April 5, 2012 [Page 20]
INTERNET-DRAFT PKIX OCSP October 3, 2011
2.3.6.2. Verifying Responder's Authorization
Systems or applications that rely on OCSP responses MUST reject a
response if the certificate required to validate the signature on the
response fails to meet at least one of the following criteria:
1. Matches a local configuration of OCSP signing authority for
the certificate in question (i.e., is signed by a locally
trusted OCSP responder).
2. Is the certificate of the CA that issued the certificate in
question. (For this criterion to be satisfied, the subject DN
in the certificate required to validate the signature on the
OCSP response MUST be the same as the issuer DN in the
certificate in question.)
3. Has an extended key usage extension that includes the id-kp-
OCSPSigning OID and is issued by the CA that issued the
certificate in question. (For this criterion to be satisfied,
the issuer DN in the certificate required to validate the
signature on the OCSP response MUST be the same as the issuer
DN in the certificate in question.)
Systems or applications that rely on OCSP responses MUST be capable
of detecting and enforcing use of the id-kp-OCSPSigning value as
described in Section 2.3.5.1. They MAY provide a means of locally
configuring one or more OCSP signing authorities, and specifying the
set of CAs for which each signing authority is trusted.
Additional acceptance or rejection criteria may apply to either the
response itself or to the certificate used to validate the signature
on the response.
3. OCSP Responder Discovery
CAs that operate as integrated OCSP responders or that designate one
or more OCSP responders as authorized to provide revocation status
information for the certificates that they issue MUST include an
authorityInfoAccess extension (defined in [RFC5280], Section 4.2.2.1)
in certificates that can be checked using OCSP. The
authorityInfoAccess extension MUST include an entry with an
accessMethod of id-ad-ocsp and an accessLocation that is a
uniformResourceIdentifier (URI). The value of the accessLocation
field in the certificate defines the transport (e.g., HTTP) used to
access the OCSP responder and may contain other transport dependent
information (e.g., a URL).
Cooper Expires April 5, 2012 [Page 21]
INTERNET-DRAFT PKIX OCSP October 3, 2011
Information about the access location of OCSP responders that are
neither integrated nor designated SHOULD NOT be included in the
authorityInfoAccess extension of certificates. Instead, the access
location for such OCSP responders SHOULD be provided using out-of-
band means and be configured locally at the OCSP client.
[Editor's note: This text was based on my original interpretation of
Section 3.1 in RFC 2560. However, emails from 1999
(http://www.ietf.org/mail-archive/web/pkix/current/msg25976.html)
imply that the text was only intended to impose a requirement on CA
products, not to require CAs to include the extension under certain
circumstances. Was the second paragraph in Section 3.1 of RFC 2560
only intended to impose a requirement on CA products?]
4. Security Considerations
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.
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. Unsigned error responses open up the
protocol to another denial of service attack, where the attacker
sends false error responses.
The use of pre-computed 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 pre-computed responses against the
probability of a replay attack and the costs associated with its
successful execution.
Requests do not contain the responder to which they are directed.
This allows an attacker to replay a request to any number of OCSP
responders.
While X.509 mandates that names be unambiguous, there is a risk that
two unrelated authorities will issue certificates and/or OCSP
responses under the same name. As a means of reducing problems and
security issues related to issuer name collisions, CA and OCSP
responder names SHOULD be formed in a way that reduces the likelihood
of name collisions. Implementers should take into account the
possible existence of multiple unrelated CAs and OCSP responders with
the same name. At a minimum, implementations validating OCSP
responses MUST ensure that the certification path of a target
Cooper Expires April 5, 2012 [Page 22]
INTERNET-DRAFT PKIX OCSP October 3, 2011
certificate and the certification path of the certificate required to
validate the signature on the OCSP response terminate at the same
trust anchor, except in the case that the OCSP response was signed by
a locally trusted OCSP responder.
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.
Implementers are advised to take the reliability of HTTP cache
mechanisms into account when deploying OCSP over HTTP.
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. However, this criteria
may not hold in long-term archival applications in which the status
of a certificate is being queried for a date in the distant past,
long after the signing algorithm has ceased being considered
trustworthy.
4.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 the responder MUST NOT generate a signature for a
signing mechanism that is considered unacceptably insecure.
A client MUST accept any signature algorithm in a response that it
specified as a preferred signature algorithm in the request. It
follows, therefore, that a client MUST NOT specify as a preferred
signature algorithm any algorithm that is either not supported or not
considered acceptably secure.
Cooper Expires April 5, 2012 [Page 23]
INTERNET-DRAFT PKIX OCSP October 3, 2011
4.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 signature algorithm of the
response.
4.3. Denial of Service Attack
Algorithm agility mechanisms defined in this document introduce 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 or that do not match pre-generated responses.
5. IANA Considerations
Request types and extensions in OCSP requests and responses are
identified using object identifiers. The objects are identified in
an arc delegated by IANA to the PKIX Working Group. No further
action by IANA is necessary for this document or any anticipated
updates.
6. Acknowledgments
TBD
Cooper Expires April 5, 2012 [Page 24]
INTERNET-DRAFT PKIX OCSP October 3, 2011
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.
[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.
[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.
Cooper Expires April 5, 2012 [Page 25]
INTERNET-DRAFT PKIX OCSP October 3, 2011
Appendix A. Implementation Notes
RFC 2560 did not specify a syntax for the nonce extension. As a
result, some OCSP clients and responders may not populate extnValue
for the nonce extension with a DER encoded OCTET STRING. OCSP
responders that support the nonce extension should be prepared to
accept such values from OCSP clients and should place the exact same
value in the extnValue of the nonce extension in the response as
appeared in the request. OCSP clients that do not include a nonce
extension in a request should be prepared to accept responses that
include nonce extensions in which extnValue does not contain a DER
encoded OCTET STRING.
OCSP does not provide a mechanism for an OCSP responder to indicate
whether it supports the nonce extension. If an OCSP responder that
provides fresh responses to every request that includes a nonce only
includes a nonce in responses corresponding to requests that include
a nonce then an attacker could obtain a response without a nonce and
then later replay it to a client that included a nonce in its
request. The client may be unable to distinguish this replayed
response from a response received directly from a responder that does
not support the nonce extension. A responder that supports the nonce
extension may protect against this by including a randomly generated
nonce in any response that corresponds to a request that did not
include a nonce extension.
Appendix B. OCSP over HTTP
This appendix describes the formatting that will be done to the
request and response to support HTTP [RFC2616].
B.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.
Cooper Expires April 5, 2012 [Page 26]
INTERNET-DRAFT PKIX OCSP October 3, 2011
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.
B.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.
Cooper Expires April 5, 2012 [Page 27]
INTERNET-DRAFT PKIX OCSP October 3, 2011
Appendix C. ASN.1 Modules
This appendix includes the ASN.1 modules for OCSP. Appendix C.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. An alternative to this module that conforms to
the 2002 version of ASN.1 my be found in Section 4 of [RFC5912].
Appendix C.2 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.
C.1. OCSP in ASN.1
OCSP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)}
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 }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
Cooper Expires April 5, 2012 [Page 28]
INTERNET-DRAFT PKIX OCSP October 3, 2011
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 }
Cooper Expires April 5, 2012 [Page 29]
INTERNET-DRAFT PKIX OCSP October 3, 2011
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 }
-- 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
Cooper Expires April 5, 2012 [Page 30]
INTERNET-DRAFT PKIX OCSP October 3, 2011
C.2. Preferred Signature Algorithms ASN.1
C.2.1. ASN.1 Module
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
re-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
Cooper Expires April 5, 2012 [Page 31]
INTERNET-DRAFT PKIX OCSP October 3, 2011
C.2.2. 1988 ASN.1 Module
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
Cooper Expires April 5, 2012 [Page 32]
INTERNET-DRAFT PKIX OCSP October 3, 2011
Appendix D. Media Types
D.1. application/ocsp-request
Type name: application
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: X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
Applications that 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@yahoo.com>
Intended usage: COMMON
Restrictions on usage: none
Author:
Ambarish Malpani <ambarish@yahoo.com>
Change controller:
The IESG <iesg@ietf.org>
Cooper Expires April 5, 2012 [Page 33]
INTERNET-DRAFT PKIX OCSP October 3, 2011
D.2. application/ocsp-response
Type name: application
Subtype name: ocsp-response
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a cryptographically signed response.
Interoperability considerations: None
Published specification: X.509 Internet Public Key Infrastructure
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@yahoo.com>
Intended usage: COMMON
Restrictions on usage: none
Author:
Ambarish Malpani <ambarish@yahoo.com>
Change controller:
The IESG <iesg@ietf.org>
Cooper Expires April 5, 2012 [Page 34]
INTERNET-DRAFT PKIX OCSP October 3, 2011
Appendix E. Example PKIs With OCSP Responders
This appendix provides some examples of valid PKI architectures that
include OCSP responders.
E.1. Integrated OCSP Responders
The examples in this appendix involve integrated OCSP responders.
None of the certificates depicted in the examples in this appendix
include an extended key usage extension that asserts the
id-kp-OCSPSigning OID.
Figure 1 depicts a scenario in which the OCSP response is signed
using the same key as the target certificate.
+-----------------------------------------+
| Certification Authority/OCSP Responder |
| +-------------------------------------+ |
| | CA's certificate | |
| | +-------------------------------+ | |
| | | certificate and OCSP response | | |
| | | signing key | | |
| | +---|---------------------|-----+ | |
| +------|---------------------|--------+ |
+--------|---------------------|----------+
| |
V V
+---------------+ +--------------------+
| OCSP response | | target certificate |
+---------------+ +--------------------+
Figure 1. Integrated OCSP Responder With One Certificate and OCSP
Response Signing Key
Figures 2 and 3 depict scenarios in which the OCSP response is signed
using a different key than the one used to sign the target
certificate. In each case, the CA has performed a key rollover since
it issued the target certificate, and is using its new key to sign
OCSP responses. In Figure 2, the CA has used its new private key to
sign a self-issued certificate that contains its old public key. In
Figure 3, the CA has been issued a new certificate from the root CA,
while the certificate from the root CA certifying the old public key
remains valid.
Cooper Expires April 5, 2012 [Page 35]
INTERNET-DRAFT PKIX OCSP October 3, 2011
+------------------------------------------------------+
| Certification Authority/OCSP Responder |
| +-------------------+ +-------------------------+ |
| | CA's certificate | | self-issued certificate | |
| | +---------------+ | | +-------------+ | |
| | | OCSP response | | | | certificate | | |
| | | signing key |----------->| signing key | | |
| | +-----|---------+ | | +----|--------+ | |
| +-------|-----------+ +----------|--------------+ |
+---------|---------------------------|----------------+
| |
V V
+---------------+ +--------------------+
| OCSP response | | target certificate |
+---------------+ +--------------------+
Figure 2. Integrated OCSP Responder With a Self-issued Key
Rollover Certificate
+-----------------------------------------+
| Root CA |
| +-------------------------------------+ |
| | Root CA's self-signed certificate | |
| | +-------------------------------+ | |
| | | certificate | | |
| | | signing key | | |
| | +--|-------------------------|--+ | |
| +-----|-------------------------|-----+ |
+-------|-------------------------|-------+
| |
+-----------|-------------------------|------------+
| V CA/OCSP Responder V |
|+--------------------+ +--------------------+ |
|| CA's certificate 2 | | CA's certificate 1 | |
|| +---------------+ | | +-------------+ | |
|| | OCSP response | | | | certificate | | |
|| | signing key | | | | signing key | | |
|| +------|--------+ | | +------|------+ | |
|+--------|-----------+ +---------|----------+ |
+---------|---------------------------|------------+
| |
V V
+---------------+ +--------------------+
| OCSP response | | target certificate |
+---------------+ +--------------------+
Figure 3. Integrated OCSP Responder With a Separate Key Certified
by Root CA
Cooper Expires April 5, 2012 [Page 36]
INTERNET-DRAFT PKIX OCSP October 3, 2011
E.2. Designated OCSP Responders
The examples in this appendix involve designated OCSP responders.
Certificates that are marked with "**" include an extended key usage
extension with the id-kp-OCSPSigning OID.
Figure 4 depicts a scenario in which the OCSP responder's certificate
is signed using the same key as the target certificate.
+-----------------------------------------+
| Certification Authority | +----------------------+
| +-------------------------------------+ | | OCSP Responder's |
| | CA's certificate | | | certificate **|
| | +-------------------------------+ | | | +------------------+ |
| | | certificate signing key |------>| | OCSP Responder's | |
| | +---------------|---------------+ | | | | key | |
| +------------------|------------------+ | | +--------|---------+ |
+--------------------|--------------------+ +----------|-----------+
| |
V V
+--------------------+ +---------------+
| target certificate | | OCSP response |
+--------------------+ +---------------+
Figure 4. Designated OCSP Responder in Which CA Has One Certificate
Signing Key
+-------------------------------------------------------------------+
| Root CA |
| +-----------------------------------+ +------------------------+|
| | Root CA's self-signed certificate | | OCSP certificate **||
| | +-------------------------------------------------------------+||
| | | certificate and OCSP signing key |||
| | +---------------|---------------------------------------------+||
| +-----------------|-----------------+ +------------------------+|
+-------------------|---------------------------------^-------------+
| |
V |
+-----------------------------+ |
| Subordinate CA certificate | |
| +-------------------------+ | |
| | certificate signing key |--------------------'
| +-------------------------+ |
+-----------------------------+
Figure 5. Integrated and Designated OCSP Responder
Cooper Expires April 5, 2012 [Page 37]
INTERNET-DRAFT PKIX OCSP October 3, 2011
Figure 5 depicts a hierarchical PKI in which the root CA uses its key
to sign OCSP responses for both the certificates that it issues and
certificates issued by the subordinate CA. The subordinate CA has
designated the root CA as authorized to provide revocation status
information for the certificates that it issues by issuing a
certificate to the root CA with an extended key usage extension that
includes the id-kp-OCSPSigning OID. When an OCSP client is verifying
a response from the OCSP responder that provides status information
for a target certificate issued by the root CA the responder is an
integrated OCSP responder. When an OCSP client is verifying a
response from the OCSP responder that provides status information a
target certificate issued by the subordinate CA the responder is a
designated OCSP responder.
Figure 6 depicts a scenario in which the OCSP responder's certificate
is signed using a different key than the one used to sign the target
certificate. The CA has performed a key rollover since it issued the
target certificate, and the OCSP responder's certificate was signed
using the CA's new private key. The CA has used its new private key
to sign a self-issued certificate that contains its old public key.
+-----------------------------------------------------+
| Certification Authority |
|+--------------------+ +-------------------------+ |
|| CA's certificate | | self-issued certificate | |
|| +---------------+ | | +---------------+ | |
|| | certificate | | | | certificate | | |
|| | signing key 2 |---------->| signing key 1 | | |
|| +----------|----+ | | +-------|-------+ | |
|+------------|-------+ +------------|------------+ |
+-------------|------------------------|--------------+
| |
V V
+----------------------+ +-------------+
| OCSP Responder's | | target |
| certificate **| | certificate |
| +------------------+ | +-------------+
| | OCSP Responder's | |
| | key ------>+---------------+
| +------------------+ | | OCSP response |
+----------------------+ +---------------+
Figure 6. Designated OCSP Responder and CA with a Self-issued Key
Rollover Certificate
Figure 7 depicts another scenario in which the OCSP responder's
certificate is signed using a different key than the one used to sign
Cooper Expires April 5, 2012 [Page 38]
INTERNET-DRAFT PKIX OCSP October 3, 2011
the target certificate. As in Figure 6, the CA has performed a key
rollover since it issued the target certificate, and the OCSP
responder's certificate was signed using the CA's new private key.
In this case, however, the CA has been issued a new certificate from
the root CA, while the certificate from the root CA certifying the
old public key remains valid.
In the PKI in Figure 7, there is also a designated OCSP responder
that provides revocation status information for certificates issued
by the root CA. So, the root CA has issued a certificate to this
OCSP responder that includes an extended key usage extension with the
id-kp-OCSPSigning OID.
+-----------------------------------------+
| Root CA | +----------------------+
| +-------------------------------------+ | | Root's OCSP |
| | Root CA's self-signed certificate | | | Responder's **|
| | +-------------------------------+ | | | certificate |
| | | certificate | | | | +------------------+ |
| | | signing key |-------->| Root's OCSP | |
| | +-|---------------------------|-+ | | | | Responder's key | |
| +----|---------------------------|----+ | | +------------------+ |
+------|---------------------------|------+ +----------------------+
| |
+------|---------------------------|------------------+
| V Certification Authority V |
| +----------------------+ +--------------------+ |
| | CA's certificate 2 | | CA's certificate 1 | |
| | +---------------+ | | +---------------+ | |
| | | certificate | | | | certificate | | |
| | | signing key 2 | | | | signing key 1 | | |
| | +----------|----+ | | +-----|---------+ | |
| +-------------|--------+ +--------|-----------+ |
+---------------|-----------------------|-------------+
| |
V V
+----------------------+ +-------------+
| OCSP Responder's | | target |
| certificate **| | certificate |
| +------------------+ | +-------------+
| | OCSP Responder's | |
| | key ------->+---------------+
| +------------------+ | | OCSP response |
+----------------------+ +---------------+
Figure 7. Designated OCSP Responder and CA With Two Keys Certified
by Root CA
Cooper Expires April 5, 2012 [Page 39]
INTERNET-DRAFT PKIX OCSP October 3, 2011
As noted in Section 2.3.5.1, some OCSP clients cannot validate
signatures on OCSP responses created by designated OCSP responders if
the OCSP responder's certificate has been signed using a different
key than the target certificate. Figure 8 depicts a CA that
accommodates this limitation by issuing two certificates to the
designated OCSP responder, one signed with its old private key and
one signed with its new private key. Both certificates include an
extended key usage extension with the id-kp-OCSPSigning OID.
As in Figure 7, there is also a designated OCSP responder that
provides revocation status information for certificates issued by the
root CA, and so this responder has been issued a certificate by the
root CA.
+-----------------------------------------+
| Root CA | +----------------------+
| +-------------------------------------+ | | Root's OCSP |
| | Root CA's self-signed certificate | | | Responder's **|
| | +-------------------------------+ | | | certificate |
| | | certificate | | | | +------------------+ |
| | | signing key |-------->| Root's OCSP | |
| | +-|---------------------------|-+ | | | | Responder's key | |
| +----|---------------------------|----+ | | +------------------+ |
+------|---------------------------|------+ +----------------------+
| |
+------|---------------------------|------------------+
| V Certification Authority V |
| +----------------------+ +--------------------+ |
| | CA's certificate 2 | | CA's certificate 1 | |
| | +---------------+ | | +---------------+ | |
| | | certificate | | | | certificate | | |
| | | signing key 2 | | | | signing key 1 | | |
| | +----------|----+ | | +-----|---------+ | |
| +-------------|--------+ +--------|-----------+ |
+---------------|-----------------------|-------------+
| |
V V
+----------------------+ +----------------------+
| OCSP Responder's | | OCSP Responder's |
| certificate 2 **| | certificate 1 **|
| +-----------------------------------------------+ |
| | OCSP Responder's key | |
| +-----------------------------------------------+ |
+----------------------+ +----------------------+
Figure 8. Designated OCSP Responder With Two Certificates
Cooper Expires April 5, 2012 [Page 40]
INTERNET-DRAFT PKIX OCSP October 3, 2011
Figure 9 depicts a scenario in which an organization has a
hierarchical PKI with three CAs, but has a single designated OCSP
responder, which each CA has designated as being authorized to
provide revocation status information for the certificates that it
has issued. In order to satisfy the requirement that the authorizing
CA issue a certificate directly to the designated OCSP responder,
each of the CAs has issued a certificate to the OCSP responder that
includes the id-kp-ocspSigning OID in the extended key usage
extension. The subject public key in each of the three certificates
issued to the OCSP responder is the same since the OCSP responder
uses the same private key to sign all responses.
+-----------------------------------------+
| Root CA |
| +-------------------------------------+ |
| | Root CA's self-signed certificate | |
| | +-------------------------------+ | |
| | | Root CA's certificate | | |
| | | signing key | | |
| | +----|------------|---------|---+ | |
| +-------|------------|---------|------+ |
+---------|------------|---------|--------+
| | |
+----------------|-------+ | +----|-------------------+
| CA 1 V | | | V CA 2 |
| +--------------------+ | | | +--------------------+ |
| | CA 1's certificate | | | | | CA 2's certificate | |
| | +---------------+ | | | | | +---------------+ | |
| | | CA 1's | | | | | | | CA 2's | | |
| | | certificate | | | | | | | certificate | | |
| | | signing key | | | | | | | signing key | | |
| | +-----|---------+ | | | | | +---------|-----+ | |
| +-------|------------+ | | | +------------|-------+ |
+---------|--------------+ | +--------------|---------+
| | |
V V V
+------------------+ +------------------+ +------------------+
| OCSP Responder's | | OCSP Responder's | | OCSP Responder's |
| certificate 1 **| | certificate 2 **| | certificate 3 **|
| +--------------------------------------------------------+ |
| | OCSP Responder's key | |
| +--------------------------------------------------------+ |
+------------------+ +------------------+ +------------------+
Figure 9. Hierarchical PKI with One Designated OCSP Responder
Cooper Expires April 5, 2012 [Page 41]
INTERNET-DRAFT PKIX OCSP October 3, 2011
E.3. Locally Trusted OCSP Responder
Figure 10 depicts a PKI with a locally trusted OCSP responder. The
PKI consists of six companies' CAs that are connected through a
bridge CA. Company F operates an OCSP responder that it only makes
accessible to computers owned by Company F. Company F's computers
have been configured to trust the OCSP responder's public key to
validate signatures on OCSP responses and have also been configured
to use the OCSP responder to obtain revocation status information for
all certificates.
Each of the CAs in the PKI issues CRLs, which they make available
from publicly accessible directories. The OCSP responder retrieves
these CRLs and uses the information in them to generate responses for
its clients.
+-----------+ +-----------+ +-----------+
| Company A | | Company B | | Company C |
| CA | | CA | | CA |
+-----------+ +-----------+ +-----------+
\ | /
\ | /
+-----------+ +----------------+ +-----------+
| Company D | | Bridge | | Company E |
| CA |---| CA |---| CA |
+-----------+ +----------------+ +-----------+
|
|
+-------------+
| Company F |
| Root CA |
+-------------+
/ | \
/ | \
+-----------+ +-----------+ +-----------+
| Company F | | Company F | | Company F |
| Sub CA 1 | | Sub CA 2 | | Sub CA 3 |
+-----------+ +-----------+ +-----------+
+------------------------------+
| Company F's OCSP Responder's |
| self-signed certificate |
| +----------------------+ | +---------------+
| | OCSP Responder's key |------>| OCSP response |
| +----------------------+ | +---------------+
+------------------------------+
Figure 10. Locally Trusted OCSP Responder
Cooper Expires April 5, 2012 [Page 42]
INTERNET-DRAFT PKIX OCSP October 3, 2011
Author's Address
David Cooper
National Institute of Standards and Technology
100 Bureau Drive, Mail Stop 8930
Gaithersburg, MD 20899-8930
USA
EMail: david.cooper@nist.gov
Stefan Santesson
3xA Security AB
Scheelev. 17
223 70 Lund
Sweden
EMail: sts@aaa-sec.com
Cooper Expires April 5, 2012 [Page 43]