idnits 2.17.1 draft-malpani-rcsp-00.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-04-19) 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. == 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 603 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 73 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 25 has weird spacing: '...ctories on f...' == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 466 -- Looks like a reference, but probably isn't: '1' on line 467 -- Looks like a reference, but probably isn't: '2' on line 468 == Unused Reference: 'HTTP' is defined on line 533, but no explicit reference was found in the text == Unused Reference: 'MUSTSHOULD' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'URL' is defined on line 539, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. 'HTTP') ** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC 4248, RFC 4266) Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group Ambarish Malpani(ValiCert) 2 draft-malpani-rcsp-00.txt Carlisle Adams (Entrust Technologies) 3 Expires in 6 months Rich Ankney (CertCo) 4 Slava Galperin (Netscape) 5 March, 1998 7 Internet Public Key Infrastructure 8 Real Time Certificate Status Protocol - RCSP 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups MAY also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and MAY be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 1. Abstract 31 The protocol conventions described in this document satisfy some of 32 the operational requirements of the Internet Public Key Infrastructure 33 (PKI). This document specifies a protocol useful in determining the 34 current status of a digital certificate without the use of CRLs. 35 Additional mechanisms addressing PKIX operational requirements are 36 specified in separate documents. 38 Section 2 provides an overview of the protocol. Section 3 goes through 39 the functional requirements, while section 4 provides the details of 40 the protocol. In section 5 we cover security issues with the 41 protocol. Appendix A demonstrates RCSP over HTTP. 43 Please send comments on this document to the ietf-pkix@tandem.com mail 44 list. 46 2. Protocol Overview 48 In lieu of or as a supplement to checking against a periodic CRL, it MAY 49 be necessary to obtain timely status regarding a certificate's 50 revocation status (cf. PKIX Part 1, Section 3.3). Examples include high- 51 value fund transfers or the compromise of a highly sensitive key. 53 The Real Time Certificate Status Protocol (RCSP) enables applications 54 to determine the revocation state of an identified certificate. RCSP 55 may be used to satisfy some of the operational requirements of 56 providing more timely revocation information than is possible with 57 CRLs. An RCSP client issues a status request to an RCSP responder and 58 suspends acceptance of the certificate in question until the responder 59 provides a response. 61 This protocol specifies the data that needs to be exchanged between an 62 application checking the revocation status of a certificate and the 63 server providing that status. 65 2.1 Request 67 An RCSP request contains the following data: 69 - protocol version 70 - service request 71 - target identifier for one or more certificates to be checked 72 - optional extensions which MAY be processed by the RCSP responder 74 Upon receipt of a request, an RCSP responder determines if: 1) the 75 message is well formed, 2) the responder is configured to provide the 76 requested service, and 3) the responder can perform the requested 77 service for the certificate in question. If any of the prior 78 conditions are not met, the RCSP responder produces an error message; 79 otherwise, it returns a definitive response. 81 2.2 Response 83 All definitive responses SHALL be digitally signed. The key used to 84 sign definitive responses need not be the same key used to sign the 85 certificate. The key used to sign the response MUST belong to one of 86 the following: 88 - a Trusted Responder, whose public key is already known to the 89 requestor 90 - the CA who issued the certificate in question 91 - an Authorized Responder, with a certificate which has a special 92 extension 93 authorizing it to sign RCSP responses 95 A definitive response message is composed of: 97 - response type identifier (to allow for different response types) 98 - version of the response 99 - name of the responder 100 - responses for each of the certificates in a request 101 - optional extensions 102 - signature algorithm OID 103 - signature computed across the hash of the response 105 The response for each of the certificates in a request consists of 107 - target certificate identifier 108 - certificate status value 109 - response validity interval 110 - optional extensions 112 This specification defines the following definitive response indicators 113 for use in the certificate status value: 115 - notRevoked 116 - revoked 117 - onHold 119 The notRevoked state indicates that the certificate is not revoked. It 120 does not necessarily mean that the certificate was ever issued. Nor 121 does it mean that the certificate is in its validity interval. A 122 notRevoked state by an RCSP responder DOES NOT absolve the application 123 of the responsibility of checking that the certificate is in its 124 validity period and has been correctly signed. 126 The revoked state indicates that the certificate has been revoked. 128 The onHold state corresponds to valid certificates that are 129 operationally suspended in accordance with PKIX Part 1. 131 In case of errors, the RCSP Responder may return an error message. 132 Errors 133 can be of the following types: 135 - malformedRequest 136 - requestorUnauthorized 137 - internalError 138 - tryLater 140 A server produces the malformedRequest response if the request received 141 does not conform to the RCSP syntax. 143 The response requestorUnauthorized is used in cases where the server 144 does not consider the client authorized to query it. Authorization 145 data is not explicitly a part of the request or this protocol. 146 However, certain responders may choose to require clients to ship an 147 authorization token with the request and may choose to refuse service 148 to clients that do not ship a correct authorization token. 150 The response internalError indicates that the RCSP responder reached 151 an inconsistent internal state. The query should be retried, potentially 152 with another responder. 154 The response tryLater is produced in any circumstance in which the 155 server has received a well formed RCSP request but is unable to process 156 it. 158 2.3 Response Pre-production 160 The response validity interval noted in the prior section is composed of 161 a {producedAt, nextUpdate} pair of elements in the response syntax. 162 Section 4.2 provides details of the response syntax. 164 RCSP responders MAY pre-produce signed responses specifying the 165 current status of certificates at the time the response was 166 produced. The time at which the response was known to be correct SHALL 167 be specified in the producedAt field of the response. This time is not 168 necessarily the same as the time at which the response was produced - 169 e.g. if the responder obtains a CRL from a CA and creates pre-produced 170 responses, the producedAt time should specify the thisUpdate time in 171 the CRL. 173 The producer of the response MAY include a value for nextUpdate. The 174 exact interval between producedAt and nextUpdate for a given response 175 is a matter of local security and operational policy. If the 176 nextUpdate field is not present, the response is known to be correct 177 at the producedAt time. No assertions are being made about the current 178 state of the certificate, nor are any recommendations being made as to 179 when the requestor should check again with the responder. If the 180 value of nextUpdate is set, it is just a hint, not a guarantee, of 181 when the responder expects to have new information about that 182 certificate's status. 184 If responses are pre-produced, then for a given certificate, the 185 periodicity of this pre-production SHOULD match the response validity 186 interval of the most recently produced response. 188 2.4 Delegation of the task of RCSP responses to an Authorized Responder 190 One or more CAs may decide to delegate the task of producing RCSP 191 response to a third party (an Authorized Responder). In that case, 192 each of those CAs should provide the Authorized Responder with a 193 certificate 194 that includes a special extension authorizing the holder to issue RCSP 195 responses. 197 3. Functional Requirements 199 3.1 Certificate Content 201 In order to convey to RCSP clients a well-known point of information 202 access, CAs SHALL provide the capability to include the 203 AuthorityInfoAccess extension (defined in PKIX Part 1, section 204 4.2.2.1) in certificates that can be checked using RCSP. 206 CAs that support an RCSP service, either hosted locally or provided by 207 an Authorized Responder, MAY provide a value for a 208 uniformResourceIndicator (URI) accessLocation and the OID value 209 id-ad-rcsp for the accessMethod in the AccessDescription SEQUENCE. 210 The value of the accessLocation field in the subject certificate 211 corresponds to the URL placed into an RCSP request. Alternatively, the 212 accessLocation for the RCSP provider may be configured locally at the 213 RCSP client (e.g., in cases where the RCSP provider is a trusted party 214 for the particular client, whose job is to aggregate revocation 215 information from all trusted CAs). 217 id-ad-rcsp OBJECT IDENTIFIER ::= {id-ad ?} 219 3.2 Error Responses 221 Upon receipt of a request which fails to parse, the receiving RCSP 222 responder SHALL respond with an error message. Error responses MAY be 223 signed. 225 3.3 Signed Response Acceptance Requirements 227 Prior to accepting a signed response as valid, RCSP clients SHALL 228 confirm that: 230 - The certificate identified in a received response corresponds to 231 that which was identified in the corresponding request. 232 - The signature on the response is valid. 233 - The identity of the signer matches the intended recipient of the 234 request. 235 - The signer is currently authorized to sign the response. 237 4. Detailed Protocol 239 The ASN.1 syntax imports terms defined in the X.509 Certificate and CRL 240 Profile Internet Draft. For signature calculation, the data to be signed 241 is 242 encoded using the ASN.1 distinguished encoding rules (DER) [X.690]. 244 ASN.1 EXPLICIT tagging is used as a default unless specified otherwise. 246 The terms imported from elsewhere are: 247 Version, Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, 248 Name, 249 AlgorithmIdentifier, GeneralizedTime 251 4.1 Request Syntax 253 RCSPRequest ::= SEQUENCE { 254 version [0] EXPLICIT Version DEFAULT v1, 255 hashAlgorithm AlgorithmIdentifier, 256 requestList SEQUENCE OF Request, 257 requestExtensions [1] EXPLICIT Extensions OPTIONAL 258 } 260 Request ::= CHOICE { 261 certID [0] EXPLICIT CertID, 262 cert [1] EXPLICIT Certificate 263 } 265 CertID ::= SEQUENCE { 266 issuerNameAndKeyHash Hash, 267 serialNumber CertificateSerialNumber, 268 } 270 IssuerNameAndKey ::= SEQUENCE { 271 issuer Name, 272 issuerPublicKey SubjectPublicKeyInfo 273 } 275 Hash ::= OCTET STRING --hash of IssuerNameAndKey-- 277 4.2 Notes on the RCSP Request Syntax 279 The issuerNameAndKeyHash is computed by hashing an IssuerNameAndKey 280 field constructed for the CA in question using a cryptographic hash 281 function (e.g., SHA-1) specified as the hashAlgorithm in the request. 282 The primary reason to use both the name and the public key to identify 283 the issuer is that it is possible that two CAs may choose to use the 284 same Name (uniqueness in the Name is a recommendation that cannot be 285 enforced). Two CAs will never, however, have the same public key 286 unless the CAs either explicitly decided to share their private key, 287 or the key of one of the CAs was compromised. 289 While it is possible to identify a certificate by sending over either 290 the entire certificate or just a CertID, it is recommended that 291 clients use just the CertID to reduce the size of both the request 292 and the response. However, certain RCSP responders MAY require the 293 entire certificate whose status is to be determined. 295 Support for extensions is OPTIONAL. The critical flag SHOULD NOT be 296 set for any of them. This standard suggests several useful extensions 297 in Section 4.5. Additional extensions MAY be defined in additional 298 RFCs. Unrecognized extensions SHOULD be ignored. 300 4.2 Response Syntax 302 This section specifies the ASN.1 specification for a confirmation 303 response. The actual formatting of the message could vary depending on 304 the transport mechanism used (http, smtp, ldap, etc.). 306 4.2.1 ASN.1 Specification of the RCSP Response 308 RCSPResponse ::= SEQUENCE { 309 responseStatus RCSPResponseStatus, 310 responseBytes [0] EXPLICIT ResponseBytes OPTIONAL 311 } 313 RCSPResponseStatus ::= ENUMERATED { 314 successful ( 0 ), --Response has valid confirmations-- 315 malformedRequest ( 1 ), --Illegal confirmation request-- 316 requestorUnauthorized ( 2 ), --User not authorized to use issuer-- 317 internalError ( 3 ), --Internal error in issuer-- 318 tryLater ( 4 ) --Try again later-- 319 } 321 ResponseBytes ::= SEQUENCE { 322 responseType OBJECT IDENTIFIER, 323 response OCTET STRING 324 } 326 If the responseStatus is one of the error conditions, responseBytes 327 are not set. 329 For a basic RCSP responder, responseType will be id-pkix-rcsp-basic, 330 where: 331 id-pkix-rcsp OBJECT IDENTIFIER ::= { id-pkix ? } 332 id-pkix-rcsp-basic OBJECT IDENTIFIER ::= { id-pkix-rcsp ? } 334 The response will be the DER encoding of BasicRCSPResponse 336 BasicRCSPResponse ::= SEQUENCE { 337 tbsResponseData ResponseData, 338 signatureAlgorithm AlgorithmIdentifier, 339 signature BIT STRING, 340 certs [1] EXPLICIT SEQUENCE OF Certificate 341 OPTIONAL 342 } 344 ResponseData ::= SEQUENCE { 345 version [0] EXPLICIT Version DEFAULT v1, 346 responderName Name, 347 responses SEQUENCE OF SingleResponse, 348 responseExtensions [1] EXPLICIT Extensions OPTIONAL 349 } 351 SingleResponse ::= SEQUENCE { 352 request Request, 353 certStatus CertStatus, 354 producedAt GeneralizedTime, 355 nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, 356 singleExtensions [2] EXPLICIT Extensions OPTIONAL 357 } 359 CertStatus ::= CHOICE { 360 certStatusType [0] EXPLICIT CertStatusType 361 (notRevoked | onHold), 362 statusWithTime [1] EXPLICIT StatusWithTime 363 } 365 StatusWithTime ::= SEQUENCE { 366 certStatusType CertStatusType (revoked), 367 time GeneralizedTime 368 } 370 CertStatusType ::= ENUMERATED { 371 notRevoked (0), --This serial number is not revoked-- 372 revoked (1), --Serial number was revoked-- 373 onHold (2) --Cert is on hold-- 374 } 376 4.2.2 Notes on RCSP Responses 378 If the certStatusType is revoked, time is the time of revocation of 379 the certificate. 381 The producedAt and nextUpdate fields define a recommended validity 382 interval. This interval corresponds to the {thisUpdate, nextUpdate} 383 interval in CRLs. Responses whose nextUpdate value is earlier 384 than the local system time value SHOULD be considered unreliable. 385 Responses whose producedAt time is earlier than the local system time 386 SHOULD be considered unreliable. Responses where the nextUpdate value 387 is not set are equivalant to a CRL with no time for nextUpdate (see 388 section 2.3). 390 The signature should be computed on the hash of the DER encoding of 391 the ResponseData. 393 4.3 Authorized Responders 395 One or more CAs may designate an Authorized RCSP Responder, by issuing 396 a special certificate. The Authorized Responder will have the right to 397 issue RCSP responses on behalf of that CA as long as that certificate 398 does not expire. The certificates for Authorized Responders SHALL 399 contain a non-critical extension, proving the authorization. The 400 extension identifier will be id-kp-rcsp, while the value will be the 401 DER encoding of the integer 1. The certificate of an Authorized RCSP 402 Responder cannot be revoked. It is recommended that the life of this 403 certificate be kept short and every effort be made to protect its 404 private key atleast as carefully as that of the CA. 406 id-kp-rcsp OBJECT IDENTIFIER ::= {id-kp ?} 408 4.4 Mandatory and Optional Cryptographic Algorithms 410 Clients that request RCSP services SHALL be capable of processing 411 responses signed used DSA keys identified by the DSA sig-alg-oid 412 specified in section 7.2.2 of PKIX Part 1. Clients SHOULD also be 413 capable of processing RSA signatures as specified in section 7.2.1 of 414 PKIX Part 1. RCSP responders SHALL support the SHA1 hash algorithm. 416 4.5 Extensions 418 This section defines the way to support some commonly requested 419 tasks. Support for all extensions is OPTIONAL, so critical 420 SHOULD NOT be set for any of these extensions. 422 4.5.1 Nonce 424 The nonce cryptographically binds a request and a response to prevent 425 replay attacks. The nonce is included as one of the requestExtensions 426 in requests, while in responses it would be included as one of the 427 responseExtensions. In both the request and the response, the nonce 428 will be identified by the object identifier id-pkix-rcsp-nonce, while 429 the extnValue is the value of the nonce. 431 id-pkix-rcsp-nonce OBJECT IDENTIFIER ::= { id-pkix-rcsp ? } 433 4.5.2 Signed Requests 435 This extension allows the requestor to sign a request. The 436 requestor includes an extension that has the signatureIdentifier, the 437 actual bits of the signature and a sequence of certificates to allow 438 the RCSP responder to verify the signature. The data to be 439 signed is just the basic request (none of the extensions). The RCSP 440 Responder can verify the signature, potentially using certificates 441 that have been included with the extension. The signature on a request 442 will be identified by id-pkix-rcsp-signature, while the value will 443 be SignatureData, where: 445 id-pkix-rcsp-signature OBJECT IDENTIFIER ::= { id-pkix-rcsp ? } 446 SignatureData ::= SEQUENCE { 447 signatureAlgorithm AlgorithmIdentifier, 448 signature BIT STRING, 449 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL 450 } 452 4.5.3 CRL References 454 It MAY be desirable for the RCSP responder to indicate the CRL on which 455 a revoked or onHold certificate is found. This can be useful where RCSP 456 is used between repositories, and also as an auditing mechanism. The 457 CRL may be specified by a URL (the URL at which the CRL is available), 458 a number (CRL number) or a time (the time at which the relevant CRL 459 was created). These extensions will be specified as singleExtensions. 460 The identifier for this extension will be id-pkix-rcsp-crl, while the 461 value 462 will be CrlID. 464 id-pkix-rcsp-crl OBJECT IDENTIFIER ::= { id-pkix-rcsp ? } 465 CrlID ::= SEQUENCE { 466 crlUrl [0] EXPLICIT IA5String OPTIONAL, 467 crlNum [1] EXPLICIT INTEGER OPTIONAL, 468 crlTime [2] EXPLICIT GeneralizedTime OPTIONAL 469 } 471 For the choice crlUrl, the IA5String will specify the URL at which the 472 CRL is available. For crlNum, the INTEGER will specify the value of the 473 CRL 474 number extension of the relevant CRL. For crlTime, the GeneralizedTime 475 will indicate the time at which the relevant CRL was issued. 477 4.5.4 Acceptable Response Types 479 An RCSP client MAY wish to specify the kinds of response types it 480 understands. To do so, it SHOULD use an extension with the OID 481 id-pkix-rcsp-response, and the value AcceptableResponses. The id's 482 included in AcceptableResponses are the OIDs of the various response 483 types this client can accept (e.g., id-pkix-rcsp-basic). 485 id-pkix-rcsp-response OBJECT IDENTIFIER ::= {id-pkix-rcsp ?} 486 AcceptableResponses ::= SEQUENCE OF { 487 id OBJECT IDENTIFIER 488 } 490 4.5.4 Other Extensions 492 CRL Entry Extensions - specified in Section 5.3 of PKIX part I - are 493 also 494 supported as singleExtensions. 496 5. Security Considerations 498 For this service to be effective, systems using certificates must 499 connect to the certificate status service provider. In the event such 500 a connection cannot be obtained, these systems could implement CRL 501 processing logic as a fall-back position. 503 If a CA authorizes another public key to sign RCSP responses, 504 compromise of that key is as serious as the compromise of the CA's key 505 as long as the authorization is valid. An authorized RCSP responder's 506 key cannot be revoked. 508 A denial of service vulnerability is evident with respect to a flood 509 of queries constructed to produce error responses. The production of a 510 cryptographic signature significantly affects response generation 511 cycle time, thereby exacerbating the situation. Unsigned error 512 responses can be produced more rapidly and thus reduce the danger of 513 this 514 attack. However, unsigned error responses open up the protocol to 515 another denial of service attack, where the attacker sends false error 516 responses. 518 The use of precomputed responses allows replay attacks in which an old 519 (notRevoked) response is replayed prior to its expiration but after 520 the certificate has been revoked. To reduce this vulnerability, it is 521 recommended that the period between producedAt and nextUpdate be 522 kept as small as possible. 524 6. Acknowledgements 526 This protocol uses many ideas from the Online Certificate Status 527 Protocol (OCSP), developed by Mike Meyers (VeriSign) and Rich Ankney 528 (CertCo). We have also used comments from Marc Branchaud (XCert), 529 Robert Zuccherato (Entrust) and Anil Gangolli (Structured Arts). 531 7. References 533 [HTTP] Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, 534 R. Fielding & H. Frystyk, RFC 1945, May 1996. 536 [MUSTSHOULD] Key words for use in RFCs to Indicate Requirement Levels, 537 S. Bradner, RFC 2119, March 1997. 539 [URL] Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter, 540 M. McCahill, RFC 1738, December 1994. 542 8. Author's Address 544 Ambarish Malpani 545 ValiCert, Inc. 546 3160 W. Bayshore Drive 547 Palo Alto, CA 94303 548 ambarish@valicert.com 550 Carlisle Adams 551 Entrust Technologies 552 750 Heron Road, Suite E08 553 Ottawa, Ontario 554 K1V 1A7 555 Canada 556 cadams@entrust.com 558 Rich Ankney 559 CertCo, LLC 560 13506 King Charles Dr. 561 Chantilly, VA 20151 562 rankney@erols.com 564 Slava Galperin 565 Netscape Communications Corp. 566 MV-068 567 501 E. Middlefield Rd. 568 Mountain View, CA 94043 569 galperin@netscape.com 571 Appendix A 573 A.1 RCSP over HTTP 575 This section describes the formatting that will be done to the request 576 and 577 response to support HTTP. 579 A.1.1 Request 581 An RCSP request is an HTTP 1.0 POST method. The Content-Type header 582 has the value "application/rcsp-request" while the body of the message 583 is the DER encoding of the RCSPRequest. 585 A.1.2 Response 587 An HTTP-based RCSP response is composed of the appropriate HTTP headers, 588 followed by the DER encoding of the RCSPResponse. The Content-Type 589 header has the value "application/rcsp-response". The Content-Length 590 header SHOULD specify the length of the response. Other HTTP headers 591 MAY be present and MAY be ignored if not understood by the requestor. 593 Expires September, 1998