idnits 2.17.1 draft-ietf-pkix-ocsp-00.txt: ** The Abstract section seems to be numbered -(42): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(182): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(187): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(192): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(197): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(202): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(380): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 18 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 8) being 88 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == Line 11 has weird spacing: '...-Drafts are ...' == Line 12 has weird spacing: '...ments of the ...' == Line 17 has weird spacing: '...and may be ...' == Line 18 has weird spacing: '...afts as refer...' == Line 21 has weird spacing: '...atus of any ...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1997) is 9718 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'HTTP' is defined on line 388, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. 'HTTP') Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group Michael Myers 2 draft-ietf-pkix-ocsp-00.txt VeriSign, Inc. 3 Expires in 6 months September 1997 5 Internet Public Key Infrastructure 6 Online Certificate Status Protocol - OCSP 7 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working docu- 14 ments as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 1. Abstract 29 The protocol conventions described in this document satisfy some of the 30 operational requirements of the Internet Public Key Infrastructure 31 (PKI). This document specifies an HTTP-based application protocol use- 32 ful in determining the current status of a digital certificate without 33 the use of CRLs. Additional mechanisms addressing PKIX operational re- 34 quirements are specified in separate documents. 36 Please send comments on this document to the ietf-pkix@tandem.com mail 37 list. 39 2. Protocol Overview 41 In lieu of or as a supplement to checking against a periodic CRL, it may 42 be necessary to obtain timely status regarding a certificate�s revoca- 43 tion state (cf. PKIX Part 1, Section 3.3). Examples include high-value 44 funds transfer or the compromise of a highly sensitive key. 46 The Online Certificate Status Protocol (OCSP) enables applications to 47 efficiently and rapidly determine the validity and revocation state of 48 an identified certificate. An OCSP client issues a status request to an 49 OCSP responder and suspends acceptance of the subject certificate until 50 the responder provides a response. 52 2.1 Request 54 An OCSP request contains the following data: 56 - protocol version 57 - service request 58 - target certificate identifier or a single end-entity certificate 60 Upon receipt of a request, an OCSP Responder first determines if: 1) the 61 message is well formed, 2) the responder is configured to provide the 62 requested service, and 3) the responder can perform the requested serv- 63 ice for the subject certificate. If any one of the prior conditions are 64 not met, an error message is produced; otherwise, a definitive response 65 is returned. 67 2.2 Response 69 All definitive response messages shall be digitally signed. The key 70 used to sign definitive responses need not be the same signing key used 71 to sign the certificate. Note that caching signed responses for fre- 72 quently requested certificates may optionally provide some support for 73 reducing the cryptographic and bandwidth loads on the responder. 75 A definitive response message is composed of: 77 - date and time of response 78 - target certificate identifier 79 - certificate status value 80 - identification of public key needed to validate the signature 81 - signature algorithm OID 82 - signature computed across hash of previous five values 84 This specification defines the following definitive response indicators 85 for use in the certificate status value: 87 - VALID 88 - INVALID {includes reason text} 89 - REVOKED {includes X.509 reason code} 90 - EXPIRED {includes date of expiration} 91 - ON HOLD 92 - NOT ACTIVE 94 The path validation logic implied by the VALID and INVALID indicators is 95 that defined by PKIX Part 1. 97 The INVALID state is distinguished from the REVOKED and EXPIRED states 98 in that a valid certificate may be revoked or expired but such informa- 99 tion on an invalid certificate is misleading. 101 The ON HOLD state corresponds to valid certificates that are operation- 102 ally suspended in accordance with PKIX Part 1. 103 A request that receives a NOT ACTIVE response is a special case created 104 by the inclusion of a prior_to date field (see section 4.2). 106 Signed error messages extend the set of definitive response indicators 107 to include the following error conditions: 109 - ILLFORMED MESSAGE 110 - NO SERVICE 112 3. Functional Requirements 114 3.1 Certificate Content 116 In order to convey to OCSP clients a well-known point of information ac- 117 cess, CAs shall provide the capability to include the AuthorityInfoAc- 118 cess extension (defined in PKIX Part 1, section 4.2.2.1) in certificates 119 intended to be applied to the service. 121 CAs that support an OCSP service, either hosted locally or provided by a 122 Trusted Third Party, shall provide a value for a uniformResourceIndica- 123 tor (URI) accessLocation and the OID value id-pkix-ocsp for the access- 124 Method in the AccessDescription SEQUENCE. 126 The value of the accessLocation field in the subject certificate corre- 127 sponds to the URL placed into an OCSP request (see section 5.1). 129 3.2 Request Generation and Submission 131 OCSP clients shall be capable of transmitting OCSP as an HTTP 1.0 GET 132 and of receiving the response as the Entity-Body of an HTTP 1.0 Full- 133 Response. 135 3.3 Error Responses 137 Upon receipt of a request which fails to parse, the receiving OCSP re- 138 sponder shall respond with an error message. If the responder is con- 139 figured to provide signed error responses, a failure to parse an incom- 140 ing request shall be indicated by an ILLFORMED MESSAGE response. The 141 value of the identifier of such a response shall be NULL_ID. 143 For service requests not supported by the responder, the responder shall 144 respond with an error message. If the responder is configured to provide 145 signed error responses, non-availability of the requested service shall 146 be indicated by a NO SERVICE response. 148 This protocol makes use of HTTP as a transport. OCSP clients should 149 consequently enable automatic recovery from a lost connection. An HTTP 150 timeout mechanism is one conventional means of doing so. 152 3.4 Status Responses 154 Upon receipt of an OCSP request containing an end-entity certificate, if 155 the certificate fails to validate against Section 6 of PKIX Part 1 for 156 reasons other than revocation, OCSP responders shall respond with INVA- 157 LID. Responses may be supplemented with explanatory text that provides 158 additional context. Section 5.2 of this document specifies a minimal 159 set of explanatory text for this purpose. 161 The OCSP service request syntax provides a means for clients to bound 162 the date of interest through the use of a prior_to field. Requests con- 163 cerned with current status would thus include the current date in the 164 prior_to field while requests concerned with the validity of aged signed 165 content may supply the date of the signed document. 167 The following mandatory and optional requirements apply to OCSP respond- 168 ers with respect to prior_to field and current date: 170 1. Shall be capable of generating responses to requests that contain 171 values for prior_to matching the current date. 173 2. May provide services for values of prior_to that are earlier than the 174 current date. 176 3. Shall respond with NO SERVICE if the prior_to date in a request is 177 later than the current date. 179 The means by which OCSP clients and servers establish a common value for 180 "current date" is beyond the scope of this document. 182 If the prior_to date is earlier than the notBefore date of certificate�s 183 validity interval and the certificate otherwise satisfies the validation 184 requirements of Section 6 of PKIX Part 1, OCSP servers shall respond 185 with NOT ACTIVE. 187 If the prior_to date lies within the subject certificate�s validity in- 188 terval and the certificate otherwise satisfies the validation require- 189 ments of Section 6 of PKIX Part 1, OCSP servers shall respond with 190 VALID. 192 If the prior_to date lies within the subject certificate�s validity in- 193 terval and the certificate has been revoked by its issuing Certification 194 Authority, OCSP servers shall respond with REVOKED. 196 If the prior_to date specifies a date beyond the notAfter date in the 197 certificate�s validity interval and the certificate has not been revoked 198 by its issuing Certification Authority, OCSP responders shall respond 199 with EXPIRED. 201 If the prior_to date specifies a date beyond the notAfter date in the 202 certificate�s validity interval and the certificate has been revoked by 203 its issuing Certification Authority, OCSP responders shall respond with 204 REVOKED. 206 3.5 Signed Response Acceptance Requirements 208 Prior to accepting a signed response as valid, OCSP clients shall con- 209 firm that: 211 1. The certificate identified in a received response corresponds to that 212 which was identified in a former request; 214 2. The signature on the response is valid; 216 3. The identity of the signer matches the intended recipient of the re- 217 quest. 219 4. Detailed Protocol 221 4.1 Request Syntax 223 An OCSP request is an HTTP 1.0 GET method composed of a URL followed by 224 a sequence of keyword-value pairs. The following grammar specifies the 225 request portion of the protocol. Quoted syntactic elements are terminal 226 elements of the grammar. 228 OCSP_request : url request version target 229 url : protocol "://" domain_name "/" 230 protocol : "http" 231 request : service_class "/" action "/" prior_to 232 version : "2" 233 service_class : "status" 234 action : "check" 235 prior_to : "prior_to" time 236 time : YYYYMMDDHHMMSSZ 237 target : cert or cert_id 238 cert : "cert" "/" certificate 239 certificate : {base-64 encoding of single certificate} 240 trans_id : {an opaque identifier} 241 cert_id : "ID" "/" hash 242 hash : md5_hash(Issuer DN | cert serial number) 244 The value of "2" for the version field accommodates preliminary imple- 245 mentations of a different request and response syntax. 247 To produce a value for the cert_id field, the client first calculates an 248 MD5 hash across the concatenation of Issuer DN with the serial number in 249 the target certificate, base-64 encodes the hash and appends the result 250 to the prior fields. 252 The "prior_to" constraint indicates a client request for the status of a 253 certificate prior to the specified time. 255 4.2 Response Syntax 257 An HTTP-based OCSP response is composed of a sequence of data fields 258 separated by a "#" character. Response codes are returned as the ASCII 259 encoding of a decimal number. Values with a minus sign (ASCII encoding 260 of "-") indicate definitive error values. 262 OCSP_response : definitive_rsp | error_rsp 263 definitive_rsp : base status_value signature_block 264 error_rsp : minimal_error | definitive_error 266 minimal_error : 0x20 // " " // 267 definitive_error : base error_value signature_block 269 base : time "#" prior_id "#" 270 time : YYYYMMDDHHMMSSZ 271 prior_id : // cert_id of prior request // 273 error_value : illformed_msg | no_service 274 illformed_msg : 0x2d 0x31 // "-1" // 275 no_service : 0x2d 0x32 // "-2" // 276 status_value : status_code {reason_text or date_text} "#" 277 status_code : valid|invalid|revoked|not_revoked|expired 278 valid : 0x31 // "1" // 279 invalid : 0x32 // "2" // 280 revoked : 0x33 // "3" // 281 expired : 0x34 // "4" // 282 on_hold : 0x35 // "5" // 283 not_active : 0x36 // "6" // 284 reason_text : {for additional context} 285 date_text : YYYYMMDDHHMMSSZ 286 signature_block : key_id "#" sig_alg_oid "#" signature 287 key_id : // SHA-1 hash of public key needed to 288 validate signature // 289 sig_alg_oid : // algorithm combination used to produce sig // 290 signature : // base-64 encoded value corresponding to 291 the result of using sig-alg-oid // 293 Standard values for reason_text shall include: 294 "1 The root for this certificate is not trusted on this responder." 295 "2 Could not find CA�s public key." 296 "3 CA�s public key invalid." 297 "4 CA�s public key revoked." 298 "5 CA�s public key expired." 299 "6 CA not authorized for Subject�s name." 300 "7 CA not authorized for Subject�s privileges." 301 "8 CA�s public key did not validate signature." 302 "9 Could not find CA�s revocation information." 303 "10 CA�s CRL out of date." 305 When producing REVOKED responses, OCSP responders shall include the date 306 of the revocation in the status_value field. 308 To produce a value for the cert_id field, the client first calculates an 309 MD5 hash across the concatenation of Issuer DN with the serial number in 310 the target certificate, base-64 encodes the hash and appends the result 311 to the prior fields. 313 To produce a signed response, the responder first calculates a hash 314 across the sequence 316 { time#prior_id#status_value#key_id#sig_alg_oid# }, 318 signs the hash, base-64 encodes the result and then appends it to the 319 prior fields. The associated hash and signing algorithms are identified 320 by the value of sig_alg_oid. 322 If a request contains a direct certificate instead of a cert_id--and the 323 request results in a definitive response--OCSP responders shall calcu- 324 late a cert_id as defined in section 5.1 of this specification and in- 325 clude the resultant value in the cert_id field of the response. 327 4.3 Mandatory and Optional Cryptographic Algorithms 329 Clients that request OCSP services shall be capable of processing re- 330 sponses signed used DSA keys identified by the DSA sig_alg_oid specified 331 in section 7.2.2 of PKIX Part 1. Clients should also be capable of 332 processing RSA signatures as specified in section 7.2.1 of PKIX Part 1. 334 4.4 Responder Key Identification 336 It is possible that an OCSP responder may have more than one valid pub- 337 lic signature key of the same cryptographic algorithm. To assist cli- 338 ents in identifying which public key to use, OCSP responders shall in- 339 clude in all signed responses a SHA-1 hash of the required public key. 341 It is also possible that an OCSP client may be in possession of more 342 than one valid certificate containing the OCSP responder�s public key. 344 This specification asserts no constraints on the means by which clients 345 determine which certificate to use. 347 4.5 HTTP Transport Mechanism 349 The request syntax is intended to mimic a file system GET via HTTP in 350 order for it to be cached by local proxy responders. 352 OCSP requests are composed as an HTTP 1.0 GET as follows: 354 GET HTTP/1.0 356 Conversely, OCSP responders shall be capable of receiving such queries. 358 The response to such a query is the Entity-Body of an HTTP 1.0 Full- 359 Response as defined in RFC 1945 with Content-Type: XX/XX. 361 5. Security Considerations 363 For this service to be effective, certificate using systems must connect 364 to the certificate status service provider. In the event such a connec- 365 tion cannot be obtained, certificate-using systems should implement CRL 366 processing logic as a fall-back position. 368 A denial of service vulnerability is evident with respect to a flood of 369 queries constructed to produce error responses. The production of a 370 cryptographic signature significantly affects response generation cycle 371 time, thereby exacerbating the situation. Performance studies on a pre- 372 liminary implementation of OCSP capable of handling two million hits per 373 day without degradation suggest this effect is of an orders of magnitude 374 per response. Unsigned error responses provide a reasonable tradeoff 375 against protection against this particular attack. 377 The use of unsigned error messages introduces a vulnerability to inter- 378 mediation attacks. It is reasonable to ask for error messages to be 379 signed to address this vulnerability. A request to do so however must 380 also consider the converse risk identified above�namely that increasing 381 the response cycle time of error messages through use of cryptographic 382 signing increases the impact of flooding attacks. Parties implementing 383 OCSP responders that wish to offer the benefit of signed error responses 384 should strongly consider the use of hardware-assisted cryptography. Do- 385 ing so will reduce the threat of flood attacks. 387 6. References 388 [HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, 389 R. Fielding & H. Frystyk, RFC 1945, May 1996. 391 7. Author�s Address 393 Michael Myers 394 VeriSign, Inc. 395 1390 Shorebird Way 396 Mountain View, CA 94019 397 mmyers@verisign.com