idnits 2.17.00 (12 Aug 2021) /tmp/idnits42329/draft-turner-caclearanceconstraints-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 610. 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 (July 14, 2008) is 5058 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 536 -- Looks like a reference, but probably isn't: '1' on line 538 -- Looks like a reference, but probably isn't: '2' on line 521 ** Obsolete normative reference: RFC 3281 (Obsoleted by RFC 5755) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sean Turner 2 Internet Draft IECA 3 Intended Status: Standard Track Santosh Chokhani 4 CygnaCom Solutions 5 Expires: January 14, 2009 July 14, 2008 7 Clearance and CA Clearance Constraints Certificate Extensions 8 draft-turner-caclearanceconstraints-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on January 14, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document defines the syntax and semantics for the Clearance 42 attribute and the Authority Clearance Constraints extension in X.509 43 certificates. The Clearance attribute is used to indicate the 44 clearance held by the subject. The Clearance attribute may appear in 45 the subject directory attributes extension of a public key 46 certificate or in the attributes field of an attribute certificate. 47 The Authority Clearance Constraints certificate extension values in a 48 Trust Anchor (TA), a CA public key certificate, and an Attribute 49 Authority (AA) attribute certificate in a certification path 50 constrain the effective Clearance of the subject of the last 51 certificate in the certification path. 53 Table of Contents 55 1. Introduction...................................................2 56 1.1. Terminology...............................................3 57 1.2. ASN.1 Syntax Notation.....................................3 58 2. Clearance Attribute............................................3 59 3. Authority Clearance Constraints Certificate Extension..........4 60 4. Clearance and Authority Clearance Constraints Processing.......5 61 4.1. Collecting Constraints....................................6 62 4.1.1. Certification Path Processing........................6 63 4.1.1.1. Inputs..........................................6 64 4.1.1.2. Initialization..................................6 65 4.1.1.3. Basic Certificate Processing....................7 66 4.1.1.4. Preparation for Certificate i+1.................8 67 4.1.1.5. Wrap-up Procedure...............................8 68 4.1.1.6. Outputs.........................................9 69 5. Application of Algorithm to Attribute Certificates.............9 70 6. Security Considerations.......................................10 71 7. IANA Considerations...........................................10 72 8. References....................................................10 73 8.1. Normative References.....................................10 74 8.2. Informative References...................................11 75 Appendix A. ASN.1 Module.........................................12 77 1. Introduction 79 Organizations that have implemented a security policy can issue 80 certificates that include an indication of the clearance values held 81 by the subject. The Clearance attribute indicates the security 82 policy, the clearance levels held by the subject, and additional 83 authorization information held by the subject. This specification 84 makes use of the ASN.1 syntax for clearance from [RFC3281]. 86 Some organizations have multiple TAs, CAs, and/or AAs and these 87 organizations may wish to indicate to relying parties which clearance 88 values from a particular TA, CA, or AA should be accepted. For 89 example, consider the security policies described in [RFC3114], where 90 a security policy has been defined for Amoco with three security 91 classification values (HIGHLY CONFIDENTIAL, CONFIDENTIAL, and 92 GENERAL). To constrain a CA for just one security classification, the 93 Authority Clearance Constraints certificate extension would be 94 included in the CA's certificate. 96 Cross-certified domains can also make use of the Authority Clearance 97 Constraints certificate extension to indicate which clearance values 98 should be acceptable to relying parties. 100 1.1. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 1.2. ASN.1 Syntax Notation 108 All X.509 public key certificate [RFC5280] extensions are defined 109 using ASN.1 [X.680]. All X.509 attribute certificate [RFC3281] 110 extensions are defined using ASN.1 [X.680]. 112 2. Clearance Attribute 114 The Clearance attribute in a certificate indicates the clearances 115 held by the subject. It uses the clearance attribute syntax from 116 Section 4.4.6 of [RFC3281], which is included below for convenience, 117 in the Attributes field. A certificate MUST include either zero or 118 one instance of the Clearance attribute. 120 The following object identifier identifies the Clearance attribute 121 (either in the subject directory attributes extension of a public key 122 certificate or in the Attributes field of an attribute certificate): 124 id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 125 ds(5) module(1) selected-attribute-types(5) clearance(55) } 127 The ASN.1 syntax for the Clearance attribute is as follows: 129 Clearance ::= SEQUENCE { 130 policyId [0] OBJECT IDENTIFIER, 131 classList [1] ClassList DEFAULT {unclassified}, 132 securityCategories [2] SET OF SecurityCategory OPTIONAL 133 } 134 ClassList ::= BIT STRING { 135 unmarked (0), 136 unclassified (1), 137 restricted (2), 138 confidential (3), 139 secret (4), 140 topSecret (5) 141 } 143 SecurityCategory ::= SEQUENCE { 144 type [0] IMPLICIT OBJECT IDENTIFIER, 145 value [1] ANY DEFINED BY type 146 } 148 The Clearance attribute takes its meaning from Section 4.4.6 of 149 [RFC3281], which is repeated here for convenience: 151 - policyId identifies the security policy to which the clearance 152 relates. The policyId indicates the semantics of the classList 153 and securityCategory fields. 155 - classlist identifies the security classifications. Six basic 156 values are defined in bit positions 0 through 5 and more may be 157 defined by an organizational security policy. 159 - securityCategories provides additional authorization information. 161 If a trust anchor's public key is used directly, then the Clearance 162 associated with the trust anchor, if any, should be used as the 163 effective clearance (also defined as effective-clearance for a 164 certification path). 166 3. Authority Clearance Constraints Certificate Extension 168 The Authority Clearance Constraints certificate extension indicates 169 to the relying party what clearances should be acceptable for the 170 subject of the last certificate in the certification path containing 171 the TA, the CA, or the AA. It is only meaningful in trust anchor, CA 172 certificates, or AA certificates. A trust anchor, CA certificate, or 173 AA certificate MUST include either zero or one instance of the 174 Authority Clearance Constraints certificate extension. The Authority 175 Clearance Constraints certificate extension MAY be critical or non- 176 critical. 178 Absence of this certificate extension in a TA, in a CA certificate, 179 or in an AA certificate indicates that clearance of the subject of 180 the last certificate in the certification path containing the TA, the 181 CA or the AA is not constrained by the respective TA, CA or AA. 183 The following object identifier identifies the Authority Clearance 184 Constraints certificate extension: 186 id-ce-authorityClearanceConstraints OBJECT IDENTIFIER ::= { 187 id-TBSL } 189 The ASN.1 syntax for the Authority Clearance Constraints certificate 190 extension is as follows: 192 AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) 193 OF Clearance 195 The syntax for Authority Clearance Constraints certificate extension 196 contains Clearance values that the CA or the AA asserts. The 197 sequence MUST NOT include more than one entry with the same policyId. 198 This constraint is enforced during Clearance and Authority Clearance 199 Constraints Processing described below. If more than one entry with 200 the same policyId is present in AuthorityClearanceConstraints 201 certificate extension, the certification path is rejected. 203 4. Clearance and Authority Clearance Constraints Processing 205 Authority Clearance Constraints certificate extension processing 206 determines the effective clearance (henceforth called effective- 207 clearance) for the end certificate. Authority Clearance Constraints 208 certificate extension in the TA and in each certificate up to but not 209 including the end certificate in a certification path impact the 210 effective-clearance. If there is more than one path to the end- 211 entity certificate, each path is processed independently. The 212 process involves two steps: 214 1) collecting the Authority Clearance Constraints; and 216 2) using Authority Clearance Constraints in the certification path 217 and the Clearance in the end certificate to determine the 218 effective-clearance for the subject of the end certificate. 220 Assuming a certification path consisting of n certificates, the 221 effective-clearance for the subject of the end certificate is the 222 intersection of Clearance in the subject certificate, Authority 223 Clearance Constraints, if present, in trust anchor and all Authority 224 Clearance Constraints present in intermediate certificates. Any 225 effective-clearance calculation algorithm that performs this 226 calculation and provides the same outcome as the one from the 227 algorithm described herein is considered compliant with the 228 requirements of this RFC. 230 When processing a certification path, Authority Clearance Constraints 231 are maintained in one state variable: permitted-clearances. When 232 processing begins, permitted-clearances is initialized to the special 233 value all-clearances if Authority Clearance Constraints certificate 234 extension is not present in the trust anchor, otherwise this value is 235 initialized to Authority Clearance Constraints associated with the 236 trust anchor. The permitted-clearances state variable is updated 237 each time an intermediate certificate that contains an Authority 238 Clearance Constraints certificate extension in the path is processed. 240 When processing the end certificate, the value in the Clearance 241 certificate extension in the end certificate is intersected with the 242 permitted-clearances state variable. 244 The output of Clearance and Authority Clearance Constraint 245 certificate extensions processing is the effective-clearance, which 246 could also be an empty list; and success or failure with reason code 247 for failure. 249 4.1. Collecting Constraints 251 Authority Clearance Constraints are collected from the trust anchor 252 and the intermediate certificates in a certification path. 254 4.1.1. Certification Path Processing 256 When processing Authority Clearance Constraints certificate extension 257 for the purposes of validating Clearance in the end certificate, the 258 processing described in this section or an equivalent algorithm MUST 259 be included in the certification path validation. The processing is 260 presented as additions to the certification path validation algorithm 261 described in section 6 of [RFC5280]. 263 4.1.1.1. Inputs 265 Trust anchor information may include the 266 AuthorityClearanceConstraints structure to specify Authority 267 Clearance Constraints for the trust anchor. The trust anchor may be 268 constrained or unconstrained. 270 4.1.1.2. Initialization 272 Examine the trust anchor information and verify that it does not 273 contain more than one instance of AuthorityClearanceConstraints 274 extension. If the trust anchor information contains more than one 275 instance of AuthorityClearanceConstraints extension, set effective- 276 clearance to an empty list, set error code to "multiple extension 277 instances", and exit with failure. 279 Create a state variable named permitted-clearances. If the trust 280 anchor contains an AuthorityClearanceConstraints extension, then the 281 initial value of permitted-clearances is the 282 AuthorityClearanceConstraints extension from the trust anchor. 284 Examine the permitted-clearances for the same Policy ID appearing 285 more then once. If a policyID appears more than once in the 286 permitted-clearance state variable, set effective-clearance to an 287 empty list, set error code to "multiple instances of same clearance", 288 and exit with failure. 290 If the trust anchor does not contain an AuthorityClearanceConstraints 291 extension, the permitted-clearances variable is assigned the special 292 value all-clearances. 294 4.1.1.3. Basic Certificate Processing 296 If the certificate is the last certificate (i.e., certificate n), 297 skip the steps listed in this section. 299 Examine the certificate and verify that it does not contain more than 300 one instance of AuthorityClearanceConstraints extension. If the 301 certificate contains more than one instance of 302 AuthorityClearanceConstraints extension, set effective-clearance to 303 an empty list, set error code to "multiple extension instances", and 304 exit with failure. 306 If the AuthorityClearanceConstraints certificate extension is not 307 present in the certificate, no action is taken, and the permitted- 308 clearances value is unchanged. 310 If the AuthorityClearanceConstraints certificate extension is present 311 in the certificate, set the variable temp-clearances to 312 AuthorityClearanceConstraints certificate extension. Examine the 313 temp-clearances for the same Policy ID appearing more then once. If 314 a policyID appears more than once in the temp-clearances state 315 variable, set effective-clearance to an empty list, set error code to 316 "multiple instances of same clearance", and exit with failure. 318 If the AuthorityClearanceConstraints certificate extension is present 319 in the certificate and permitted-clearances contains the all- 320 clearances special value, then assign permitted-clearances the value 321 of the temp-clearances. 323 If the AuthorityClearanceConstraints certificate extension is present 324 in the certificate and permitted-clearances does not contain the all- 325 clearances special value, take the intersection of temp-clearances 326 and permitted-clearances by repeating the following steps for each 327 clearance in the permitted-clearances state variable: 329 - If the policyID associated with the clearance is absent in the 330 temp-clearances, delete the clearance structure associated with 331 the policyID from the permitted-clearances state variable. 333 - If the policyID is present in the temp-clearances: 335 -- For every classList bit, assign the classList bit a value of 336 one (1) for the policyID in permitted-clearances state 337 variable if the bit is one (1) in both the permitted- 338 clearances state variable and the temp-clearances for that 339 policyID; otherwise assign the bit a value of zero (0). 341 -- If no bits are one (1) for the classList, delete the clearance 342 structure associated with the policyID from the permitted- 343 clearances state variable and skip the next step of processing 344 securityCategories. 346 -- Calculate securityCategories intersection in accordance with 347 guidelines associated with the security policy represented by 348 the policyID. 350 4.1.1.4. Preparation for Certificate i+1 352 No additional action associated with the Clearance attribute or 353 AuthorityClearanceConstraints certificate extensions is taken during 354 this phase of certification path validation as described in section 6 355 of [RFC5280]. 357 4.1.1.5. Wrap-up Procedure 359 To complete the processing, perform the following steps for the last 360 certificate (i.e., certificate n). 362 Examine the certificate and verify that it does not contain more than 363 one instance of Clearance attribute. If the certificate contains 364 more than one instance of Clearance attribute, set effective- 365 clearance to an empty list, set error code to "multiple instances of 366 an attribute", and exit with failure. 368 If the Clearance attribute is not present in the end certificate, set 369 effective-clearance to an empty list and exit with success. 371 Set effective-clearance to the value from the Clearance attribute in 372 the end certificate. Let us say policyID in effective-clearance is 373 X. 375 If permitted-clearance is an empty list, set effective-clearance to 376 an empty list and exit with success. 378 If the permitted-clearance has special value of all-clearances, exit 379 with success. 381 If the policyID X in effective-clearance is absent from the 382 permitted-clearance, set effective-clearance to an empty list and 383 exit with success. 385 Assign those classList bits in effective-clearance a value of one (1) 386 that have a value of one (1) both in effective-clearance and in the 387 clearance structure in permitted-clearance associated with policyID 388 X. Assign all other classList bits in effective-clearance a value of 389 zero (0). 391 If none of the classList bits have a value of one (1) in effective- 392 clearance, set effective-clearance to an empty list and exit with 393 success. 395 Set securityCategories in effective-clearance as an intersection of 396 the securityCategories in the effective-clearance and 397 securityCategories in the permitted-clearances for policyID X as 398 defined by the policyID X. 400 Exit with Success 402 4.1.1.6. Outputs 404 If certification path validation processing succeeds, effective- 405 clearance contains the effective clearance for the subject of the 406 certification path. Processing also returns success or failure 407 indication and reason for failure, if applicable. 409 5. Application of Algorithm to Attribute Certificates 411 The algorithm presented in Section 4 is public key certificate 412 centric. Its application to attribute certificates is 413 straightforward as described below. 415 If the current [RFC3281] constraint of not having chain of attribute 416 certificate chain is observed, the AC Issuer (i.e., AA) Authority 417 Clearance Constraints is used as the TA Authority Clearance 418 Constraints for the initialization step described in Section 4.1.1.2. 419 Since there is no intermediate steps, sections 4.1.1.3. and 4.1.1.4. 420 will not be executed. 422 If the current [RFC3281] constraint of not having chain of attribute 423 certificate chain is removed, the Source of Authority in the 424 Attribute Certificate chain becomes the TA for the purpose of Section 425 4. 427 6. Security Considerations 429 Certificate issuers must recognize that absence of the 430 AuthorityClearanceConstraints in a CA or AA certificate means that in 431 terms of the clearance, the subject Authority is not constrained. 433 Absence of Clearance attribute in a certificate means that the 434 subject has not been assigned any clearance. 436 If there is no Clearance associated with a TA, it means that the TA 437 has not been assigned any clearance. 439 If the local security policy considers the clearance held by a 440 subject or those supported by a CA or AA to be sensitive, then the 441 Clearance attribute or Authority Clearance Constraints should only be 442 included if the subject's and Authority's certificate can be privacy 443 protected. Also in this case, distribution of trust anchors and 444 associated Authority Clearance Constraints extension or Clearance 445 must also be privacy protected. 447 7. IANA Considerations 449 None. Please remove this section prior to publication as an RFC. 451 8. References 453 8.1. Normative References 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, March 1997. 458 [RFC5280] Cooper, D. et. al., "Internet X.509 Public Key 459 Infrastructure Certificate and Certification Revocation 460 List (CRL) Profile", RFC 5280, May 2008. 462 [RFC3281] Farrell, S., and Housley, R., "An Internet Attribute 463 Certificate Profile for Authorization", RFC 3281, April 464 2002. 466 [X.680] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1997. 467 Information Technology - Abstract Syntax Notation One. 469 8.2. Informative References 471 [RFC3114] Nicolls, W., "Implementing Company Classification Policy 472 with S/MIME Security Label", RFC3114, May 2002. 474 Appendix A. ASN.1 Module 476 This appendix provides the normative ASN.1 definitions for 477 the structures described in this specification using ASN.1 as defined 478 in X.680. 480 Clearance-AuthorityClearanceConstraints93 { id-TBSL } 482 DEFINITIONS IMPLICIT TAGS ::= 484 BEGIN 486 -- EXPORTS ALL -- 488 IMPORTS 490 -- IMPORTS from [RFC3281] 492 id-at-clearance, Clearance 493 FROM PKIXAttributeCertificate 494 { iso(1) identified-organization(3) dod(6) internet(1) 495 security(5) mechanisms(5) pkix(7) id-mod(0) 496 id-mod-attribute-cert(12) 497 } 499 -- IMPORTS from [RFC5280] 501 EXTENSION 502 FROM PKIX1Explicit93 503 { iso(1) identified-organization(3) dod(6) internet(1) 504 security(5) mechanisms(5) pkix(7) id-mod(0) 505 id-pkix1-explicit-93(3) 506 } 507 ; 509 -- Clearance attribute OID and syntax 511 -- The following is a '93 version for clearance. 512 -- It is included for convenience. 514 -- id-at-clearance OBJECT IDENTIFIER ::= 515 -- { joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 516 -- clearance (55) 517 -- } 518 -- Clearance ::= SEQUENCE { 519 -- policyId [0] OBJECT IDENTIFIER, 520 -- classList [1] ClassList DEFAULT {unclassified}, 521 -- securityCategories [2] SET OF SecurityCategory OPTIONAL 522 -- } 524 -- ClassList ::= BIT STRING { 525 -- unmarked (0), 526 -- unclassified (1), 527 -- restricted (2), 528 -- confidential (3), 529 -- secret (4), 530 -- topSecret (5) 531 -- } 533 -- SECURITY-CATEGORY ::= TYPE-IDENTIFIER 535 -- SecurityCategory ::= SEQUENCE { 536 -- type [0] 537 -- IMPLICIT TYPE-IDENTIFIER.&id({SupportedSecurityCategories}), 538 -- value [1] 539 -- TYPE-IDENTIFIER.&Type({SupportedSecurityCategories}{@type}) 540 -- } 542 -- Authority Clearance Constraints certificate extension OID 543 -- and syntax 545 id-ce-AuthorityClearanceConstraints OBJECT IDENTIFIER ::= { id-TBSL } 547 AuthorityClearanceConstraints EXTENSION ::= { 548 SYNTAX AuthorityClearanceConstraints 549 IDENTIFIED BY id-ce-AuthorityClearanceConstraints 550 } 552 AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance 554 END 556 Author's Addresses 558 Sean Turner 560 IECA, Inc. 561 3057 Nutley Street, Suite 106 562 Fairfax, VA 22031 563 USA 565 EMail: turners@ieca.com 567 Santosh Chokhani 568 CygnaCom Solutions, Inc. 570 Email: schokhani@ocygnacom.com 572 Full Copyright Statement 574 Copyright (C) The IETF Trust (2008). 576 This document is subject to the rights, licenses and restrictions 577 contained in BCP 78, and except as set forth therein, the authors 578 retain all their rights. 580 This document and the information contained herein are provided on an 581 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 582 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 583 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 584 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 585 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 586 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 588 Intellectual Property 590 The IETF takes no position regarding the validity or scope of any 591 Intellectual Property Rights or other rights that might be claimed to 592 pertain to the implementation or use of the technology described in 593 this document or the extent to which any license under such rights 594 might or might not be available; nor does it represent that it has 595 made any independent effort to identify any such rights. Information 596 on the procedures with respect to rights in RFC documents can be 597 found in BCP 78 and BCP 79. 599 Copies of IPR disclosures made to the IETF Secretariat and any 600 assurances of licenses to be made available, or the result of an 601 attempt made to obtain a general license or permission for the use of 602 such proprietary rights by implementers or users of this 603 specification can be obtained from the IETF on-line IPR repository at 604 http://www.ietf.org/ipr. 606 The IETF invites any interested party to bring to its attention any 607 copyrights, patents or patent applications, or other proprietary 608 rights that may cover technology that may be required to implement 609 this standard. Please address the information to the IETF at 610 ietf-ipr@ietf.org. 612 Acknowledgment 614 Funding for the RFC Editor function is provided by the IETF 615 Administrative Support Activity (IASA).