idnits 2.17.00 (12 Aug 2021) /tmp/idnits42923/draft-turner-caclearanceconstraints-00.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 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 590. 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 (December 5, 2007) is 5280 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 518 -- Looks like a reference, but probably isn't: '1' on line 520 -- Looks like a reference, but probably isn't: '2' on line 503 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3281 (Obsoleted by RFC 5755) Summary: 3 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 Orion Security Solutions 5 Expires: June 5, 2008 December 5, 2007 7 Clearance and CA Clearance Constraints Certificate Extensions 8 draft-turner-caclearanceconstraints-00.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 June 5, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document defines the syntax and semantics for the Clearance and 42 the Certification Authority (CA) Clearance Constraints X.509 43 certificate extensions. The Clearance certificate extension is used 44 to indicate the clearance held by the subject. The CA Clearance 45 Constraints certificate extension values in a Trust Anchor (TA) and 46 the CAs in a certification path constrain the effective Clearance of 47 the subject of the last certificate in the certification path. 49 Table of Contents 51 1. Introduction...................................................2 52 1.1. Terminology...............................................3 53 1.2. ASN.1 Syntax Notation.....................................3 54 2. Clearance Certificate Extension................................3 55 3. CA Clearance Constraints Certificate Extension.................4 56 4. Clearance and CA Clearance Constraints Processing..............5 57 4.1. Collecting Constraints....................................6 58 4.1.1. Certification Path Processing........................6 59 4.1.1.1. Inputs..........................................6 60 4.1.1.2. Initialization..................................6 61 4.1.1.2.1. Basic Certificate Processing...............7 62 4.1.1.2.2. Preparation for Certificate i+1............8 63 4.1.1.2.3. Wrap-up Procedure..........................8 64 4.1.1.2.4. Outputs....................................9 65 5. Security Considerations........................................9 66 6. IANA Considerations...........................................10 67 7. References....................................................10 68 7.1. Normative References.....................................10 69 7.2. Informative References...................................10 70 Appendix A. ASN.1 Module.........................................11 72 1. Introduction 74 Organizations that have implemented a security policy can issue 75 certificates that include an indication of the clearance values held 76 by the subject. The Clearance certificate extension indicates the 77 security policy, the clearance levels held by the subject, and 78 additional authorization information held by the subject. This 79 specification makes use of the ASN.1 syntax for clearance from 80 [RFC3281]. 82 Some organizations have multiple TAs and/or CAs, and these 83 organizations may wish to indicate to relying parties which clearance 84 values from a particular TA or CA should be accepted. For example, 85 consider the security policies described in [RFC3114], where a 86 security policy has been defined for Amoco with three security 87 classification values (HIGHLY CONFIDENTIAL, CONFIDENTIAL, and 88 GENERAL). To constrain a CA for just one security classification, the 89 CA Clearance Constraints certificate extension would be included in 90 the CA's certificate. 92 Cross-certified domains can also make use of the CA Clearance 93 Constraints certificate extension to indicate which clearance values 94 should be acceptable to relying parties. 96 1.1. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 1.2. ASN.1 Syntax Notation 104 All X.509 certificate [RFC3280] extensions are defined using ASN.1 105 [X.680, X.690]. 107 2. Clearance Certificate Extension 109 The Clearance certificate extension in a certificate indicates the 110 clearances held by the subject. It uses the clearance attribute 111 syntax from Section 4.4.6 of [RFC3281] in the Subject Directory 112 Attributes extension. The Clearance certificate extension MUST never 113 be marked critical. It is only meaningful if at least one of the 114 following key usage bits is set: digital signature, non-repudiation, 115 key transport, or key agreement. A certificate MUST include either 116 zero or one instance of the Clearance certificate extension. 118 The following object identifier identifies the Clearance certificate 119 extension: 121 id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 122 ds(5) module(1) selected-attribute-types(5) clearance(55) } 124 The ASN.1 syntax for the Clearance certificate extension is as 125 follows: 127 Clearance ::= SEQUENCE { 128 policyId [0] OBJECT IDENTIFIER, 129 classList [1] ClassList DEFAULT {unclassified}, 130 securityCategories [2] SET OF SecurityCategory OPTIONAL 131 } 132 ClassList ::= BIT STRING { 133 unmarked (0), 134 unclassified (1), 135 restricted (2), 136 confidential (3), 137 secret (4), 138 topSecret (5) 139 } 141 SecurityCategory ::= SEQUENCE { 142 type [0] IMPLICIT OBJECT IDENTIFIER, 143 value [1] ANY DEFINED BY type 144 } 146 The fields in Clearance certificate extension take their meaning from 147 Section 4.4.6 of [RFC3281], which is repeated here for convenience: 149 - policyId identifies the security policy to which the clearance 150 relates. The policyId indicates the semantics of the classList 151 and securityCategory fields. 153 - classlist identifies the security classifications. Six basic 154 values are defined in bit positions 0 through 5 and more may be 155 defined by an organizational security policy. 157 - securityCategories provides additional authorization information. 159 If a trust anchor's public key is used directly, then the Clearance 160 associated with the trust anchor, if any, should be used as the 161 effective clearance (also defined as effective-clearance for a 162 certification path). 164 3. CA Clearance Constraints Certificate Extension 166 The CA Clearance Constraints certificate extension indicates to the 167 relying party what clearances should be acceptable for the subject of 168 the last certificate in the certification path containing the TA or 169 the CA. It is only meaningful in trust anchor or CA certificates. A 170 trust anchor or CA certificate MUST include either zero or one 171 instance of the CA Clearance Constraints certificate extension. The 172 CA Clearance Constraints certificate extension MAY be critical or 173 non-critical. 175 Absence of this certificate extension in a CA certificate or in a TA 176 indicates that clearance of the subject of the last certificate in 177 the certification path containing the CA or the TA is not constrained 178 by the respective CA or TA. 180 The following object identifier identifies the CA Clearance 181 Constraints certificate extension: 183 id-ce-caClearanceConstraints OBJECT IDENTIFIER ::= { id-TBSL } 185 The ASN.1 syntax for the CA Clearance Constraints certificate 186 extension is as follows: 188 CAClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance 190 The syntax for CA Clearance Constraints certificate extension 191 contains Clearance values that the CA asserts. The sequence MUST NOT 192 include more than one entry with the same policyId. This constraint 193 is enforced during Clearance and CA Clearance Constraints Processing 194 described below. If more than one entry with the same policyId is 195 present in CAClearanceConstraints certificate extension, the 196 certification path is rejected. 198 4. Clearance and CA Clearance Constraints Processing 200 CA Clearance Constraints certificate extension processing determines 201 the effective clearance (henceforth called effective-clearance) for 202 the end certificate. CA Clearance Constraints certificate extension 203 in the TA and in each certificate up to but not including the end 204 certificate in a certification path impact the effective-clearance. 205 If there is more than one path to the end-entity certificate, each 206 path is processed independently. The process involves two steps: 208 1) collecting the CA Clearance Constraints; and 210 2) using CA Clearance Constraints in the certification path and the 211 Clearance in the end certificate to determine the effective- 212 clearance for the subject of the end certificate. 214 Assuming a certification path consisting of n certificates, the 215 effective-clearance for the subject of the end certificate is the 216 intersection of Clearance in the subject certificate, CA Clearance 217 Constraints, if present, in trust anchor and all CA Clearance 218 Constraints present in intermediate certificates. Any effective- 219 clearance calculation algorithm that performs this calculation and 220 provides the same outcome as the one from the algorithm described 221 herein is considered compliant with the requirements of this RFC. 223 When processing a certification path, CA Clearance Constraints are 224 maintained in one state variable: permitted-clearances. When 225 processing begins, permitted-clearances is initialized to the special 226 value all-clearances if CA Clearance Constraints certificate 227 extension is not present in the trust anchor, otherwise this value is 228 initialized to CA Clearance Constraints associated with the trust 229 anchor. The permitted-clearances state variable is updated each time 230 an intermediate certificate that contains a CA Clearance Constraints 231 certificate extension in the path is processed. 233 When processing the end certificate, the value in the Clearance 234 certificate extension in the end certificate is intersected with the 235 permitted-clearances state variable. 237 The output of Clearance and CA Clearance Constraint certificate 238 extensions processing is the effective-clearance, which could also be 239 an empty list; and success or failure with reason code for failure. 241 4.1. Collecting Constraints 243 CA Clearance Constraints are collected from the trust anchor and the 244 intermediate certificates in a certification path. 246 4.1.1. Certification Path Processing 248 When processing CA Clearance Constraints certificate extension for 249 the purposes of validating Clearance in the end certificate, the 250 processing described in this section or an equivalent algorithm MUST 251 be included in the certification path validation. The processing is 252 presented as additions to the certification path validation algorithm 253 described in section 6 of [RFC3280]. 255 4.1.1.1. Inputs 257 Trust anchor information may include the CAClearanceConstraints 258 structure to specify CA Clearance Constraints for the trust anchor. 259 The trust anchor may be constrained or unconstrained. 261 4.1.1.2. Initialization 263 Examine the trust anchor and verify that it does not contain more 264 than one instance of CAClearanceConstraints extension. If the trust 265 anchor contains more than one instance of CAClearanceConstraints 266 extension, set effective-clearance to an empty list, set error code 267 to "multiple extension instances", and exit with failure. 269 Create a state variable named permitted-clearances. If the trust 270 anchor contains a CAClearanceConstraints extension, then the initial 271 value of permitted-clearances is the CAClearanceConstraints extension 272 from the trust anchor. 274 Examine the permitted-clearances for the same Policy ID appearing 275 more then once. If a policyID appears more than once in the 276 permitted-clearance state variable, set effective-clearance to an 277 empty list, set error code to "multiple instances of same clearance", 278 and exit with failure.. 280 If the trust anchor does not contain a CAClearanceConstraints 281 extension, the permitted-clearances variable is assigned the special 282 value all-clearances. 284 4.1.1.2.1. Basic Certificate Processing 286 If the certificate is the last certificate (i.e., certificate n), 287 skip the steps listed in this section. 289 Examine the certificate and verify that it does not contain more than 290 one instance of CAClearanceConstraints extension. If the certificate 291 contains more than one instance of CAClearanceConstraints extension, 292 set effective-clearance to an empty list, set error code to "multiple 293 extension instances", and exit with failure. 295 If the CAClearanceConstraints certificate extension is not present in 296 the certificate, no action is taken, and the permitted-clearances 297 value is unchanged. 299 If the CAClearanceConstraints certificate extension is present in the 300 certificate, set the variable temp-clearances to 301 CAClearanceConstraints certificate extension. Examine the temp- 302 clearances for the same Policy ID appearing more then once. If a 303 policyID appears more than once in the temp-clearances state 304 variable, set effective-clearance to an empty list, set error code to 305 "multiple instances of same clearance", and exit with failure. 307 If the CAClearanceConstraints certificate extension is present in the 308 certificate and permitted-clearances contains the all-clearances 309 special value, then assign permitted-clearances the value of the 310 temp-clearances. 312 If the CAClearanceConstraints certificate extension is present in the 313 certificate and permitted-clearances does not contain the all- 314 clearances special value, take the intersection of temp-clearances 315 and permitted-clearances by repeating the following steps for each 316 clearance in the permitted-clearances state variable: 318 - If the policyID associated with the clearance is absent in the 319 temp-clearances, delete the clearance structure associated with 320 the policyID from the permitted-clearances state variable. 322 - If the policyID is present in the temp-clearances: 324 -- For every classList bit, assign the classList bit a value of 325 one (1) for the policyID in permitted-clearances state 326 variable if the bit is one (1) in both the permitted- 327 clearances state variable and the temp-clearances for that 328 policyID; otherwise assign the bit a value of zero (0). 330 -- If no bits are one (1) for the classList, delete the clearance 331 structure associated with the policyID from the permitted- 332 clearances state variable and skip the next step of processing 333 securityCategories. 335 -- Calculate securityCategories intersection in accordance with 336 guidelines associated with the security policy represented by 337 the policyID. 339 4.1.1.2.2. Preparation for Certificate i+1 341 No additional action associated with the Clearance or 342 CAClearanceConstraints certificate extensions is taken during this 343 phase of certification path validation as described in section 6 of 344 [RFC3280]. 346 4.1.1.2.3. Wrap-up Procedure 348 To complete the processing, perform the following steps for the last 349 certificate (i.e., certificate n). 351 Examine the certificate and verify that it does not contain more than 352 one instance of Clearance extension. If the certificate contains 353 more than one instance of Clearance extension, set effective- 354 clearance to an empty list, set error code to "multiple extension 355 instances", and exit with failure. 357 If the Clearance certificate extension is not present in the end 358 certificate, set effective-clearance to an empty list and exit with 359 success. 361 Set effective-clearance to the value from the Clearance certificate 362 extension in the end certificate. Let us say policyID in effective- 363 clearance is X. 365 If permitted-clearance is an empty list, set effective-clearance to 366 an empty list and exit with success. 368 If the permitted-clearance has special value of all-clearances, exit 369 with success. 371 If the policyID X in effective-clearance is absent from the 372 permitted-clearance, set effective-clearance to an empty list and 373 exit with success. 375 Assign those classList bits in effective-clearance a value of one (1) 376 that have a value of one (1) both in effective-clearance and in the 377 clearance structure in permitted-clearance associated with policyID 378 X. Assign all other classList bits in effective-clearance a value of 379 zero (0). 381 If none of the classList bits have a value of one (1) in effective- 382 clearance, set effective-clearance to an empty list and exit with 383 success. 385 Set securityCategories in effective-clearance as an intersection of 386 the securityCategories in the effective-clearance and 387 securityCategories in the permitted-clearances for policyID X as 388 defined by the policyID X. 390 Exit with Success 392 4.1.1.2.4. Outputs 394 If certification path validation processing succeeds, effective- 395 clearance contains the effective clearance for the subject of the 396 certification path. Processing also returns success or failure 397 indication and reason for failure, if applicable. 399 5. Security Considerations 401 Certificate issuers must recognize that absence of the 402 CAClearanceConstraints in a CA certificate means that in terms of the 403 clearance, the subject CA is not constrained. 405 Absence of Clearance extension in a certificate means that the 406 subject has not been assigned any clearance. 408 If there is no Clearance associated with a TA, it means that the TA 409 has not been assigned any clearance. 411 If the local security policy considers the clearance held by a 412 subject or those supported by a CA to be sensitive, then the 413 Clearance or CA Clearance Constraints should only be included if the 414 subject's and CA's certificate can be privacy protected. Also in 415 this case, distribution of trust anchors and associated CA Clearance 416 Constraints extension or Clearance must also be privacy protected. 418 6. IANA Considerations 420 None. Please remove this section prior to publication as an RFC. 422 7. References 424 7.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 430 X.509 Public Key Infrastructure Certificate and 431 Certification Revocation List (CRL) Profile", RFC 3280, 432 April 2002. 434 [RFC3281] Farrell, S., and Housley, R., "An Internet Attribute 435 Certificate Profile for Authorization", RFC 3281, April 436 2002. 438 [X.680] ITU-T Recommendation X.680: Information Technology - 439 Abstract Syntax Notation One, 1997. 441 [X.690] ITU-T Recommendation X.690 Information Technology - ASN.1 442 encoding rules: Specification of Basic Encoding Rules 443 (BER), Canonical Encoding Rules (CER) and Distinguished 444 Encoding Rules (DER), 1997. 446 7.2. Informative References 448 [RFC3114] Nicolls, W., "Implementing Company Classification Policy 449 with S/MIME Security Label", RFC3114, May 2002. 451 Appendix A. ASN.1 Module 453 This appendix provides the normative ASN.1 definitions for 454 the structures described in this specification using ASN.1 as defined 455 in X.680. 457 Clearance-CAClearanceConstraints93 { id-TBSL } 459 DEFINITIONS IMPLICIT TAGS ::= 461 BEGIN 463 -- EXPORTS ALL -- 465 IMPORTS 467 -- IMPORTS from RFC3281 469 Clearance 470 FROM PKIXAttributeCertificate 471 { iso(1) identified-organization(3) dod(6) internet(1) 472 security(5) mechanisms(5) pkix(7) id-mod(0) 473 id-mod-attribute-cert(12) 474 } 476 EXTENSION 477 FROM PKIX1Explicit93 478 { iso(1) identified-organization(3) dod(6) internet(1) 479 security(5) mechanisms(5) pkix(7) id-mod(0) 480 id-pkix1-explicit-93(3) 481 } 483 ; 485 -- Clearance certificate extension OID and syntax 487 clearance EXTENSION ::= { 488 SYNTAX Clearance 489 IDENTIFIED BY id-at-clearance 490 } 492 -- The following is a '93 version for clearance. 493 -- It is included for convenience. 495 -- id-at-clearance OBJECT IDENTIFIER ::= 496 -- { joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 497 -- clearance (55) 498 -- } 500 -- Clearance ::= SEQUENCE { 501 -- policyId [0] OBJECT IDENTIFIER, 502 -- classList [1] ClassList DEFAULT {unclassified}, 503 -- securityCategories [2] SET OF SecurityCategory OPTIONAL 504 -- } 506 -- ClassList ::= BIT STRING { 507 -- unmarked (0), 508 -- unclassified (1), 509 -- restricted (2), 510 -- confidential (3), 511 -- secret (4), 512 -- topSecret (5) 513 -- } 515 -- SECURITY-CATEGORY ::= TYPE-IDENTIFIER 517 -- SecurityCategory ::= SEQUENCE { 518 -- type [0] 519 -- IMPLICIT TYPE-IDENTIFIER.&id({SupportedSecurityCategories}), 520 -- value [1] 521 -- TYPE-IDENTIFIER.&Type({SupportedSecurityCategories}{@type}) 522 -- } 524 -- CA Clearance Constraints certificate extension OID and syntax 526 id-ce-caClearanceConstraints OBJECT IDENTIFIER ::= { id-TBSL } 528 caClearanceConstraints EXTENSION ::= { 529 SYNTAX CAClearanceConstraints 530 IDENTIFIED BY id-ce-caClearanceConstraints 531 } 532 CAClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance 534 END 536 Author's Addresses 538 Sean Turner 540 IECA, Inc. 541 3057 Nutley Street, Suite 106 542 Fairfax, VA 22031 543 USA 545 EMail: turners@ieca.com 547 Santosh Chokhani 548 Orion Security Solutions, Inc. 550 Email: chokhani@orionsec.com 552 Full Copyright Statement 554 Copyright (C) The IETF Trust (2007). 556 This document is subject to the rights, licenses and restrictions 557 contained in BCP 78, and except as set forth therein, the authors 558 retain all their rights. 560 This document and the information contained herein are provided on an 561 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 562 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 563 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 564 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 565 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 566 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 568 Intellectual Property 570 The IETF takes no position regarding the validity or scope of any 571 Intellectual Property Rights or other rights that might be claimed to 572 pertain to the implementation or use of the technology described in 573 this document or the extent to which any license under such rights 574 might or might not be available; nor does it represent that it has 575 made any independent effort to identify any such rights. Information 576 on the procedures with respect to rights in RFC documents can be 577 found in BCP 78 and BCP 79. 579 Copies of IPR disclosures made to the IETF Secretariat and any 580 assurances of licenses to be made available, or the result of an 581 attempt made to obtain a general license or permission for the use of 582 such proprietary rights by implementers or users of this 583 specification can be obtained from the IETF on-line IPR repository at 584 http://www.ietf.org/ipr. 586 The IETF invites any interested party to bring to its attention any 587 copyrights, patents or patent applications, or other proprietary 588 rights that may cover technology that may be required to implement 589 this standard. Please address the information to the IETF at ietf- 590 ipr@ietf.org. 592 Acknowledgment 594 Funding for the RFC Editor function is provided by the IETF 595 Administrative Support Activity (IASA).