view Side-By-Side changes
Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
<draft-ietf-pkix-opp-ocsp-01.txt>
<draft-ietf-pkix-ocsp-02.txt>
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may MAY also distribute working docu-
ments
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may 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."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
1. Abstract
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure
(PKI). This document specifies an HTTP-based application protocol use-
ful
useful in determining the current status of a digital certificate
without the use of CRLs. Additional mechanisms addressing PKIX
operational re-
quirements requirements are specified in separate documents.
Please send comments on this document to the ietf-pkix@tandem.com mail
list.
2. Protocol Overview
In lieu of or as a supplement to checking against a periodic CRL, it may MAY
be necessary to obtain timely status regarding a certificates revoca-
tion
revocation state (cf. PKIX Part 1, Section 3.3). Examples include high-value high-
value funds transfer or the compromise of a highly sensitive key.
The Online Certificate Status Protocol (OCSP) enables applications to
efficiently and rapidly determine the validity and revocation state of
an identified certificate. An OCSP client issues a status request to an
OCSP responder and suspends acceptance of the subject certificate until
the responder provides a response.
Myers
The OCSP protocol is intended to be a light-weight HTTP application that
allows certificate recipients (users or application programs) to assure
Myers, Ankey [Page 1]
INTERNET DRAFT October 21, 1997 February 1998
themselves, in a low-overhead manner, that a certificate is valid. By
design, OCSP resembles HTTP in syntax and, where they overlap, in
semantics. An anticipated goal of this decision is to leverage the
growing tools and infrastructure of the Web (most notably HTTP caching)
wherever possible. Section 4.6 discusses the use (and limitations) of
HTTP 1.0 and HTTP 1.1 in more detail.
2.1 Request
An OCSP request contains the following data:
- protocol version
- service request
- target certificate identifier or a single end-entity certificate
- optional extensions which MAY be processed by the OCSP Responder
- an optional signature computed over the previous four fields
- additional (optional) extensions, which are not included in the
signature computation
Upon receipt of a request, an OCSP Responder first determines if: 1) the
message is well formed, 2) the responder is configured to provide the
requested service, and 3) the responder can perform the requested serv-
ice
service for the subject certificate. If any one of the prior conditions
are not met, an error message is produced; otherwise, a definitive
response is returned.
2.2 Response
All definitive response messages shall SHALL be digitally signed. The key
used to sign definitive responses need not be the same signing key used
to sign the certificate. Note that caching signed responses for fre-
quently
frequently requested certificates may MAY optionally provide some support
for reducing the cryptographic and bandwidth loads on the responder.
A definitive response message is composed of:
- response validity interval
- target certificate identifier
- certificate status value
- identification of public key needed to validate the signature
- signature algorithm OID
- optional extensions
- signature computed across hash of previous five six values
- additional (optional) extensions, which are not included in the
signature computation
This specification defines the following definitive response indicators
for use in the certificate status value:
- VALID
- INVALID {includes reason text}
- REVOKED {includes X.509 reason code} date of revocation}
- EXPIRED {includes date of expiration}
- ON HOLD {includes date of suspension}
- TRY LATER {service temporarily unavailable}
Myers, Ankey [Page 2]
INTERNET DRAFT February 1998
The path validation logic implied by the VALID and INVALID indicators is
that defined by PKIX Part 1.
The INVALID state is distinguished from the REVOKED and EXPIRED states
in that a valid certificate may MAY be revoked or expired but such informa-
tion
information on an invalid certificate is misleading.
Myers [Page 2]
INTERNET DRAFT October 21, 1997
The ON HOLD state corresponds to valid certificates that are operation-
ally
operationally suspended in accordance with PKIX Part 1.
In the event that the OCSP responder is operational, but unable to
return a status for the requested certificate, the TRY LATER response
can be used to indicate that the service exists, but is temporarily
unable to respond.
Signed error messages extend the set of definitive response indicators
to include the following error conditions:
- ILLFORMED MESSAGE
- NO SERVICE
- CERTIFICATE DATA REQUIRED
A server produces the ILLFORMED MESSAGE response if the request received
does not conform to the OCSP syntax.
The response NO SERVICE MAY be produced in any circumstance in which the
server has received a well formed OCSP request but is unable to process
it.
The response CERTIFICATE DATA REQUIRED is used in cases where the server
requires the client to supply the certificate data itself in order to
construct a response.
2.3 Response Pre-production
The response validity interval noted in the prior section is composed of
a {produced_at, expires_on} {produced-at, next-update} pair of elements in the response syntax.
Section 4.2 provides details of the response syntax.
OCSP responders MAY pre-produce signed responses reflecting the current
status of certificates at the time the response was produced. The time
at which the response was produced SHALL be reflected in the produced_at produced-at
field of the response.
The producer of the response SHALL MAY include a value for expires_on. next-update. The
exact interval between produced_at produced-at and expires_on next-update for given response is
a matter of local security and operational policy. If the next-update
field is not present, the response is valid only for the particular
request which prompted it. Equivalently, the next-update field is
considered to be the same as the produced-at field.
If responses are pre-produced, then for a given certificate, the perio-
dicity
periodicity of this pre-production SHOULD match the response validity inter-
val
interval of the most recently produced response.
Myers, Ankey [Page 3]
INTERNET DRAFT February 1998
3. Functional Requirements
3.1 Certificate Content
In order to convey to OCSP clients a well-known point of information ac-
cess,
access, CAs shall SHALL provide the capability to include the AuthorityInfoAc-
cess
AuthorityInfoAccess extension (defined in PKIX Part 1, section 4.2.2.1)
in certificates intended to be applied to the service.
CAs that support an OCSP service, either hosted locally or provided by a
Trusted Third Party, shall SHALL provide a value for a uniformResourceIndica-
tor
uniformResourceIndicator (URI) accessLocation and the OID value id-pkix-ocsp id-pkix-
ocsp for the access-
Method accessMethod in the AccessDescription SEQUENCE.
The value of the accessLocation field in the subject certificate corre-
sponds
corresponds to the URL placed into an OCSP request (see section 5.1).
3.2 Request Generation and Submission
OCSP clients shall SHALL be capable of transmitting OCSP as an HTTP 1.1 GET
and of receiving the response as the Entity-Body of an HTTP 1.1 Full-
Response. Section 4.5 discusses use of HTTP OCSP Clients MAY be capable of transmitting OCSP as an HTTP
1.1 POST with the certificate being queried forming the message body.
OCSP servers SHALL support HTTP 1.1 GET requests and MAY support HTTP
1.1 POST requests. Section 4.5 discusses use of HTTP transport.
Myers [Page 3]
INTERNET DRAFT October 21, 1997
3.3 Error Responses
Upon receipt of a request which fails to parse, the receiving OCSP re-
sponder shall
responder SHALL respond with an error message. If the responder is con-
figured
configured to provide signed error responses, a failure to parse an incom-
ing
incoming request shall SHALL be indicated by an ILLFORMED MESSAGE response.
The value of the identifier of such a response shall SHALL be NULL_ID.
For service requests not supported by the responder, the responder shall SHALL
respond with an error message. If the responder is configured to provide
signed error responses, non-availability of the requested service shall SHALL
be indicated by a NO SERVICE response.
This protocol makes use of HTTP as a transport. OCSP clients should SHOULD
consequently enable automatic recovery from a lost connection. An HTTP
timeout mechanism is one conventional means of doing so.
3.4 Status Responses
Upon receipt of an OCSP request containing an end-entity certificate, if
the certificate fails to validate against Section 6 of PKIX Part 1 for
reasons other than revocation, OCSP responders shall esponders SHALL respond with INVA-
LID.
INVALID. Responses may MAY be supplemented with explanatory text that
provides additional context. Section 5.2 of this document specifies a
minimal set of explanatory text for this purpose.
Myers, Ankey [Page 4]
INTERNET DRAFT February 1998
3.5 Signed Response Acceptance Requirements
Prior to accepting a signed response as valid, OCSP clients shall con-
firm SHALL
confirm that:
1. The certificate identified in a received response corresponds to
that which was identified in a former request;
2. The signature on the response is valid;
3. The identity of the signer matches the intended recipient of the re-
quest.
request.
4. Detailed Protocol
4.1 Request Syntax
An
The protocol consists of an OCSP request and an OCSP response. The
request is conveyed as part of an HTTP 1.1 GET method composed of a URL followed by
a sequence of keyword-value pairs. The following grammar specifies or POST request, and its
syntax is compatible with that defined in [URL]. In particular,
reserved characters in the request portion of the protocol. Quoted syntactic elements are terminal
elements of encoded using the grammar.
Myers [Page 4]
INTERNET DRAFT October 21, 1997
OCSP_request : url request version target
url : protocol :// domain_name /
protocol : http
request : service_class / action
version : 2
service_class : status
action : check
time : YYYYMMDDHHMMSSZ
target : cert or cert_id
cert : cert / certificate
certificate : {base-64 encoding of single certificate}
cert_id : ID / hash
hash : md5_hash(Issuer DN | cert serial number)
The value %xx mechanism
of 2 [URL], unless they are used for their reserved purposes (in this
case, delimiting fields in the version field accommodates preliminary imple-
mentations of a different request and response syntax.
To produce a value for request). Note that this encoding
requirement includes the cert_id field, three special characters (plus sign, forward
slash, and equal sign) used in the client first calculates an
MD5 hash across base64 encoding mechanism. Components
in the concatenation request are thus of Issuer DN with the serial number in form:
token = *(ALPHA / DIGIT / SAFE / EXTRA)
safe = "$" | "-" | "_" | "." | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
Components (and sub-fields within the target certificate, base-64 encodes components) are delimited using
several of the hash and appends reserved characters:
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
The following (punctuation) characters are always encoded, as they might
have meaning outside the result
to scope of the prior fields.
4.2 Response Syntax
An HTTP-based OCSP response URL. E.g., the pound sign (#) is composed of
used to separate a sequence of data fields
separated by URL and a # character. Response codes fragment identifier.
punctuation = "<" | ">" | "#" | "%" | <">
Requests and responses are returned as the ASCII
encoding of a decimal number. Values with composed of:
- fixed fields (required in all messages), followed by
- optional fields, which MUST be supported by an OCSP responder,
but need not be present in all messages, and
- optional extensions, which MAY be supported by an OCSP responder.
Optional fields and extensions use a minus sign (ASCII encoding
of -) indicate simple name/value syntax.
Definitive responses and definitive error values.
OCSP_response : definitive_rsp | error_rsp
definitive_rsp : base status_value signature_block
error_rsp : minimal_error | definitive_error
minimal_error : 0x20 // //
definitive_error : base error_value signature_block
base : produced_at # expires_on # prior_id #
produced_at : YYYYMMDDHHMMSSZ
expires_on : YYYYMMDDHHMMSSZ
prior_id : // cert_id responses MUST be signed.
Requests MAY be signed using the request-signature extension.
Signatures are computed from the beginning of prior the request //
error_value : illformed_msg | no_service
illformed_msg : 0x2d 0x31 // -1 //
no_service : 0x2d 0x32 // -2 //
status_value : status_code {reason_text or date_context} #
status_code : valid|invalid|revoked|not_revoked|expired
valid : 0x31 // 1 //
invalid : 0x32 // 2 //
revoked : 0x33 // 3 //
Myers or response
through the first two fields of the signature block. Extensions MAY be
present before the signature (in which case they are included in the
Myers, Ankey [Page 5]
INTERNET DRAFT October 21, 1997
expired : 0x34 // 4 //
on_hold : 0x35 // 5 //
reason_text : {for additional context}
date_context : YYYYMMDDHHMMSSZ
signature_block : key_id # sig_alg_oid # signature
key_id : // SHA-1 hash February 1998
signature computation), or after the signature (in which case they are
not signed.
4.1 Request Syntax
An OCSP request is an HTTP 1.1 GET or POST method composed of public a URL
followed by a sequence of required and optional fields. The following
grammar specifies the request portion of the protocol. Quoted syntactic
elements are terminal elements of the grammar, which is the ABNF grammar
from [ABNF].
OCSP-request = url "/ocsp/ver/1/" target [extensions]
[signature] [extensions]
url = protocol :// domain-name /
protocol = http
time = <date and time, as: YYYYMMDDHHMMSSZ>
target = cert-id
cert-id = ID / hash
hash = <sha1-hash(Issuer DN | cert serial number)>
extensions = *extension
extension = / ext-name / ext-value
ext-name = ALPHA *(ALPHA / DIGIT / -)
ext-value = token
DQUOTE = %x22
signature = / sig / signature-block
signature-block = key-id & sig-alg-oid & signature-value
key-id = <subject key ID of certificate needed to
validate signature //
sig_alg_oid : // algorithm signature, per PKIX-1; defaults to
SHA-1 hash of public key in certificate>
sig-alg-oid = <algorithm combination used to produce sig //
signature : // base-64 sig,
as dotted integer e.g. 1.2.3.4>
signature-value = <base-64 encoded value corresponding to
the result of using sig-alg-oid //
Standard values for reason_text shall include:
1 sig-alg-oid>
The root value of 2 for this certificate is not trusted on this responder.
2 Could not find CAs public key. the version field accommodates preliminary
implementations of a different request and response syntax.
To produce a value for the cert-id field, the client first calculates a
SHA-1 hash across the concatenation of Issuer DN with the serial number
in the target certificate, base-64 encodes the hash and appends the
result to the prior fields.
The HTTP POST method is to be used in cases where the certificate data
itself is required by the server. The body of the request has content
type application/xxxx and consists of the certificate data itself. Since
HTTP requires connections to be 8-bit clean no additional encoding of
the certificate data is required.
Support for extensions is OPTIONAL. This standard defines several
useful extensions in Section 4.5. Additional extensions MAY be defined
in additional RFCs. All extensions use the name/value syntax described
above. Unrecognized extensions can be ignored, by skipping past the
slash delimiting the value, then skipping the value.
Myers, Ankey [Page 6]
INTERNET DRAFT February 1998
The requester signature is used to authenticate the requester to the
OCSP Responder. It is used in conjunction with the requester
certificate extension defined below.
The signature is computed over the portion of the request which precedes
the signature, i.e. the URL, request, and target fields, any extensions
which precede the signature, and the key-id and sig-alg-oid portions of
this extension. Note that extensions following this one are not
included; typically the requester certificate extension does not need to
be signed, and would be positioned after the signature. Thus, the
signature is computed over:
{ url request target extensions sig-fields }
The OCSP Responder verifies the signature, using the public key
identified by key-id and the requester certificate extension defined
below.
4.2 Response Syntax
An HTTP-based OCSP response is composed of a sequence of data fields
similar to the OCSP request. Response codes are returned as the ASCII
encoding of a decimal number. Values with a minus sign (ASCII encoding
of -) indicate definitive error values.
OCSP-response = definitive-rsp / error-rsp
definitive-rsp = base status-value [extensions] signature
[extensions]
error-rsp = minimal-error / definitive-error
minimal-error = %x20 ;
definitive-error = base error-value [extensions] signature
[extensions]
base = produced-at / prior-id / next-update
produced-at = time
next-update = next-update / time
prior-id = <cert-id of prior request>
error-value = illformed-msg / no-service /certificate-reqd
illformed-msg = %x2d %x31 ; -1
no-service = %x2d %x32 ; -2
certificate-reqd = %x2d %x33 ; -3
status-value = status-code [/ reason-text ]
[ / date-context ]
status-code = valid /invalid / revoked / not-revoked /
expired / try-later
valid = %x31 ; 1
invalid = %x32 ; 2
revoked = %x33 ; 3
expired = %x34 ; 4
on-hold = %x35 ; 5
try-later = %x36 ; 6
reason-text = reason / token ; for additional context
date-context = on / time
Myers, Ankey [Page 7]
INTERNET DRAFT February 1998
Standard values for reason-text SHALL include:
1 The root for this certificate is not trusted on this responder.
2 Could not find CAs public key.
3 CAs public key invalid.
4 CAs public key revoked.
5 CAs public key expired.
6 CA not authorized for Subjects name.
7 CA not authorized for Subjects privileges.
8 CAs public key did not validate signature.
9 Could not find CAs revocation information.
10 CAs CRL out of date.
When producing REVOKED or HOLD responses, OCSP responders shall SHALL include
the date of the revocation in the status_value status-value field as a value for date_context.
date-context.
The produced_at produced-at and expires_on next-update fields define a validity interval. This
interval corresponds to the {thisUpdate, nextUpdate} CRL validity inter-
val.
interval. Responses whose expires_on next-update value is earlier than the local
system time value should SHOULD be considered unreliable.
To produce a value for the cert_id field, value for the cert-id field, the client first calculates an
MD5 hash across the concatenation of Issuer DN with the serial number
in the target certificate, base-64 encodes the hash and appends the
result to the prior fields.
To produce a signed response, the responder first calculates a hash of
the sequence of characters from the beginning of the response through
the & following the sig-alg-oid subfield of the signature block.
Using the above syntax, this is the sequence:
base status-value [extensions] sig-fields
where
sig-fields = / sig / key-id & sig-alg-oid &
The responder signs the hash, base-64 encodes the result and then
appends it to the prior fields, encoding any special characters in the
base64 signature as described in [URL]. The associated hash and signing
algorithms are identified by the value of sig-alg-oid.
4.3 Mandatory and Optional Cryptographic Algorithms
Clients that request OCSP services SHALL be capable of processing
responses signed used DSA keys identified by the DSA sig-alg-oid
specified in section 7.2.2 of PKIX Part 1. Clients SHOULD also be
capable of processing RSA signatures as specified in ection 7.2.1 of
PKIX Part 1.
4.4 Extensions
This section defines some standard extensions. Support for all
extensions is OPTIONAL. For each extension, the definition indicates
Myers, Ankey [Page 8]
INTERNET DRAFT February 1998
its syntax, processing performed by the OCSP Responder, and any
extensions which are included in the corresponding response. Note that
extensions use a simple name/value syntax.
4.4.1 Nonce
The nonce cryptographically binds a request and response, to prevent
replay attacks. The nonce extension has syntax:
nonce / atom
and MAY be any non-repeating value (e.g., random number, transaction
hash, counter, or timestamp). The OCSP Responder returns the nonce as a
response extension. The nonce is included in the response signature
computation. The nonce structure is opaque to the OCSP Responder.
4.4.2 Requester Certificate
This extension conveys the certificate of the signer, and is used by the
OCSP Responder to verify the requester signature. It has syntax:
reqcert / <base64 encoding of a certificate>
reqid / hash ; MD5(issuer || serial #)
The cert production is either a base64-encoded certificate, or the client first calculates an
MD5
hash across the concatenation of Issuer DN with the issuer and serial number of the certificate as described in
Section 4.1.
NOTE: Depending on the target certificate, base-64 encodes OCSP implementation, the hash and appends key-id contained
in the result key-id portion of the signature extension MAY be sufficient
to identify the prior fields.
To produce a signed response, key needed to verify the responder first calculates signature. In this case,
this extension is not needed.
NOTE: This extension contains a hash
across single certificate. Other(CA)
certificates MAY be needed for the sequence
{ produced_at#expires_on#prior_id#status_value#key_id#sig_alg_oid# },
signs OCSP to verify the hash, base-64 encodes signature.
This could be included in the result and then appends it to request, as additional instances of
this extension. Or another extension could be defined, which
might convey a SEQUENCE OF Certificate, or an empty CMS SignedData
instance (with the
prior fields. The associated hash and signing algorithms are identified certificates field populated appropriately).
Construction of the relevant certification path by the value OCSP
Responder could (instead) just be declared out of sig_alg_oid.
If a request contains scope for this
standard.
4.4.3 CRL References
It MAY be desirable for the OCSP responder to indicate the CRL on which
a direct revoked or held certificate instead of is found. This can be useful where OCSP
is used between repositories, and also as an auditing mechanism. Three
extensions are defined for this purpose:
crlurl / token
crlnum / number
crltime / time
number = *DIGIT
Myers, Ankey [Page 9]
INTERNET DRAFT February 1998
The crlurl extension contains a cert_id--and URL which can be used to retrieve the
request results
CRL the requested certificate is listed on. Note that any reserved
characters in a definitive response--OCSP responders shall calcu-
late a cert_id as defined the token must be encoded per [URL].
The crlnum extension indicates the value in section 5.1 the CRL number extension of this specification and in-
clude
the resultant relevant CRL.
The crltime extension indicates the value in the cert_id thisUpdate field of the response.
Myers [Page 6]
INTERNET DRAFT October 21, 1997
4.3 Mandatory and Optional Cryptographic Algorithms
Clients that request OCSP services shall be capable of processing re-
sponses signed used DSA keys identified by the DSA sig_alg_oid specified
relevant CRL.
4.4.4 Policy Identifier
This extension contains a policy ID and relevant qualifiers. It MAY be
sent in section 7.2.2 of PKIX Part 1. Clients should a request to indicate the policy which the requester considers
acceptable. This extension MAY also be capable of
processing RSA signatures as specified included in section 7.2.1 the response. The
syntax is:
policy / <base64 encoding of PKIX Part 1.
4.4 a PolicyInformation structure>
4.5 Responder Key Identification
It is possible that an OCSP responder may MAY have more than one valid pub-
lic
public signature key of the same cryptographic algorithm. To assist cli-
ents
clients in identifying which public key to use, OCSP responders shall in-
clude SHALL
include in all signed responses a SHA-1 hash of the required public key.
It is also possible that an OCSP client may MAY be in possession of more
than one valid certificate containing the OCSP responders public key.
This specification asserts no constraints on the means by which clients
determine which certificate to use.
4.5
4.6 HTTP Transport Mechanism
The request syntax is intended to mimic a file system GET an object retrieval via HTTP 1.1
in order for it to be cached by local proxy responders.
OCSP requests are composed as an HTTP GET as follows:
GET <request> HTTP/1.1
<headers>
OCSP requests are composed as an HTTP POST as follows:
POST <request> HTTP/1.1
<headers>
<certificate>
The response to such a query is the Entity-Body of an HTTP 1.1 Full-
Response as defined in RFC 2068 with Content-Type: XX/XX. application/ocsp.
Myers, Ankey [Page 10]
INTERNET DRAFT February 1998
A representation of the HTTP context of an OCSP request and response
follows. The content differs slightly from current request and response
syntax.
GET /status/check/ver/1/ID/qyXLklpfK2wYd8iPsGdOwQ== HTTP/1.1
Host: status.our-ca.com
Date: Thu, 23 Oct 1997 22:33:30 GMT
User-Agent: Transport xy/z
HTTP/1.0 200 OK
Server: Netscape-Enterprise/2.0a
Date: Thu, 23 Oct 1997 22:33:34 GMT
Last-modified: Thursday, 23 Oct 1997 12:38:25 GMT
Expires: Thursday, 23 Oct 1997 23:38:25 GMT
Content-type: application/octet-stream
19971023123825Z#qyXLklpfK2wYd8iPsGdOwQ==#2#1.3.14.3.2.15
19971023123825Z&qyXLklpfK2wYd8iPsGdOwQ==&2&1.3.14.3.2.15
#uFom3GIAHjIdlWZ5SsFKTvGXHgML35n21zsQvFGT3hWmULBsvH6MDg4+FY55P6wgwxAWTSV
S3h8xFiacN9m5S4xBDO/5IpVFpFwdhrSe8S5/jYK2qPGsGdjzCmGQIX03CaGLh+NOn8x9Wpo
wtnCMhg4UeDZm+b4BKrmNpT6g0Mw=
Myers
In cases where the server returns the response CERTIFICATE DATA REQUIRED
the request must be repeated using the POST method to provide the server
with the certificate data. Note that base64 encoding is specified in the
following example for readability alone. A production client would
normally use binary encoding.
POST /status/check/ver/1/ID/qyXLklpfK2wYd8iPsGdOwQ== HTTP/1.1
Host: status.our-ca.com
Date: Thu, 23 Oct 1997 22:33:30 GMT
User-Agent: Transport xy/z
Content-Type: application/X509
Content-Encoding: Base-64
2+3094fh9p2831410t493upoiqwjf9p832174rtawoirtf0913274r5hqefpq0w7rfqolaiw
yerq32047r9qwherfpqw40/r7qp9w84utrp92q34723q940+3q4tp0u3q4tu3qp40t73q04t
7r0q394ut0qwu4t0[9qw40t7q3/048u3q4wtu3q0+4t0+3q47034q7t093749734097t0709
3475t023q743wq/890++ewrtpoiausrpoiurpsoituqwpoet/0==
HTTP/1.0 200 OK
Server: Netscape-Enterprise/2.0a
Date: Thu, 23 Oct 1997 22:33:34 GMT
Last-modified: Thursday, 23 Oct 1997 12:38:25 GMT
Expires: Thursday, 23 Oct 1997 23:38:25 GMT
Content-type: application/octet-stream
19971023123825Z&qyXLklpfK2wYd8iPsGdOwQ==&2&1.3.14.3.2.15
#uFom3GIAHjIdlWZ5SsFKTvGXHgML35n21zsQvFGT3hWmULBsvH6MDg4+FY55P6wgwxAWTSV
S3h8xFiacN9m5S4xBDO/5IpVFpFwdhrSe8S5/jYK2qPGsGdjzCmGQIX03CaGLh+NOn8x9Wpo
wtnCMhg4UeDZm+b4BKrmNpT6g0Mw=
Myers, Ankey [Page 7] 11]
INTERNET DRAFT October 21, 1997 February 1998
If an HTTP/1.0 server receives the message or a proxy downgrades the re-
quest
request to a 1.0 message the request will work as expected except that
the connection will be closed at the end of the request, a keep-alive re-
quest
request will not be supported. The advantages of using HTTP 1.1 over
HTTP 1.0 are:
1) HTTP 1.0 is a Best Commercial Practices document while HTTP 1.1 is
full standards track.
2) It would be possible to send a sequence of requests at the same time
using the 'keep-alive' facility. This would allow the raw data for vali-
dating
validating a certificate to be collected in a single server transaction
or allow a whole 'address book' of certificates to be checked in one go.
3) The 1.1 cache control features would be available. These allow cli-
ents
clients to specify precisely the degree of staleness they will permit.
They can also make statementslike statements like 'get me the latest if you can get it other-
wise
otherwise send me something no more than 240 seconds old.'
3a) A particularly useful feature is that the server can require caches
to poll to check freshness each time they serve a piece of data. In the
HTTP/1.0 model there is only the pragma: no-cache which prohibits all
caching entirely.
5. Security Considerations
For this service to be effective, certificate using systems must connect
to the certificate status service provider. In the event such a connec-
tion
connection cannot be obtained, certificate-using systems should could implement
CRL processing logic as a fall-back position.
A denial of service vulnerability is evident with respect to a flood of
queries constructed to produce error responses. The production of a
cryptographic signature significantly affects response generation cycle
time, thereby exacerbating the situation. Performance studies on a pre-
liminary
preliminary implementation of OCSP capable of handling two million hits
per day without degradation suggest this effect is of an orders of
magnitude per response. Unsigned error responses provide a reasonable
tradeoff against protection against this particular attack.
The use of unsigned error messages introduces a vulnerability to inter-
mediation
intermediation attacks. It is reasonable to ask for error messages to be
signed to address this vulnerability. A request to do so however must
also consider the converse risk identified abovenamely that increasing
the response cycle time of error messages through use of cryptographic
signing increases the impact of flooding attacks. Parties implementing
OCSP responders that wish to offer the benefit of signed error responses
should
SHOULD strongly consider the use of hardware-assisted cryptography. Do-
ing
Doing so will reduce the threat of flood attacks.
Myers
The use of precomputed responses MAY allow replay attacks in which an
old (VALID) response is replayed prior to its expiration date but after
the certificate has been revoked. HTTP caching MAY also allow replay of
Myers, Ankey [Page 7] 12]
INTERNET DRAFT October 21, 1997 February 1998
stale responses; see Section 4.5 for a discussion of how caching MAY be
controlled in HTTP 1.1.
6. References
[HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee,
R. Fielding & H. Frystyk, RFC 1945, May 1996.
[ABNF] Augmented BNF for Syntax Specifications: ABNF. D. Crocker,
P. Overell, RFC 2234, November 1997.
[MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels,
S. Bradner, RFC 2119, March 1997.
[URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter,
M. McCahill, RFC 1738, December 1994.
7. Authors Address
Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA 94019
mmyers@verisign.com
INTERNET DRAFT October 14, 1997
Myers [Page 1]
Rich Ankney
CertCo, LLC
13506 King Charles Dr.
Chantilly, VA 20151
rankney@erols.com
Appendix A
Registration of OCSP as a MIME type
To: IANA@isi.edu
Subject: Registration of new MIME content-type/subtype
MIME type name: application
MIME subtype name: ocsp
Required parameters: none
Optional parameters: none
Encoding considerations: none
Security considerations:
This data information which may be conceivably be used to enforce legal contracts,
resolve disputes or transfer financial risk from one party to another. The design
of software that processes this type should be trustworthy in its design and
operations.
Published specification: This document
----