INTERNET-DRAFT D. Cooper
Intended Status: Proposed Standard NIST
Obsoletes: 2560 (once approved) June 28, 2010
Expires: December 30, 2010
X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
<draft-cooper-pkix-rfc2560bis-00.txt>
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) 2010 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
described in the Simplified BSD License.
Cooper Expires December 30, 2010 [Page 1]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . 14
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
2.3.5.2. Revocation Information for OCSP Responder's
Certificate . . . . . . . . . . . . . . . . . 18
Cooper Expires December 30, 2010 [Page 2]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 . . . . . . . . . . . . . . . . . 21
2.3.6.2. Verifying Responder's Authorization . . . . . 21
3. OCSP Responder Discovery . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. OCSP over HTTP . . . . . . . . . . . . . . . . . . . 25
A.1. Request . . . . . . . . . . . . . . . . . . . . . . . . 25
A.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix B. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 26
B.1. OCSP in ASN.1 . . . . . . . . . . . . . . . . . . . . . 27
B.2. Preferred Signature Algorithms ASN.1 . . . . . . . . . . 30
B.2.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . 30
B.2.2. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . 31
Appendix C. Media Types . . . . . . . . . . . . . . . . . . . . 32
C.1. application/ocsp-request . . . . . . . . . . . . . . . . 32
C.2. application/ocsp-response . . . . . . . . . . . . . . . 33
Appendix D. Example PKIs With OCSP Responders . . . . . . . . . 34
D.1. Integrated OCSP Responders . . . . . . . . . . . . . . . 34
D.2. Designated OCSP Responders . . . . . . . . . . . . . . . 36
D.3. Locally Trusted OCSP Responder . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
Cooper Expires December 30, 2010 [Page 3]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 defines OCSP over HTTP, Appendix B accumulates
ASN.1 syntactic elements, Appendix C specifies the media types for
the messages, and Appendix D 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.3 specifies a new request extension that allows
the client to specify preferred signature algorithms for the
server to 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].
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.
Cooper Expires December 30, 2010 [Page 4]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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
A responder is an integrated OCSP responder if the subject
distinguished name (DN) in the certificate containing the public key
required to verify the signature on the OCSP response is the same as
the issuer DN in the target certificate(s). In other words, an
integrated OCSP responder is a responder that provides revocation
status information for its own certificates. 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
distinguished name (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 December 30, 2010 [Page 5]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 error response when it does not
have a pre-generated response that corresponds to the request.
2. Protocol Overview
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.
Support for any specific extension is OPTIONAL for both clients and
Cooper Expires December 30, 2010 [Page 6]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 December 30, 2010 [Page 7]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 SHALL 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
SHALL be calculated over the value (excluding tag and length)
of the subject public key field 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 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 in the certs field of Signature that help the OCSP
responder verify the requestor's signature.
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 is the value of the nonce.
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
Cooper Expires December 30, 2010 [Page 8]
INTERNET-DRAFT PKIX OCSP June 28, 2010
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
[Editor's note: What is the syntax for the nonce extension? Section
4.1 of RFC 5280 states that extnValue "contains the DER encoding of
an ASN.1 value corresponding to the extension type identified by
extnID". Does that apply for the nonce extension? Is so, what is the
ASN.1? OCTET STRING? INTEGER? ANY?]
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 December 30, 2010 [Page 9]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 December 30, 2010 [Page 10]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 December 30, 2010 [Page 11]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 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 hash of the DER
encoding of ResponseData.
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
Cooper Expires December 30, 2010 [Page 12]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 }
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
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:
Cooper Expires December 30, 2010 [Page 13]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 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 responder regarding the status of the certificate such as
a positive statement about issuance, validity, etc.
The "revoked" status 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.
The "unknown" status indicates that the responder doesn't know about
the certificate being requested.
2.3.2. thisUpdate, nextUpdate, and producedAt
Responses can contain three times in them - thisUpdate, nextUpdate,
and producedAt. The semantics of these fields are:
Cooper Expires December 30, 2010 [Page 14]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 may be included as a response extension when it
appears as one of the requestExtensions in the corresponding request
(see Section 2.1.1.1).
When present, the nonce MUST have the same value as the nonce in the
corresponding request. If the request did not include a nonce then a
nonce MUST NOT be included in the response. The nonce extension in
the response is identified using the same object identifier as is
used in the request, id-pkix-ocsp-nonce.
[Editor's note: RFC 5019 says that "Clients that do not include a
nonce in the request MUST ignore any nonce that may be present in the
response." Is it permissible for a server to include a nonce in the
response if there was no nonce in the request? If the request
included a nonce, may the server send a response that includes a
different nonce?]
Cooper Expires December 30, 2010 [Page 15]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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,
while the value will be ArchiveCutoff.
id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }
Cooper Expires December 30, 2010 [Page 16]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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.
[Editor's note: RFC 2560 states that all the extensions specified as
CRL Entry Extensions in Section 5.3 of RFC 2459 are also supported as
singleExtensions. However, RFC 2459 specifies 4 CRL entry
extensions: reason Code, hold instruction code, invalidity date, and
certificate issuer. RevokedInfo already includes a revocationReason
field, so including the reason code extension in singleExtensions
would be redundant. Certificate issuer would similarly be redundant
since the identity of the certificate's issuer is already known.
Hold instruction code extension was removed from RFC 5280 and so
should not be included here either. So, that leaves invalidity date
as the only CRL entry extension in RFC 5280 that would be appropriate
for inclusion in singleExtensions.]
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
Cooper Expires December 30, 2010 [Page 17]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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
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 OCSP 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 OCSP responses from a
designated OCSP responder, will only accept OCSP responses if
the certificate required to validate the signature on the OCSP
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
Cooper Expires December 30, 2010 [Page 18]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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
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 the 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.
Cooper Expires December 30, 2010 [Page 19]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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).
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 identity of the signer matches the intended recipient of
the request; [Editor's note: I think this should be deleted.
Except in the case of a locally trusted OCSP responder, the
client only knows the URL of the OCSP responder, not the
identity of the responder. Isn't it sufficient for the client
to verify that the signer is authorized?]
4. the signer is currently authorized to sign the response (see
Section 2.3.6.2);
5. the time at which the status being indicated is known to be
correct (thisUpdate) is sufficiently recent; and
Cooper Expires December 30, 2010 [Page 20]
INTERNET-DRAFT PKIX OCSP June 28, 2010
6. when available, the time at or before which newer information
will be available about the status of the certificate
(nextUpdate) is greater than the current time.
2.3.6.1. 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.
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. (This criterion is satisfied if the subject DN in
the certificate required to validate the signature on the OCSP
response is the same as the issuer DN in the certificate in
question.)
3. Has an extended key usage extension that includes the id-ad-
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-ad-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.
Cooper Expires December 30, 2010 [Page 21]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 SHALL 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).
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.
Cooper Expires December 30, 2010 [Page 22]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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.
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 December 30, 2010 [Page 23]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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
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] Polk, W., Housley, R., and L. Bassham, "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.
Cooper Expires December 30, 2010 [Page 24]
INTERNET-DRAFT PKIX OCSP June 28, 2010
[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", RFC 5912, June
2010.
Appendix A. OCSP over HTTP
This appendix describes the formatting that will be done to the
request and response to support HTTP [RFC2616].
A.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}
Cooper Expires December 30, 2010 [Page 25]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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.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.
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. An alternative to this module that conforms to
the 2002 version of ASN.1 my be found in Section 4 of [RFC5912].
Appendix B.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.
[Editor's note: The OCSP ASN.1 module in Appendix B.1 did not have
an OID, so I copied the OID from draft-ietf-pkix-ocspagility-08.txt.
Why does the OCSP module import Certificate, AlgorithmIdentifier, and
CRLReason from AuthenticationFramework when Certificate and
AlgorithmIdentifier are in PKIX1Explicit88 and CRLReason is in
PKIX1Implicit88?]
Cooper Expires December 30, 2010 [Page 26]
INTERNET-DRAFT PKIX OCSP June 28, 2010
B.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
-- Directory Authentication Framework (X.509)
Certificate, AlgorithmIdentifier, CRLReason
FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1)
authenticationFramework(7) 3 }
-- PKIX Certificate Extensions
AuthorityInfoAccessSyntax
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
Name, GeneralName, CertificateSerialNumber, Extensions,
id-kp, id-ad-ocsp
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)};
OCSPRequest ::= SEQUENCE {
tbsRequest TBSRequest,
optionalSignature [0] EXPLICIT Signature OPTIONAL }
TBSRequest ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
requestorName [1] EXPLICIT GeneralName OPTIONAL,
requestList SEQUENCE OF Request,
requestExtensions [2] EXPLICIT Extensions OPTIONAL }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
Version ::= INTEGER { v1(0) }
Request ::= SEQUENCE {
reqCert CertID,
singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }
Cooper Expires December 30, 2010 [Page 27]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 }
KeyHash ::= OCTET STRING --SHA-1 hash of responder's public key
--(excluding the tag and length fields)
Cooper Expires December 30, 2010 [Page 28]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 December 30, 2010 [Page 29]
INTERNET-DRAFT PKIX OCSP June 28, 2010
B.2. Preferred Signature Algorithms ASN.1
B.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 December 30, 2010 [Page 30]
INTERNET-DRAFT PKIX OCSP June 28, 2010
B.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 December 30, 2010 [Page 31]
INTERNET-DRAFT PKIX OCSP June 28, 2010
Appendix C. Media Types
C.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 December 30, 2010 [Page 32]
INTERNET-DRAFT PKIX OCSP June 28, 2010
C.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 December 30, 2010 [Page 33]
INTERNET-DRAFT PKIX OCSP June 28, 2010
Appendix D. Example PKIs With OCSP Responders
This appendix provides some examples of valid PKI architectures that
include OCSP responders.
D.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 December 30, 2010 [Page 34]
INTERNET-DRAFT PKIX OCSP June 28, 2010
+------------------------------------------------------+
| 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 December 30, 2010 [Page 35]
INTERNET-DRAFT PKIX OCSP June 28, 2010
D.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 |
+-----------------------------+ |
| Sub CA certificate | |
| +-------------------------+ | |
| | certificate signing key |--------------------+
| +-------------------------+ |
+-----------------------------+
Figure 5. Integrated and Designated OCSP Responder
Cooper Expires December 30, 2010 [Page 36]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 contains a target certificate
issued by the root CA the OCSP responder is an integrated OCSP
responder. When an OCSP client is verifying a response from the OCSP
responder that contains a target certificate issued by the
subordinate CA the OCSP 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
the target certificate. As in Figure 6, the CA has performed a key
Cooper Expires December 30, 2010 [Page 37]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 CA's self-signed certificate | | | Root's OCSP |
| | +-------------------------------+ | | | Responder's cert **|
| | | 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 December 30, 2010 [Page 38]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 CA's self-signed certificate | | | Root's OCSP |
| | +-------------------------------+ | | | Responder's cert **|
| | | 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 1 **| | certificate 2 **|
| +-----------------------------------------------+ |
| | OCSP Responder's key | |
| +-----------------------------------------------+ |
+----------------------+ +----------------------+
Figure 8. Designated OCSP Responder With Two Certificates
Cooper Expires December 30, 2010 [Page 39]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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 December 30, 2010 [Page 40]
INTERNET-DRAFT PKIX OCSP June 28, 2010
D.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 December 30, 2010 [Page 41]
INTERNET-DRAFT PKIX OCSP June 28, 2010
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
Cooper Expires December 30, 2010 [Page 42]