idnits 2.17.1 draft-ietf-ltans-ers-scvp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 545. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (June 20, 2008) is 5787 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) == Outdated reference: A later version (-08) exists of draft-ietf-ltans-ltap-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Long-term Archive And Notary C. Wallace 3 Services (LTANS) Cygnacom Solutions 4 Internet-Draft June 20, 2008 5 Intended status: Standards Track 6 Expires: December 22, 2008 8 Using Server-based Certificate Validation Protocol (SCVP) to Convey 9 Long-term Evidence Records 10 draft-ietf-ltans-ers-scvp-07.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 22, 2008. 37 Abstract 39 The Server-based Certificate Validation Protocol (SCVP) defines an 40 extensible means of delegating the development and validation of 41 certification paths to a server. It can be used to support the 42 development and validation of certification paths well after the 43 expiration of the certificates in the path by specifying a time of 44 interest in the past. The Evidence Record Syntax (ERS) defines 45 structures, called evidence records, to support non-repudiation of 46 existence of data. Evidence records can be used to preserve 47 materials that comprise a certification path such that trust in the 48 certificates can be established after the expiration of the 49 certificates in the path and after the cryptographic algorithms used 50 to sign the certificates in the path are no longer secure. This 51 document describes usage of the SCVP WantBack feature to convey 52 evidence records, enabling SCVP responders to provide preservation 53 evidence for certificates and certificate revocation lists (CRLs). 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 59 2. Concept of Operations . . . . . . . . . . . . . . . . . . . . 5 60 3. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. WantBacks . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.1. Evidence record for a complete certification path . . . . 9 64 5.2. Evidence record for a partial certification path . . . . . 9 65 5.3. Evidence record for a public key certificate . . . . . . . 10 66 5.4. Evidence record for revocation information . . . . . . . . 10 67 5.5. Evidence record for any replyWantBack . . . . . . . . . . 11 68 5.6. Partial certification path . . . . . . . . . . . . . . . . 11 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 74 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 Intellectual Property and Copyright Statements . . . . . . . . . . 19 78 1. Introduction 80 Digital signatures are frequently verified using public key 81 infrastructure (PKI) artifacts, including public key certificates and 82 certificate revocation information. Verifiers construct and validate 83 certification paths from a public key certificate containing the 84 public key used to verify the signature to a trusted public key. 85 Construction of a certification path may require acquisition of 86 different types of information generated by multiple PKIs. To verify 87 digital signatures many years after signature generation, additional 88 considerations must be addressed. For example, some necessary PKI 89 artifacts may no longer be available, some may have expired and the 90 cryptographic algorithms or keys used in generating digital 91 signatures may no longer provide the desired degree of security. 93 SCVP [RFC5055] provides a means of delegating certification path 94 construction and/or validation to a server, including the ability to 95 request the status of a certificate relative to a time in the past. 96 SCVP does not define a means of providing or validating long-term 97 non-repudiation information. ERS [RFC4998] defines a syntax for 98 preserving materials over long periods of time through a regimen that 99 includes periodic re-signing of relevant materials using newer keys 100 and stronger cryptographic algorithms. LTAP [I-D.ietf-ltans-ltap] 101 defines a protocol for communicating with a long-term archive (LTA) 102 server for the purpose of preserving evidence records and data. 103 Clients store, retrieve and delete data using LTAP; LTAs maintain 104 evidence records covering data submitted by clients. 106 This document defines an application of SCVP to permit retrieval of 107 an evidence record corresponding to information returned by the SCVP 108 server by creating an association between an evidence record and 109 information contained in an SCVP response. The SCVP response can 110 then in turn be used to verify archived data objects retrieved using 111 LTAP. Separating the preservation of the certification path 112 information from the preservation of data enables the LTA to store 113 archived data objects more efficiently, i.e., complete verification 114 information need not be stored with each archived data object. 115 Verifiers can more efficiently process archived data object by 116 reusing the same certification path information to verify multiple 117 archived data objects of similar vintage without retrieving and/or 118 validating the same PKI artifacts multiple times. 120 1.1. Requirements notation 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 2. Concept of Operations 128 During certification path processing, active SCVP servers may 129 encounter a large portion of the PKI artifacts generated by a 130 particular PKI. By storing and preserving these artifacts, an SCVP 131 server can respond to queries for certificate status over very long 132 periods of time. Optionally, SCVP servers may actively seek PKI 133 information for storage and preservation even when no query is made 134 that requires the information during its period of validity in order 135 to service future queries relative to any point in time. 137 SCVP permits clients to request as much or as little information as 138 desired from the SCVP server. Clients include zero or more OIDs 139 indicating the type(s) of information the server should include in 140 the response. By defining additional OID values, clients can request 141 an evidence record for specific types of information returned by the 142 SCVP server. This document defines OIDs to permit the retrieval of 143 evidence records for the following four types of information: 145 - end entity certificates 147 - certification paths containing an end entity certificate up to a 148 trust anchor 150 - certification paths containing an intermediate certificate up to 151 a trust anchor 153 - revocation information. 155 Additionally, an OID is defined to permit inclusion of a single OID 156 indicating an evidence record is desired for all information 157 requested via the WantBack mechanism. 159 By associating evidence records with information maintained by an 160 SCVP server, clients are able to determine the status of certificates 161 over very long periods of time using SCVP without consulting 162 additional resources. The nature of SCVP servers is well suited to 163 preservation of infrastructure materials. Additionally, the SCVP 164 server's signature over an SCVP response can secure the transmission 165 of trust anchors included in evidence records, allowing clients to 166 refrain from establishing additional trust relationships with LTAs. 168 The transactions used to verify an archived data object using LTAP 169 and the SCVP WantBacks described in this document are as follows: 171 - Client retrieves a signed archived data object from an LTA using 172 LTAP 173 - Client prepares an SCVP request to validate the signer's 174 certificate at the time of interest and includes WantBacks for 175 evidence records corresponding to the PKI artifacts required to 176 validate the signer's certificate 178 - SCVP server returns a response with status as of time of 179 interest and includes requested evidence records 181 - Client processes the SCVP request, determines the status and 182 verifies the evidence records 184 - Client verifies signatures in the archived data object using the 185 validated signer's certificate 187 3. Requests 189 Clients request long-term archive evidence records from an SCVP 190 server by including one of the following OIDs in the wantBack field 191 of a CVRequest sent to an SCVP server: 193 - id-swb-ers-best-cert-path 195 - id-swb-ers-partial-cert-path 197 - id-swb-ers-pkc-cert 199 - id-swb-ers-revocation-info 201 - id-swb-ers-all 203 Additionally, id-swb-partial-cert-path is defined to permit clients 204 to request a partial certification path consisting of the CA who 205 issued the end entity certificate through a trust anchor. This is 206 similar to the id-swb-best-cert-path WantBack defined in SCVP except 207 the resulting replyWantBack will contain a CertBundle containing the 208 certification path minus the end entity certificate. 210 For each id-swb-ers OID except id-swb-ers-all, an EvidenceRecord (as 211 defined in [RFC4998]) covering the corresponding information in the 212 response will be returned as a replyWantBack. For example, if a 213 client wishes to obtain a certification path and revocation 214 information plus an evidence record for each, the SCVP request would 215 include the following four replyWantBack OIDs: id-swb-best-cert-path, 216 id-swb-pkc-revocation-info, id-swb-ers-best-cert-path and id-swb-ers- 217 revocation-info. 219 Alternatively, for id-swb-ers-all, an EvidenceRecordWantBacks 220 structure will be returned containing an EvidenceRecord for each 221 information item contained in the replyWantBacks field. For example, 222 if a client wishes to obtain a certification path and revocation 223 information plus an evidence record for each, the SCVP request would 224 include the following four replyWantBack OIDs: id-swb-best-cert-path, 225 id-swb-pkc-revocation-info and id-swb-ers-all. 227 4. Responses 229 When a client request contains a WantBack request for an evidence 230 record, the response generated MUST include the replyWantBack 231 containing the requested information plus a replyWantBack containing 232 the evidence record corresponding to that information. For each id- 233 swb-ers OID except id-swb-ers-pkc-cert and id-swb-ers-revocation- 234 info, the evidence record MUST be calculated over the value of the 235 value field in the corresponding replyWantBack; the tag and length 236 bytes are not covered by the evidence record. The targets for the 237 id-swb-ers-pkc-cert and id-swb-ers-revocation-info replyWantBacks are 238 described below. For example, if a client request contains id-swb- 239 pkc-best-cert-path and id-swb-ers-best-cert-path, the resulting 240 response will contain a replyWantBack of each type where the evidence 241 record covers the DER encoded CertBundle returned in the id-swb-pkc- 242 best-cert-path replyWantBack. For id-swb-ers-pkc-cert, the evidence 243 record MUST be calculated over the value of the cert field in the 244 CertReply object. For id-swb-ers-revocation-info, a sequence of 245 evidence records is returned. Each revocation information object 246 contained in the id-swb-pkc-revocation-info replyWantBack is covered 247 by an evidence record in the id-swb-ers-revocation-info 248 replyWantWant. A single evidence record may cover multiple 249 revocation information objects. The correct evidence record can be 250 identified by locating the hash of the revocation information object 251 in the first initial timestamp of the evidence record. 253 If the server can not return an EvidenceRecord for the requested 254 information item, a replyWantBack of the appropriate type MUST be 255 returned with an empty value field. For example, if a client 256 requests id-swb-ers-pkc-cert and the server cannot fulfill the 257 request, the resulting response will contain a replyWantBack with the 258 wb field set to id-swb-ers-pkc-cert and the value field empty, i.e., 259 zero length. 261 5. WantBacks 263 The following sections describe each WantBack defined in this 264 document. Each wantBack for an evidence record requires a 265 corresponding wantBack for the object covered by the evidence record 266 to be present in the request. Upon receipt of a request missing the 267 corresponding wantBack for the object covered by a requested evidence 268 record, the server MUST indicate wantBackUnsatisfied in the 269 ReplyStatus. Clients MAY ignore evidence record wantBacks when the 270 wantBack for the corresponding object is not present. 272 5.1. Evidence record for a complete certification path 274 The id-swb-ers-best-cert-path OID is used to request an evidence 275 record for a complete certification path. It is used in conjunction 276 with the id-swb-best-cert-path OID. Requests containing id-swb-ers- 277 best-cert-path as a WantBack MUST also contain id-swb-best-cert-path. 278 Responses containing id-swb-ers-best-cert-path MUST also contain id- 279 swb-best-cert-path. 281 An SCVP server may maintain evidence records for complete 282 certification paths, i.e., certification paths containing all 283 certificates from end entity to trust anchor. The evidence record 284 MUST be calculated over the CertBundle returned via the id-swb-best- 285 cert-path replyWantBack. In such cases, a signature within the 286 archived data object may be verified using an end entity certificate 287 returned via SCVP. The end entity certificate can be verified using 288 SCVP using a request containing id-swb-ers-best-cert-path, id-swb- 289 best-cert-path, id-swb-pkc-revocation-info and id-swb-ers-revocation- 290 info 292 5.2. Evidence record for a partial certification path 294 The id-swb-ers-partial-cert-path OID is used to request an evidence 295 record for a partial certification path. It is used in conjunction 296 with the id-swb-partial-cert-path OID. Requests containing id-swb- 297 ers-partial-cert-path as a WantBack MUST also contain id-swb-partial- 298 cert-path. Responses containing id-swb-ers-partial-cert-path MUST 299 also contain id-swb-partial-cert-path. 301 As an alternative to relying on SCVP to obtain evidence records for 302 end entity certificates, the certificate could be included in the 303 archived data object(s) submitted to an LTA. In such cases, a 304 signature within the archived data object may be verified using the 305 included end entity certificate, which is protected by the evidence 306 record covering the archived data object including the certificate. 307 The end entity certificate can be verified using SCVP using a request 308 containing id-swb-partial-cert-path, id-swb-ers-partial-cert-path, 309 id-swb-pkc-revocation-info and id-swb-ers-revocation-info. Unlike 310 the partial certification path, the revocation information includes 311 material that can be used to determine the status of the end entity 312 certificate. 314 By maintaining an evidence record for a partial certification path, 315 SCVP servers can achieve greater storage efficiency. 317 5.3. Evidence record for a public key certificate 319 The id-swb-ers-pkc-cert OID is used to request an evidence record for 320 an individual public key certificate. It is used in conjunction with 321 the id-swb-pkc-cert OID. Requests containing id-swb-ers-pkc-cert as 322 a WantBack MUST also contain id-swb-pkc-cert. Responses containing 323 id-swb-ers-pkc-cert MUST also contain id-swb-pkc-cert. 325 SCVP servers may maintain evidence records for individual 326 certificates. This enables clients to omit the signer's certificate 327 from archived data object(s) submitted to an LTA. In such cases, a 328 signature within the archived data object may be verified using an 329 end entity certificate returned via SCVP. The end entity certificate 330 can be verified using SCVP using a request containing id-swb-pkc- 331 cert, id-swb-ers-pkc-cert, id-swb-partial-cert-path, id-swb-ers- 332 partial-cert-path, id-swb-pkc-revocation-info and id-swb-ers- 333 revocation-info. 335 5.4. Evidence record for revocation information 337 The id-swb-ers-revocation-info OID is used to request evidence 338 records for a set of revocation information. It is used in 339 conjunction with the id-swb-revocation-info OID. Requests containing 340 id-swb-ers-revocation-info as a WantBack MUST also contain id-swb- 341 revocation-info. Responses containing id-swb-ers-revocation-info 342 MUST also contain id-swb-revocation-info. A sequence of evidence 343 records is returned, with one evidence record provided for each 344 element in id-swb-revocation-info. 346 EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord 348 An SCVP server may maintain evidence records for revocation 349 information. Revocation information may be provided in the form of 350 CRLs or OCSP responses. Cumulative CRLs may be generated for 351 archiving to simplify evidence record maintenance. 353 5.5. Evidence record for any replyWantBack 355 An SCVP server may maintain evidence records for additional types of 356 information that can be returned using the wantBack mechanism, e.g., 357 attribute certificate information. The id-swb-ers-all OID provides a 358 shorthand means for clients to request evidence records for all 359 information returned via the replyWantBacks field. Since id-swb-ers- 360 all can result in the return of multiple evidence records in the 361 response, a mechanism is needed to associate an evidence record with 362 the type of information covered by the evidence record. The 363 EvidenceRecordWantBacks structure provides a flexible means of 364 conveying an evidence record for different types of information. 366 EvidenceRecordWantBack ::= SEQUENCE 367 { 368 targetWantBack OBJECT IDENTIFIER, 369 evidenceRecord EvidenceRecord OPTIONAL 370 } 372 EvidenceRecordWantBacks ::= 373 SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack 375 EvidenceRecordWantBacks is a SEQUENCE OF EvidenceRecordWantBack 376 structures. The targetWantBack field indicates the type of 377 replyWantBack covered by the associated EvidenceRecord. The 378 evidenceRecord field, if present, contains an EvidenceRecord 379 structure calculated over the replyWantBack indicated by the 380 targetWantBack field. Where EvidenceRecordWantBacks is used, there 381 MUST be a one to one correspondence between other replyWantBack 382 objects and objects in the EvidenceRecordWantBacks collection. If a 383 server does not have an EvidenceRecord for a particular replyWantBack 384 object, an EvidenceRecordWantBack with the evidenceRecord field 385 absent should be included in the EvidenceRecordWantBacks collection. 387 5.6. Partial certification path 389 The id-swb-partial-cert-path is an alternative to id-swb-best-cert- 390 path. This is the only OID defined in this document for which an 391 EvidenceRecord is not returned in the response. For efficiency, SCVP 392 servers that maintain evidence records for certification paths may 393 only do so for partial paths instead of maintaining one or more paths 394 for each end entity certificate. 396 SCVP clients can include id-swb-partial-cert-path in a request when a 397 partial certification path is required. This would typically be 398 included along with id-swb-ers-partial-cert-path to account for the 399 fact that some SCVP servers only produce evidence records for partial 400 paths for storage and computational efficiency reasons. In such 401 cases, a separate evidence record may be available for the end entity 402 certificate by including id-swb-pkc-cert and id-swb-ers-pkc-cert in 403 the request. 405 6. Security Considerations 407 For security considerations specific to SCVP, see [RFC5055]. For 408 security considerations specific to ERS, see [RFC4998]. 410 The signature on the SCVP response containing one or more ERS 411 structures must be verified using a public key trusted by the relying 412 party. The response may contain trust anchors used to verify 413 interior layers of an ERS structure. The trust anchors are protected 414 by the SCVP server's signature covering the response. The relying 415 party may elect to use the trust anchors conveyed in the response or 416 ignore the trust anchors in favor of trust anchors retrieved out of 417 band. Relying parties SHOULD ignore trust anchors contained in 418 unsigned SCVP responses. 420 7. IANA Considerations 422 This document has no actions for IANA. 424 8. References 426 8.1. Normative References 428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 429 Requirement Levels", BCP 14, RFC 2119, March 1997. 431 [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence 432 Record Syntax (ERS)", RFC 4998, August 2007. 434 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 435 Polk, "Server-Based Certificate Validation Protocol 436 (SCVP)", RFC 5055, December 2007. 438 8.2. Informative References 440 [I-D.ietf-ltans-ltap] 441 Jerman-Blazic, A., Sylvester, P., and C. Wallace, "Long- 442 term Archive Protocol (LTAP)", draft-ietf-ltans-ltap-06 443 (work in progress), February 2008. 445 Appendix A. ASN.1 Module 447 The following ASN.1 module defines object identifiers used to 448 identify six new forms of SCVP WantBacks and three new structures. 449 EvidenceRecordWantBack and EvidenceRecordWantBacks are used in 450 conjunction with the id-swb-ers-all WantBack to correlate evidence 451 records with WantBacks. EvidenceRecords is used in conjunction with 452 the id-swb-ers-revocation-info WantBack to return evidence records 453 for individual revocation information objects. 455 LTANS-SCVP-EXTENSION 456 { iso(1) identified-organization(3) dod(6) internet(1) 457 security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-ers-scvp(5) 458 id-mod-ers-scvp-v1(1) } 460 DEFINITIONS IMPLICIT TAGS ::= 461 BEGIN 463 IMPORTS 465 id-swb 466 FROM SCVP 467 { iso(1) identified-organization(3) dod(6) internet(1) 468 security(5) mechanisms(5) pkix(7) id-mod(0) 21 } 470 EvidenceRecord 471 FROM ERS 472 {iso(1) identified-organization(3) dod(6) internet(1) 473 security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-ers88(2) 474 id-mod-ers88-v1(1) }; 476 id-swb-partial-cert-path OBJECT IDENTIFIER ::= {id-swb 15 } 478 id-swb-ers-pkc-cert OBJECT IDENTIFIER ::= {id-swb 16 } 479 id-swb-ers-best-cert-path OBJECT IDENTIFIER ::= {id-swb 17 } 480 id-swb-ers-partial-cert-path OBJECT IDENTIFIER ::= {id-swb 18 } 481 id-swb-ers-revocation-info OBJECT IDENTIFIER ::= {id-swb 19 } 482 id-swb-ers-all OBJECT IDENTIFIER ::= {id-swb 20 } 484 EvidenceRecordWantBack ::= SEQUENCE 485 { 486 targetWantBack OBJECT IDENTIFIER, 487 evidenceRecord EvidenceRecord OPTIONAL 488 } 490 EvidenceRecordWantBacks ::= 491 SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack 493 EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord 495 END 497 Author's Address 499 Carl Wallace 500 Cygnacom Solutions 501 Suite 5200 502 7925 Jones Branch Drive 503 McLean, VA 22102 505 Email: cwallace@cygnacom.com 507 Full Copyright Statement 509 Copyright (C) The IETF Trust (2008). 511 This document is subject to the rights, licenses and restrictions 512 contained in BCP 78, and except as set forth therein, the authors 513 retain all their rights. 515 This document and the information contained herein are provided on an 516 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 517 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 518 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 519 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 520 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 521 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 523 Intellectual Property 525 The IETF takes no position regarding the validity or scope of any 526 Intellectual Property Rights or other rights that might be claimed to 527 pertain to the implementation or use of the technology described in 528 this document or the extent to which any license under such rights 529 might or might not be available; nor does it represent that it has 530 made any independent effort to identify any such rights. Information 531 on the procedures with respect to rights in RFC documents can be 532 found in BCP 78 and BCP 79. 534 Copies of IPR disclosures made to the IETF Secretariat and any 535 assurances of licenses to be made available, or the result of an 536 attempt made to obtain a general license or permission for the use of 537 such proprietary rights by implementers or users of this 538 specification can be obtained from the IETF on-line IPR repository at 539 http://www.ietf.org/ipr. 541 The IETF invites any interested party to bring to its attention any 542 copyrights, patents or patent applications, or other proprietary 543 rights that may cover technology that may be required to implement 544 this standard. Please address the information to the IETF at 545 ietf-ipr@ietf.org.