Expires in 6 months September Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP <draft-ietf-pkix-ocsp-00.

Transcription

1 HTTP/ OK Date: Tue, 09 Apr :26:11 GMT Server: Apache/ (Unix) Last-Modified: Thu, 23 Oct :29:00 GMT ETag: "304c31-471a-344f6d3c" Accept-Ranges: bytes Content-Length: Connection: close Content-Type: text/plain PKIX Working Group Michael Myers draft-ietf-pkix-ocsp-00.txt VeriSign, Inc. Expires in 6 months September 1997 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP <draft-ietf-pkix-ocsp-00.txt> 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working 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 certificate\222s 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. Myers [Page 1]

2 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 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: - date and time of response - target certificate identifier - certificate status value - identification of public key needed to validate the signature - signature algorithm OID - signature computed across hash of previous five values This specification defines the following definitive response indicators for use in the certificate status value: - VALID - INVALID {includes reason text} - REVOKED {includes X.509 reason code} - EXPIRED {includes date of expiration} - ON HOLD - NOT ACTIVE The path validation logic implied by the VALID and INVALID indicators is that defined by PKIX Part 1. The INVALID state is distinguished from the REVOKED and EXPIRED states in that a valid certificate may be revoked or expired but such information on an invalid certificate is misleading. Myers [Page 2] The ON HOLD state corresponds to valid certificates that are operationally suspended in accordance with PKIX Part 1. A request that receives a NOT ACTIVE response is a special case created by the inclusion of a prior_to date field (see section 4.2). Signed error messages extend the set of definitive response indicators to include the following error conditions: - ILLFORMED MESSAGE - NO SERVICE

3 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 ) 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 access- Method 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.0 GET and of receiving the response as the Entity-Body of an HTTP 1.0 Full- Response. 3.3 Error Responses Upon receipt of a request which fails to parse, the receiving OCSP 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. Myers [Page 3] This protocol makes use of HTTP as a transport. OCSP clients should consequently enable automatic recovery from a lost connection. An HTTP timeout mechanism is one conventional means of doing so. 3.4 Status Responses Upon receipt of an OCSP request containing an end-entity certificate, if the certificate fails to validate against Section 6 of PKIX Part 1 for reasons other than revocation, OCSP responders shall respond with INVA- LID. Responses may be supplemented with explanatory text that provides additional context. Section 5.2 of this document specifies a minimal set of explanatory text for this purpose. The OCSP service request syntax provides a means for clients to bound the date of interest through the use of a prior_to field. Requests concerned with current status would thus include the current date in the prior_to field while requests concerned with the validity of aged signed content may supply the date of the signed document. The following mandatory and optional requirements apply to OCSP responders with respect to prior_to field and current date: 1. Shall be capable of generating responses to requests that contain values for prior_to matching the current date.

4 2. May provide services for values of prior_to that are earlier than the current date. 3. Shall respond with NO SERVICE if the prior_to date in a request is later than the current date. The means by which OCSP clients and servers establish a common value for "current date" is beyond the scope of this document. If the prior_to date is earlier than the notbefore date of certificate\222s validity interval and the certificate otherwise satisfies the validation requirements of Section 6 of PKIX Part 1, OCSP servers shall respond with NOT ACTIVE. If the prior_to date lies within the subject certificate\222s validity interval and the certificate otherwise satisfies the validation requirements of Section 6 of PKIX Part 1, OCSP servers shall respond with VALID. If the prior_to date lies within the subject certificate\222s validity interval and the certificate has been revoked by its issuing Certification Authority, OCSP servers shall respond with REVOKED. If the prior_to date specifies a date beyond the notafter date in the certificate\222s validity interval and the certificate has not been revoked Myers [Page 4] by its issuing Certification Authority, OCSP responders shall respond with EXPIRED. If the prior_to date specifies a date beyond the notafter date in the certificate\222s validity interval and the certificate has been revoked by its issuing Certification Authority, OCSP responders shall respond with REVOKED. 3.5 Signed Response Acceptance Requirements Prior to accepting a signed response as valid, OCSP clients shall 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 4.1 Request Syntax An OCSP request is an HTTP 1.0 GET method composed of a URL followed by a sequence of keyword-value pairs. The following grammar specifies the request portion of the protocol. Quoted syntactic elements are terminal elements of the grammar. OCSP_request : url request version target url : protocol "://" domain_name "/" protocol : "http" request : service_class "/" action "/" prior_to version : "2" service_class : "status" action : "check" prior_to : "prior_to" time

5 time : YYYYMMDDHHMMSSZ target : cert or cert_id cert : "cert" "/" certificate certificate : {base-64 encoding of single certificate} trans_id : {an opaque identifier} cert_id : "ID" "/" hash hash : md5_hash(issuer DN cert serial number) The value of "2" for the version field accommodates preliminary implementations of a different request and response syntax. To produce a value for the cert_id field, the client first calculates an MD5 hash across the concatenation of Issuer DN with the serial number in Myers [Page 5] the target certificate, base-64 encodes the hash and appends the result to the prior fields. The "prior_to" constraint indicates a client request for the status of a certificate prior to the specified time. 4.2 Response Syntax An HTTP-based OCSP response is composed of a sequence of data fields separated by a "#" character. Response codes are returned as the ASCII encoding of a decimal number. Values with a minus sign (ASCII encoding of "-") indicate definitive error values. OCSP_response : definitive_rsp error_rsp definitive_rsp : base status_value signature_block error_rsp : minimal_error definitive_error minimal_error : 0x20 // " " // definitive_error : base error_value signature_block base : time "#" prior_id "#" time : YYYYMMDDHHMMSSZ prior_id : // cert_id of prior request // error_value : illformed_msg no_service illformed_msg : 0x2d 0x31 // "-1" // no_service : 0x2d 0x32 // "-2" // status_value : status_code {reason_text or date_text} "#" status_code : valid invalid revoked not_revoked expired valid : 0x31 // "1" // invalid : 0x32 // "2" // revoked : 0x33 // "3" // expired : 0x34 // "4" // on_hold : 0x35 // "5" // not_active : 0x36 // "6" // reason_text : {for additional context} date_text : YYYYMMDDHHMMSSZ signature_block : key_id "#" sig_alg_oid "#" signature key_id : // SHA-1 hash of public key needed to validate signature // sig_alg_oid : // algorithm combination used to produce sig // signature : // base-64 encoded value corresponding to the result of using sig-alg-oid // Standard values for reason_text shall include: "1 The root for this certificate is not trusted on this responder." "2 Could not find CA\222s public key." "3 CA\222s public key invalid."

6 Myers [Page 6] "4 CA\222s public key revoked." "5 CA\222s public key expired." "6 CA not authorized for Subject\222s name." "7 CA not authorized for Subject\222s privileges." "8 CA\222s public key did not validate signature." "9 Could not find CA\222s revocation information." "10 CA\222s CRL out of date." When producing REVOKED responses, OCSP responders shall include the date of the revocation in the status_value field. To produce a value for the cert_id field, the client first calculates an MD5 hash across the concatenation of Issuer DN with the serial number in the target certificate, base-64 encodes the hash and appends the result to the prior fields. To produce a signed response, the responder first calculates a hash across the sequence { time#prior_id#status_value#key_id#sig_alg_oid# }, signs the hash, base-64 encodes the result and then appends it to the prior fields. The associated hash and signing algorithms are identified by the value of sig_alg_oid. If a request contains a direct certificate instead of a cert_id--and the request results in a definitive response--ocsp responders shall calculate a cert_id as defined in section 5.1 of this specification and include the resultant value in the cert_id field of the response. 4.3 Mandatory and Optional Cryptographic Algorithms Clients that request OCSP services shall be capable of processing responses signed used DSA keys identified by the DSA sig_alg_oid specified in section of PKIX Part 1. Clients should also be capable of processing RSA signatures as specified in section of PKIX Part 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 responder\222s public key. This specification asserts no constraints on the means by which clients determine which certificate to use. Myers [Page 7] 4.5 HTTP Transport Mechanism The request syntax is intended to mimic a file system GET via HTTP in

7 order for it to be cached by local proxy responders. OCSP requests are composed as an HTTP 1.0 GET as follows: GET <request> HTTP/1.0 Conversely, OCSP responders shall be capable of receiving such queries. The response to such a query is the Entity-Body of an HTTP 1.0 Full- Response as defined in RFC 1945 with Content-Type: XX/XX. 5. Security Considerations For this service to be effective, certificate using systems must connect to the certificate status service provider. In the event such a connection 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 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 above\227namely 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. 6. References [HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R. Fielding & H. Frystyk, RFC 1945, May Author\222s Address Michael Myers VeriSign, Inc Shorebird Way Mountain View, CA mmyers@verisign.com

8 Myers [Page 8] INTERNET DRAFT October 14, 1997