idnits 2.17.00 (12 Aug 2021) /tmp/idnits25855/draft-turner-caclearanceconstraints-02.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 805. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 823. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 829. 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 (October 31, 2008) is 4943 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 754 -- Looks like a reference, but probably isn't: '1' on line 756 == Outdated reference: draft-ietf-pkix-new-asn1 has been published as RFC 5912 ** Downref: Normative reference to an Informational draft: draft-ietf-pkix-new-asn1 (ref. 'PKI-ASN') ** Obsolete normative reference: RFC 3281 (Obsoleted by RFC 5755) == Outdated reference: draft-ietf-pkix-3281update has been published as RFC 5755 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF PKIX Working Group Sean Turner 2 Internet Draft IECA 3 Intended Status: Standard Track Santosh Chokhani 4 CygnaCom Solutions 5 Expires: April 30, 2009 October 31, 2008 7 Clearance Attribute and Authority Clearance Constraints 8 Certificate Extension 9 draft-turner-caclearanceconstraints-02.txt 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 April 30, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines the syntax and semantics for the Clearance 43 attribute and the Authority Clearance Constraints extension in X.509 44 certificates. The Clearance attribute is used to indicate the 45 clearance held by the subject. The Clearance attribute may appear in 46 the subject directory attributes extension of a public key 47 certificate or in the attributes field of an attribute certificate. 48 The Authority Clearance Constraints certificate extension values in a 49 Trust Anchor (TA), CA public key certificates, and an Attribute 50 Authority (AA) public key certificate in a public key certification 51 path constrain the effective Clearance of the subject. 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............................................4 59 3. Authority Clearance Constraints Certificate Extension..........5 60 4. Clearance and Authority Clearance Constraints Processing in PKC6 61 4.1. Collecting Constraints....................................7 62 4.1.1. Certification Path Processing........................7 63 5. Clearance and Authority Clearance Constraints Processing in AC11 64 5.1. Collecting Constraints...................................12 65 5.1.1. Certification Path Processing.......................12 66 6. Computing Intersection of securityCategories..................13 67 7. Recommended securityCategories................................14 68 8. Security Considerations.......................................14 69 9. IANA Considerations...........................................15 70 10. References...................................................15 71 10.1. Normative References....................................15 72 10.2. Informative References..................................15 73 Appendix A. ASN.1 Module.........................................16 74 Author's Addresses...............................................18 75 Full Copyright Statement.........................................19 76 Intellectual Property............................................19 78 1. Introduction 80 Organizations that have implemented a security policy can issue 81 certificates that include an indication of the clearance values held 82 by the subject. The Clearance attribute indicates the security 83 policy, the clearance levels held by the subject, and additional 84 authorization information held by the subject. This specification 85 makes use of the ASN.1 syntax for clearance from [3281bis]. 87 Clearance attribute may be placed in the Subject Directory extension 88 of a PKC or may be placed in a separate attribute certificate (AC). 90 The placement of Clearance attribute in PKCs is desirable when the 91 credentials such as PKCs need to be revoked when the clearance 92 information changes or when clearance information is relatively 93 static, and clearance information can be verified as part of PKC 94 issuance process (e.g., using local databases). The placement of 95 Clearance attribute in PKCs may also be made to simplify the 96 infrastructure, to reduce the infrastructure design cost, or to 97 reduce the infrastructure operations cost. An example of placement 98 of Clearance attribute in PKCs in operational PKI is the Defense 99 Messaging Service. An example of placement of attributes in PKCs is 100 Qualified Certificates [RFC3739]. 102 The placement of Clearance attribute in ACs is desirable when the 103 clearance information is relatively dynamic and changes in the 104 clearance information does not require revocation of credentials such 105 as PKCs, or the clearance information can not be verified as part of 106 PKC issuance process. 108 Since [RFC3281] does not permit chain of ACs, the Authority 109 Clearance Constraints extension may only appear in the PKCs of CA or 110 AA. The Authority Clearance Constraints extension may also appear 111 in a TA or may be associated with a TA. 113 Some organizations have multiple TAs, CAs, and/or AAs and these 114 organizations may wish to indicate to relying parties which clearance 115 values from a particular TA, CA, or AA should be accepted. For 116 example, consider the security policies described in [RFC3114], where 117 a security policy has been defined for Amoco with three security 118 classification values (HIGHLY CONFIDENTIAL, CONFIDENTIAL, and 119 GENERAL). To constrain a CA for just one security classification, the 120 Authority Clearance Constraints certificate extension would be 121 included in the CA's PKC. 123 Cross-certified domains can also make use of the Authority Clearance 124 Constraints certificate extension to indicate which clearance values 125 should be acceptable to relying parties. 127 1.1. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 1.2. ASN.1 Syntax Notation 135 All X.509 PKC [RFC5280] extensions are defined using ASN.1 [X.680]. 136 All X.509 AC [RFC3281] extensions are defined using ASN.1 [X.680]. 138 2. Clearance Attribute 140 The Clearance attribute in a certificate indicates the clearances 141 held by the subject. It uses the clearance attribute syntax from 142 Section 4.4.6 of [3281bis], which is included below for convenience, 143 in the Attributes field. A certificate MUST include either zero or 144 one instance of the Clearance attribute. If the Clearance attribute 145 is present, it must contain a single value. 147 The following object identifier identifies the Clearance attribute 148 (either in the subject directory attributes extension of a PKC or in 149 the Attributes field of an AC): 151 id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 152 ds(5) module(1) selected-attribute-types(5) clearance(55) } 154 The ASN.1 syntax for the Clearance attribute is as follows [PKI-ASN]: 156 Clearance ::= SEQUENCE { 157 policyId OBJECT IDENTIFIER, 158 classList ClassList DEFAULT {unclassified}, 159 securityCategories SET OF SecurityCategory OPTIONAL 160 } 162 ClassList ::= BIT STRING { 163 unmarked (0), 164 unclassified (1), 165 restricted (2), 166 confidential (3), 167 secret (4), 168 topSecret (5) 169 } 171 SECURITY-CATEGORY ::= TYPE-IDENTIFIER 173 SecurityCategory ::= SEQUENCE { 174 type [0] 175 TYPE-IDENTIFIER.&id({SupportedSecurityCategories}), 176 value [1] 177 EXPLICIT TYPE-IDENTIFIER.&Type 178 ({SupportedSecurityCategories}{@type}) 179 } 181 The Clearance attribute takes its meaning from Section 4.4.6 of 182 [RFC3281], which is repeated here for convenience: 184 - policyId identifies the security policy to which the clearance 185 relates. The policyId indicates the semantics of the classList 186 and securityCategory fields. 188 - classlist identifies the security classifications. Six basic 189 values are defined in bit positions 0 through 5 and more may be 190 defined by an organizational security policy. 192 - securityCategories provides additional authorization information. 194 If a trust anchor's public key is used directly, then the Clearance 195 associated with the trust anchor, if any, should be used as the 196 effective clearance (also defined as effective-clearance for a 197 certification path). 199 3. Authority Clearance Constraints Certificate Extension 201 The Authority Clearance Constraints certificate extension indicates 202 to the relying party what clearances should be acceptable for the 203 subject of the AC or the subject of the last certificate in a PKC 204 certification path. It is only meaningful in trust anchor, CA PKCs, 205 or AA PKCs. A trust anchor, CA PKC, or AA PKC MUST include either 206 zero or one instance of the Authority Clearance Constraints 207 certificate extension. The Authority Clearance Constraints 208 certificate extension MAY be critical or non-critical. 210 Absence of this certificate extension in a TA, in a CA PKC, or in an 211 AA PKC indicates that clearance of the subject of the AC or the 212 subject of the last certificate in a PKC certification path 213 containing the TA, the CA or the AA is not constrained by the 214 respective TA, CA or AA. 216 The following object identifier identifies the Authority Clearance 217 Constraints certificate extension: 219 id-ce-authorityClearanceConstraints OBJECT IDENTIFIER ::= { 220 id-TBSL } 222 The ASN.1 syntax for the Authority Clearance Constraints certificate 223 extension is as follows: 225 AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF 226 Clearance 228 The syntax for Authority Clearance Constraints certificate extension 229 contains Clearance values that the CA or the AA asserts. The 230 sequence MUST NOT include more than one entry with the same policyId. 232 This constraint is enforced during Clearance and Authority Clearance 233 Constraints Processing described below. If more than one entry with 234 the same policyId is present in AuthorityClearanceConstraints 235 certificate extension, the certification path is rejected. In 236 addition, each Clearance attribute in the SEQUENCE must not contain 237 more than one value. 239 4. Clearance and Authority Clearance Constraints Processing in PKC 241 This section describes the processing of certification path when 242 Clearance is asserted in PKC. 244 Authority Clearance Constraints certificate extension and Clearance 245 attribute processing determines the effective clearance (henceforth 246 called effective-clearance) for the end PKC. Authority Clearance 247 Constraints certificate extension in the TA and in each PKC up to but 248 not including the end PKC in a PKC certification path impact the 249 effective-clearance. If there is more than one path to the end- 250 entity PKC, each path is processed independently. The process 251 involves two steps: 253 1) collecting the Authority Clearance Constraints; and 255 2) using Authority Clearance Constraints in the certification path 256 and the Clearance in the end PKC to determine the effective- 257 clearance for the subject of the end PKC. 259 Assuming a certification path consisting of n PKCs, the effective- 260 clearance for the subject of the end PKC is the intersection of 261 Clearance attribute in the subject PKC, Authority Clearance 262 Constraints, if present, in trust anchor and all Authority Clearance 263 Constraints present in intermediate PKCs. Any effective-clearance 264 calculation algorithm that performs this calculation and provides the 265 same outcome as the one from the algorithm described herein is 266 considered compliant with the requirements of this RFC. 268 When processing a certification path, Authority Clearance Constraints 269 are maintained in one state variable: permitted-clearances. When 270 processing begins, permitted-clearances is initialized to the special 271 value all-clearances if Authority Clearance Constraints certificate 272 extension is not present in or associated with the trust anchor, 273 otherwise this value is initialized to Authority Clearance 274 Constraints associated with the trust anchor. The permitted- 275 clearances state variable is updated each time an intermediate PKC 276 that contains an Authority Clearance Constraints certificate 277 extension in the path is processed. 279 When processing the end PKC, the value in the Clearance attribute in 280 the end PKC is intersected with the permitted-clearances state 281 variable. 283 The output of Clearance attribute and Authority Clearance Constraint 284 certificate extensions processing is the effective-clearance, which 285 could also be an empty list; and success or failure with reason code 286 for failure. 288 4.1. Collecting Constraints 290 Authority Clearance Constraints are collected from the trust anchor 291 and the intermediate PKCs in a certification path. 293 4.1.1. Certification Path Processing 295 When processing Authority Clearance Constraints certificate extension 296 for the purposes of validating Clearance attribute in the end PKC, 297 the processing described in this section or an equivalent algorithm 298 MUST be included in the certification path validation. The 299 processing is presented as additions to the certification path 300 validation algorithm described in section 6 of [RFC5280]. 302 4.1.1.1. Inputs 304 Trust anchor information may include the 305 AuthorityClearanceConstraints structure to specify Authority 306 Clearance Constraints for the trust anchor. The trust anchor may be 307 constrained or unconstrained. 309 4.1.1.2. Initialization 311 Examine the trust anchor information and verify that it does not 312 contain more than one instance of AuthorityClearanceConstraints 313 extension. If the trust anchor information contains more than one 314 instance of AuthorityClearanceConstraints extension, set effective- 315 clearance to an empty list, set error code to "multiple extension 316 instances", and exit with failure. 318 If any of the Clearance attributes in the 319 AuthorityClearanceConstraints extension contains more than one value, 320 set effective-clearance to an empty list, set error code to "multiple 321 values", and exit with failure. 323 Create a state variable named permitted-clearances. If the trust 324 anchor contains an AuthorityClearanceConstraints extension, then the 325 initial value of permitted-clearances is the 326 AuthorityClearanceConstraints extension from the trust anchor. 328 Examine the permitted-clearances for the same Policy ID appearing 329 more then once. If a policyID appears more than once in the 330 permitted-clearances state variable, set effective-clearance to an 331 empty list, set error code to "multiple instances of same clearance", 332 and exit with failure. 334 If the trust anchor does not contain an AuthorityClearanceConstraints 335 extension, the permitted-clearances variable is assigned the special 336 value all-clearances. 338 4.1.1.3. Basic Certificate Processing 340 If the PKC is the last PKC (i.e., certificate n), skip the steps 341 listed in this section. 343 Examine the PKC and verify that it does not contain more than one 344 instance of AuthorityClearanceConstraints extension. If the PKC 345 contains more than one instance of AuthorityClearanceConstraints 346 extension, set effective-clearance to an empty list, set error code 347 to "multiple extension instances", and exit with failure. 349 If any of the Clearance attributes in the 350 AuthorityClearanceConstraints extension contains more than one value, 351 set effective-clearance to an empty list, set error code to "multiple 352 values", and exit with failure. 354 If the AuthorityClearanceConstraints certificate extension is not 355 present in the PKC, no action is taken, and the permitted-clearances 356 value is unchanged. 358 If the AuthorityClearanceConstraints certificate extension is present 359 in the PKC, set the variable temp-clearances to 360 AuthorityClearanceConstraints certificate extension. Examine the 361 temp-clearances for the same Policy ID appearing more then once. If 362 a policyID appears more than once in the temp-clearances state 363 variable, set effective-clearance to an empty list, set error code to 364 "multiple instances of same clearance", and exit with failure. 366 If the AuthorityClearanceConstraints certificate extension is present 367 in the PKC and permitted-clearances contains the all-clearances 368 special value, then assign permitted-clearances the value of the 369 temp-clearances. 371 If the AuthorityClearanceConstraints certificate extension is present 372 in the PKC and permitted-clearances does not contain the all- 373 clearances special value, take the intersection of temp-clearances 374 and permitted-clearances by repeating the following steps for each 375 clearance in the permitted-clearances state variable: 377 - If the policyID associated with the clearance is absent in the 378 temp-clearances, delete the clearance structure associated with 379 the policyID from the permitted-clearances state variable. 381 - If the policyID is present in the temp-clearances: 383 -- For every classList bit, assign the classList bit a value of 384 one (1) for the policyID in permitted-clearances state 385 variable if the bit is one (1) in both the permitted- 386 clearances state variable and the temp-clearances for that 387 policyID; otherwise assign the bit a value of zero (0). 389 -- If no bits are one (1) for the classList, delete the clearance 390 structure associated with the policyID from the permitted- 391 clearances state variable and skip the next step of processing 392 securityCategories. 394 -- For the policyID in permitted-clearances, set the 395 securityCategories to the intersection of securityCategories 396 for the policyID in permitted-clearances and in temp- 397 clearances using the algorithm described in Section 6. Note 398 that an empty SET is represented by simply omitting the SET. 400 4.1.1.4. Preparation for Certificate i+1 402 No additional action associated with the Clearance attribute or 403 AuthorityClearanceConstraints certificate extensions is taken during 404 this phase of certification path validation as described in section 6 405 of [RFC5280]. 407 4.1.1.5. Wrap-up Procedure 409 To complete the processing, perform the following steps for the last 410 PKC (i.e., certificate n). 412 Examine the PKC and verify that it does not contain more than one 413 instance of Clearance attribute. If the PKC contains more than one 414 instance of Clearance attribute, set effective-clearance to an empty 415 list, set error code to "multiple instances of an attribute", and 416 exit with failure. 418 If the Clearance attribute is not present in the end PKC, set 419 effective-clearance to an empty list and exit with success. 421 Set effective-clearance to the Clearance attribute in the end PKC. 423 4.1.1.5.1. Wrap Up Clearance 425 Examine effective-clearance and verify that it does not contain more 426 than one value. If effective-clearance contains more than one value, 427 set effective-clearance to an empty list, set error code to "multiple 428 values", and exit with failure. 430 Let us say policyID in effective-clearance is X. 432 If permitted-clearances is an empty list, set effective-clearance to 433 an empty list and exit with success. 435 If the permitted-clearances has special value of all-clearances, exit 436 with success. 438 If the policyID X in effective-clearance is absent from the 439 permitted-clearances, set effective-clearance to an empty list and 440 exit with success. 442 Assign those classList bits in effective-clearance a value of one (1) 443 that have a value of one (1) both in effective-clearance and in the 444 clearance structure in permitted-clearances associated with policyID 445 X. Assign all other classList bits in effective-clearance a value of 446 zero (0). 448 If none of the classList bits have a value of one (1) in effective- 449 clearance, set effective-clearance to an empty list and exit with 450 success. 452 Set the securityCategories in effective-clearance to the intersection 453 of securityCategories in effective-clearance and in permitted- 454 clearances using the algorithm described in Section 6. Note that 455 empty an SET is represented by simply omitting the SET. 457 Exit with Success 459 4.1.1.6. Outputs 461 If certification path validation processing succeeds, effective- 462 clearance contains the effective clearance for the subject of the 463 certification path. Processing also returns success or failure 464 indication and reason for failure, if applicable. 466 5. Clearance and Authority Clearance Constraints Processing in AC 468 This section describes the processing of certification path when 469 Clearance is asserted in an AC. Relevant to processing are: one TA; 470 0 or more CA PKCs; 0 or 1 AA PKC; and 1 AC. 472 Authority Clearance Constraints certificate extension and Clearance 473 attribute processing determines the effective clearance (henceforth 474 called effective-clearance) for the AC. Authority Clearance 475 Constraints certificate extension in the TA and in each PKC up to and 476 including the AA PKC in a certification path impact the effective- 477 clearance. If there is more than one path to the AA PKC, each path 478 is processed independently. The process involves two steps: 480 1) collecting the Authority Clearance Constraints; and 482 2) using Authority Clearance Constraints in the PKC certification 483 path and the Clearance in the AC to determine the effective- 484 clearance for the subject of the AC. 486 The effective-clearance for the subject of the AC is the intersection 487 of Clearance in the subject AC, Authority Clearance Constraints, if 488 present, in trust anchor and all Authority Clearance Constraints 489 present in PKC certification path from the TA to the AA. Any 490 effective-clearance calculation algorithm that performs this 491 calculation and provides the same outcome as the one from the 492 algorithm described herein is considered compliant with the 493 requirements of this RFC. 495 Authority Clearance Constraints is maintained in one state variable: 496 permitted-clearances. When processing begins, permitted-clearances 497 is initialized to the special value all-clearances if Authority 498 Clearance Constraints certificate extension is not present in or 499 associated with the trust anchor, otherwise this value is initialized 500 to Authority Clearance Constraints associated with the trust anchor. 501 The permitted-clearances state variable is updated each time a PKC 502 (other than AC holder PKC) that contains an Authority Clearance 503 Constraints certificate extension in the path is processed. 505 When processing the AC, the value in the Clearance attribute in the 506 AC is intersected with the permitted-clearances state variable. 508 The output of Clearance and Authority Clearance Constraint 509 certificate extensions processing is the effective-clearance, which 510 could also be an empty list; and success or failure with reason code 511 for failure. 513 5.1. Collecting Constraints 515 Authority Clearance Constraints are collected from the trust anchor 516 and all the PKCs in a PKC certification path. 518 5.1.1. Certification Path Processing 520 When processing Authority Clearance Constraints certificate extension 521 for the purposes of validating Clearance in the AC, the processing 522 described in this section or an equivalent algorithm MUST be included 523 in the certification path validation. The processing is presented as 524 additions to the PKC certification path validation algorithm 525 described in section 6 of [RFC5280] for the AA PKC certification path 526 and the algorithm described in section 5 of [RFC3281] for the AC 527 validation. 529 5.1.1.1. Inputs 531 Same as Section 4.1.1.1. 533 In addition, let us assume that the PKC certification path for the AA 534 consists of n certificates. 536 5.1.1.2. Initialization 538 Same as Section 4.1.1.2. 540 5.1.1.3. Basic PKC Processing 542 Same as Section 4.1.1.3. except that the logic is applied to all n 543 PKCs. 545 5.1.1.4. Preparation for Certificate i+1 547 Same as Section 4.1.1.4. 549 5.1.1.5. Wrap-up Procedure 551 To complete the processing, perform the following steps for the AC. 553 Examine the AC and verify that it does not contain more than one 554 instance of Clearance attribute. If the AC contains more than one 555 instance of Clearance attribute, set effective-clearance to an empty 556 list, set error code to "multiple instances of an attribute", and 557 exit with failure. 559 If the Clearance attribute is not present in the AC, set effective- 560 clearance to an empty list and exit with success. 562 Set effective-clearance to the Clearance attribute in the AC. 564 5.1.1.5.1. Wrap Up Clearance 566 Same as Section 4.1.1.5.1. 568 5.1.1.6. Outputs 570 Same as Section 4.1.1.6. 572 In addition, apply AC processing rules described in Section 5 of 573 [RFC3281]. 575 6. Computing Intersection of securityCategories 577 This section describes how to compute the intersection of 578 securityCategories A and B. It uses the state variable temp-set. 580 Set the SET temp-set to empty. 582 If SET A is empty (i.e., securityCategories is absent), return temp- 583 set. 585 If SET B is empty (i.e., securityCategories is absent), return temp- 586 set. 588 For every element (i.e., securityCategory) in the SET A carry out the 589 following steps: 591 1. If there is no element in SET B with the same Type OID as the 592 type OID in the element from SET A, go to step 6. 594 2. If there is an element in SET B with the same Type OID and value 595 as in the element in SET A, carry out the following steps: 597 a) Add an element containing the Type OID and the value to the 598 SET temp-set. 600 b) Delete all elements with the same Type OID and the same 601 value from the SET B. 603 c) Go to step 6. 605 3. If the processing semantics of Type OID in the element in SET A 606 is not known, go to step 6. 608 4. Perform Type OID specific intersection of the value in the 609 element in SET A with the values in the applicable elements in 610 SET B with the same Type OID. 612 5. If the intersection is not empty, add and element containing the 613 Type OID and intersection result as value to temp-set. 615 6. If more elements remain in SET A, process the next element 616 starting with step 1. 618 Return temp-set. 620 7. Recommended securityCategories 622 This RFC also include a recommended securityCategories as follows: 624 SecurityCategory ::= SEQUENCE { 625 type [0] OID id-TBSL, 626 value [1] BIT STRING 627 } 629 Note that Type specific intersection of two values for this Type will 630 be simply setting the bits that are set in both values. If the 631 resulting intersection has none of the bits set, the intersection is 632 considered empty. 634 8. Security Considerations 636 Certificate issuers must recognize that absence of the 637 AuthorityClearanceConstraints in a CA or AA certificate means that in 638 terms of the clearance, the subject Authority is not constrained. 640 Absence of Clearance attribute in a certificate means that the 641 subject has not been assigned any clearance. 643 If there is no Clearance associated with a TA, it means that the TA 644 has not been assigned any clearance. 646 If the local security policy considers the clearance held by a 647 subject or those supported by a CA or AA to be sensitive, then the 648 Clearance attribute or Authority Clearance Constraints should only be 649 included if the subject's and Authority's certificate can be privacy 650 protected. Also in this case, distribution of trust anchors and 651 associated Authority Clearance Constraints extension or Clearance 652 must also be privacy protected. 654 9. IANA Considerations 656 None. Please remove this section prior to publication as an RFC. 658 10. References 660 10.1. Normative References 662 [PKI-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for PKIX", 663 draft-ietf-pkix-new-asn1, work-in-progress. 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, March 1997. 668 [RFC3281] Farrell, S., and Housley, R., "An Internet Attribute 669 Certificate Profile for Authorization", RFC 3281, April 670 2002. 672 [3281bis] Farrell, S., Housely, R., and S. Turner, "An Internet 673 Attribute Certificate Profile for Authorization: Update", 674 draft-ietf-pkix-3281update-01, work-in-progress. 676 [RFC5280] Cooper, D. et. al., "Internet X.509 Public Key 677 Infrastructure Certificate and Certification Revocation 678 List (CRL) Profile", RFC 5280, May 2008. 680 [X.680] ITU-T Recommendation X.680 (2004) | ISO/IEC 8824-1:2004. 681 Information Technology - Abstract Syntax Notation One. 683 10.2. Informative References 685 [RFC3114] Nicolls, W., "Implementing Company Classification Policy 686 with S/MIME Security Label", RFC3114, May 2002. 688 [RFC3739] Santesson, S. et. al., "Internet X.509 Public Key 689 Infrastructure: Qualified Certificate Profile", RFC 3739, 690 March 2004. 692 Appendix A. ASN.1 Module 694 This appendix provides the normative ASN.1 definitions for 695 the structures described in this specification using ASN.1 as defined 696 in X.680. 698 Clearance-AuthorityClearanceConstraints93 { id-TBSL } 700 DEFINITIONS IMPLICIT TAGS ::= 702 BEGIN 704 -- EXPORTS ALL -- 706 IMPORTS 708 -- IMPORTS from [PKI-ASN] 710 id-at-clearance, Clearance 711 FROM PKIXAttributeCertificate 712 { iso(1) identified-organization(3) dod(6) internet(1) 713 security(5) mechanisms(5) pkix(7) id-mod(0) 714 id-mod-attribute-cert(12) 715 } 717 -- IMPORTS from [PKI-ASN] 719 EXTENSION 720 FROM PKIX-CommonTypes 721 { iso(1) identified-organization(3) dod(6) internet(1) 722 security(5) mechanisms(5) pkix(7) id-mod(0) 723 id-mod-pkixCommon(43) 724 } 725 ; 727 -- Clearance attribute OID and syntax 729 -- The following is a '93 version for clearance. 730 -- It is included for convenience. 732 -- id-at-clearance OBJECT IDENTIFIER ::= 733 -- { joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 734 -- clearance (55) 735 -- } 736 -- Clearance ::= SEQUENCE { 737 -- policyId OBJECT IDENTIFIER, 738 -- classList ClassList DEFAULT {unclassified}, 739 -- securityCategories SET OF SecurityCategory OPTIONAL 740 -- } 742 -- ClassList ::= BIT STRING { 743 -- unmarked (0), 744 -- unclassified (1), 745 -- restricted (2), 746 -- confidential (3), 747 -- secret (4), 748 -- topSecret (5) 749 -- } 751 -- SECURITY-CATEGORY ::= TYPE-IDENTIFIER 753 -- SecurityCategory ::= SEQUENCE { 754 -- type [0] 755 -- TYPE-IDENTIFIER.&id({SupportedSecurityCategories}), 756 -- value [1] 757 -- EXPLICIT TYPE-IDENTIFIER.&Type 758 -- ({SupportedSecurityCategories}{@type}) 759 -- } 761 -- Authority Clearance Constraints certificate extension OID 762 -- and syntax 764 id-ce-authorityClearanceConstraints OBJECT IDENTIFIER ::= { id-TBSL } 766 authorityClearanceConstraints EXTENSION ::= { 767 SYNTAX AuthorityClearanceConstraints 768 IDENTIFIED BY id-ce-AuthorityClearanceConstraints 769 } 771 AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance 773 END 775 Author's Addresses 777 Sean Turner 779 IECA, Inc. 780 3057 Nutley Street, Suite 106 781 Fairfax, VA 22031 782 USA 784 EMail: turners@ieca.com 786 Santosh Chokhani 787 CygnaCom Solutions, Inc. 789 Email: SChokhani@cygnacom.com 791 Full Copyright Statement 793 Copyright (C) The IETF Trust (2008). 795 This document is subject to the rights, licenses and restrictions 796 contained in BCP 78, and except as set forth therein, the authors 797 retain all their rights. 799 This document and the information contained herein are provided on an 800 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 801 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 802 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 803 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 804 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 805 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 807 Intellectual Property 809 The IETF takes no position regarding the validity or scope of any 810 Intellectual Property Rights or other rights that might be claimed to 811 pertain to the implementation or use of the technology described in 812 this document or the extent to which any license under such rights 813 might or might not be available; nor does it represent that it has 814 made any independent effort to identify any such rights. Information 815 on the procedures with respect to rights in RFC documents can be 816 found in BCP 78 and BCP 79. 818 Copies of IPR disclosures made to the IETF Secretariat and any 819 assurances of licenses to be made available, or the result of an 820 attempt made to obtain a general license or permission for the use of 821 such proprietary rights by implementers or users of this 822 specification can be obtained from the IETF on-line IPR repository at 823 http://www.ietf.org/ipr. 825 The IETF invites any interested party to bring to its attention any 826 copyrights, patents or patent applications, or other proprietary 827 rights that may cover technology that may be required to implement 828 this standard. Please address the information to the IETF at 829 ietf-ipr@ietf.org. 831 Acknowledgment 833 Funding for the RFC Editor function is provided by the IETF 834 Administrative Support Activity (IASA).