PKIX Working Group Michael Myers draft-ietf-pkix-ocsp-00.txt VeriSign, Inc. Expires in 6 months November 1997 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP 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 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 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: - response validity interval - 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 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. Signed error messages extend the set of definitive response indicators to include the following error conditions: - ILLFORMED MESSAGE - NO SERVICE 2.3 Response Pre-production The response validity interval noted in the prior section is composed of a {produced_at, expires_on} 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 SHALL include a value for expires_on. The exact interval between produced_at and expires_on for given response is a matter of local security and operational policy. If responses are pre-produced, then for a given certificate, the perio- dicity of this pre-production SHOULD match the response validity inter- val of the most recently produced response. 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.1 GET and of receiving the response as the Entity-Body of an HTTP 1.1 Full- Response. Section 4.5 discusses use of HTTP transport. Myers [Page 3] INTERNET DRAFT October 21, 1997 3.3 Error Responses Upon receipt of a request which fails to parse, the receiving OCSP re- sponder shall 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. 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. 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.1 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. Myers [Page 4] INTERNET DRAFT October 21, 1997 OCSP_request : url request version target url : protocol “://” domain_name “/” protocol : “http” request : service_class “/” action version : “2” service_class : “status” action : “check” time : YYYYMMDDHHMMSSZ target : cert or cert_id cert : “cert” “/” certificate certificate : {base-64 encoding of single certificate} cert_id : “ID” “/” hash hash : md5_hash(Issuer DN | cert serial number) The value 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 the target certificate, base-64 encodes the hash and appends the result to the prior fields. 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 : produced_at “#” expires_on # prior_id “#” produced_at : YYYYMMDDHHMMSSZ expires_on : 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_context} “#” status_code : valid|invalid|revoked|not_revoked|expired valid : 0x31 // “1” // invalid : 0x32 // “2” // revoked : 0x33 // “3” // Myers [Page 5] INTERNET DRAFT October 21, 1997 expired : 0x34 // “4” // on_hold : 0x35 // “5” // reason_text : {for additional context} date_context : YYYYMMDDHHMMSSZ signature_block : key_id “#” sig_alg_oid “#” signature key_id : // SHA-1 hash 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.” “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 as a value for date_context. The produced_at and expires_on fields define a validity interval. This interval corresponds to the {thisUpdate, nextUpdate} CRL validity inter- val. Responses whose expires_on 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 across the sequence { produced_at#expires_on#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. Myers [Page 6] INTERNET DRAFT October 21, 1997 4.3 Mandatory and Optional Cryptographic Algorithms Clients that request OCSP services shall be capable of processing re- sponses signed used DSA keys identified by the DSA sig_alg_oid specified 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. 4.5 HTTP Transport Mechanism The request syntax is intended to mimic a file system GET 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 HTTP/1.1 The response to such a query is the Entity-Body of an HTTP 1.1 Full- Response as defined in RFC 2068 with Content-Type: XX/XX. 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= Myers [Page 7] INTERNET DRAFT October 21, 1997 If an HTTP/1.0 server receives the message or a proxy downgrades the re- quest to a 1.0 message the request will work as expected except that the connection will be closed at the end of the request, a keep-alive re- quest will not be supported. The advantages of using HTTP 1.1 over HTTP 1.0 are: 1) HTTP 1.0 is a Best Commercial Practices document while HTTP 1.1 is full standards track. 2) It would be possible to send a sequence of requests at the same time using the 'keep-alive' facility. This would allow the raw data for vali- dating a certificate to be collected in a single server transaction or allow a whole 'address book' of certificates to be checked in one go. 3) The 1.1 cache control features would be available. These allow cli- ents to specify precisely the degree of staleness they will permit. They can also make statementslike 'get me the latest if you can get it other- wise send me something no more than 240 seconds old.' 3a) A particularly useful feature is that the server can require caches to poll to check freshness each time they serve a piece of data. In the HTTP/1.0 model there is only the pragma: no-cache which prohibits all caching entirely. 5. Security Considerations For this service to be effective, certificate using systems must connect to the certificate status service provider. In the event such a connec- tion 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. Myers [Page 7] INTERNET DRAFT October 21, 1997 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 mmyers@verisign.com INTERNET DRAFT October 14, 1997 Myers [Page 1]