idnits 2.17.1 draft-ietf-pkix-ocsp-03.txt: ** The Abstract section seems to be numbered 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-03-29) 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 7 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 1) 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 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 15 has weird spacing: '...-Drafts are ...' == Line 16 has weird spacing: '...cuments of th...' == Line 21 has weird spacing: '...and may be u...' == Line 22 has weird spacing: '...afts as refer...' == 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 (March 1998) is 9511 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) -- Looks like a reference, but probably isn't: '0' on line 670 -- Looks like a reference, but probably isn't: '1' on line 671 -- Looks like a reference, but probably isn't: '2' on line 672 == Unused Reference: 'HTTP' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'ABNF' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'MUSTSHOULD' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'URL' is defined on line 528, 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: 15 errors (**), 0 flaws (~~), 12 warnings (==), 6 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-03.txt Rich Ankney (CertCo) 3 Ambarish Malpani (Valicert) 4 Slava Galperin (Netscape) 5 Carlisle Adams (Entrust Technologies) 7 Expires in 6 months March 1998 9 X.509 Internet Public Key Infrastructure 10 Online Certificate Status Protocol - OCSP 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 To view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 29 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 30 (US West Coast). 32 1. Abstract 34 This document specifies a protocol useful in determining the 35 current status of a digital certificate without the use of CRLs. 36 Additional mechanisms addressing PKIX operational requirements are 37 specified in separate documents. 39 Section 2 provides an overview of the protocol. Section 3 goes 40 establishes functional requirements, while section 4 provides the 41 details of the protocol. In section 5 we cover security issues with the 42 protocol. Appendix A demonstrates OCSP over HTTP and appendix B 43 accumulates ASN.1 syntactic elements. 45 2. Protocol Overview 47 In lieu of or as a supplement to checking against a periodic CRL, it may 48 be necessary to obtain timely status regarding a certificate�s 49 revocation state (cf. PKIX Part 1, Section 3.3). Examples include high- 50 value funds transfer or the compromise of a highly sensitive key. 52 The Online Certificate Status Protocol (OCSP) enables applications 53 to determine the revocation state of an identified certificate. OCSP may 54 be used to satisfy some of the operational requirements of providing 55 more timely revocation information than is possible with CRLs. An OCSP 56 client issues a status request to an OCSP responder and suspends 57 acceptance of the certificate in question until the responder 58 provides a response. 60 This protocol specifies the data that needs to be exchanged between an 61 application checking the revocation status of a certificate and the 62 server providing that status. 64 2.1 Request 66 An OCSP request contains the following data: 68 - protocol version 69 - service request 70 - target certificate identifier or a single end-entity certificate 71 - optional extensions which MAY be processed by the OCSP Responder 73 Upon receipt of a request, an OCSP Responder 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, the OCSP responder produces an error message; otherwise, it 78 returns a definitive response. 80 2.2 Response 82 All definitive response messages SHALL be digitally signed. The key 83 used to sign the response MUST belong to one of the following: 85 - the CA who issued the certificate in question 86 - a Trusted Responder whose public key is trusted by the requester 88 A definitive response message is composed of: 90 - response type identifier (to allow for different response types) 91 - version of the response 92 - name of the responder 93 - responses for each of the certificates in a request 94 - optional extensions 95 - signature algorithm OID 96 - signature computed across hash of the response 98 The response for each of the certificates in a request consists of 100 - target certificate identifier 101 - certificate status value 102 - response validity interval 103 - optional extensions 105 This specification defines the following definitive response indicators 106 for use in the certificate status value: 108 - notRevoked 109 - revoked 110 - onHold 111 - expired 113 The notRevoked state indicates that the certificate is not revoked. It 114 does not necessarily mean that the certificate was ever issued. Nor 115 does it mean that the certificate is in its validity interval. A 116 notRevoked state by an OCSP responder DOES NOT absolve the application 117 of the responsibility of checking that the certificate is in its 118 validity period and has been correctly signed. 120 The revoked state indicates that the certificate has been revoked. 122 The onHold state corresponds to valid certificates that are 123 operationally suspended in accordance with PKIX Part 1. 125 A request that returns an expired state indicates that the validity of 126 the subject certificate has expired. Applications SHOULD check the 127 validity interval of a certificate and not perform an OCSP request if 128 the certificate�s validity has expired. 130 2.3 Exception Cases 132 In case of errors, the OCSP Responder may return an error message. 133 Errors can be of the following types: 135 - malformedRequest 136 - internalError 137 - tryLater 138 - notFound 139 - certRequired 140 - noCRL 142 A server produces the malformedRequest response if the request received 143 does not conform to the OCSP syntax. 145 The response internalError indicates that the OCSP responder reached 146 an inconsistent internal state. The query should be retried, potentially 147 with another responder. 149 In the event that the OCSP responder is operational, but unable to 150 return a status for the requested certificate, the tryLater response 151 can be used to indicate that the service exists, but is temporarily 152 unable to respond. 154 A recipient of a request may not be able to resolve a reference to the 155 subject certificate; a value of notFound is returned in such a case. 156 This value should not be taken as confirmation of the certificate's 157 existence. 159 The response certRequired is returned in cases where the server requires 160 the client to supply the certificate data itself in order to construct a 161 response. 163 An extension is defined to enable delivery of CRLs with OCSP responses. 164 However, there is no requirement to list certificates on a CRL in order 165 to use OCSP to acquire revocation status on those certificates. The 166 error value noCRL is defined for this instance. 168 2.4 Response Pre-production 170 The response validity interval noted in the prior section is composed of 171 a {thisUpdate, nextUpdate} pair of elements in the response syntax. 172 Section 4.2 provides details of the response syntax. 174 OCSP responders MAY pre-produce signed responses specifying the current 175 status of certificates at the time the response was produced. The time 176 at which the response was produced SHALL be reflected in the thisUpdate 177 field of the response. 179 If responses are pre-produced, then for a given certificate, the 180 periodicity of this pre-production SHOULD match the response validity 181 interval of the most recently produced response. 183 [need to resolve the above statement with the following RCSP assertions, 184 esp. with respect to positive responses. Question put to the list.] 186 The time at which the response was known to be correct SHALL 187 be specified in the producedAt field of the response. This time is not 188 necessarily the same as the time at which the response was produced - 189 e.g. if the responder obtains a CRL from a CA and creates pre-produced 190 responses, the thisUpdate time should specify the thisUpdate time in 191 the CRL. 193 The producer of the response MAY include a value for nextUpdate. The 194 exact interval between thisUpdate and nextUpdate for given response is 195 a matter of local security and operational policy. If the nextUpdate 196 field is not present, the response is is known to be correct at the 197 thisUpdate time. Equivalently, the nextUpdate field is considered to be 198 the same as the thisUpdate field. 200 No assertions are being made about the current state of the certificate, 201 nor are any recommendations being made as to when the requestor should 202 check again with the responder. If the value of nextUpdate is set, it 203 is just a hint, not a guarantee, of when the responder expects to have 204 new information about that certificate's status. 206 3. Functional Requirements 208 3.1 Certificate Content 210 In order to convey to OCSP clients a well-known point of information 211 access, CAs SHALL provide the capability to include the 212 AuthorityInfoAccess extension (defined in PKIX Part 1, section 4.2.2.1) 213 in certificates that can be checked using OCSP. Alternatively, the 214 accessLocation for the OCSP provider may be configured locally at the 215 OCSP client. 217 CAs that support an OCSP service, either hosted locally or provided by 218 an Authorized Responder, MAY provide a value for a 219 uniformResourceIndicator (URI) accessLocation and the OID value 220 id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE. 222 The value of the accessLocation field in the subject certificate 223 corresponds to the URL placed into an OCSP request. 225 3.3 Error Responses 227 Upon receipt of a request which fails to parse, the receiving OCSP 228 responder SHALL respond with an error message. Error responses MAY be 229 signed. 231 3.5 Signed Response Acceptance Requirements 233 Prior to accepting a signed response as valid, OCSP clients SHALL 234 confirm that: 236 1. The certificate identified in a received response corresponds to 237 that which was identified in the corresponding request; 239 2. The signature on the response is valid; 241 3. The identity of the signer matches the intended recipient of the 242 request. 244 4. Detailed Protocol 246 The ASN.1 syntax imports terms defined in the X.509 Certificate and CRL 247 Profile Internet Draft. For signature calculation, the data to be signed 248 is encoded using the ASN.1 distinguished encoding rules (DER) [X.690]. 250 ASN.1 EXPLICIT tagging is used as a default unless specified otherwise. 252 The terms imported from elsewhere are: Version, Extensions, 253 CertificateSerialNumber, SubjectPublicKeyInfo, Name, 254 AlgorithmIdentifier, GeneralizedTime 256 4.1 Request Syntax 258 OCSPRequest ::= SEQUENCE { 259 version [0] EXPLICIT Version DEFAULT v1, 260 hashAlgorithm AlgorithmIdentifier, 261 requestList SEQUENCE OF Request, 262 requestExtensions [1] EXPLICIT Extensions OPTIONAL } 264 Version ::= INTEGER { v1(0) } 266 Request ::= CHOICE { 267 certID [0] EXPLICIT CertID, 268 cert [1] EXPLICIT Certificate } 270 CertID ::= SEQUENCE { 271 issuerNameAndKeyHash Hash, 272 serialNumber CertificateSerialNumber } 274 IssuerNameAndKey ::= SEQUENCE { 275 issuer Name, 276 issuerPublicKey SubjectPublicKeyInfo } 278 Hash ::= OCTET STRING --hash of IssuerNameAndKey-- 280 3.2 Response Syntax 282 This section specifies the ASN.1 specification for a confirmation 283 response. The actual formatting of the message could vary depending on 284 the transport mechanism used (http, smtp, ldap, etc.). 286 3.2.1 ASN.1 Specification of the OCSP Response 288 An OCSP response at a minimum consists of a responseStatus field 289 indicating the processing status of the prior request. If the value of 290 responseStatus is one of the error conditions, responseBytes are not 291 set. 293 OCSPResponse ::= SEQUENCE { 294 responseStatus OCSPResponseStatus, 295 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 297 OCSPResponseStatus ::= ENUMERATED { 298 successful (0), --Response has valid confirmations 299 malformedRequest (1), --Illegal confirmation request 300 internalError (2), --Internal error in issuer 301 tryLater (3), --Try again later 302 notFound (4), --Certificate not on record 303 certRequired (5) --Must supply certificate } 305 3.2.1.1 BasicResponse 307 The value for responseBytes consists of an OBJECT IDENTIFIER and a 308 response syntax identified by that OID encoded as an OCTET STRING: 310 ResponseBytes ::= SEQUENCE { 311 responseType OBJECT IDENTIFIER, 312 response OCTET STRING } 314 For a basic OCSP responder, responseType will be id-pkix-ocsp-basic, 315 where: 317 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 318 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 320 OCSP responders SHALL be capable of recognizing and responding to the 321 id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be 322 capable of receiving and processing the id-pkix-ocsp-basic response 323 type. 325 The value for response SHALL be the DER encoding of BasicOCSPResponse: 327 BasicOCSPResponse ::= SEQUENCE { 328 tbsResponseData ResponseData, 329 signatureAlgorithm AlgorithmIdentifier, 330 signature BIT STRING, 331 certs [1] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 333 The value for signature SHALL be computed on the hash of the DER 334 encoding ResponseData. 336 3.2.1.2 ResponseData 338 ResponseData ::= SEQUENCE { 339 version [0] EXPLICIT Version DEFAULT v1, 340 reponderID ResponderID, 341 responses SEQUENCE OF SingleResponse, 342 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 344 ResponderID ::= CHOICE { 345 byName [0] Name, 346 byKey [1] KeyHash } 348 KeyHash ::= KeyIdentifier �-SHA-1 hash as defined in PKIX Part.1 350 3.2.1.3 SingleResponse 352 [note: question put to the list regarding bandwidth issues associated 353 with sending certificates back; could just use certID directly since 354 requester already has certificates in question.] 356 SingleResponse ::= SEQUENCE { 357 request Request, 358 certStatus CertStatus, 359 producedAt GeneralizedTime, 360 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 361 singleExtensions [2] EXPLICIT Extensions OPTIONAL } 363 CertStatus ::= CHOICE { 364 certStatusType [0] EXPLICIT CertStatusType (notRevoked | onHold), 365 statusWithTime [1] EXPLICIT StatusWithTime } 367 StatusWithTime ::= SEQUENCE { 368 certStatusType CertStatusType (revoked), 369 time GeneralizedTime } 371 CertStatusType ::= ENUMERATED { 372 notRevoked (0), --This serial number is not revoked 373 revoked (1), --Serial number was revoked 374 onHold (2), --Cert is on hold 375 expired (3) -- certificate is expired } 377 Applications SHOULD determine by observation of the certificate�s 378 validity interval that a certificate is expired. The expired value of 379 CertStatusType defines a value to return when a request is received for 380 a subject certificate in this state. 382 3.2.2 Notes on OCSP Responses 384 If the certStatusType is revoked, onHold or expired, the time field of 385 StatusWithTime is the time of revocation, suspension or expiration 386 respectively. The date returned for expiration should match the 387 notAfter date of the certificate�s validity interval. 389 The thisUpdate and nextUpdate fields define a recommended validity 390 interval. This interval corresponds to the {thisUpdate, nextUpdate} 391 interval in CRLs. Responses whose nextUpdate value is earlier 392 than the local system time value SHOULD be considered unreliable. 393 Responses whose thusUpdate time is earlier than the local system time 394 SHOULD be considered unreliable. Responses where the nextUpdate value 395 is not set are equivalant to a CRL with no time for nextUpdate (see 396 section 2.3). 398 3.3 Mandatory and Optional Cryptographic Algorithms 400 Clients that request OCSP services SHALL be capable of processing 401 responses signed used DSA keys identified by the DSA sig-alg-oid 402 specified in section 7.2.2 of PKIX Part 1. Clients SHOULD also be 403 capable of processing RSA signatures as specified in section 7.2.1 of 404 PKIX Part 1. OCSP responders SHALL support the SHA1 hash algorithm. 406 3.4 Extensions 408 This section defines some standard extensions. Support for all 409 extensions is OPTIONAL. For each extension, the definition indicates 410 its syntax, processing performed by the OCSP Responder, and any 411 extensions which are included in the corresponding response. 413 3.4.1 Nonce 415 The nonce cryptographically binds a request and a response to prevent 416 replay attacks. The nonce is included as one of the requestExtensions 417 in requests, while in responses it would be included as one of the 418 responseExtensions. In both the request and the response, the nonce 419 will be identified by the object identifier id-pkix-ocsp-nonce, while 420 the extnValue is the value of the nonce. 422 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 424 3.4.2 Signed Requests 426 This extension allows the requester to sign a request. The requestor 427 includes an extension that has the signatureIdentifier, the actual bits 428 of the signature and a sequence of certificates to allow the OCSP 429 responder to verify the signature. The data to be signed is just the 430 basic request (none of the extensions). The OCSP Responder can verify 431 the signature, potentially using certificates that have been included 432 with the extension. The signature on a request will be identified by id- 433 pkix-ocsp-signature, while the value will be SignatureData, where: 435 id-pkix-ocsp-signature OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } 437 SignatureData ::= SEQUENCE { 438 signatureAlgorithm AlgorithmIdentifier, 439 signature BIT STRING, 440 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 442 3.4.3 CRL References 444 It may be desirable for the OCSP responder to indicate the CRL on which 445 a revoked or onHold certificate is found. This can be useful where OCSP 446 is used between repositories, and also as an auditing mechanism. The 447 CRL may be specified by a URL (the URL at which the CRL is available), 448 a number (CRL number) or a time (the time at which the relevant CRL 449 was created). These extensions will be specified as singleExtensions. 450 The identifier for this extension will be id-pkix-ocsp-crl, while the 451 value will be CrlID. 453 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 455 CrlID ::= SEQUENCE { 456 crlUrl [0] EXPLICIT IA5String OPTIONAL, 457 crlNum [1] EXPLICIT INTEGER OPTIONAL, 458 crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } 460 For the choice crlUrl, the IA5String will specify the URL at which the 461 CRL is available. For crlNum, the INTEGER will specify the value of the 462 CRL number extension of the relevant CRL. For crlTime, the 463 GeneralizedTime will indicate the time at which the relevant CRL was 464 issued. 466 Note: There is no requirement to list certificates on a CRL in order to 467 use OCSP to acquire revocation status on those certificates. Therefore 468 inclusion of this extension in a request may yield no CRL information. 469 The error value noCRL is defined for this instance. 471 3.4.4 Acceptable Response Types 473 An OCSP client MAY wish to specify the kinds of response types it 474 understands. To do so, it SHOULD use an extension with the OID 475 id-pkix-ocsp-response, and the value AcceptableResponses. The OIDs 476 included in AcceptableResponses are the OIDs of the various response 477 types this client can accept (e.g., id-pkix-ocsp-basic). 479 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 481 AcceptableResponses ::= SEQUENCE OF { id OBJECT IDENTIFIER } 483 As noted in section 3.3, OCSP responders SHALL be capable of recognizing 484 and responding to the id-pkix-ocsp-basic response type. Correspondingly, 485 OCSP clients SHALL be capable of receiving and processing the id-pkix- 486 ocsp-basic response type. 488 3.4.5 Other Extensions 490 CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are 491 also supported as singleExtensions. 493 4. Security Considerations 495 For this service to be effective, certificate using systems must connect 496 to the certificate status service provider. In the event such a 497 connection cannot be obtained, certificate-using systems could implement 498 CRL processing logic as a fall-back position. 500 A denial of service vulnerability is evident with respect to a flood of 501 queries constructed to produce error responses. The production of a 502 cryptographic signature significantly affects response generation cycle 503 time, thereby exacerbating the situation. 505 Unsigned error responses can be produced more rapidly and thus reduce 506 the danger of this attack. However, unsigned error responses open up the 507 protocol to another denial of service attack, where the attacker sends 508 false error responses. 510 The use of precomputed responses allows replay attacks in which an 511 old (notRevoked) response is replayed prior to its expiration date but 512 after the certificate has been revoked. Deployments of OCSP should 513 carefully evaluate the benefit of precomputed responses against the 514 probability of a replay attack and the costs associated its successful 515 execution. 517 5. References 519 [HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, 520 R. Fielding & H. Frystyk, RFC 1945, May 1996. 522 [ABNF] Augmented BNF for Syntax Specifications: ABNF. D. Crocker, 523 P. Overell, RFC 2234, November 1997. 525 [MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels, 526 S. Bradner, RFC 2119, March 1997. 528 [URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter, 529 M. McCahill, RFC 1738, December 1994. 531 7. Author�s Address 533 Michael Myers 534 VeriSign, Inc. 535 1390 Shorebird Way 536 Mountain View, CA 94019 537 mmyers@verisign.com 538 Rich Ankney 539 CertCo, LLC 540 13506 King Charles Dr. 541 Chantilly, VA 20151 542 rankney@erols.com 544 Ambarish Malpani 545 ValiCert, Inc. 546 3160 W. Bayshore Drive 547 Palo Alto, CA 94303 548 ambarish@valicert.com 550 Slava Galperin 551 Netscape Communications Corp. 552 MV-068 553 501 E. Middlefield Rd. 554 Mountain View, CA 94043 555 galperin@netscape.com 557 Carlisle Adams 558 Entrust Technologies 559 750 Heron Road, Suite E08 560 Ottawa, Ontario 561 K1V 1A7 562 Canada 563 cadams@entrust.com 565 Appendix A 567 A.1 OCSP over HTTP 569 This section describes the formatting that will be done to the request 570 and response to support HTTP. 572 A.1.1 Request 574 An OCSP request is an HTTP 1.0 POST method. The Content-Type header 575 has the value "application/ocsp-request" while the body of the message 576 is the DER encoding of the OCSPRequest. 578 A.1.2 Response 580 An HTTP-based OCSP response is composed of the appropriate HTTP headers, 581 followed by the DER encoding of the OCSPResponse. The Content-Type 582 header has the value "application/ocsp-response". The Content-Length 583 header SHOULD specify the length of the response. Other HTTP headers 584 MAY be present and MAY be ignored if not understood by the requestor. 586 Appendix B: OCSP in ASN.1 588 OCSPRequest ::= SEQUENCE { 589 version [0] EXPLICIT Version DEFAULT v1, 590 hashAlgorithm AlgorithmIdentifier, 591 requestList SEQUENCE OF Request, 592 requestExtensions [1] EXPLICIT Extensions OPTIONAL } 594 Version ::= INTEGER { v1(0) } 596 Request ::= CHOICE { 597 certID [0] EXPLICIT CertID, 598 cert [1] EXPLICIT Certificate } 600 CertID ::= SEQUENCE { 601 issuerNameAndKeyHash Hash, 602 serialNumber CertificateSerialNumber } 604 IssuerNameAndKey ::= SEQUENCE { 605 issuer Name, 606 issuerPublicKey SubjectPublicKeyInfo } 608 Hash ::= OCTET STRING --hash of IssuerNameAndKey-- 610 OCSPResponse ::= SEQUENCE { 611 responseStatus OCSPResponseStatus, 612 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } 614 OCSPResponseStatus ::= ENUMERATED { 615 successful (0), --Response has valid confirmations 616 malformedRequest (1), --Illegal confirmation request 617 internalError (2), --Internal error in issuer 618 tryLater (3), --Try again later 619 notFound (4), --Certificate not on record 620 certRequired (5) --Must supply certificate } 622 BasicOCSPResponse ::= SEQUENCE { 623 tbsResponseData ResponseData, 624 signatureAlgorithm AlgorithmIdentifier, 625 signature BIT STRING, 626 certs [1] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 628 ResponseData ::= SEQUENCE { 629 version [0] EXPLICIT Version DEFAULT v1, 630 reponderID ResponderID, 631 responses SEQUENCE OF SingleResponse, 632 responseExtensions [1] EXPLICIT Extensions OPTIONAL } 634 ResponderID ::= CHOICE { 635 byName [0] Name, 636 byKey [1] KeyHash } 638 KeyHash ::= KeyIdentifier �-SHA-1 hash as defined in PKIX Part.1 639 SingleResponse ::= SEQUENCE { 640 request Request, 641 certStatus CertStatus, 642 producedAt GeneralizedTime, 643 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 644 singleExtensions [2] EXPLICIT Extensions OPTIONAL } 646 CertStatus ::= CHOICE { 647 certStatusType [0] EXPLICIT CertStatusType (notRevoked | onHold), 648 statusWithTime [1] EXPLICIT StatusWithTime } 650 StatusWithTime ::= SEQUENCE { 651 certStatusType CertStatusType (revoked), 652 time GeneralizedTime } 654 CertStatusType ::= ENUMERATED { 655 notRevoked (0), --This serial number is not revoked 656 revoked (1), --Serial number was revoked 657 onHold (2), --Cert is on hold 658 expired (3) -- certificate is expired } 660 --Extensions 662 SignatureData ::= SEQUENCE { 663 signatureAlgorithm AlgorithmIdentifier, 664 signature BIT STRING, 665 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } 667 AcceptableResponses ::= SEQUENCE OF { id OBJECT IDENTIFIER } 669 CrlID ::= SEQUENCE { 670 crlUrl [0] EXPLICIT IA5String OPTIONAL, 671 crlNum [1] EXPLICIT INTEGER OPTIONAL, 672 crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } 674 -- Object Identifiers 676 id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } 677 id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } 678 id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 679 id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } 680 id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } 681 id-pkix-ocsp-signature OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }