idnits 2.17.00 (12 Aug 2021) /tmp/idnits6100/draft-ietf-pkix-dpv-dpd-req-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 6) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 147: '...n the DPV server MUST return an error....' RFC 2119 keyword, line 150: '...response MUST indicate the one that wa...' RFC 2119 keyword, line 154: '...s). The protocol MUST allow the client...' RFC 2119 keyword, line 160: '... the current time. The DPV server MUST...' RFC 2119 keyword, line 169: '...n the DPV server MUST return a status ...' (46 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (April 2002) is 7340 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 66, but not defined == Unused Reference: 'CMS' is defined on line 573, but no explicit reference was found in the text == Unused Reference: 'ISO-X509' is defined on line 583, but no explicit reference was found in the text Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Denis Pinkas, Bull 2 draft-ietf-pkix-dpv-dpd-req-04.txt Russ Housley, RSA Laboratories 3 Target Category: INFORMATIONAL April 2002 4 Expires in six months 6 Delegated Path Validation and Delegated Path Discovery 7 Protocol Requirements (DPV&DPD-REQ) 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document specifies the requirements for Delegated Path Validation 33 (DPV) and Delegated Path Discovery (DPD) for Public Key Certificates. 34 It also specifies the requirements for DPV and DPD policy management. 36 1. Introduction 38 This document specifies the requirements for Delegated Path Validation 39 (DPV) and Delegated Path Discovery (DPD) for Public Key Certificates, 40 using two main request/response pairs. 42 Delegated processing provides two primary services: DPV and DPD. 43 Some clients require a server to perform certification path validation 44 and have no need for data acquisition, while some other clients 45 require only path discovery in support of local path validation. 47 The DPV request/response pair, can be used to fully delegate path 48 validation processing to an DPV server, according to a set of rules, 49 called a validation policy. 51 The DPD request/response pair can be used to obtain from a DPD server 52 all the information needed (e.g., the end-entity certificate, the CA 53 certificates, full CRLs, delta-CRLs, OCSP responses) to locally 54 validate a certificate. The DPD server uses a set of rules, called 55 a path discovery policy, to determine which information to return. 57 A third request/response pair allows clients to obtain references for 58 the policies supported by a DPV or DPD server. 60 1.1. Terminology 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 64 this document (in uppercase, as shown) are to be interpreted as 65 described in [RFC2119]. 67 2. Rationale and benefits for DPV (Delegated Path Validation) 69 DPV allows a server to perform a real time certificate validation for 70 a validation time T, where T may be the current time or a time in the 71 recent past. 73 In order to validate a certificate, a chain of multiple certificates, 74 called a certification path, may be needed, comprising a certificate 75 of the public key owner (the end entity) signed by one CA, and zero or 76 more additional certificates of CAs signed by other CAs. 78 Offloading path validation to a server may be required by a client 79 that lacks the processing, and/or communication capabilities to 80 perform path construction and then local path validation. 82 In constrained execution environments, such as telephones and PDAs, 83 memory and processing limitations may preclude local implementation of 84 complete, PKIX-compliant certification path validation [PKIX-1]. 86 In applications where minimum latency is critical, delegating 87 validation to a trusted server can offer significant advantages. 88 The time required to send the target certificate to the validation 89 server, receive the response, and authenticate the response, 90 can be considerably less than the time required for the client to 91 perform certification path discovery and validation. Even if a 92 certification path were readily available to the client, the 93 processing time associated with signature verification for each 94 certificate in the path might (especially when validating very long 95 paths or using a limited processor) be greater than the delay 96 associated with use of a validation server. 98 Another motivation for offloading path validation is that it allows 99 validation against validation policies defined by the management in a 100 consistent fashion across an enterprise. Clients that are able to 101 do their own path validation may rely on a trusted server to do path 102 validation if centralized management of validation policies is needed, 103 or the clients rely on a trusted server to maintain centralized records 104 of such activities. 106 When a client uses this service, it inherently trusts the server as 107 much as it would its own path validation software (if it contained 108 such software). Clients can direct the server to perform path 109 validation in accordance with a particular validation policy. 111 3. Rationale and benefits for DPD (Delegated Path Discovery) 113 DPD is valuable for clients that do much of the PKI processing 114 themselves and simply want a server to collect information for them. 115 The server is trusted to return the most current information that is 116 available to it (which may not be the most current information that 117 has been issued). The client will ultimately perform certification 118 path validation. 120 A client that performs path validation for itself may get benefit in 121 several ways from using a server to acquire certificates, CRLs, and 122 OCSP responses to aid in the validation process. In this context, the 123 client is relying on the server to interact with repositories to 124 acquire the data that the client would otherwise have to acquire using 125 LDAP [LDAP], HTTP [HTTP], FTP [FTP] or another repository access 126 protocol. Since these data items are digitally signed, the client need 127 not trust the server any more than the client would trust the 128 repositories. 130 There are several benefits to this approach; for example, a single 131 query to a server can replace multiple repository queries, and caching 132 by the server can reduce latency. Another benefit to the client system 133 is that it need not incorporate a diverse set of software to interact 134 with various forms of repositories, perhaps via different protocols, 135 nor to perform the graph processing necessary to discover certification 136 paths, separate from making the queries to acquire path validation data. 138 4. Delegated Path Validation Protocol Requirements 140 4.1. Basic protocol 142 The Delegated Path Validation (DPV) protocol allows a server to 143 validate one or more public key certificates according to a validation 144 policy. 146 If the DPV server does not support the client requested validation 147 policy, then the DPV server MUST return an error. 149 If the DPV request does not specify a validation policy, the server 150 response MUST indicate the one that was used. 152 Policy definitions can be quite long and complex, and some policies 153 may allow for the setting of a few parameters (e.g. root self-signed 154 certificates). The protocol MUST allow the client to include these 155 policy dependant parameters in the DPV request. It is expected that 156 most clients will simply reference a validation policy for a given 157 application or accept the DPV serverĘs default validation policy. 159 The client can request that the server determine the certificate 160 validity at a time other than the current time. The DPV server MUST 161 obtain revocation status information for the validation time 162 in the client request. 164 In order to obtain the revocation status information of any 165 certificate from the certification path, the DPV server might use, in 166 accordance with the validation policy, different sources of revocation 167 information, e.g. a combination of OCSP responses, CRLs, or delta-CRLs. 168 If the revocation status information for the requested validation time 169 is unavailable, then the DPV server MUST return a status indicating 170 that the certificate is invalid. 172 The certificate to be validated MUST either be directly provided in 173 the request or unambiguously referenced, such as the CA distinguished 174 name, certificate serial number, and the hash of the certificate, 175 like ESSCertID as defined in [ESS] or OtherSigningCertificate as 176 defined in [ES-F]. 178 The DPV client MUST be able to provide to the validation server, 179 associated with each certificate to be validated, "useful 180 certificates", as well as "useful revocation information". Revocation 181 information includes OCSP responses, CRLs, and delta-CRLs. As an 182 example, an S/MIME message might include such information, and the 183 client can simply copy that information into the DPV request. 185 The DPV server MUST have the full certificate to be validated. When 186 the certificate is not provided in the request, the server MUST verify 187 that the certificate is indeed the one being unambiguous referenced by 188 the client. The DPV server MUST include either the full certificate or 189 an unambiguous reference to the certificate (in case of a CA key 190 compromise) in the DPV response. 192 Unless an error is reported, the DPV response MUST indicate one of the 193 following two status alternatives: 195 1) the certificate is valid according to the validation policy. 197 2) the certificate is not valid according to the validation policy. 199 3) the validity of the certificate is unknown according to the 200 validation policy. 202 When the certificate is not valid according to the validation policy, 203 then the reason MUST also be indicated. Invalidity reasons include: 205 a) the DPV server cannot determine the validity of the certificate 206 because a certification path cannot be constructed. 208 b) the DPV server successfully constructed a certification path, but 209 it was not valid according to the validation algorithm in 210 [PKIX-1]. 212 c) the certificate is not yet valid at this time. If another 213 request could be made later on, the certificate could possibly 214 be determined as valid. This condition may occur before a 215 certificate validity period has begun or while a certificate is 216 suspended. 218 The protocol MUST prevent replay attacks, and the replay prevention 219 mechanism employed by the protocol MUST NOT rely on clocks being 220 synchronized with UTC. 222 The DPV request MUST allow the client to request the server to include 223 in its response additional information which will allow relying parties 224 not trusting the requested DPV server to be confident that the 225 certificate validation has correctly been performed. Such information 226 may (not necessarily exclusively) consist of a certification path, 227 revocation status information from authorised CRL issuers or 228 authorised OCSP responders, revocation status information from CRL 229 issuers or OCSP responders trusted under the validation policy, 230 time-stamp tokens from TSAs responders trusted under the validation 231 policy, or a DPV response from a DPV server that is trusted under the 232 validation policy. When the certificate is valid according to the 233 validation policy, the server MUST, upon request, include that 234 information in the response. However, the server MAY omit that 235 information when the certificate is invalid or when it cannot 236 determine the validity. 238 The DPV response MUST be bound to the DPV request. This can be 239 accomplished by repeating the important components from the request in 240 the response or by including a one-way hash of the request in the 241 response. 243 For the client to be confident that the certificate validation was 244 handled by the expected DPV server, the DPV response MUST be 245 authenticated, unless an error is reported (e.g. a badly formatted 246 request, etc.). 248 For the client to be able prove to a third party that trusts the 249 same DPV server that the certificate validation was handled correctly, 250 the DPV response MUST be digitally signed, unless an error is reported 251 (e.g. a badly formatted request, etc.). The certificate from the DPV 252 server SHALL be used to identify the DPV server. 254 The DPV server MAY require client authentication, therefore, the DPV 255 request MUST be able to be authenticated. 257 There are no specific confidentiality requirement within this 258 application layer protocol. However, when confidentiality is needed, 259 it can be achieved with a lower-layer security protocol. 261 4.2. Relaying, re-direction and multicasting. 263 In some network environments, especially ones that include firewalls, 264 a DPV server might not be able to obtain all of the information that 265 it needs to process a request. However, the DPV server might be 266 configured to use the services of one or more other DPV servers to 267 fulfill all requests. In such cases, the client is unaware that the 268 queried DPV server is using the services of other DPV servers. In such 269 environments, the client-queried DPV server acts as a DPV client to 270 another DPV server. Unlike the original client, the DPV server is 271 expected to have moderate computing and memory resources, enabling the 272 use of relay, re-direct or multicasting mechanisms. The requirements 273 in this section support such mechanisms for DPV server-to-DPV server 274 exchanges without imposing them on DPV client-to-DPV client exchanges. 276 Protocols designed to satisfy these requirements MAY include optional 277 fields and/or extensions to support relaying, re-direction or 278 multicasting. However, DPV clients are not expected to support relay, 279 re-direct or multicast. If the protocol supports such features, the 280 protocol MUST include provisions for DPV clients and DPV servers that 281 do not support such features, allowing them to conform to the basic 282 set of requirements. 284 1. When a server supports a relay mechanism, a mechanism to detect 285 loops or repetition MUST be provided. 287 2. When a protocol provides the capability for a DPV server to 288 re-direct a request to another DPV server (i.e. the protocol 289 chooses to provide a referral mechanism), a mechanism to provide 290 information to be used for the re-direction SHOULD be supported. 291 If such re-direction information is sent back to clients, then 292 the protocol MUST allow conforming clients to ignore it. 294 3. Optional parameters in the protocol request and/or response MAY 295 be provide support for relaying, re-direction or multicasting. 296 DPV clients that ignore any such optional parameters MUST still 297 be able to use the DPV service. DPV servers that ignore any such 298 optional parameters MUST still be able to offer the DPV service, 299 although they might not be able to overcome the limitations 300 imposed by the network topology. In this way, protocol 301 implementors need not understand the syntax or semantics of any 302 such optional parameters. 304 5. Delegated Path Discovery Protocol Requirements 306 The Delegated Path Discovery (DPD) protocol allows the client to use 307 a single request to collect at one time from a single server the data 308 elements available at the current time that might be collected using 309 different protocols (e.g. LDAP, HTTP, FTP, OCSP) or by querying 310 multiple servers, to locally validate a public key certificate 311 according to a single path discovery policy. The returned information 313 can be used to locally validate one or more certificates for the 314 current time. 316 Clients MUST be able to specify whether they want, in addition to the 317 certification path, the revocation information associated with the 318 path, for the end-entity certificate, for the CA certificates, or for 319 both. 321 If the DPD server does not support the client requested path 322 discovery policy, the DPD server MUST return an error. Some forms 323 of path discovery policy can be simple. In that case it is acceptable 324 to pass the parameters from the path discovery policy with each 325 individual request. For example, the client might provide a set of 326 trust anchors and separate revocation status conditions for the 327 end-entity certificate and for the other certificates. The DPD request 328 MUST allow more elaborated path discovery policies to be referenced. 330 It is expected that most of the time clients will only be aware of 331 the referenced path discovery policy for a given application. 333 The DPD server response includes zero, one, or several certification 334 paths. Each path consists of a sequence of certificates, starting with 335 the certificate to be validated and ending with a trust anchor. If the 336 trust anchor is a self-signed certificate, that self-signed certificate 337 is not included. In addition, if requested, the revocation information 338 associated with each certificate in the path MUST also be returned. 340 The DPD client needs to be able to limit the number of paths returned. 341 Therefore the client MUST be able to indicate the maximum number of 342 certification paths to be returned (provided that they can be found). 343 If the client does not specify a maximum number, then the DPD server 344 MUST return a single certification path. 346 The paths that are returned may need to match some additional local 347 criteria known only to the client. For example, the client might 348 require the presence of a particular certificate extension. 350 If that number cannot be reached by the server, an indication SHOULD 351 be returned by the DPD server showing that an additional query will not 352 return more paths. 354 If the paths that are returned do not match the clientĘs local 355 criteria, then the number of number of certification paths to be 356 returned can be extended by increasing this value. Previously found 357 paths will likely be returned, but the client can easily discard them. 358 This avoids requirements for state information at the server, but does 359 not prevent a server from maintaining a cache of previous responses. 361 Avoiding the maintenance of state information for previous requests 362 minimizes potential denial of service attacks or other problems 363 associated with server crashes. 365 Path discovery MUST be performed according to the path discovery policy. 366 The DPD response MUST indicate one of four status alternatives: 368 1) one or more certification paths was found according to the 369 path discovery policy, with all of the requested revocation 370 information present. 372 2) one or more certification paths was found according to the 373 path discovery policy, with a subset of the requested revocation 374 information present. 376 3) one or more certification paths was found according to the 377 path discovery policy, with none of the requested revocation 378 information present. 380 4) no certification path was found according to the path 381 discovery policy. 383 The information that is returned consists of one or more certification 384 paths and, if requested, its associated revocation status information 385 for each element from the path. 387 For the client to be confident that the response originates from the 388 expected DPD server, the server MAY provide an authenticated response. 389 For example, the server might sign the response. 391 The DPD server MAY require client authentication, therefore, the DPD 392 request MUST be able to be authenticated. 394 There are no specific confidentiality requirement within the 395 application layer protocol. However, when confidentiality is needed, 396 it can be achieved with a lower-layer security protocol. 398 6. Requirements common both to DPV and DPD 400 The client MUST be able to obtain references for the default policy 401 or for all of the policies supported by the server by using an 402 additional request/response pair. The response can include references 403 to previously defined policies or to a priori known policies. 405 7. Validation Policy 407 A validation policy is a set of rules against which the validation of 408 the certificate is performed. 410 A validation policy MAY include several trust anchors. A trust anchor 411 is defined as one public key, a CA name, and a validity time interval; 412 a trust anchor optionally includes additional constraints. The use of a 413 self-signed certificate is one way to specify the public key to be 414 used, the CA name, and the validity period of the public key. 416 Additional constraints for each trust anchor MAY be defined. These 417 constraints might include a set of certification policy constraints or 418 a set of naming constraints. These constraints MAY also be included in 419 self-signed certificates. 421 Additional conditions that apply to the certificates in the path MAY 422 also be specified in the validation policy. For example, specific 423 values could be provided for the inputs to the certification path 424 validation algorithm in [PKIX-1], such as user-initial-policy-set, 425 initial-policy-mapping-inhibit, initial-explicit-policy, or 426 initial-any-policy-inhibit. 428 Additional conditions that apply to the end-entity certificate MAY 429 also be specified in the validation policy. For example, a specific 430 name form, like an e-mail address either in the rfc822 subject 431 alternative name or in the emailAddress naming attribute in the 432 subject name, might be required. 434 In order to succeed, one valid certification path (none of the 435 certificates in the path are expired or revoked) MUST be found between 436 an end-entity certificate and a trust anchor and all constraints that 437 apply to the certification path MUST be verified. 439 7.1. Components for a validation policy 441 A validation policy is built from three components: 443 1. Certification path requirements, 444 2. Revocation requirements, 445 3. End-entity certificate specific requirements. 447 Note: [ES-P] defines ASN.1 data elements that may be useful while 448 defining the components of a validation policy. 450 7.2. Certificate path requirements 452 The path requirements identify a sequence of trust anchors used to 453 start certification path processing and initial conditions for 454 certification path validation as defined in [PKIX-1]. 456 7.3. Revocation Requirements 458 Revocation information might be obtained through CRLs, delta-CRLs or 459 OCSP responses. Certificate revocation requirements are specified in 460 terms of checks required on the end-entity certificate and CA 461 certificates. 463 Revocation requirements for the end-entity certificate may not be the 464 same as the requirements for the CA certificates. For example, an OCSP 465 response may be needed for the end-entity certificate while CRLs may 466 be sufficient for the CA certificates. 468 The validation policy MUST specify the source of revocation 469 information: 471 - full CRLs (or full Authority Revocation Lists) have to be 472 collected, 474 - OCSP responses, using [OCSP], have to be collected, 476 - delta-CRLs and the relevant associated full CRLs (or full 477 Authority Revocation Lists) are to be collected. 479 - any available revocation information has to be collected. 481 - no revocation information has to be collected. 483 7.4. End-entity certificate specific requirements 485 The validation policy might require the end-entity certificate to contain 486 specific extensions with specific types or values (it does not matter 487 whether they are critical or non-critical). For example, the 488 validation policy might require an end-entity certificate that 489 contains an electronic mail address (either in the rfc822 subject alt 490 name or in the emailAddress naming attribute in the subject name). 492 8. Path Discovery Policy 494 A path discovery policy is a set of rules against which the discovery 495 of a certification path is performed. A path discovery policy is a 496 subset of a validation policy. A path discovery policy MAY either be 497 a reference to a validation policy or contain only some major elements 498 from a validation policy, such as the trust anchors. 500 Since the DPD client is "PKI aware", it can locally apply additional 501 selection criteria to the certification paths returned by the server. 502 Thus, a simpler policy can be defined and used for path discovery. 504 8.1. Components for a Path Discovery Policy 506 The path discovery policy includes certification path requirements, 507 revocation requirements, and end-entity certificate specific 508 requirements. These requirements are specified in sections 7.2, 7.3, 509 and 7.4, respectively. 511 9. Security considerations 513 A DPV client must trust a DPV server to provide the correct answer. 514 However, this does not mean that all DPV clients will trust the same 515 DPV servers. While a positive answer might be sufficient for one DPV 516 client, that same positive answer will not necessarily convince 517 another DPV client. 519 Other clients may trust their own DPV servers, or they might perform 520 certification path validation themselves. DPV clients operating under 521 an organizational policy must ensure that each of the DPV servers they 522 trust is operating under that organizational policy. 524 When no policy reference is present in the DPV request, the DPV client 525 should verify that the policy selected by the DPV server is appropriate. 527 The revocation status information is obtained for the validation time. 528 In case of a digital signature, it is not necessarily identical to the 529 time when the private key was used. The validation time should be 530 adjusted by the DPV client to compensate for: 532 1) time for the end-entity to realize that its private key has 533 been or could possibly be compromised, and/or 535 2) time for the end-entity to report the key compromise, and/or 537 3) time for the revocation authority to process the revocation 538 request from the end-entity, and/or 540 4) time for the revocation authority to update and distribute the 541 revocation status information. 543 10. Acknowledgments 545 These requirements have been refined after some valuable inputs from 546 Ambarish Malpani, Tim Polk, and Paul Hoffman. 548 11. References 550 [PKIX-1] 552 Internet X.509 Public Key Infrastructure. 553 Certificate and CRL Profile. RFC 2459 554 R. Housley, W. Ford, W. Polk, D. Solo. 555 or its successor as soon as it can be referenced. 557 [OCSP] 559 X.509 Internet Public Key Infrastructure. 560 Online Certificate Status Protocol - OCSP. RFC 2560 561 M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. 563 [ES-F] 565 Electronic Signature Formats for long term electronic signatures 566 RFC 3126. D. Pinkas, J. Ross, N. Pope. September 2001. 568 [ES-P] 570 Electronic Signature Policies. RFC 3125. 571 D. Pinkas, J. Ross, N. Pope. September 2001. 573 [CMS] 575 Cryptographic Message Syntax. RFC 2630. R. Housley June 1999. 576 or its successor as soon as it can be referenced. 578 [ESS] 580 Enhanced Security Services for S/MIME. RFC 2634. P. Hoffman. 581 RFC 2634, June 1999. 583 [ISO-X509] 585 ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information 586 Technology - Open Systems Interconnection: The Directory: 587 Authentication Framework," 1997 edition. 589 [FTP] 591 Internet X.509 Public Key Infrastructure. Operational Protocols: 592 FTP and HTTP. RFC 2585. R. Housley, P. Hoffman. May 1999. 594 [HTTP] 596 Internet X.509 Public Key Infrastructure. Operational Protocols: 597 FTP and HTTP. RFC 2585. R. Housley, P. Hoffman. May 1999. 599 [LDAP] 601 Internet X.509 Public Key Infrastructure Operational Protocols 602 LDAPv2. RFC 2559. S. Boeyen, T. Howes, P. Richard. April 1999. 604 12. Authors' addresses 606 Denis Pinkas 607 Bull. 608 68, Route de Versailles 609 78434 Louveciennes CEDEX 610 FRANCE 611 Denis.Pinkas@bull.net 613 Russell Housley 614 RSA Laboratories 615 918 Spring Knoll Drive 616 Herndon, VA 20170 617 USA 618 rhousley@rsasecurity.com 620 Full Copyright Statement 622 Copyright (C) The Internet Society (2002). All Rights Reserved. 624 This document and translations of it may be copied and furnished to 625 others, and derivative works that comment on or otherwise explain it 626 or assist in its implementation may be prepared, copied, published 627 and distributed, in whole or in part, without restriction of any 628 kind, provided that the above copyright notice and this paragraph 629 are included on all such copies and derivative works. However, this 630 document itself may not be modified in any way, such as by removing 631 the copyright notice or references to the Internet Society or other 632 Internet organizations, except as needed for the purpose of 633 developing Internet standards in which case the procedures for 634 copyrights defined in the Internet Standards process must be 635 followed, or as required to translate it into languages other than 636 English. 638 The limited permissions granted above are perpetual and will not be 639 revoked by the Internet Society or its successors or assigns. 641 This document and the information contained herein is provided on an 642 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 643 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 644 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 645 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 646 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.