idnits 2.17.00 (12 Aug 2021) /tmp/idnits44183/draft-ietf-pkix-authorityclearanceconstraints-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 (March 4, 2009) is 4825 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 786 -- Looks like a reference, but probably isn't: '1' on line 788 == 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') == Outdated reference: draft-ietf-pkix-3281update has been published as RFC 5755 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 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: September 4, 2009 March 4, 2009 7 Clearance Attribute and Authority Clearance Constraints 8 Certificate Extension 9 draft-ietf-pkix-authorityclearanceconstraints-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on September 4, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document defines the syntax and semantics for the Clearance 48 attribute and the Authority Clearance Constraints extension in X.509 49 certificates. The Clearance attribute is used to indicate the 50 clearance held by the subject. The Clearance attribute may appear in 51 the subject directory attributes extension of a public key 52 certificate or in the attributes field of an attribute certificate. 53 The Authority Clearance Constraints certificate extension values in a 54 Trust Anchor (TA), CA public key certificates, and an Attribute 55 Authority (AA) public key certificate in a public key certification 56 path constrain the effective Clearance of the subject. 58 Table of Contents 60 1. Introduction...................................................3 61 1.1. Terminology...............................................4 62 1.2. ASN.1 Syntax Notation.....................................4 63 2. Clearance Attribute............................................4 64 3. Authority Clearance Constraints Certificate Extension..........5 65 4. Clearance and Authority Clearance Constraints Processing in 66 PKC............................................................6 67 4.1. Collecting Constraints....................................7 68 4.1.1. Certification Path Processing........................7 69 4.1.1.1. Inputs..........................................8 70 4.1.1.2. Initialization..................................8 71 4.1.1.3. Basic Certificate Processing....................8 72 4.1.1.4. Preparation for Certificate i+1.................9 73 4.1.1.5. Wrap-up Procedure...............................9 74 4.1.1.5.1. Wrap Up Clearance..........................9 75 4.1.1.6. Outputs........................................10 76 5. Clearance and Authority Clearance Constraints Processing in 77 AC............................................................10 78 5.1. Collecting Constraints...................................11 79 5.1.1. Certification Path Processing.......................11 80 5.1.1.1. Inputs.........................................11 81 5.1.1.2. Initialization.................................11 82 5.1.1.3. Basic PKC Processing...........................12 83 5.1.1.4. Preparation for Certificate i+1................12 84 5.1.1.5. Wrap-up Procedure..............................12 85 5.1.1.5.1. Wrap Up Clearance.........................12 86 5.1.1.6. Outputs........................................12 87 6. Computing Intersection of permitted-clearances and 88 AuthorityClearanceConstraints extension.......................12 89 7. Computing Intersection of securityCategories..................14 90 8. Recommended securityCategories................................15 91 9. Security Considerations.......................................15 92 10. IANA Considerations..........................................15 93 11. References...................................................15 94 11.1. Normative References....................................15 95 11.2. Informative References..................................16 96 Appendix A. ASN.1 Module.........................................17 97 Author's Addresses...............................................19 99 1. Introduction 101 Organizations that have implemented a security policy can issue 102 certificates that include an indication of the clearance values held 103 by the subject. The Clearance attribute indicates the security 104 policy, the clearance levels held by the subject, and additional 105 authorization information held by the subject. This specification 106 makes use of the ASN.1 syntax for clearance from [3281bis]. 108 Clearance attribute may be placed in the subject directory attributes 109 extension of a PKC or may be placed in a separate attribute 110 certificate (AC). 112 The placement of Clearance attribute in PKCs is desirable when the 113 credentials such as PKCs need to be revoked when the clearance 114 information changes or when clearance information is relatively 115 static, and clearance information can be verified as part of PKC 116 issuance process (e.g., using local databases). The placement of 117 Clearance attribute in PKCs may also be made to simplify the 118 infrastructure, to reduce the infrastructure design cost, or to 119 reduce the infrastructure operations cost. An example of placement 120 of Clearance attribute in PKCs in operational PKI is the Defense 121 Messaging Service. An example of placement of attributes in PKCs is 122 Qualified Certificates [RFC3739]. 124 The placement of Clearance attribute in ACs is desirable when the 125 clearance information is relatively dynamic and changes in the 126 clearance information does not require revocation of credentials such 127 as PKCs, or the clearance information can not be verified as part of 128 PKC issuance process. 130 Since [3281bis] does not permit chain of ACs, the Authority 131 Clearance Constraints extension may only appear in the PKCs of CA or 132 AA. The Authority Clearance Constraints extension may also appear 133 in a TA or may be associated with a TA. 135 Some organizations have multiple TAs, CAs, and/or AAs and these 136 organizations may wish to indicate to relying parties which clearance 137 values from a particular TA, CA, or AA should be accepted. For 138 example, consider the security policies described in [RFC3114], where 139 a security policy has been defined for Amoco with three security 140 classification values (HIGHLY CONFIDENTIAL, CONFIDENTIAL, and 141 GENERAL). To constrain a CA for just one security classification, the 142 Authority Clearance Constraints certificate extension would be 143 included in the CA's PKC. 145 Cross-certified domains can also make use of the Authority Clearance 146 Constraints certificate extension to indicate which clearance values 147 should be acceptable to relying parties. 149 1.1. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 1.2. ASN.1 Syntax Notation 157 All X.509 PKC [RFC5280] extensions are defined using ASN.1 [X.680]. 158 All X.509 AC [3281bis] extensions are defined using ASN.1 [X.680]. 160 2. Clearance Attribute 162 The Clearance attribute in a certificate indicates the clearances 163 held by the subject. It uses the clearance attribute syntax from 164 Section 4.4.6 of [3281bis], which is included below for convenience, 165 in the Attributes field. A certificate MUST include either zero or 166 one instance of the Clearance attribute. If the Clearance attribute 167 is present, it must contain a single value. 169 The following object identifier identifies the Clearance attribute 170 (either in the subject directory attributes extension of a PKC or in 171 the Attributes field of an AC): 173 id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) 174 ds(5) attributeTypes(5) clearance(55) } 176 The ASN.1 syntax for the Clearance attribute is as follows [PKI-ASN]: 178 Clearance ::= SEQUENCE { 179 policyId OBJECT IDENTIFIER, 180 classList ClassList DEFAULT {unclassified}, 181 securityCategories SET OF SecurityCategory OPTIONAL 182 } 183 ClassList ::= BIT STRING { 184 unmarked (0), 185 unclassified (1), 186 restricted (2), 187 confidential (3), 188 secret (4), 189 topSecret (5) 190 } 192 SECURITY-CATEGORY ::= TYPE-IDENTIFIER 194 SecurityCategory ::= SEQUENCE { 195 type [0] 196 TYPE-IDENTIFIER.&id({SupportedSecurityCategories}), 197 value [1] 198 EXPLICIT TYPE-IDENTIFIER.&Type 199 ({SupportedSecurityCategories}{@type}) 200 } 202 The Clearance attribute takes its meaning from Section 4.4.6 of 203 [3281bis], which is repeated here for convenience: 205 - policyId identifies the security policy to which the clearance 206 relates. The policyId indicates the semantics of the classList 207 and securityCategory fields. 209 - classlist identifies the security classifications. Six basic 210 values are defined in bit positions 0 through 5 and more may be 211 defined by an organizational security policy. 213 - securityCategories provides additional authorization information. 215 If a trust anchor's public key is used directly, then the Clearance 216 associated with the trust anchor, if any, should be used as the 217 effective clearance (also defined as effective-clearance for a 218 certification path). 220 3. Authority Clearance Constraints Certificate Extension 222 The Authority Clearance Constraints certificate extension indicates 223 to the relying party what clearances should be acceptable for the 224 subject of the AC or the subject of the last certificate in a PKC 225 certification path. It is only meaningful in trust anchor, CA PKCs, 226 or AA PKCs. A trust anchor, CA PKC, or AA PKC MUST include either 227 zero or one instance of the Authority Clearance Constraints 228 certificate extension. The Authority Clearance Constraints 229 certificate extension MAY be critical or non-critical. 231 Absence of this certificate extension in a TA, in a CA PKC, or in an 232 AA PKC indicates that clearance of the subject of the AC or the 233 subject of the last certificate in a PKC certification path 234 containing the TA, the CA or the AA is not constrained by the 235 respective TA, CA or AA. 237 The following object identifier identifies the Authority Clearance 238 Constraints certificate extension: 240 id-pe-authorityClearanceConstraints OBJECT IDENTIFIER ::= { 241 iso(1) identified-organization(3) dod(6) internet(1) security(5) 242 mechanisms(5) pkix(7) pe(1) 21 } 244 The ASN.1 syntax for the Authority Clearance Constraints certificate 245 extension is as follows: 247 AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF 248 Clearance 250 The syntax for Authority Clearance Constraints certificate extension 251 contains Clearance values that the CA or the AA asserts. The 252 sequence MUST NOT include more than one entry with the same policyId. 253 This constraint is enforced during Clearance and Authority Clearance 254 Constraints Processing described below. If more than one entry with 255 the same policyId is present in AuthorityClearanceConstraints 256 certificate extension, the certification path is rejected. In 257 addition, each Clearance attribute in the SEQUENCE must not contain 258 more than one value. 260 4. Clearance and Authority Clearance Constraints Processing in PKC 262 This section describes the processing of certification path when 263 Clearance is asserted in PKC. 265 User input, Authority Clearance Constraints certificate extension, 266 and Clearance attribute processing determines the effective clearance 267 (henceforth called effective-clearance) for the end PKC. User input, 268 Authority Clearance Constraints certificate extension in the TA and 269 in each PKC up to but not including the end PKC in a PKC 270 certification path impact the effective-clearance. If there is more 271 than one path to the end-entity PKC, each path is processed 272 independently. The process involves two steps: 274 1) collecting the Authority Clearance Constraints; and 275 2) using Authority Clearance Constraints in the certification path 276 and the Clearance in the end PKC to determine the effective- 277 clearance for the subject of the end PKC. 279 Assuming a certification path consisting of n PKCs, the effective- 280 clearance for the subject of the end PKC is the intersection of 281 Clearance attribute in the subject PKC, Authority Clearance 282 Constraints, if present, in trust anchor, user input, and all 283 Authority Clearance Constraints present in intermediate PKCs. Any 284 effective-clearance calculation algorithm that performs this 285 calculation and provides the same outcome as the one from the 286 algorithm described herein is considered compliant with the 287 requirements of this RFC. 289 When processing a certification path, Authority Clearance Constraints 290 are maintained in one state variable: permitted-clearances. When 291 processing begins, permitted-clearances is initialized to the user 292 input value or special value all-clearances if Authority Clearance 293 Constraints user input is not provided. The permitted-clearances 294 state variable is updated by first processing Authority Clearance 295 Constraints associated with the trust anchor, and then each time an 296 intermediate PKC that contains an Authority Clearance Constraints 297 certificate extension in the path is processed. 299 When processing the end PKC, the value in the Clearance attribute in 300 the end PKC is intersected with the permitted-clearances state 301 variable. 303 The output of Clearance attribute and Authority Clearance Constraint 304 certificate extensions processing is the effective-clearance, which 305 could also be an empty list; and success or failure with reason code 306 for failure. 308 4.1. Collecting Constraints 310 Authority Clearance Constraints are collected from the user input, 311 the trust anchor and the intermediate PKCs in a certification path. 313 4.1.1. Certification Path Processing 315 When processing Authority Clearance Constraints certificate extension 316 for the purposes of validating Clearance attribute in the end PKC, 317 the processing described in this section or an equivalent algorithm 318 MUST be included in the certification path validation. The 319 processing is presented as additions to the certification path 320 validation algorithm described in section 6 of [RFC5280]. Note that 321 this RFC is fully consistent with [RFC5280]; however, it augments 322 [RFC5280] with the following steps: 324 . Ability to provide and process Authority Clearance Constraints 325 as an additional input to the certification path processing 326 engine 328 . Requirement to process Authority Clearance Constraints present 329 with Trust anchor information. 331 4.1.1.1. Inputs 333 User input may include AuthorityClearanceConstraints structure or 334 omit it. 336 Trust anchor information may include the 337 AuthorityClearanceConstraints structure to specify Authority 338 Clearance Constraints for the trust anchor. The trust anchor may be 339 constrained or unconstrained. 341 4.1.1.2. Initialization 343 If user input includes AuthorityClearanceConstraints, set the 344 permitted-clearances to the input value, otherwise,, set the 345 permitted-clearances to special value all-clearances. 347 If any of the Clearance attributes in the permitted-clearances 348 contains more than one value, set effective-clearance to an empty 349 list, set error code to "multiple values in input", and exit with 350 failure. 352 Examine the permitted-clearances for the same Policy ID appearing 353 more then once. If a policyID appears more than once in the 354 permitted-clearances state variable, set effective-clearance to an 355 empty list, set error code to "multiple instances of same clearance", 356 and exit with failure. 358 If the trust anchor does not contain an AuthorityClearanceConstraints 359 extension, continue at Section 4.1.1.3. Otherwise, execute the 360 procedure described in Section 6 as an in-line macro by treating the 361 trust anchor as a PKC. 363 4.1.1.3. Basic Certificate Processing 365 If the PKC is the last PKC (i.e., certificate n), skip the steps 366 listed in this section. Otherwise, execute the procedure described 367 in Section 6. as an in-line macro. 369 4.1.1.4. Preparation for Certificate i+1 371 No additional action associated with the Clearance attribute or 372 AuthorityClearanceConstraints certificate extensions is taken during 373 this phase of certification path validation as described in section 6 374 of [RFC5280]. 376 4.1.1.5. Wrap-up Procedure 378 To complete the processing, perform the following steps for the last 379 PKC (i.e., certificate n). 381 Examine the PKC and verify that it does not contain more than one 382 instance of Clearance attribute. If the PKC contains more than one 383 instance of Clearance attribute, set effective-clearance to an empty 384 list, set error code to "multiple instances of an attribute", and 385 exit with failure. 387 If the Clearance attribute is not present in the end PKC, set 388 effective-clearance to an empty list and exit with success. 390 Set effective-clearance to the Clearance attribute in the end PKC. 392 4.1.1.5.1. Wrap Up Clearance 394 Examine effective-clearance and verify that it does not contain more 395 than one value. If effective-clearance contains more than one value, 396 set effective-clearance to an empty list, set error code to "multiple 397 values", and exit with failure. 399 Let us say policyID in effective-clearance is X. 401 If permitted-clearances is an empty list, set effective-clearance to 402 an empty list and exit with success. 404 If the permitted-clearances has special value of all-clearances, exit 405 with success. 407 If the policyID X in effective-clearance is absent from the 408 permitted-clearances, set effective-clearance to an empty list and 409 exit with success. 411 Assign those classList bits in effective-clearance a value of one (1) 412 that have a value of one (1) both in effective-clearance and in the 413 clearance structure in permitted-clearances associated with policyID 414 X. Assign all other classList bits in effective-clearance a value of 415 zero (0). 417 If none of the classList bits have a value of one (1) in effective- 418 clearance, set effective-clearance to an empty list and exit with 419 success. 421 Set the securityCategories in effective-clearance to the intersection 422 of securityCategories in effective-clearance and in permitted- 423 clearances using the algorithm described in Section 6. Note that 424 empty an SET is represented by simply omitting the SET. 426 Exit with Success 428 4.1.1.6. Outputs 430 If certification path validation processing succeeds, effective- 431 clearance contains the effective clearance for the subject of the 432 certification path. Processing also returns success or failure 433 indication and reason for failure, if applicable. 435 5. Clearance and Authority Clearance Constraints Processing in AC 437 This section describes the processing of certification path when 438 Clearance is asserted in an AC. Relevant to processing are: one TA; 439 0 or more CA PKCs; 0 or 1 AA PKC; and 1 AC. 441 User input, Authority Clearance Constraints certificate extension and 442 Clearance attribute processing determines the effective clearance 443 (henceforth called effective-clearance) for the AC. User input, 444 Authority Clearance Constraints certificate extension in the TA and 445 in each PKC up to and including the AA PKC in a certification path 446 impact the effective-clearance. If there is more than one path to 447 the AA PKC, each path is processed independently. The process 448 involves two steps: 450 1) collecting the Authority Clearance Constraints; and 452 2) using Authority Clearance Constraints in the PKC certification 453 path and the Clearance in the AC to determine the effective- 454 clearance for the subject of the AC. 456 The effective-clearance for the subject of the AC is the intersection 457 of Clearance in the subject AC, Authority Clearance Constraints, if 458 present, in trust anchor, user input, and all Authority Clearance 459 Constraints present in PKC certification path from the TA to the AA. 460 Any effective-clearance calculation algorithm that performs this 461 calculation and provides the same outcome as the one from the 462 algorithm described herein is considered compliant with the 463 requirements of this RFC. 465 Authority Clearance Constraints is maintained in one state variable: 466 permitted-clearances. When processing begins, permitted-clearances 467 is initialized to user input or special value all-clearances if 468 Authority Clearance Constraints user input is not provided. The 469 permitted-clearances state variable is updated by first processing 470 Authority Clearance Constraints associated with the trust anchor, and 471 then each time a PKC (other than AC holder PKC) that contains an 472 Authority Clearance Constraints certificate extension in the path is 473 processed. 475 When processing the AC, the value in the Clearance attribute in the 476 AC is intersected with the permitted-clearances state variable. 478 The output of Clearance and Authority Clearance Constraint 479 certificate extensions processing is the effective-clearance, which 480 could also be an empty list; and success or failure with reason code 481 for failure. 483 5.1. Collecting Constraints 485 Authority Clearance Constraints are collected from the user input, 486 the trust anchor and all the PKCs in a PKC certification path. 488 5.1.1. Certification Path Processing 490 When processing Authority Clearance Constraints certificate extension 491 for the purposes of validating Clearance in the AC, the processing 492 described in this section or an equivalent algorithm MUST be included 493 in the certification path validation. The processing is presented as 494 additions to the PKC certification path validation algorithm 495 described in section 6 of [RFC5280] for the AA PKC certification path 496 and the algorithm described in section 5 of [3281bis] for the AC 497 validation. Also see note related to [RFC5280 augmentation in 498 Section 4.1.1. 500 5.1.1.1. Inputs 502 Same as Section 4.1.1.1. 504 In addition, let us assume that the PKC certification path for the AA 505 consists of n certificates. 507 5.1.1.2. Initialization 509 Same as Section 4.1.1.2. 511 5.1.1.3. Basic PKC Processing 513 Same as Section 4.1.1.3. except that the logic is applied to all n 514 PKCs. 516 5.1.1.4. Preparation for Certificate i+1 518 Same as Section 4.1.1.4. 520 5.1.1.5. Wrap-up Procedure 522 To complete the processing, perform the following steps for the AC. 524 Examine the AC and verify that it does not contain more than one 525 instance of Clearance attribute. If the AC contains more than one 526 instance of Clearance attribute, set effective-clearance to an empty 527 list, set error code to "multiple instances of an attribute", and 528 exit with failure. 530 If the Clearance attribute is not present in the AC, set effective- 531 clearance to an empty list and exit with success. 533 Set effective-clearance to the Clearance attribute in the AC. 535 5.1.1.5.1. Wrap Up Clearance 537 Same as Section 4.1.1.5.1. 539 5.1.1.6. Outputs 541 Same as Section 4.1.1.6. 543 In addition, apply AC processing rules described in Section 5 of 544 [3281bis]. 546 6. Computing Intersection of permitted-clearances and 547 AuthorityClearanceConstraints extension 549 Examine the PKC and verify that it does not contain more than one 550 instance of AuthorityClearanceConstraints extension. If the PKC 551 contains more than one instance of AuthorityClearanceConstraints 552 extension, set effective-clearance to an empty list, set error code 553 to "multiple extension instances", and exit with failure. 555 If any of the Clearance attributes in the 556 AuthorityClearanceConstraints extension contains more than one value, 557 set effective-clearance to an empty list, set error code to "multiple 558 values", and exit with failure. 560 If the AuthorityClearanceConstraints certificate extension is not 561 present in the PKC, no action is taken, and the permitted-clearances 562 value is unchanged. 564 If the AuthorityClearanceConstraints certificate extension is present 565 in the PKC, set the variable temp-clearances to 566 AuthorityClearanceConstraints certificate extension. Examine the 567 temp-clearances for the same Policy ID appearing more then once. If 568 a policyID appears more than once in the temp-clearances state 569 variable, set effective-clearance to an empty list, set error code to 570 "multiple instances of same clearance", and exit with failure. 572 If the AuthorityClearanceConstraints certificate extension is present 573 in the PKC and permitted-clearances contains the all-clearances 574 special value, then assign permitted-clearances the value of the 575 temp-clearances. 577 If the AuthorityClearanceConstraints certificate extension is present 578 in the PKC and permitted-clearances does not contain the all- 579 clearances special value, take the intersection of temp-clearances 580 and permitted-clearances by repeating the following steps for each 581 clearance in the permitted-clearances state variable: 583 - If the policyID associated with the clearance is absent in the 584 temp-clearances, delete the clearance structure associated with 585 the policyID from the permitted-clearances state variable. 587 - If the policyID is present in the temp-clearances: 589 -- For every classList bit, assign the classList bit a value of 590 one (1) for the policyID in permitted-clearances state 591 variable if the bit is one (1) in both the permitted- 592 clearances state variable and the temp-clearances for that 593 policyID; otherwise assign the bit a value of zero (0). 595 -- If no bits are one (1) for the classList, delete the clearance 596 structure associated with the policyID from the permitted- 597 clearances state variable and skip the next step of processing 598 securityCategories. 600 -- For the policyID in permitted-clearances, set the 601 securityCategories to the intersection of securityCategories 602 for the policyID in permitted-clearances and in temp- 603 clearances using the algorithm described in Section 7. Note 604 that an empty SET is represented by simply omitting the SET. 606 7. Computing Intersection of securityCategories 608 This section describes how to compute the intersection of 609 securityCategories A and B. It uses the state variable temp-set. 611 Set the SET temp-set to empty. 613 If SET A is empty (i.e., securityCategories is absent), return temp- 614 set. 616 If SET B is empty (i.e., securityCategories is absent), return temp- 617 set. 619 For every element (i.e., securityCategory) in the SET A carry out the 620 following steps: 622 1. If there is no element in SET B with the same Type OID as the 623 type OID in the element from SET A, go to step 6. 625 2. If there is an element in SET B with the same Type OID and value 626 as in the element in SET A, carry out the following steps: 628 a) Add an element containing the Type OID and the value to the 629 SET temp-set. 631 b) Delete all elements with the same Type OID and the same 632 value from the SET B. 634 c) Go to step 6. 636 3. If the processing semantics of Type OID in the element in SET A 637 is not known, go to step 6. 639 4. Perform Type OID specific intersection of the value in the 640 element in SET A with the values in the applicable elements in 641 SET B with the same Type OID. 643 5. If the intersection is not empty, add and element containing the 644 Type OID and intersection result as value to temp-set. 646 6. If more elements remain in SET A, process the next element 647 starting with step 1. 649 Return temp-set. 651 8. Recommended securityCategories 653 This RFC also include a recommended securityCategories as follows: 655 SecurityCategory ::= SEQUENCE { 656 type [0] OID id-TBSL, 657 value [1] BIT STRING 658 } 660 Note that Type specific intersection of two values for this Type will 661 be simply setting the bits that are set in both values. If the 662 resulting intersection has none of the bits set, the intersection is 663 considered empty. 665 9. Security Considerations 667 Certificate issuers must recognize that absence of the 668 AuthorityClearanceConstraints in a CA or AA certificate means that in 669 terms of the clearance, the subject Authority is not constrained. 671 Absence of Clearance attribute in a certificate means that the 672 subject has not been assigned any clearance. 674 If there is no Clearance associated with a TA, it means that the TA 675 has not been assigned any clearance. 677 If the local security policy considers the clearance held by a 678 subject or those supported by a CA or AA to be sensitive, then the 679 Clearance attribute or Authority Clearance Constraints should only be 680 included if the subject's and Authority's certificate can be privacy 681 protected. Also in this case, distribution of trust anchors and 682 associated Authority Clearance Constraints extension or Clearance 683 must also be privacy protected. 685 10. IANA Considerations 687 None. Please remove this section prior to publication as an RFC. 689 11. References 691 11.1. Normative References 693 [PKI-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for PKIX", 694 draft-ietf-pkix-new-asn1, work-in-progress. 696 /*** RFC EDITOR: Please replace PKI-ASN with RFCXYZA when draft-ietf- 697 pkix-new-asn1 is published. 699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 700 Requirement Levels", BCP 14, RFC 2119, March 1997. 702 [3281bis] Farrell, S., Housely, R., and S. Turner, "An Internet 703 Attribute Certificate Profile for Authorization: Update", 704 draft-ietf-pkix-3281update-04, work-in-progress. 706 /*** RFC EDITOR: Please replace 3281bis with RFCXYZA when draft-ietf- 707 pkix-3281update is published. 709 [RFC5280] Cooper, D. et. al., "Internet X.509 Public Key 710 Infrastructure Certificate and Certification Revocation 711 List (CRL) Profile", RFC 5280, May 2008. 713 [X.680] ITU-T Recommendation X.680 (2004) | ISO/IEC 8824-1:2004. 714 Information Technology - Abstract Syntax Notation One. 716 11.2. Informative References 718 [RFC3114] Nicolls, W., "Implementing Company Classification Policy 719 with S/MIME Security Label", RFC3114, May 2002. 721 [RFC3739] Santesson, S. et. al., "Internet X.509 Public Key 722 Infrastructure: Qualified Certificate Profile", RFC 3739, 723 March 2004. 725 Appendix A. ASN.1 Module 727 This appendix provides the normative ASN.1 definitions for 728 the structures described in this specification using ASN.1 as defined 729 in X.680. 731 ClearanceConstraints { iso(1) identified-organization(3) dod(6) 732 internet(1) security(5) mechanisms(5) pkix(7) mod(0) 46 } 734 DEFINITIONS IMPLICIT TAGS ::= 736 BEGIN 738 -- EXPORTS ALL -- 740 IMPORTS 742 -- IMPORTS from [PKI-ASN] 744 id-at-clearance, Clearance 745 FROM PKIXAttributeCertificate 746 { iso(1) identified-organization(3) dod(6) internet(1) 747 security(5) mechanisms(5) pkix(7) id-mod(0) 748 id-mod-attribute-cert(12) 749 } 751 -- IMPORTS from [PKI-ASN] 753 EXTENSION 754 FROM PKIX-CommonTypes 755 { iso(1) identified-organization(3) dod(6) internet(1) 756 security(5) mechanisms(5) pkix(7) id-mod(0) 757 id-mod-pkixCommon(43) 758 } 759 ; 761 -- Clearance attribute OID and syntax 763 -- The following is a '93 version for clearance. 764 -- It is included for convenience. 766 -- id-at-clearance OBJECT IDENTIFIER ::= 767 -- { joint-iso-ccitt(2) ds(5) attributeTypes(5) clearance (55) } 768 -- Clearance ::= SEQUENCE { 769 -- policyId OBJECT IDENTIFIER, 770 -- classList ClassList DEFAULT {unclassified}, 771 -- securityCategories SET OF SecurityCategory OPTIONAL 772 -- } 774 -- ClassList ::= BIT STRING { 775 -- unmarked (0), 776 -- unclassified (1), 777 -- restricted (2), 778 -- confidential (3), 779 -- secret (4), 780 -- topSecret (5) 781 -- } 783 -- SECURITY-CATEGORY ::= TYPE-IDENTIFIER 785 -- SecurityCategory ::= SEQUENCE { 786 -- type [0] 787 -- TYPE-IDENTIFIER.&id({SupportedSecurityCategories}), 788 -- value [1] 789 -- EXPLICIT TYPE-IDENTIFIER.&Type 790 -- ({SupportedSecurityCategories}{@type}) 791 -- } 793 -- Authority Clearance Constraints certificate extension OID 794 -- and syntax 796 id-pe-clearanceConstraints OBJECT IDENTIFIER ::= 797 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 798 mechanisms(5) pkix(7) pe(1) 21 } 800 authorityClearanceConstraints EXTENSION ::= { 801 SYNTAX AuthorityClearanceConstraints 802 IDENTIFIED BY id-pe-clearanceConstraints 803 } 805 AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance 807 END 809 Author's Addresses 811 Sean Turner 813 IECA, Inc. 814 3057 Nutley Street, Suite 106 815 Fairfax, VA 22031 816 USA 818 EMail: turners@ieca.com 820 Santosh Chokhani 821 CygnaCom Solutions, Inc. 823 Email: SChokhani@cygnacom.com