view Side-By-Side changes

Expires in 6 months                                        February                                           March 1998


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



1.
                        <draft-ietf-pkix-ocsp-03.txt>



Status of this Memo

This document is an Internet-Draft. Internet-Drafts  are  working 
documents  of the Internet Engineering Task Force (IETF), its areas, and 
its working groups. Note that other groups MAY may also distribute working 
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 view the current status entire list of  any  Internet-Draft, current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa),   nic.nordu.net    (Europe), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim),  ds.internic.net ftp.ietf.org (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 a protocol useful in determining the
current status of a digital certificate without the use of CRLs.
Additional mechanisms addressing PKIX operational requirements are
specified in separate documents.

Please send comments on this document to

Section 2 provides an overview of the protocol. Section 3 goes 
establishes functional requirements, while section 4 provides the 
details of the ietf-pkix@tandem.com mail 
list. protocol. In section 5 we cover security issues with the
protocol. Appendix A demonstrates OCSP over HTTP and appendix B 
accumulates ASN.1 syntactic elements.

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  certificate’s 
revocation 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. OCSP may 


Myers, Ankney, Malpani, Galperin, Adams                        [Page 1]
INTERNET DRAFT                                                March 1998

be used to satisfy some of the operational requirements of providing 
more timely revocation information than is possible with CRLs.  An OCSP 
client issues a status request to an OCSP responder and suspends 
acceptance of the subject certificate in question until the responder
provides a response. 

The OCSP

This protocol is intended specifies the data that needs to be a light-weight HTTP application that 
allows certificate recipients (users or exchanged between an
application programs) to assure 

Myers, Ankey                                                    [Page 1]

INTERNET DRAFT                                             February 1998

themselves, in a low-overhead manner, that checking the revocation status of 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.
server providing that status.

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 
service for the subject certificate.  If any one of the prior conditions 
are not met, the OCSP responder produces an error message is produced; message; otherwise, it 
returns a definitive 
response is returned. response.

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 response MUST belong to sign one of the certificate. Note that caching signed responses for 
frequently requested certificates MAY optionally provide some support 
for reducing following:

- the cryptographic and bandwidth loads on CA who issued the responder. certificate in question
- a Trusted Responder whose public key is trusted by the requester

A definitive response message is composed of:

- response validity interval
- target certificate type identifier (to allow for different response types)
- certificate status value version of the response
- identification name of public key needed to validate the signature responder
- signature algorithm OID responses for each of the certificates in a request
- optional extensions
- signature algorithm OID
- signature computed across hash of previous six values
- additional (optional) extensions, which are not included in the
  signature computation response

The response for each of the certificates in a request consists of

- target certificate identifier
- certificate status value
- response validity interval
- optional extensions

This specification defines the following definitive response indicators 
for use in the certificate status value:

- VALID
- INVALID              {includes reason text}
- REVOKED              {includes date of revocation}
- EXPIRED              {includes date of expiration}
- ON HOLD              {includes date of suspension}
- TRY LATER            {service temporarily unavailable}


Myers, Ankey Ankney, Malpani, Galperin, Adams                        [Page 2]
INTERNET DRAFT                                             February                                                March 1998

- notRevoked
- revoked
- onHold
- expired

The path validation logic implied by notRevoked state indicates that the VALID and INVALID indicators certificate is not revoked. It
does not necessarily mean that defined by PKIX Part 1.

The INVALID state is distinguished from the REVOKED and EXPIRED states 
in certificate was ever issued. Nor
does it mean that a valid the certificate MAY be revoked or expired but such 
information on is in its validity interval. A
notRevoked state by an invalid OCSP responder DOES NOT absolve the application
of the responsibility of checking that the certificate is misleading. in its
validity period and has been correctly signed.

The revoked state indicates that the certificate has been revoked.

The ON HOLD onHold state corresponds to valid certificates that are 
operationally suspended in accordance with PKIX Part 1.

A request that returns an expired state indicates that the validity of 
the subject certificate has expired.  Applications SHOULD check the 
validity interval of a certificate and not perform an OCSP request if 
the certificate’s validity has expired.

2.3 Exception Cases

In case of errors, the OCSP Responder may return an error message.
Errors can be of the following types:

- malformedRequest
- internalError
- tryLater
- notFound
- certRequired
- noCRL

A server produces the malformedRequest response if the request received 
does not conform to the OCSP syntax.

The response internalError indicates that the OCSP responder reached
an inconsistent internal state. The query should be retried, potentially
with another responder.

In the event that the OCSP responder is operational, but unable to 
return a status for the requested certificate, the TRY LATER tryLater response 
can be used to indicate that the service exists, but is temporarily 
unable to respond.

Signed error messages extend the set

A recipient of definitive response indicators a request may not be able to resolve a reference 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 
subject certificate; a value of notFound is returned in such a case. 
This value should not conform to the OCSP syntax.

The response NO SERVICE MAY be produced in any circumstance in which taken as confirmation of the 
server has received a well formed OCSP request but is unable to process 
it. certificate's 
existence.

The response CERTIFICATE DATA REQUIRED certRequired is used returned in cases where the server requires 
the client to supply the certificate data itself in order to construct a 
response.

2.3

Myers, Ankney, Malpani, Galperin, Adams                        [Page 3]
INTERNET DRAFT                                                March 1998

An extension is defined to enable delivery of CRLs with OCSP responses.  
However, there is no requirement to list certificates on a CRL in order 
to use OCSP to acquire revocation status on those certificates. The 
error value noCRL is defined for this instance.

2.4 Response Pre-production

The response validity interval noted in the prior section is composed of 
a {produced-at, next-update} {thisUpdate, nextUpdate} pair of elements in the response syntax. 
Section 4.2 provides details of the response syntax.

OCSP responders MAY pre-produce signed responses reflecting specifying 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 thisUpdate 
field of the response.

If responses are pre-produced, then for a given certificate, the 
periodicity of this pre-production SHOULD match the response validity 
interval of the most recently produced response.

[need to resolve the above statement with the following RCSP assertions, 
esp. with respect to positive responses.  Question put to the list.]

The time at which the response was known to be correct SHALL
be specified in the producedAt field of the response. This time is not
necessarily the same as the time at which the response was produced -
e.g. if the responder obtains a CRL from a CA and creates pre-produced
responses, the thisUpdate time should specify the thisUpdate time in
the CRL.

The producer of the response MAY include a value for next-update. nextUpdate.  The 
exact interval between produced-at thisUpdate and next-update nextUpdate for given response is 
a matter of local security and operational policy.  If the next-update nextUpdate 
field is not present, the response is valid only for is known to be correct at the particular 
request which prompted it. 
thisUpdate time.  Equivalently, the next-update nextUpdate field is considered to be 
the same as the produced-at thisUpdate field.

If responses

No assertions are pre-produced, then for a given certificate, being made about the 
periodicity current state of this pre-production SHOULD match the response validity 
interval certificate, 
nor are any recommendations being made as to when the requestor should 
check again with the responder.  If the value of nextUpdate is set, it 
is just a hint, not a guarantee, of when the most recently produced response.


Myers, Ankey                                                    [Page 3]

INTERNET DRAFT                                             February 1998 responder expects to have 
new information about that certificate's status.

3. Functional Requirements

3.1 Certificate Content

In order to convey to OCSP clients a well-known point of information 
access, CAs SHALL provide the capability to include the 
AuthorityInfoAccess extension (defined in PKIX Part 1, section 4.2.2.1) 
in certificates intended to that can be applied to checked using OCSP.  Alternatively, the service. 
accessLocation for the OCSP provider may be configured locally at the 
OCSP client.


Myers, Ankney, Malpani, Galperin, Adams                        [Page 4]
INTERNET DRAFT                                                March 1998

CAs that support an OCSP service, either hosted locally or provided by a 
Trusted Third Party, SHALL
an Authorized Responder, MAY provide a value for a
uniformResourceIndicator (URI) accessLocation and the OID value id-pkix-
ocsp
id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

The value of the accessLocation field in the subject certificate
corresponds 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.1 GET 
and of receiving the response as the Entity-Body of an HTTP 1.1 Full-
Response.  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. request.

3.3 Error Responses

Upon receipt of a request which fails to parse, the receiving OCSP 
responder SHALL respond with an error message.  If the responder is 
configured to provide signed error responses, a failure to parse an 
incoming 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.

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 esponders SHALL respond with 
INVALID.  Responses  Error 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.




Myers, Ankey                                                    [Page 4]

INTERNET DRAFT                                             February 1998 
signed.

3.5 Signed Response Acceptance Requirements

Prior to accepting a signed response as valid, OCSP clients SHALL 
confirm that:

1.  The certificate identified in a received response corresponds to 
    that which was identified in a former the corresponding request;
 
2.  The signature on the response is valid;
 
3.  The identity of the signer matches the intended recipient of the 
    request.

4. Detailed Protocol

The protocol consists of an OCSP request ASN.1 syntax imports terms defined in the X.509 Certificate and an OCSP response.  The 
request is conveyed as part of an HTTP GET or POST request, and its 
syntax is compatible with that defined in [URL].  In particular, 
reserved characters in CRL
Profile Internet Draft. For signature calculation, the request are data to be signed 
is encoded using the %xx mechanism 
of [URL], unless they are ASN.1 distinguished encoding rules (DER) [X.690].

ASN.1 EXPLICIT tagging is used as a default unless specified otherwise.

The terms imported from elsewhere are: Version, Extensions, 
CertificateSerialNumber, SubjectPublicKeyInfo, Name, 
AlgorithmIdentifier, GeneralizedTime

4.1 Request Syntax

OCSPRequest	::=  SEQUENCE {
   version             [0]  EXPLICIT Version DEFAULT v1,
   hashAlgorithm            AlgorithmIdentifier,
   requestList	          SEQUENCE OF Request,
   requestExtensions   [1]  EXPLICIT Extensions OPTIONAL }

Version  ::=  INTEGER  {  v1(0) }

Request ::= CHOICE {
   certID              [0]  EXPLICIT CertID,
   cert                [1]  EXPLICIT Certificate }



Myers, Ankney, Malpani, Galperin, Adams                        [Page 5]
INTERNET DRAFT                                                March 1998

CertID ::= SEQUENCE {
   issuerNameAndKeyHash Hash,
   serialNumber         CertificateSerialNumber }

IssuerNameAndKey ::= SEQUENCE {
   issuer               Name,
   issuerPublicKey      SubjectPublicKeyInfo }

Hash			::=	OCTET STRING --hash of IssuerNameAndKey--

3.2 Response Syntax

This section specifies the ASN.1 specification for their reserved purposes (in this 
case, delimiting fields in a confirmation
response. The actual formatting of the request).  Note that this encoding 
requirement includes message could vary depending on
the three special characters (plus sign, forward 
slash, and equal sign) transport mechanism used in (http, smtp, ldap, etc.).

3.2.1 ASN.1 Specification of the base64 encoding mechanism. Components 
in OCSP Response

An OCSP response at a minimum consists of a responseStatus field 
indicating the request are thus processing status of the form:

token		= *(ALPHA / DIGIT / SAFE / EXTRA)
safe        = "$" | "-" | "_" | "." | "+"
extra       = "!" | "*" | "'" | "(" | ")" | ","

Components (and sub-fields within prior request.  If the components) are delimited using 
several value of 
responseStatus is one of the reserved characters:

reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "="

The following (punctuation) characters error conditions, responseBytes are always encoded, as they might 
have meaning outside the scope not 
set.

OCSPResponse ::= SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::= ENUMERATED {
    successful            (0),      --Response has valid confirmations
    malformedRequest      (1),      --Illegal confirmation request
    internalError         (2),      --Internal error in issuer
    tryLater              (3),      --Try again later
    notFound              (4),      --Certificate not on record
    certRequired          (5)       --Must supply certificate }

3.2.1.1 BasicResponse

The value for responseBytes consists of the URL.  E.g., the pound sign (#) is 
used to separate a URL an OBJECT IDENTIFIER and a fragment identifier.

punctuation	= "<" | ">" | "#" | "%" | <">

Requests and responses are composed of:

  -	fixed fields (required in all messages), followed by
  -	optional fields, which MUST be supported 
response syntax identified by that OID encoded as an OCTET STRING:

ResponseBytes ::=	SEQUENCE {
    responseType   OBJECT IDENTIFIER,
    response       OCTET STRING }

For a basic OCSP responder,
     	but need not responseType will be present in all messages, and
  -	optional extensions, which MAY id-pkix-ocsp-basic,
where:

id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-basic     OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }

OCSP responders SHALL be supported by an capable of recognizing and responding to the 
id-pkix-ocsp-basic response type. Correspondingly, OCSP responder.

Optional fields clients SHALL be 
capable of receiving and extensions use a simple name/value syntax.

Definitive responses and definitive error responses MUST be signed.  
Requests MAY be signed using the request-signature extension.  
Signatures are computed from the beginning of processing the request or id-pkix-ocsp-basic 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 
type.

Myers, Ankey Ankney, Malpani, Galperin, Adams                        [Page 5] 6]
INTERNET DRAFT                                             February                                                March 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 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, per PKIX-1; defaults to
SHA-1 hash of public key in certificate>
sig-alg-oid      =      <algorithm combination used to produce sig,
				   as dotted integer e.g. 1.2.3.4>
signature-value  =    <base-64 encoded value corresponding to for response SHALL be the result DER encoding of using sig-alg-oid> BasicOCSPResponse:

BasicOCSPResponse	::= SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs                [1] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

The value of “2” for signature SHALL be computed on the version field accommodates preliminary 
implementations hash of a different request and response syntax.

To produce a value for the cert-id field, the client first calculates a 
SHA-1 DER 
encoding ResponseData.

3.2.1.2 ResponseData

ResponseData ::= SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   reponderID               ResponderID,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::= CHOICE {
   byName   [0] Name,
   byKey    [1] KeyHash }

KeyHash ::= KeyIdentifier –-SHA-1 hash across as defined in PKIX Part.1

3.2.1.3 SingleResponse

[note: question put to the concatenation of Issuer DN list regarding bandwidth issues associated 
with the sending certificates back; could just use certID directly since 
requester already has certificates in question.]

SingleResponse ::= SEQUENCE {
   request            Request,
   certStatus         CertStatus,
   producedAt         GeneralizedTime,
   nextUpdate         [0] EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions   [2] EXPLICIT Extensions OPTIONAL }

CertStatus ::= CHOICE {
    certStatusType    [0] EXPLICIT CertStatusType (notRevoked | onHold),
    statusWithTime    [1] EXPLICIT StatusWithTime }

StatusWithTime ::= SEQUENCE {
    certStatusType    CertStatusType (revoked),
    time              GeneralizedTime }

CertStatusType ::= ENUMERATED {
    notRevoked        (0),  --This 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 not revoked
    revoked           (1),  --Serial number was revoked
    onHold            (2),  --Cert is on hold
    expired           (3)   -- certificate data 
itself is required expired }

Applications SHOULD determine by observation of the server. certificate’s 
validity interval that a certificate is expired.  The body expired value 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 CA’s public key.”
“3   CA’s public key invalid.”
“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 or HOLD responses, OCSP responders SHALL include 
the date of the revocation in the status-value field as a value for 
date-context.

The produced-at and next-update fields define a validity interval.  This 
interval corresponds to the {thisUpdate, nextUpdate} CRL validity 
interval.  Responses whose next-update value is earlier than the local 
system time value SHOULD be considered unreliable.

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 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 Ankney, Malpani, Galperin, Adams                        [Page 8] 7]
INTERNET DRAFT                                             February                                                March 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

CertStatusType defines 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 
hash of the issuer and serial number of the certificate as described in 
Section 4.1.  

NOTE:  Depending on the OCSP implementation, the key-id contained 
in the key-id portion of the signature extension MAY be sufficient to identify the key needed to verify the signature.  In this case, 
this extension is not needed.

NOTE:  This extension contains return when a single certificate.  Other(CA) 
certificates MAY be needed request is received for the OCSP to verify the signature. 
This could be included 
a subject certificate in the request, as additional instances of this extension.  Or another extension could be defined, which 
might convey a SEQUENCE OF Certificate, state.

3.2.2 Notes on OCSP Responses

If the certStatusType is revoked, onHold or an empty CMS SignedData 
instance (with expired, the certificates time field populated appropriately).  
Construction of 
StatusWithTime is the relevant certification path by the OCSP 
Responder could (instead) just be declared out time of scope for this 
standard.

4.4.3 CRL References

It MAY be desirable revocation, suspension or expiration 
respectively.  The date returned for expiration should match the OCSP responder to indicate 
notAfter date of the CRL on which certificate’s validity interval.

The thisUpdate and nextUpdate fields define a revoked or held certificate is found. recommended validity
interval. This can interval corresponds to the {thisUpdate, nextUpdate}
interval in CRLs. Responses whose nextUpdate value is earlier
than the local system time value SHOULD be useful considered unreliable.
Responses whose thusUpdate time is earlier than the local system time
SHOULD be considered unreliable.  Responses where OCSP the nextUpdate value
is used between repositories, and also as an auditing mechanism.  Three 
extensions not set 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 equivalant to a URL which can CRL with no time for nextUpdate (see
section 2.3).

3.3 Mandatory and Optional Cryptographic Algorithms

Clients that request OCSP services SHALL be capable of processing 
responses signed used to retrieve the 
CRL DSA keys identified by the requested certificate is listed on. Note that any reserved 
characters DSA sig-alg-oid 
specified in the token must section 7.2.2 of PKIX Part 1.  Clients SHOULD also be encoded per [URL].

The crlnum extension indicates the value 
capable of processing RSA signatures as specified in the CRL number extension section 7.2.1 of 
PKIX Part 1.  OCSP responders SHALL support the SHA1 hash algorithm.

3.4 Extensions

This section defines some standard extensions.  Support for all 
extensions is OPTIONAL.  For each extension, the relevant CRL.

The crltime extension definition indicates 
its syntax, processing performed by the value in the thisUpdate field of the 
relevant CRL. 

4.4.4 Policy Identifier

This extension contains a policy ID OCSP Responder, and relevant qualifiers.  It MAY be 
sent in a request to indicate the policy any 
extensions which the requester considers 
acceptable.  This extension MAY also be are included in the corresponding response.

3.4.1 Nonce

The 
syntax is:

	“policy” “/” <base64 encoding of nonce cryptographically binds a PolicyInformation structure>

4.5 Responder Key Identification

It request and a response to prevent
replay attacks. The nonce is possible that an OCSP responder MAY have more than included as one valid 
public signature key of the same cryptographic algorithm.  To assist 
clients requestExtensions
in identifying which public key to use, OCSP responders SHALL 
include requests, while in all signed responses a SHA-1 hash it would be included as one of the required public key.

It is also possible that an OCSP client MAY
responseExtensions.  In both the request and the response, the nonce
will be in possession identified by the object identifier id-pkix-ocsp-nonce, while
the extnValue is the value of more 
than one valid certificate containing the OCSP responder’s public key. nonce.

id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

3.4.2 Signed Requests

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

4.6 HTTP Transport Mechanism sign a request. The request syntax is intended to mimic requestor 
includes an object retrieval via HTTP 1.1 
in order for it extension that has the signatureIdentifier, the actual bits 
of the signature and a sequence of certificates to be cached by local proxy responders.

OCSP requests are composed as an HTTP GET as follows:

GET <request> HTTP/1.1
<headers> allow the OCSP requests are composed as an HTTP POST as follows:

POST <request> HTTP/1.1
<headers>

<certificate> 
responder to verify the signature. The response data to such a query be signed is just the Entity-Body 
basic request (none of an HTTP 1.1 Full-
Response as defined in RFC 2068 with Content-Type: application/ocsp. the extensions). The OCSP Responder can verify 
the signature, potentially using certificates that have been included 


Myers, Ankey Ankney, Malpani, Galperin, Adams                        [Page 10] 8]
INTERNET DRAFT                                             February                                                March 1998

A representation of

with the HTTP context of an OCSP request and response 
follows. extension. The content differs slightly from current signature on a 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

#uFom3GIAHjIdlWZ5SsFKTvGXHgML35n21zsQvFGT3hWmULBsvH6MDg4+FY55P6wgwxAWTSV
S3h8xFiacN9m5S4xBDO/5IpVFpFwdhrSe8S5/jYK2qPGsGdjzCmGQIX03CaGLh+NOn8x9Wpo
wtnCMhg4UeDZm+b4BKrmNpT6g0Mw=

In cases where the server returns the response CERTIFICATE DATA REQUIRED will be identified by id-
pkix-ocsp-signature, while the request must value will be repeated using SignatureData, where:

id-pkix-ocsp-signature OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

SignatureData ::= SEQUENCE {
   signatureAlgorithm	    AlgorithmIdentifier,
   signature		    BIT STRING,
   certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

3.4.3 CRL References

It may be desirable for the POST method OCSP responder to provide the server 
with indicate the CRL on which 
a revoked or onHold 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 11]

INTERNET DRAFT                                             February 1998

If found. This can be useful where OCSP 
is used between repositories, and also as an HTTP/1.0 server receives the message or auditing mechanism. The
CRL may be specified by a proxy downgrades URL (the URL at which the 
request to CRL is available),
a 1.0 message number (CRL number) or a time (the time at which the request relevant CRL
was created). These extensions will work be specified as expected except that singleExtensions.
The identifier for this extension will be id-pkix-ocsp-crl, while the connection
value will be closed CrlID.

id-pkix-ocsp-crl       OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }

CrlID ::= SEQUENCE {
   crlUrl		[0]	EXPLICIT IA5String OPTIONAL,
   crlNum		[1]	EXPLICIT INTEGER OPTIONAL,
   crlTime		[2]	EXPLICIT GeneralizedTime OPTIONAL }

For the choice crlUrl, the IA5String will specify the URL at which the end of
CRL is available. For crlNum, the request, a keep-alive 
request INTEGER will not be supported. The advantages specify the value 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 the
CRL number extension of requests at the same time 
using relevant CRL. For crlTime, the 'keep-alive' facility. This would allow 
GeneralizedTime will indicate the raw data for 
validating a certificate time at which the relevant CRL was 
issued.

Note:  There is no requirement to be collected in a single server transaction 
or allow a whole 'address book' of list certificates on a CRL in order to be checked 
use OCSP to acquire revocation status on those certificates.  Therefore 
inclusion of this extension in one go.

3) a request may yield no CRL information.  
The 1.1 cache control features would be available. These allow 
clients error value noCRL is defined for this instance.

3.4.4 Acceptable Response Types

An OCSP client MAY wish to specify precisely the degree kinds of staleness they will permit. 
They can also make statements like 'get me the latest if you can get response types it 
otherwise send me something no more than 240 seconds old.'

3a) A particularly useful feature is that
understands. To do so, it SHOULD use an extension with the server 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 require caches 
to poll to check freshness each time they serve a piece accept (e.g., id-pkix-ocsp-basic).

id-pkix-ocsp-response  OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }

AcceptableResponses ::=	SEQUENCE OF { id OBJECT IDENTIFIER }

As noted in section 3.3, OCSP responders SHALL be capable of data. In recognizing 
and responding to the 
HTTP/1.0 model there is only id-pkix-ocsp-basic response type. Correspondingly, 


Myers, Ankney, Malpani, Galperin, Adams                        [Page 9]
INTERNET DRAFT                                                March 1998

OCSP clients SHALL be capable of receiving and processing the pragma: no-cache which prohibits all 
caching entirely.

5. id-pkix-
ocsp-basic response type.

3.4.5 Other Extensions

CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are 
also supported as singleExtensions.

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 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 
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 
intermediation attacks. It is reasonable to ask for error messages to can 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 produced more rapidly and thus reduce 
the benefit danger of signed this attack. However, unsigned error responses 
SHOULD strongly consider open up the use 
protocol to another denial of hardware-assisted cryptography.  
Doing so will reduce service attack, where the threat of flood attacks. attacker sends 
false error responses.

The use of precomputed responses MAY allow allows replay attacks in which an 
old (VALID) (notRevoked) response is replayed prior to its expiration date but 
after the certificate has been revoked.  HTTP caching MAY also allow replay Deployments of 

Myers, Ankey                                                   [Page 12]

INTERNET DRAFT                                             February 1998

stale responses; see Section 4.5 for a discussion OCSP should 
carefully evaluate the benefit of precomputed responses against the 
probability of how caching MAY be 
controlled in HTTP 1.1.

6. a replay attack and the costs associated its successful 
execution.

5. 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. Author’s Address

Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA 94019
mmyers@verisign.com
 

Myers, Ankney, Malpani, Galperin, Adams                        [Page 10]
INTERNET DRAFT                                                March 1998

Rich Ankney
CertCo, LLC
13506 King Charles Dr.
Chantilly, VA  20151
rankney@erols.com

Ambarish Malpani
ValiCert, Inc.
3160 W. Bayshore Drive
Palo Alto, CA 94303
ambarish@valicert.com

Slava Galperin
Netscape Communications Corp.
MV-068
501 E. Middlefield Rd.
Mountain View, CA 94043
galperin@netscape.com

Carlisle Adams
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Ontario
K1V 1A7
Canada
cadams@entrust.com

Appendix A

Registration of

A.1 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: over HTTP

This data information which may be conceivably section describes the formatting that will be used done to enforce legal contracts,
resolve disputes or transfer financial risk from one party the request
and response to another. support HTTP.

A.1.1 Request

An OCSP request is an HTTP 1.0 POST method. The design Content-Type header
has the value "application/ocsp-request" while the body of software that processes this type should the message
is the DER encoding of the OCSPRequest.

A.1.2 Response

An HTTP-based OCSP response is composed of the appropriate HTTP headers,
followed by the 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 trustworthy in its design present and
operations.

Published specification:  This document MAY be ignored if not understood by the requestor.








Myers, Ankney, Malpani, Galperin, Adams                        [Page 11]
INTERNET DRAFT                                                March 1998

Appendix B:  OCSP in ASN.1

OCSPRequest	::=  SEQUENCE {
   version             [0]  EXPLICIT Version DEFAULT v1,
   hashAlgorithm            AlgorithmIdentifier,
   requestList	          SEQUENCE OF Request,
   requestExtensions   [1]  EXPLICIT Extensions OPTIONAL }

Version  ::=  INTEGER  {  v1(0) }

Request ::= CHOICE {
   certID              [0]  EXPLICIT CertID,
   cert                [1]  EXPLICIT Certificate }

CertID ::= SEQUENCE {
   issuerNameAndKeyHash Hash,
   serialNumber         CertificateSerialNumber }

IssuerNameAndKey ::= SEQUENCE {
   issuer               Name,
   issuerPublicKey      SubjectPublicKeyInfo }

Hash			::=	OCTET STRING --hash of IssuerNameAndKey--

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
    notFound              (4),      --Certificate not on record
    certRequired          (5)       --Must supply certificate }

BasicOCSPResponse	::= SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs                [1] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

ResponseData ::= SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   reponderID               ResponderID,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::= CHOICE {
   byName   [0] Name,
   byKey    [1] KeyHash }

KeyHash ::= KeyIdentifier –-SHA-1 hash as defined in PKIX Part.1


Myers, Ankney, Malpani, Galperin, Adams                        [Page 12]
INTERNET DRAFT                                                March 1998

SingleResponse ::= SEQUENCE {
   request            Request,
   certStatus         CertStatus,
   producedAt         GeneralizedTime,
   nextUpdate         [0] EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions   [2] EXPLICIT Extensions OPTIONAL }

CertStatus ::= CHOICE {
    certStatusType    [0] EXPLICIT CertStatusType (notRevoked | onHold),
    statusWithTime    [1] EXPLICIT StatusWithTime }

StatusWithTime ::= SEQUENCE {
    certStatusType    CertStatusType (revoked),
    time              GeneralizedTime }

CertStatusType ::= ENUMERATED {
    notRevoked        (0),  --This serial number is not revoked
    revoked           (1),  --Serial number was revoked
    onHold            (2),  --Cert is on hold
    expired           (3)   -- certificate is expired }

--Extensions

SignatureData ::= SEQUENCE {
   signatureAlgorithm	    AlgorithmIdentifier,
   signature		    BIT STRING,
   certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

AcceptableResponses ::=	SEQUENCE OF { id OBJECT IDENTIFIER }

CrlID ::= SEQUENCE {
   crlUrl		[0]	EXPLICIT IA5String OPTIONAL,
   crlNum		[1]	EXPLICIT INTEGER OPTIONAL,
   crlTime		[2]	EXPLICIT GeneralizedTime OPTIONAL }

-- Object Identifiers

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-response  OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }
id-pkix-ocsp-crl       OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }
id-pkix-ocsp-signature OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }












Myers, Ankney, Malpani, Galperin, Adams                        [Page 13]

----