Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_j_p/draft-ietf-pkix-ocsp-00.txt

Text File | 1997-10-23 | 18KB | 498 lines

PKIX Working Group                                         Michael Myers
draft-ietf-pkix-ocsp-00.txt                               VeriSign, Inc.
Expires in 6 months                                       September 1997


                   Internet Public Key Infrastructure
                Online Certificate Status Protocol - OCSP
                   <draft-ietf-pkix-ocsp-00.txt>



1.  Status of this Memo

This document is an Internet-Draft. Internet-Drafts  are  working  docu-
ments  of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working docu-
ments 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."

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 in determining the current status of a digital certificate without
the use of CRLs.  Additional mechanisms addressing PKIX operational re-
quirements are specified in separate documents.

Please send comments on this document to the [e-mail] mail
list.

2. Protocol Overview

In lieu of or as a supplement to checking against a periodic CRL, it may
be necessary to obtain timely status regarding a  certificateÆs revoca-
tion state (cf. PKIX Part 1, Section 3.3). Examples include 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                                                           [Page 1]





INTERNET DRAFT                                          October 21, 1997

2.1 Request

An OCSP request contains the following data:

- protocol version
- service request
- target certificate identifier or a single end-entity certificate

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 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 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 requested certificates may optionally provide some support for
reducing the cryptographic and bandwidth loads on the responder.

A definitive response message is composed of:

- date and time of response
- target certificate identifier
- certificate status value
- identification of public key needed to validate the signature
- signature algorithm OID
- signature computed across hash of previous five values

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}
- EXPIRED       {includes date of expiration}
- ON HOLD
- NOT ACTIVE

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 be revoked or expired but such informa-
tion 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 suspended in accordance with PKIX Part 1.
A request that receives a NOT ACTIVE response is a special case created
by the inclusion of a prior_to date field (see section 4.2).

Signed error messages extend the set of definitive response indicators
to include the following error conditions:

- ILLFORMED MESSAGE
- NO SERVICE


3. Functional Requirements

3.1 Certificate Content

In order to convey to OCSP clients a well-known point of information ac-
cess, CAs shall provide the capability to include the AuthorityInfoAc-
cess 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 provide a value for a uniformResourceIndica-
tor (URI) accessLocation and the OID value id-pkix-ocsp for the access-
Method in the AccessDescription SEQUENCE.

The value of the accessLocation field in the subject certificate corre-
sponds to the URL placed into an OCSP request (see section 5.1).

3.2 Request Generation and Submission

OCSP clients shall be capable of transmitting OCSP as an HTTP 1.0 GET
and of receiving the response as the Entity-Body of an HTTP 1.0 Full-
Response.

3.3 Error Responses

Upon receipt of a request which fails to parse, the receiving OCSP re-
sponder shall respond with an error message.  If the responder is con-
figured to provide signed error responses, a failure to parse an incom-
ing request shall be indicated by an ILLFORMED MESSAGE response.  The
value of the identifier of such a response shall be NULL_ID.

For service requests not supported by the responder, the responder shall
respond with an error message. If the responder is configured to provide
signed error responses, non-availability of the requested service shall
be indicated by a NO SERVICE response.


Myers                                                           [Page 3]





INTERNET DRAFT                                          October 21, 1997

This protocol makes use of HTTP as a transport.  OCSP clients 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 respond with INVA-
LID.  Responses 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.

The OCSP service request syntax provides a means for clients to bound
the date of interest through the use of a prior_to field. Requests con-
cerned with current status would thus include the current date in the
prior_to field while requests concerned with the validity of aged signed
content may supply the date of the signed document.

The following mandatory and optional requirements apply to OCSP respond-
ers with respect to prior_to field and current date:

1.  Shall be capable of generating responses to requests that contain
values for prior_to matching the current date.

2.  May provide services for values of prior_to that are earlier than the
current date.

3.  Shall respond with NO SERVICE if the prior_to date in a request is
later than the current date.

The means by which OCSP clients and servers establish a common value for
"current date" is beyond the scope of this document.

If the prior_to date is earlier than the notBefore date of certificateÆs
validity interval and the certificate otherwise satisfies the validation
requirements of Section 6 of PKIX Part 1, OCSP servers shall respond
with NOT ACTIVE.

If the prior_to date lies within the subject certificateÆs validity in-
terval and the certificate otherwise satisfies the validation require-
ments of Section 6 of PKIX Part 1, OCSP servers shall respond with
VALID.

If the prior_to date lies within the subject certificateÆs validity in-
terval and the certificate has been revoked by its issuing Certification
Authority, OCSP servers shall respond with REVOKED.

If the prior_to date specifies a date beyond the notAfter date in the
certificateÆs validity interval and the certificate has not been revoked

Myers                                                           [Page 4]




INTERNET DRAFT                                          October 21, 1997

by its issuing Certification Authority, OCSP responders shall respond
with EXPIRED.

If the prior_to date specifies a date beyond the notAfter date in the
certificateÆs validity interval and the certificate has been revoked by
its issuing Certification Authority, OCSP responders shall respond with
REVOKED.

3.5 Signed Response Acceptance Requirements

Prior to accepting a signed response as valid, OCSP clients shall con-
firm 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.

4. Detailed Protocol

4.1 Request Syntax

An OCSP request is an HTTP 1.0 GET method composed of a URL followed by
a sequence of keyword-value pairs. The following grammar specifies the
request portion of the protocol.  Quoted syntactic elements are terminal
elements of the grammar.

OCSP_request     :      url request version target
url              :      protocol "://" domain_name "/"
protocol         :      "http"
request          :      service_class "/" action "/" prior_to
version          :      "2"
service_class    :      "status"
action           :      "check"
prior_to         :      "prior_to" time
time             :      YYYYMMDDHHMMSSZ
target           :      cert or cert_id
cert             :      "cert" "/" certificate
certificate      :      {base-64 encoding of single certificate}
trans_id         :      {an opaque identifier}
cert_id          :      "ID" "/" hash
hash             :      md5_hash(Issuer DN | cert serial number)

The value of "2" for the version field accommodates preliminary imple-
mentations of a different request and response syntax.

To produce a value for the cert_id field, the client first calculates an
MD5 hash across the concatenation of Issuer DN with the serial number in

Myers                                                           [Page 5]





INTERNET DRAFT                                          October 21, 1997

the target certificate, base-64 encodes the hash and appends the result
to the prior fields.

The "prior_to" constraint indicates a client request for the status of a
certificate prior to the specified time.

4.2 Response Syntax

An HTTP-based OCSP response is composed of a sequence of data fields
separated by a "#" character.  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 signature_block
error_rsp          :    minimal_error | definitive_error

minimal_error      :    0x20                             // " " //
definitive_error   :    base error_value signature_block

base               :    time "#" prior_id "#"
time               :    YYYYMMDDHHMMSSZ
prior_id           :    // cert_id of prior 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_text} "#"
status_code        :    valid|invalid|revoked|not_revoked|expired
valid              :    0x31                            // "1"  //
invalid            :    0x32                            // "2"  //
revoked            :    0x33                            // "3"  //
expired            :    0x34                            // "4"  //
on_hold            :    0x35                            // "5"  //
not_active         :    0x36                            // "6"  //
reason_text        :    {for additional context}
date_text          :    YYYYMMDDHHMMSSZ
signature_block    :    key_id "#" sig_alg_oid "#" signature
key_id             :    // SHA-1 hash of public key needed to
                           validate signature //
sig_alg_oid        :    // algorithm combination used to produce sig //
signature          :    // base-64 encoded value corresponding to
                           the result of using sig-alg-oid //

Standard values for reason_text shall include:
"1   The root for this certificate is not trusted on this responder."
"2   Could not find CAÆs public key."
"3   CAÆs public key invalid."

Myers                                                           [Page 6]





INTERNET DRAFT                                          October 21, 1997

"4   CAÆs public key revoked."
"5   CAÆs public key expired."
"6   CA not authorized for SubjectÆs name."
"7   CA not authorized for SubjectÆs privileges."
"8   CAÆs public key did not validate signature."
"9   Could not find CAÆs revocation information."
"10  CAÆs CRL out of date."

When producing REVOKED responses, OCSP responders shall include the date
of the revocation in the status_value field.

To produce a 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
across the sequence

        { time#prior_id#status_value#key_id#sig_alg_oid# },

signs the hash, base-64 encodes the result and then appends it to the
prior fields.  The associated hash and signing algorithms are identified
by the value of sig_alg_oid.

If a request contains a direct certificate instead of a cert_id--and the
request results in a definitive response--OCSP responders shall calcu-
late a cert_id as defined in section 5.1 of this specification and in-
clude the resultant value in the cert_id field of the response.

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
in section 7.2.2 of PKIX Part 1.  Clients should also be capable of
processing RSA signatures as specified in section 7.2.1 of PKIX Part 1.

4.4 Responder Key Identification

It is possible that an OCSP responder may have more than one valid pub-
lic signature key of the same cryptographic algorithm.  To assist cli-
ents in identifying which public key to use, OCSP responders shall in-
clude in all signed responses a SHA-1 hash of the required public key.

It is also possible that an OCSP client may be in possession of more
than one valid certificate containing the OCSP responderÆs public key.

This specification asserts no constraints on the means by which clients
determine which certificate to use.


Myers                                                           [Page 7]





INTERNET DRAFT                                          October 21, 1997


4.5 HTTP Transport Mechanism

The request syntax is intended to mimic a file system GET via HTTP in
order for it to be cached by local proxy responders.

OCSP requests are composed as an HTTP 1.0 GET as follows:

GET <request> HTTP/1.0

Conversely, OCSP responders shall be capable of receiving such queries.

The response to such a query is the Entity-Body of an HTTP 1.0 Full-
Response as defined in RFC 1945 with Content-Type: XX/XX.

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 cannot be obtained, certificate-using systems should 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 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 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 aboveùnamely 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 strongly consider the use of hardware-assisted cryptography.  Do-
ing so will reduce the threat of flood attacks.

6. References
[HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee,
       R. Fielding & H. Frystyk, RFC 1945, May 1996.

7. AuthorÆs Address

Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA 94019
[e-mail]




























Myers                                                           [Page 8]

INTERNET DRAFT                                          October 14, 1997