PKIX Working Group Michael Myers(VeriSign) draft-ietf-pkix-ocsp-02.txt Rich Ankney (CertCo) Expires in 6 months February 1998 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP <draft-ietf-pkix-ocsp-02.txt> 1. 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 also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and MAY be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." 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 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 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 be necessary to obtain timely status regarding a certificates 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. An OCSP client issues a status request to an OCSP responder and suspends acceptance of the subject certificate until the responder provides a response. 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 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 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 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 frequently requested certificates 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 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 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 be revoked or expired but such information on an invalid certificate is misleading. The ON HOLD state corresponds to valid certificates that are 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, 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 field of the response. The producer of the response MAY include a value for next-update. The exact interval between produced-at and 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 periodicity of this pre-production SHOULD match the response validity 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 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 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 uniformResourceIndicator (URI) accessLocation and the OID value id-pkix- 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. 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 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 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 request. 4. Detailed Protocol The protocol consists of an OCSP request 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 the request are encoded using the %xx mechanism of [URL], unless they are used for their reserved purposes (in this case, delimiting fields in the request). Note that this encoding requirement includes the three special characters (plus sign, forward slash, and equal sign) used in the base64 encoding mechanism. Components in the request are thus of the form: token = *(ALPHA / DIGIT / SAFE / EXTRA) safe = "$" | "-" | "_" | "." | "+" extra = "!" | "*" | "'" | "(" | ")" | "," Components (and sub-fields within the components) are delimited using several of the reserved characters: reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" The following (punctuation) characters are always encoded, as they might have meaning outside the scope of the URL. E.g., the pound sign (#) is used to separate a URL 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 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 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 the request 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 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 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 the result of using sig-alg-oid> The value of 2 for 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 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 [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 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 a single certificate. Other(CA) certificates MAY be needed for the OCSP to verify the signature. This could be included in the 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 certificates field populated appropriately). Construction of the relevant certification path by the OCSP Responder could (instead) just be declared out of scope for this standard. 4.4.3 CRL References It MAY be desirable for the OCSP responder to indicate the CRL on which a revoked or held certificate 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 URL which can be used to retrieve the CRL the requested certificate is listed on. Note that any reserved characters in the token must be encoded per [URL]. The crlnum extension indicates the value in the CRL number extension of the relevant CRL. The crltime extension indicates the value in the thisUpdate field of the relevant CRL. 4.4.4 Policy Identifier This extension contains a policy ID and relevant qualifiers. It MAY be sent in a request to indicate the policy which the requester considers acceptable. This extension MAY also be included in the response. The syntax is: policy / <base64 encoding of a PolicyInformation structure> 4.5 Responder Key Identification It is possible that an OCSP responder MAY have more than one valid public signature key of the same cryptographic algorithm. To assist clients in identifying which public key to use, OCSP responders SHALL include 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 responders public key. This specification asserts no constraints on the means by which clients determine which certificate to use. 4.6 HTTP Transport Mechanism The request syntax is intended to mimic 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: 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 #uFom3GIAHjIdlWZ5SsFKTvGXHgML35n21zsQvFGT3hWmULBsvH6MDg4+FY55P6wgwxAWTSV S3h8xFiacN9m5S4xBDO/5IpVFpFwdhrSe8S5/jYK2qPGsGdjzCmGQIX03CaGLh+NOn8x9Wpo wtnCMhg4UeDZm+b4BKrmNpT6g0Mw= 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 11]
INTERNET DRAFT February 1998 If an HTTP/1.0 server receives the message or a proxy downgrades the 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 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 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 clients to specify precisely the degree of staleness they will permit. They can also make statements like 'get me the latest if you can get it 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 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 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 strongly consider the use of hardware-assisted cryptography. Doing so will reduce the threat of flood attacks. 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 12]
INTERNET DRAFT 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 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
