idnits 2.17.1 draft-ietf-pkix-ocsp-02.txt: ** The Abstract section seems to be numbered -(295): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(315): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(375): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(378): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(412): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(632): 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-25) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 49 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 1 longer page, the longest (page 3) being 59 lines 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 3 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 21 instances of lines with control characters in the document. 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: '...cuments of th...' == Line 17 has weird spacing: '...MAY be updat...' == Line 18 has weird spacing: '...afts as refer...' == Line 21 has weird spacing: '...atus of any ...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 1998) is 9566 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 647, but no explicit reference was found in the text == Unused Reference: 'MUSTSHOULD' is defined on line 653, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. 'HTTP') ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC 4248, RFC 4266) Summary: 17 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group Michael Myers(VeriSign) 2 draft-ietf-pkix-ocsp-02.txt Rich Ankney (CertCo) 3 Expires in 6 months February 1998 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 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups MAY also distribute working 14 documents 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 32 useful in determining the current status of a digital certificate 33 without the use of CRLs. Additional mechanisms addressing PKIX 34 operational requirements 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 43 revocation state (cf. PKIX Part 1, Section 3.3). Examples include high- 44 value 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 The OCSP protocol is intended to be a light-weight HTTP application that 53 allows certificate recipients (users or application programs) to assure 54 themselves, in a low-overhead manner, that a certificate is valid. By 55 design, OCSP resembles HTTP in syntax and, where they overlap, in 56 semantics. An anticipated goal of this decision is to leverage the 57 growing tools and infrastructure of the Web (most notably HTTP caching) 58 wherever possible. Section 4.6 discusses the use (and limitations) of 59 HTTP 1.0 and HTTP 1.1 in more detail. 61 2.1 Request 63 An OCSP request contains the following data: 65 - protocol version 66 - service request 67 - target certificate identifier or a single end-entity certificate 68 - optional extensions which MAY be processed by the OCSP Responder 69 - an optional signature computed over the previous four fields 70 - additional (optional) extensions, which are not included in the 71 signature computation 73 Upon receipt of a request, an OCSP Responder first determines if: 1) the 74 message is well formed, 2) the responder is configured to provide the 75 requested service, and 3) the responder can perform the requested 76 service for the subject certificate. If any one of the prior conditions 77 are not met, an error message is produced; otherwise, a definitive 78 response is returned. 80 2.2 Response 82 All definitive response messages SHALL be digitally signed. The key 83 used to sign definitive responses need not be the same signing key used 84 to sign the certificate. Note that caching signed responses for 85 frequently requested certificates MAY optionally provide some support 86 for reducing the cryptographic and bandwidth loads on the responder. 88 A definitive response message is composed of: 90 - response validity interval 91 - target certificate identifier 92 - certificate status value 93 - identification of public key needed to validate the signature 94 - signature algorithm OID 95 - optional extensions 96 - signature computed across hash of previous six values 97 - additional (optional) extensions, which are not included in the 98 signature computation 100 This specification defines the following definitive response indicators 101 for use in the certificate status value: 103 - VALID 104 - INVALID {includes reason text} 105 - REVOKED {includes date of revocation} 106 - EXPIRED {includes date of expiration} 107 - ON HOLD {includes date of suspension} 108 - TRY LATER {service temporarily unavailable} 109 The path validation logic implied by the VALID and INVALID indicators is 110 that defined by PKIX Part 1. 112 The INVALID state is distinguished from the REVOKED and EXPIRED states 113 in that a valid certificate MAY be revoked or expired but such 114 information on an invalid certificate is misleading. 116 The ON HOLD state corresponds to valid certificates that are 117 operationally suspended in accordance with PKIX Part 1. 119 In the event that the OCSP responder is operational, but unable to 120 return a status for the requested certificate, the TRY LATER response 121 can be used to indicate that the service exists, but is temporarily 122 unable to respond. 124 Signed error messages extend the set of definitive response indicators 125 to include the following error conditions: 127 - ILLFORMED MESSAGE 128 - NO SERVICE 129 - CERTIFICATE DATA REQUIRED 131 A server produces the ILLFORMED MESSAGE response if the request received 132 does not conform to the OCSP syntax. 134 The response NO SERVICE MAY be produced in any circumstance in which the 135 server has received a well formed OCSP request but is unable to process 136 it. 138 The response CERTIFICATE DATA REQUIRED is used in cases where the server 139 requires the client to supply the certificate data itself in order to 140 construct a response. 142 2.3 Response Pre-production 144 The response validity interval noted in the prior section is composed of 145 a {produced-at, next-update} pair of elements in the response syntax. 146 Section 4.2 provides details of the response syntax. 148 OCSP responders MAY pre-produce signed responses reflecting the current 149 status of certificates at the time the response was produced. The time 150 at which the response was produced SHALL be reflected in the produced-at 151 field of the response. 153 The producer of the response MAY include a value for next-update. The 154 exact interval between produced-at and next-update for given response is 155 a matter of local security and operational policy. If the next-update 156 field is not present, the response is valid only for the particular 157 request which prompted it. Equivalently, the next-update field is 158 considered to be the same as the produced-at field. 160 If responses are pre-produced, then for a given certificate, the 161 periodicity of this pre-production SHOULD match the response validity 162 interval of the most recently produced response. 164 3. Functional Requirements 166 3.1 Certificate Content 168 In order to convey to OCSP clients a well-known point of information 169 access, CAs SHALL provide the capability to include the 170 AuthorityInfoAccess extension (defined in PKIX Part 1, section 4.2.2.1) 171 in certificates intended to be applied to the service. 173 CAs that support an OCSP service, either hosted locally or provided by a 174 Trusted Third Party, SHALL provide a value for a 175 uniformResourceIndicator (URI) accessLocation and the OID value id-pkix- 176 ocsp for the accessMethod in the AccessDescription SEQUENCE. 178 The value of the accessLocation field in the subject certificate 179 corresponds to the URL placed into an OCSP request (see section 5.1). 181 3.2 Request Generation and Submission 183 OCSP clients SHALL be capable of transmitting OCSP as an HTTP 1.1 GET 184 and of receiving the response as the Entity-Body of an HTTP 1.1 Full- 185 Response. OCSP Clients MAY be capable of transmitting OCSP as an HTTP 186 1.1 POST with the certificate being queried forming the message body. 187 OCSP servers SHALL support HTTP 1.1 GET requests and MAY support HTTP 188 1.1 POST requests. Section 4.5 discusses use of HTTP transport. 190 3.3 Error Responses 192 Upon receipt of a request which fails to parse, the receiving OCSP 193 responder SHALL respond with an error message. If the responder is 194 configured to provide signed error responses, a failure to parse an 195 incoming request SHALL be indicated by an ILLFORMED MESSAGE response. 196 The value of the identifier of such a response SHALL be NULL_ID. 198 For service requests not supported by the responder, the responder SHALL 199 respond with an error message. If the responder is configured to provide 200 signed error responses, non-availability of the requested service SHALL 201 be indicated by a NO SERVICE response. 203 This protocol makes use of HTTP as a transport. OCSP clients SHOULD 204 consequently enable automatic recovery from a lost connection. An HTTP 205 timeout mechanism is one conventional means of doing so. 207 3.4 Status Responses 209 Upon receipt of an OCSP request containing an end-entity certificate, if 210 the certificate fails to validate against Section 6 of PKIX Part 1 for 211 reasons other than revocation, OCSP esponders SHALL respond with 212 INVALID. Responses MAY be supplemented with explanatory text that 213 provides additional context. Section 5.2 of this document specifies a 214 minimal set of explanatory text for this purpose. 216 3.5 Signed Response Acceptance Requirements 218 Prior to accepting a signed response as valid, OCSP clients SHALL 219 confirm that: 221 1. The certificate identified in a received response corresponds to 222 that which was identified in a former request; 224 2. The signature on the response is valid; 226 3. The identity of the signer matches the intended recipient of the 227 request. 229 4. Detailed Protocol 231 The protocol consists of an OCSP request and an OCSP response. The 232 request is conveyed as part of an HTTP GET or POST request, and its 233 syntax is compatible with that defined in [URL]. In particular, 234 reserved characters in the request are encoded using the %xx mechanism 235 of [URL], unless they are used for their reserved purposes (in this 236 case, delimiting fields in the request). Note that this encoding 237 requirement includes the three special characters (plus sign, forward 238 slash, and equal sign) used in the base64 encoding mechanism. Components 239 in the request are thus of the form: 241 token = *(ALPHA / DIGIT / SAFE / EXTRA) 242 safe = "$" | "-" | "_" | "." | "+" 243 extra = "!" | "*" | "'" | "(" | ")" | "," 245 Components (and sub-fields within the components) are delimited using 246 several of the reserved characters: 248 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" 250 The following (punctuation) characters are always encoded, as they might 251 have meaning outside the scope of the URL. E.g., the pound sign (#) is 252 used to separate a URL and a fragment identifier. 254 punctuation = "<" | ">" | "#" | "%" | <"> 256 Requests and responses are composed of: 258 - fixed fields (required in all messages), followed by 259 - optional fields, which MUST be supported by an OCSP responder, 260 but need not be present in all messages, and 261 - optional extensions, which MAY be supported by an OCSP responder. 263 Optional fields and extensions use a simple name/value syntax. 265 Definitive responses and definitive error responses MUST be signed. 266 Requests MAY be signed using the request-signature extension. 267 Signatures are computed from the beginning of the request or response 268 through the first two fields of the signature block. Extensions MAY be 269 present before the signature (in which case they are included in the 270 signature computation), or after the signature (in which case they are 271 not signed. 273 4.1 Request Syntax 275 An OCSP request is an HTTP 1.1 GET or POST method composed of a URL 276 followed by a sequence of required and optional fields. The following 277 grammar specifies the request portion of the protocol. Quoted syntactic 278 elements are terminal elements of the grammar, which is the ABNF grammar 279 from [ABNF]. 281 OCSP-request = url "/ocsp/ver/1/" target [extensions] 282 [signature] [extensions] 283 url = protocol �://� domain-name �/� 284 protocol = �http� 285 time = 286 target = cert-id 287 cert-id = �ID� �/� hash 288 hash = 289 extensions = *extension 290 extension = �/� ext-name �/� ext-value 291 ext-name = ALPHA *(ALPHA / DIGIT / �-�) 292 ext-value = token 293 DQUOTE = %x22 294 signature = �/� �sig� �/� signature-block 295 signature-block = key-id �&� sig-alg-oid �&� signature-value 296 key-id = 299 sig-alg-oid = 301 signature-value = 304 The value of �2� for the version field accommodates preliminary 305 implementations of a different request and response syntax. 307 To produce a value for the cert-id field, the client first calculates a 308 SHA-1 hash across the concatenation of Issuer DN with the serial number 309 in the target certificate, base-64 encodes the hash and appends the 310 result to the prior fields. 312 The HTTP POST method is to be used in cases where the certificate data 313 itself is required by the server. The body of the request has content 314 type application/xxxx and consists of the certificate data itself. Since 315 HTTP requires connections to be �8-bit clean� no additional encoding of 316 the certificate data is required. 318 Support for extensions is OPTIONAL. This standard defines several 319 useful extensions in Section 4.5. Additional extensions MAY be defined 320 in additional RFCs. All extensions use the name/value syntax described 321 above. Unrecognized extensions can be ignored, by skipping past the 322 slash delimiting the value, then skipping the value. 324 The requester signature is used to authenticate the requester to the 325 OCSP Responder. It is used in conjunction with the requester 326 certificate extension defined below. 328 The signature is computed over the portion of the request which precedes 329 the signature, i.e. the URL, request, and target fields, any extensions 330 which precede the signature, and the key-id and sig-alg-oid portions of 331 this extension. Note that extensions following this one are not 332 included; typically the requester certificate extension does not need to 333 be signed, and would be positioned after the signature. Thus, the 334 signature is computed over: 336 { url request target extensions sig-fields } 338 The OCSP Responder verifies the signature, using the public key 339 identified by key-id and the requester certificate extension defined 340 below. 342 4.2 Response Syntax 344 An HTTP-based OCSP response is composed of a sequence of data fields 345 similar to the OCSP request. Response codes are returned as the ASCII 346 encoding of a decimal number. Values with a minus sign (ASCII encoding 347 of �-�) indicate definitive error values. 349 OCSP-response = definitive-rsp / error-rsp 350 definitive-rsp = base status-value [extensions] signature 351 [extensions] 352 error-rsp = minimal-error / definitive-error 353 minimal-error = %x20 ; � � 354 definitive-error = base error-value [extensions] signature 355 [extensions] 357 base = produced-at �/� prior-id �/� next-update 358 produced-at = time 359 next-update = �next-update� �/� time 360 prior-id = 361 error-value = illformed-msg / no-service /certificate-reqd 362 illformed-msg = %x2d %x31 ; �-1� 363 no-service = %x2d %x32 ; �-2� 364 certificate-reqd = %x2d %x33 ; �-3� 365 status-value = status-code [�/� reason-text ] 366 [ �/� date-context ] 367 status-code = valid /invalid / revoked / not-revoked / 368 expired / try-later 369 valid = %x31 ; �1� 370 invalid = %x32 ; �2� 371 revoked = %x33 ; �3� 372 expired = %x34 ; �4� 373 on-hold = %x35 ; �5� 374 try-later = %x36 ; �6� 375 reason-text = �reason� �/� token ; for additional context 376 date-context = �on� �/� time 377 Standard values for reason-text SHALL include: 378 �1 The root for this certificate is not trusted on this responder.� 379 �2 Could not find CA�s public key.� 380 �3 CA�s public key invalid.� 381 �4 CA�s public key revoked.� 382 �5 CA�s public key expired.� 383 �6 CA not authorized for Subject�s name.� 384 �7 CA not authorized for Subject�s privileges.� 385 �8 CA�s public key did not validate signature.� 386 �9 Could not find CA�s revocation information.� 387 �10 CA�s CRL out of date.� 389 When producing REVOKED or HOLD responses, OCSP responders SHALL include 390 the date of the revocation in the status-value field as a value for 391 date-context. 393 The produced-at and next-update fields define a validity interval. This 394 interval corresponds to the {thisUpdate, nextUpdate} CRL validity 395 interval. Responses whose next-update value is earlier than the local 396 system time value SHOULD be considered unreliable. 398 To produce a value for the cert-id field, the client first calculates an 399 MD5 hash across the concatenation of Issuer DN with the serial number 400 in the target certificate, base-64 encodes the hash and appends the 401 result to the prior fields. 403 To produce a signed response, the responder first calculates a hash of 404 the sequence of characters from the beginning of the response through 405 the �&� following the sig-alg-oid subfield of the signature block. 406 Using the above syntax, this is the sequence: 408 base status-value [extensions] sig-fields 410 where 412 sig-fields = �/� �sig� �/� key-id �&� sig-alg-oid �&� 414 The responder signs the hash, base-64 encodes the result and then 415 appends it to the prior fields, encoding any special characters in the 416 base64 signature as described in [URL]. The associated hash and signing 417 algorithms are identified by the value of sig-alg-oid. 419 4.3 Mandatory and Optional Cryptographic Algorithms 421 Clients that request OCSP services SHALL be capable of processing 422 responses signed used DSA keys identified by the DSA sig-alg-oid 423 specified in section 7.2.2 of PKIX Part 1. Clients SHOULD also be 424 capable of processing RSA signatures as specified in ection 7.2.1 of 425 PKIX Part 1. 427 4.4 Extensions 429 This section defines some standard extensions. Support for all 430 extensions is OPTIONAL. For each extension, the definition indicates 431 its syntax, processing performed by the OCSP Responder, and any 432 extensions which are included in the corresponding response. Note that 433 extensions use a simple name/value syntax. 435 4.4.1 Nonce 437 The nonce cryptographically binds a request and response, to prevent 438 replay attacks. The nonce extension has syntax: 440 �nonce� �/� atom 442 and MAY be any non-repeating value (e.g., random number, transaction 443 hash, counter, or timestamp). The OCSP Responder returns the nonce as a 444 response extension. The nonce is included in the response signature 445 computation. The nonce structure is opaque to the OCSP Responder. 447 4.4.2 Requester Certificate 449 This extension conveys the certificate of the signer, and is used by the 450 OCSP Responder to verify the requester signature. It has syntax: 452 �reqcert� �/� 453 �reqid� �/� hash ; MD5(issuer || serial #) 455 The cert production is either a base64-encoded certificate, or the 456 hash of the issuer and serial number of the certificate as described in 457 Section 4.1. 459 NOTE: Depending on the OCSP implementation, the key-id contained 460 in the key-id portion of the signature extension MAY be sufficient 461 to identify the key needed to verify the signature. In this case, 462 this extension is not needed. 464 NOTE: This extension contains a single certificate. Other(CA) 465 certificates MAY be needed for the OCSP to verify the signature. 466 This could be included in the request, as additional instances of 467 this extension. Or another extension could be defined, which 468 might convey a SEQUENCE OF Certificate, or an empty CMS SignedData 469 instance (with the certificates field populated appropriately). 470 Construction of the relevant certification path by the OCSP 471 Responder could (instead) just be declared out of scope for this 472 standard. 474 4.4.3 CRL References 476 It MAY be desirable for the OCSP responder to indicate the CRL on which 477 a revoked or held certificate is found. This can be useful where OCSP 478 is used between repositories, and also as an auditing mechanism. Three 479 extensions are defined for this purpose: 481 �crlurl� �/� token 482 �crlnum� �/� number 483 �crltime� �/� time 484 number = *DIGIT 485 The crlurl extension contains a URL which can be used to retrieve the 486 CRL the requested certificate is listed on. Note that any reserved 487 characters in the token must be encoded per [URL]. 489 The crlnum extension indicates the value in the CRL number extension of 490 the relevant CRL. 492 The crltime extension indicates the value in the thisUpdate field of the 493 relevant CRL. 495 4.4.4 Policy Identifier 497 This extension contains a policy ID and relevant qualifiers. It MAY be 498 sent in a request to indicate the policy which the requester considers 499 acceptable. This extension MAY also be included in the response. The 500 syntax is: 502 �policy� �/� 504 4.5 Responder Key Identification 506 It is possible that an OCSP responder MAY have more than one valid 507 public signature key of the same cryptographic algorithm. To assist 508 clients in identifying which public key to use, OCSP responders SHALL 509 include in all signed responses a SHA-1 hash of the required public key. 511 It is also possible that an OCSP client MAY be in possession of more 512 than one valid certificate containing the OCSP responder�s public key. 514 This specification asserts no constraints on the means by which clients 515 determine which certificate to use. 517 4.6 HTTP Transport Mechanism 519 The request syntax is intended to mimic an object retrieval via HTTP 1.1 520 in order for it to be cached by local proxy responders. 522 OCSP requests are composed as an HTTP GET as follows: 524 GET HTTP/1.1 525 527 OCSP requests are composed as an HTTP POST as follows: 529 POST HTTP/1.1 530 532 534 The response to such a query is the Entity-Body of an HTTP 1.1 Full- 535 Response as defined in RFC 2068 with Content-Type: application/ocsp. 537 A representation of the HTTP context of an OCSP request and response 538 follows. The content differs slightly from current request and response 539 syntax. 541 GET /status/check/ver/1/ID/qyXLklpfK2wYd8iPsGdOwQ== HTTP/1.1 542 Host: status.our-ca.com 543 Date: Thu, 23 Oct 1997 22:33:30 GMT 544 User-Agent: Transport xy/z 546 HTTP/1.0 200 OK 547 Server: Netscape-Enterprise/2.0a 548 Date: Thu, 23 Oct 1997 22:33:34 GMT 549 Last-modified: Thursday, 23 Oct 1997 12:38:25 GMT 550 Expires: Thursday, 23 Oct 1997 23:38:25 GMT 551 Content-type: application/octet-stream 553 19971023123825Z&qyXLklpfK2wYd8iPsGdOwQ==&2&1.3.14.3.2.15 555 #uFom3GIAHjIdlWZ5SsFKTvGXHgML35n21zsQvFGT3hWmULBsvH6MDg4+FY55P6wgwxAWTSV 556 S3h8xFiacN9m5S4xBDO/5IpVFpFwdhrSe8S5/jYK2qPGsGdjzCmGQIX03CaGLh+NOn8x9Wpo 557 wtnCMhg4UeDZm+b4BKrmNpT6g0Mw= 559 In cases where the server returns the response CERTIFICATE DATA REQUIRED 560 the request must be repeated using the POST method to provide the server 561 with the certificate data. Note that base64 encoding is specified in the 562 following example for readability alone. A production client would 563 normally use binary encoding. 565 POST /status/check/ver/1/ID/qyXLklpfK2wYd8iPsGdOwQ== HTTP/1.1 566 Host: status.our-ca.com 567 Date: Thu, 23 Oct 1997 22:33:30 GMT 568 User-Agent: Transport xy/z 569 Content-Type: application/X509 570 Content-Encoding: Base-64 572 2+3094fh9p2831410t493upoiqwjf9p832174rtawoirtf0913274r5hqefpq0w7rfqolaiw 573 yerq32047r9qwherfpqw40/r7qp9w84utrp92q34723q940+3q4tp0u3q4tu3qp40t73q04t 574 7r0q394ut0qwu4t0[9qw40t7q3/048u3q4wtu3q0+4t0+3q47034q7t093749734097t0709 575 3475t023q743wq/890++ewrtpoiausrpoiurpsoituqwpoet/0== 577 HTTP/1.0 200 OK 578 Server: Netscape-Enterprise/2.0a 579 Date: Thu, 23 Oct 1997 22:33:34 GMT 580 Last-modified: Thursday, 23 Oct 1997 12:38:25 GMT 581 Expires: Thursday, 23 Oct 1997 23:38:25 GMT 582 Content-type: application/octet-stream 584 19971023123825Z&qyXLklpfK2wYd8iPsGdOwQ==&2&1.3.14.3.2.15 586 #uFom3GIAHjIdlWZ5SsFKTvGXHgML35n21zsQvFGT3hWmULBsvH6MDg4+FY55P6wgwxAWTSV 587 S3h8xFiacN9m5S4xBDO/5IpVFpFwdhrSe8S5/jYK2qPGsGdjzCmGQIX03CaGLh+NOn8x9Wpo 588 wtnCMhg4UeDZm+b4BKrmNpT6g0Mw= 589 If an HTTP/1.0 server receives the message or a proxy downgrades the 590 request to a 1.0 message the request will work as expected except that 591 the connection will be closed at the end of the request, a keep-alive 592 request will not be supported. The advantages of using HTTP 1.1 over 593 HTTP 1.0 are: 595 1) HTTP 1.0 is a Best Commercial Practices document while HTTP 1.1 is 596 full standards track. 598 2) It would be possible to send a sequence of requests at the same time 599 using the 'keep-alive' facility. This would allow the raw data for 600 validating a certificate to be collected in a single server transaction 601 or allow a whole 'address book' of certificates to be checked in one go. 603 3) The 1.1 cache control features would be available. These allow 604 clients to specify precisely the degree of staleness they will permit. 605 They can also make statements like 'get me the latest if you can get it 606 otherwise send me something no more than 240 seconds old.' 608 3a) A particularly useful feature is that the server can require caches 609 to poll to check freshness each time they serve a piece of data. In the 610 HTTP/1.0 model there is only the pragma: no-cache which prohibits all 611 caching entirely. 613 5. Security Considerations 615 For this service to be effective, certificate using systems must connect 616 to the certificate status service provider. In the event such a 617 connection cannot be obtained, certificate-using systems could implement 618 CRL processing logic as a fall-back position. 620 A denial of service vulnerability is evident with respect to a flood of 621 queries constructed to produce error responses. The production of a 622 cryptographic signature significantly affects response generation cycle 623 time, thereby exacerbating the situation. Performance studies on a 624 preliminary implementation of OCSP capable of handling two million hits 625 per day without degradation suggest this effect is of an orders of 626 magnitude per response. Unsigned error responses provide a reasonable 627 tradeoff against protection against this particular attack. 629 The use of unsigned error messages introduces a vulnerability to 630 intermediation attacks. It is reasonable to ask for error messages to be 631 signed to address this vulnerability. A request to do so however must 632 also consider the converse risk identified above�namely that increasing 633 the response cycle time of error messages through use of cryptographic 634 signing increases the impact of flooding attacks. Parties implementing 635 OCSP responders that wish to offer the benefit of signed error responses 636 SHOULD strongly consider the use of hardware-assisted cryptography. 637 Doing so will reduce the threat of flood attacks. 639 The use of precomputed responses MAY allow replay attacks in which an 640 old (VALID) response is replayed prior to its expiration date but after 641 the certificate has been revoked. HTTP caching MAY also allow replay of 642 stale responses; see Section 4.5 for a discussion of how caching MAY be 643 controlled in HTTP 1.1. 645 6. References 647 [HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, 648 R. Fielding & H. Frystyk, RFC 1945, May 1996. 650 [ABNF] Augmented BNF for Syntax Specifications: ABNF. D. Crocker, 651 P. Overell, RFC 2234, November 1997. 653 [MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels, 654 S. Bradner, RFC 2119, March 1997. 656 [URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter, 657 M. McCahill, RFC 1738, December 1994. 659 7. Author�s Address 661 Michael Myers 662 VeriSign, Inc. 663 1390 Shorebird Way 664 Mountain View, CA 94019 665 mmyers@verisign.com 667 Rich Ankney 668 CertCo, LLC 669 13506 King Charles Dr. 670 Chantilly, VA 20151 671 rankney@erols.com 673 Appendix A 675 Registration of OCSP as a MIME type 677 To: IANA@isi.edu 678 Subject: Registration of new MIME content-type/subtype 680 MIME type name: application 682 MIME subtype name: ocsp 684 Required parameters: none 686 Optional parameters: none 688 Encoding considerations: none 690 Security considerations: 692 This data information which may be conceivably be used to enforce legal contracts, 693 resolve disputes or transfer financial risk from one party to another. The design 694 of software that processes this type should be trustworthy in its design and 695 operations. 697 Published specification: This document