idnits 2.17.1 draft-ietf-pkix-cmc-compl-05.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 560. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 == Line 122 has weird spacing: '... Client refer...' == Line 125 has weird spacing: '... Server refer...' == Line 139 has weird spacing: '...esponse refer...' == Line 144 has weird spacing: '...dentity refer...' == Line 151 has weird spacing: '...wrapper refer...' -- 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 (December 4, 2007) is 5981 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 (-07) exists of draft-ietf-pkix-2797-bis-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'CMC-TRANS' ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Possible downref: Non-RFC (?) normative reference: ref. 'CMS-RSA-PSS' ** Obsolete normative reference: RFC 2875 (ref. 'DH-POP') (Obsoleted by RFC 6955) ** Downref: Normative reference to an Informational RFC: RFC 3394 (ref. 'AES-WRAP') Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Expires: June 6, 2008 M. Myers 5 TraceRoute Security, Inc. 6 December 4, 2007 8 Certificate Managmement Messages over CMS (CMC): Complience Requirements 9 draft-ietf-pkix-cmc-compl-05 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 6, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document provides a set of compliance statements about the CMC 43 (Certificate Management over CMS) enrollment protocol. The ASN.1 44 structures and the transport mechanisms for the CMC enrollment 45 protocol are covered in other documents. This document provides the 46 information needed to make a compliant version of CMC. 48 Table of Contents 50 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Requirements Terminology . . . . . . . . . . . . . . . . . . . 6 53 4. Requirements for All Entities . . . . . . . . . . . . . . . . 7 54 4.1. Cryptographic Algorithm Requirements . . . . . . . . . . . 7 55 4.2. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 4.3. CRMF Feature Requirements . . . . . . . . . . . . . . . . 10 57 4.4. Requirements for Clients . . . . . . . . . . . . . . . . . 11 58 5. Requirements for Servers . . . . . . . . . . . . . . . . . . . 12 59 6. Requirements for EEs . . . . . . . . . . . . . . . . . . . . . 13 60 7. Requirements for RAs . . . . . . . . . . . . . . . . . . . . . 14 61 8. Requirements for CAs . . . . . . . . . . . . . . . . . . . . . 15 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 63 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 64 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 65 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 66 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 67 12.2. Informational References . . . . . . . . . . . . . . . . . 20 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 69 Intellectual Property and Copyright Statements . . . . . . . . . . 22 71 1. Overview 73 The CMC (Certificate Management over CMS) protocol is designed in 74 terms of a client/server relationship. In the simplest case the 75 client is the requestor of the certificate (i.e. the End Entity or 76 EE) and the server is the issuer of the certificate (i.e. the 77 Certificate Authority(CA)). The introduction of an RA (registration 78 authority) into the set of agents complicates the picture only 79 slightly. The RA becomes the server with respect to the certificate 80 requestor, and it becomes the client with respect to the certificate 81 issuer. Any number of RAs can be inserted into the picture in this 82 manner. 84 The RAs may serve specialized purposes that are not currently covered 85 by this document. One such purpose would be a Key Escrow agent. As 86 such all certificate requests for encryption keys would be directed 87 through this RA and it would take appropriate action to do the key 88 archival. Key recovery requests could be defined in the CMC 89 methodology allowing for the Key Escrow agent to perform that 90 operation acting as the final server in the chain of agents. 92 If there are multiple RAs in the system, it is considered normal that 93 not all RAs will see all certificate requests. The routing between 94 the RAs may be dependent on the content of the certificate requests 95 involved. 97 This document is divided into six sections, each section specifying 98 the requirements that are specific to a class of agents in the CMC 99 model. These are 1) All agents, 2) all servers, 3) all clients, 4) 100 all End Entities, 5) all Registration Entities, 6) all Certificate 101 Authorities. 103 2. Terminology 105 There are several different terms, abbreviations and acronyms used in 106 this document that we define here for convenience and consistency of 107 usage: 109 End-Entity (EE) refers to the entity that owns a key pair and for 110 whom a certificate is issued. 112 Registration Authority (RA) or Local RA (LRA) refers to an entity 113 that acts as an intermediary between the EE and the CA. Multiple 114 RAs can exist between the End-Entity and the Certification 115 Authority. RAs may perform additional services such as key 116 generation or key archival. This document uses the term RA for 117 both RA and LRA. 119 Certification Authority (CA) refers to the entity that issues 120 certificates. 122 Client refers to an entity that creates a PKI Request. In this 123 document both RAs and EEs can be clients. 125 Server refers to the entities that process PKI Requests and create 126 PKI Responses. In this document both CAs and RAs can be servers. 128 PKCS #10 refers to the Public Key Cryptography Standard #10 129 [PKCS10], which defines a certification request syntax. 131 CRMF refers to the Certificate Request Message Format RFC [CRMF]. 132 CMC uses this certification request syntax defined in this 133 document as part of the protocol. 135 CMS refers to the Cryptographic Message Syntax RFC [CMS]. This 136 document provides for basic cryptographic services including 137 encryption and signing with and without key management. 139 PKI Request/Response refers to the requests/responses described in 140 this document. PKI Requests include certification requests, 141 revocation requests, etc. PKI Responses include certs-only 142 messages, failure messages, etc. 144 Proof-Of-Identity refers to the client proving they are who they say 145 that are to the server. 147 Proof-Of-Possession (POP) refers to a value that can be used to 148 prove that the private key corresponding to a public key is in the 149 possession and can be used by an end-entity. 151 Transport wrapper refers to the outermost CMS wrapping layer. 153 3. Requirements Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [MUST]. 159 4. Requirements for All Entities 161 All [CMC-STRUCT] and [CMC-TRANS] compliance statements MUST be 162 adhered to unless specifically stated otherwise in this document. 164 All entities MUST support Full PKI Requests, Simple PKI Responses and 165 Full PKI Responses. Severs SHOULD support Simple PKI Requests. 167 All entities MUST support the use of the CRMF syntax for 168 certification requests. Support for the PKCS#10 syntax for 169 certification requests SHOULD be implemented by servers. 171 The extendedFailInfo field SHOULD NOT be populated in the 172 CMCStatusInfoExt object; the failInfo field SHOULD be used to relay 173 this information. If the extendedFailInfo field is used, it is 174 suggested that an additional CMCStatusInfoExt item exist for the same 175 body part with a failInfo field. 177 All entities MUST implement the HTTP transport mechanism as defined 178 in [CMC-TRANS]. Other transport mechanisms MAY be implemented. 180 4.1. Cryptographic Algorithm Requirements 182 All entities MUST verify DSA-SHA1 and RSA-SHA1 signatures in 183 SignedData (see [CMS-ALG]). Entities MAY be verify other signature 184 algorithms. It is strongly suggested that RSA-PSS with SHA-1 be 185 verified (see [CMS-RSA-PSS]). It is strongly suggested that SHA-256 186 using RSA and RSA-PSS be verified (see [RSA-256]). 188 All entities MUST generate either DSA-SHA1 or RSA-SHA1 signatures for 189 SignedData (see [CMS-ALG]). Other signatures algorithms MAY be used 190 for generation. 192 All entities MUST support AES as the content encryption algorithm for 193 EnvelopedData (see [CMS-AES]). Other content encryption algorithms 194 MAY be implemented. 196 All entities MUST support RSA as a key transport algorithm for 197 EnvelopedData (see [CMS-ALG]). All entities SHOULD support RSA-OAEP 198 (see [CMS-RSA-OAEP]) as a key transport algorithm. Other key 199 transport algorithms MAY be implemented. 201 If an entity supports key agreement for EnvelopedData, they MUST 202 support Diffie-Hellman (see [CMS-DH]). 204 If an entity supports PasswordRecipientInfo for EnvelopedData or 205 AuthenticatedData, they MUST support PBKDF2 for key derivation 206 algorithms. They MUST support AES key wrap (see [AES-WRAP] as the 207 key encryption algorithm. 209 If AuthenticatedData is supported, PasswordRecipientInfo MUST be 210 supported. 212 Algorithm requirements for the Identity Proof Version 2 control 213 (Section 6.2.1 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for 214 hashAlgId. SHA-256 SHOULD be implemented for hashAlgId. HMAC-SHA1 215 MUST be implemented for macAlgId. HMAC-SHA256 SHOULD be implemented 216 for macAlgId. 218 Algorithm requirements for the Pop Link Witness Version 2 control 219 (Section 5.3.1 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for 220 keyGenAlgorithm. SHA-256 SHOUL be implemented for keyGenAlgorithm. 221 PBKDF2 MAY be implemented for keyGenAlgorithm. HMAC-SHA1 MUST be 222 implemented for macAlgorithm. HMAC-SHA256 SHOULD be implemented for 223 macAlgorithm. 225 Algorithm requirements for the Encrypted POP and Decrypted POP 226 controls (Section 6.7 of [CMC-STRUCT]) are: SHA-1 MUST be implemented 227 for witnessAlgID. SHA-256 SHULD be implemented for witnessAlgID. 228 HMAC-SHA1 MUST be implemented for thePOPAlgID. HMAC-SHA256 SHOULD be 229 implemented for thePOPAlgID. 231 Algorithm requirements for Publish Trust Anchors control (Section 232 6.15 of [CMC-STRUCT]) are: SHA-1 MUST be implemented for 233 hashAlgorithm. SHA-256 SHOULD be implemented for hashAlgorithm. 235 If an EE generates DH keys for certification, it MUST support section 236 4 of [DH-POP]. EEs MAY support section 3 of [DH-POP]. CAs and RAs 237 that do POP verification MUST support section 4 of [DH-POP] and 238 SHOULD support section 3 of [DH-POP]. 240 EEs that need to use a signature algorithm for keys that cannot 241 produce a signature MUST support Appendix C of [CMC-STRUCT] and MUST 242 support the Encrypted/Decrypted POP controls. CAs and RAs that do 243 POP verification MUST support this signature algorithm and MUST 244 support the Encrypted/Decrypted POP controls. 246 4.2. Controls 248 The following table lists the name and level of support required for 249 each control. 251 +----------------------------+----------+----------+----------+ 252 | Control | EE | RA | CA | 253 +----------------------------+----------+----------+----------+ 254 | Extended CMC Status Info | MUST | MUST | MUST | 255 | CMC Status Info | SHOULD | SHOULD | SHOULD | 256 | | | | | 257 | Identity Proof Version 2 | MUST | MUST | MUST | 258 | | | | | 259 | Identity Proof | SHOULD | SHOULD | SHOULD | 260 | | | | | 261 | Identification | MUST | MUST | MUST | 262 | | | | | 263 | POP Link Random | MUST | MUST | MUST | 264 | | | | | 265 | POP Link Witness Version 2 | MUST | MUST | MUST | 266 | | | | | 267 | POP Link Witness | SHOULD | MUST | MUST | 268 | | | | | 269 | Data Return | MUST | MUST | MUST | 270 | | | | | 271 | Modify Cert Request | N/A | MUST | (2) | 272 | | | | | 273 | Add Extensions | N/A | MAY | (1) | 274 | | | | | 275 | Transaction ID | MUST | MUST | MUST | 276 | | | | | 277 | Sender Nonce | MUST | MUST | MUST | 278 | | | | | 279 | Recipient Nonce | MUST | MUST | MUST | 280 | | | | | 281 | Encrypted POP | (4) | (5) | SHOULD | 282 | | | | | 283 | Decrypted POP | (4) | (5) | SHOULD | 284 | | | | | 285 | RA POP Witness | N/A | SHOULD | (1) | 286 | | | | | 287 | Get Certificate | optional | optional | optional | 288 | | | | | 289 | Get CRL | optional | optional | optional | 290 | | | | | 291 | Revocation Request | SHOULD | SHOULD | MUST | 292 | | | | | 293 | Registration Info | SHOULD | SHOULD | SHOULD | 294 | | | | | 295 | Response Information | SHOULD | SHOULD | SHOULD | 296 | | | | | 297 | Query Pending | MUST | MUST | MUST | 298 | | | | | 299 | Confirm Cert. Acceptance | MUST | MUST | MUST | 300 | | | | | 301 | Publish Trust Anchors | (3) | (3) | (3) | 302 | | | | | 303 | Authenticate Data | (3) | (3) | (3) | 304 | | | | | 305 | Batch Request | N/A | MUST | (2) | 306 | | | | | 307 | Batch Responses | N/A | MUST | (2) | 308 | | | | | 309 | Publication Information | optional | optional | optional | 310 | | | | | 311 | Control Processed | N/A | MUST | (2) | 312 +----------------------------+----------+----------+----------+ 314 Table 1: CMC Control Attributes 316 Notes: 318 1. CAs SHOULD implement this control if designed to work with RAs. 320 2. CAs MUST implement this control if designed to work with RAs. 322 3. Implementation is optional for these controls. We strongly 323 suggest that they be implemented in order to populate client 324 trust anchors. 326 4. EEs only need to implement this if (a) they support key agreement 327 algorithms or (b) they need to operate in environments where the 328 hardware keys cannot provide POP. 330 5. RAs SHOULD implement this if they implement RA POP Witness. 332 Strong consideration should be given to implementing the Authenticate 333 Data and Publish Trust Anchors controls as this gives a simple method 334 for distributing trust anchors into clients without user 335 intervention. 337 4.3. CRMF Feature Requirements 339 The following additional restrictions are placed on CRMF features: 341 The registration control tokens id-regCtrl-regToken and id-regCtrl- 342 authToken MUST NOT be used. No specific CMC feature is used to 343 replace these items, but generally the CMC controls identification 344 and identityProof will perform the same service and are more 345 specifically defined. 347 The control token id-regCtrl-pkiArchiveOptions SHOULD NOT be 348 supported. An alternative method is under development to provide 349 this functionality. 351 The behavior of id-regCtrl-oldCertID is not presently used. It is 352 replaced by issuing the new certificate and using the id-cmc- 353 publishCert to remove the old certificate from publication. This 354 operation would not normally be accompanied by an immediate 355 revocation of the old certificate, however that can be accomplished 356 by the id-cmc-revokeRequest control. 358 The id-regCtrl-protocolEncrKey is not used. 360 4.4. Requirements for Clients 362 No additional requirements. 364 5. Requirements for Servers 366 No additional requirements. 368 6. Requirements for EEs 370 If an entity implements Diffie-Hellman, it MUST implement either the 371 DH-POP Proof-of-Possession as defined in [DH-POP] Section 4 or the 372 challenge-response POP controls id-cmc-encryptedPOP and id-cmc- 373 decryptedPOP. 375 7. Requirements for RAs 377 RAs SHOULD be able to do delegated POP. RAs implementing this 378 feature MUST implement the id-cmc-lraPOPWitness control. 380 All RAs MUST implement the promotion of the id-aa-cmc-unsignedData as 381 covered in section 3.8 of [CMC-STRUCT] 383 8. Requirements for CAs 385 Providing for CAs to work in an environment with RAs is strongly 386 suggested. Implementation of such support is strongly suggested as 387 this permits the delegation of substantial administrative interaction 388 onto an RA rather than at the CA. 390 CAs MUST perform at least minimal checks on all public keys before 391 issuing a certificate. At a minimum a check for syntax would occur 392 with the POP operation. Additionally CAs SHOULD perform simple 393 checks for known bad keys such as small subgroups for DSA-SHA1 and DH 394 keys [SMALL-SUB-GROUP] or known bad exponents for RSA keys. 396 CAs MUST enforce POP checking before issuing any certificate. CAs 397 MAY delegate the POP operation to an RA for those cases where 1) a 398 challenge/response message pair must be used, 2) an RA performs 399 escrow of a key and checks for POP in that manner or 3) an unusual 400 algorithm is used and that validation is done at the RA. 402 CAs SHOULD implement both the DH-POP Proof-of-Possession as defined 403 in [DH-POP] Section 4 and the challenge-response POP controls id-cmc- 404 encryptedPOP and id-cmc-decryptedPOP. 406 9. Security Considerations 408 This document uses [CMC-STRUCT] and [CMC-TRANS] as building blocks to 409 this document. The security sections of those two documents are 410 included by reference. 412 Knowledge of how an entity is expected to operate is vital in 413 determining which sections of requirements are applicable to that 414 entity. Care needs to be taken in determining which sections apply 415 and fullly implementing the necessary code. 417 Cryptographic algorithms have and will be broken or weakened. 418 Implementers and users need to check that the cryptographic 419 algorithms listed in this document make sense from a security level. 420 The IETF from time to time may issue documents dealing with the 421 current state of the art. Two examples of such documents are 422 [SMALL-SUB-GROUP] and [HASH-ATTACKS]. 424 10. IANA Considerations 426 There are no IANA considerations in this document. 428 11. Acknowledgements 430 The authors and the Working Group are grateful for the participation 431 of Xiaoui Lui and Jeff Weinstein in helping to author the original 432 versions of this document. 434 The authors would like to thank Brian LaMacchia for his work in 435 developing and writing up many of the concepts presented in this 436 document. The authors would also like to thank Alex Deacon and Barb 437 Fox for their contributions. 439 12. References 441 12.1. Normative References 443 [CMC-STRUCT] 444 Schaad, J. and M. Myers, "Certificate Management Messages 445 over CMS", draft-ietf-pkix-2797-bis-05.txt , August 2006. 447 [CMC-TRANS] 448 Schaad, J., Myers, M., Liu, X., and J. Weinstein, "CMC 449 Transport", Work In Progress , December 2004. 451 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 452 RFC 3852, July 2004. 454 [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES) 455 Encryption Algorithm in Cryptographic Message Syntax 456 (CMS)", RFC 3565, July 2003. 458 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) 459 Algorithms", RFC 3370, August 2002. 461 [CMS-DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", 462 RFC 2631, June 1999. 464 [CRMF] Schaad, J., "Internet X.509 Certificate Request M2essage 465 Format", RFC 4211, September 2005. 467 [CMS-RSA-OAEP] 468 Housley, R., "Use of the RSAES-OAEP Key Transport 469 Algorithm in the Cryptographic Message Syntax (CMS)", 470 RFC 3560, July 2003. 472 [CMS-RSA-PSS] 473 Schaad, J., "Use of the RSA PSS Signature Algorithm in 474 CMS", Work In Progress , December 2003. 476 [DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof- 477 of-Possession Algorithms", RFC 2875, June 2000. 479 [MUST] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", RFC 2119, BCP 14, March 1997. 482 [RSA-256] Schaad, J., Kaliski, B., and R. Housley, "Additional 483 Algorithms and Identifiers for RSA Cryptography for use in 484 the Internet X.509 Public Key Infrastructure Certificate 485 and Certificate Revocation List (CRL) Profile", RFC 4055, 486 June 2005. 488 [AES-WRAP] 489 Schaad, J. and R. Housley, "Advanced Encryption Standard 490 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 492 12.2. Informational References 494 [PKCS10] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 495 Request Syntax Specification v1.7", RFC 2986, 496 November 2000. 498 [SMALL-SUB-GROUP] 499 Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" 500 Attacks on the Diffie-Hellman Key Agreement Method for 501 S/MIME", RFC 2785, March 2000. 503 [HASH-ATTACKS] 504 Hoffman, P. and B. Schneier, "Attacks on Cryptographic 505 Hashes in Internet Protocols", RFC 4270, November 2005. 507 Authors' Addresses 509 Jim Schaad 510 Soaring Hawk Consulting 511 PO Box 675 512 Gold Bar, WA 98251 514 Phone: (425) 785-1031 515 Email: jimsch@nwlink.com 517 Michael Myers 518 TraceRoute Security, Inc. 520 Email: mmyers@fastq.com 522 Full Copyright Statement 524 Copyright (C) The IETF Trust (2007). 526 This document is subject to the rights, licenses and restrictions 527 contained in BCP 78, and except as set forth therein, the authors 528 retain all their rights. 530 This document and the information contained herein are provided on an 531 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 532 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 533 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 534 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 535 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 536 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 538 Intellectual Property 540 The IETF takes no position regarding the validity or scope of any 541 Intellectual Property Rights or other rights that might be claimed to 542 pertain to the implementation or use of the technology described in 543 this document or the extent to which any license under such rights 544 might or might not be available; nor does it represent that it has 545 made any independent effort to identify any such rights. Information 546 on the procedures with respect to rights in RFC documents can be 547 found in BCP 78 and BCP 79. 549 Copies of IPR disclosures made to the IETF Secretariat and any 550 assurances of licenses to be made available, or the result of an 551 attempt made to obtain a general license or permission for the use of 552 such proprietary rights by implementers or users of this 553 specification can be obtained from the IETF on-line IPR repository at 554 http://www.ietf.org/ipr. 556 The IETF invites any interested party to bring to its attention any 557 copyrights, patents or patent applications, or other proprietary 558 rights that may cover technology that may be required to implement 559 this standard. Please address the information to the IETF at 560 ietf-ipr@ietf.org. 562 Acknowledgment 564 Funding for the RFC Editor function is provided by the IETF 565 Administrative Support Activity (IASA).