| < draft-ietf-pkix-authorityclearanceconstraints-02.txt | draft-ietf-pkix-authorityclearanceconstraints-03.txt > | |||
|---|---|---|---|---|
| Network Working Group Sean Turner | Network Working Group Sean Turner, IECA | |||
| Internet Draft IECA | Internet Draft Santosh Chokhani, Cygnacom Solutions | |||
| Intended Status: Standard Track Santosh Chokhani | Intended Status: Standard Track October 19, 2009 | |||
| CygnaCom Solutions | Expires: April 19, 2010 | |||
| Expires: September 24, 2009 March 24, 2009 | ||||
| Clearance Attribute and Authority Clearance Constraints | Clearance Attribute and Authority Clearance Constraints | |||
| Certificate Extension | Certificate Extension | |||
| draft-ietf-pkix-authorityclearanceconstraints-02.txt | draft-ietf-pkix-authorityclearanceconstraints-03.txt | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 32 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
| This Internet-Draft will expire on September 24, 2009. | This Internet-Draft will expire on April 19, 2010. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents in effect on the date of | |||
| publication of this document (http://trustee.ietf.org/license-info). | publication of this document (http://trustee.ietf.org/license-info). | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 14 ¶ | skipping to change at page 2, line 14 ¶ | |||
| Abstract | Abstract | |||
| This document defines the syntax and semantics for the Clearance | This document defines the syntax and semantics for the Clearance | |||
| attribute and the Authority Clearance Constraints extension in X.509 | attribute and the Authority Clearance Constraints extension in X.509 | |||
| certificates. The Clearance attribute is used to indicate the | certificates. The Clearance attribute is used to indicate the | |||
| clearance held by the subject. The Clearance attribute may appear in | clearance held by the subject. The Clearance attribute may appear in | |||
| the subject directory attributes extension of a public key | the subject directory attributes extension of a public key | |||
| certificate or in the attributes field of an attribute certificate. | certificate or in the attributes field of an attribute certificate. | |||
| The Authority Clearance Constraints certificate extension values in a | The Authority Clearance Constraints certificate extension values in a | |||
| Trust Anchor (TA), CA public key certificates, and an Attribute | Trust Anchor (TA), Certificate Authority (CA) public key | |||
| Authority (AA) public key certificate in a public key certification | certificates, and an Attribute Authority (AA) public key certificate | |||
| path constrain the effective Clearance of the subject. | in a public key certification path constrain the effective Clearance | |||
| of the subject. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction...................................................3 | 1. Introduction...................................................3 | |||
| 1.1. Terminology...............................................4 | 1.1. Terminology...............................................4 | |||
| 1.2. ASN.1 Syntax Notation.....................................4 | 1.2. ASN.1 Syntax Notation.....................................4 | |||
| 2. Clearance Attribute............................................4 | 2. Clearance Attribute............................................4 | |||
| 3. Authority Clearance Constraints Certificate Extension..........5 | 3. Authority Clearance Constraints Certificate Extension..........5 | |||
| 4. Clearance and Authority Clearance Constraints Processing in | 4. Clearance and Authority Clearance Constraints Processing in | |||
| PKC............................................................6 | PKC............................................................6 | |||
| skipping to change at page 2, line 49 ¶ | skipping to change at page 2, line 50 ¶ | |||
| 5.1.1. Certification Path Processing.......................11 | 5.1.1. Certification Path Processing.......................11 | |||
| 5.1.1.1. Inputs.........................................11 | 5.1.1.1. Inputs.........................................11 | |||
| 5.1.1.2. Initialization.................................11 | 5.1.1.2. Initialization.................................11 | |||
| 5.1.1.3. Basic PKC Processing...........................12 | 5.1.1.3. Basic PKC Processing...........................12 | |||
| 5.1.1.4. Preparation for Certificate i+1................12 | 5.1.1.4. Preparation for Certificate i+1................12 | |||
| 5.1.1.5. Wrap-up Procedure..............................12 | 5.1.1.5. Wrap-up Procedure..............................12 | |||
| 5.1.1.5.1. Wrap Up Clearance.........................12 | 5.1.1.5.1. Wrap Up Clearance.........................12 | |||
| 5.1.1.6. Outputs........................................12 | 5.1.1.6. Outputs........................................12 | |||
| 6. Computing Intersection of permitted-clearances and | 6. Computing Intersection of permitted-clearances and | |||
| AuthorityClearanceConstraints extension.......................12 | AuthorityClearanceConstraints extension.......................12 | |||
| 7. Computing Intersection of securityCategories..................14 | 7. Computing Intersection of securityCategories..................13 | |||
| 8. Recommended securityCategories................................15 | 8. Recommended securityCategories................................15 | |||
| 9. Security Considerations.......................................15 | 9. Security Considerations.......................................15 | |||
| 10. IANA Considerations..........................................15 | 10. IANA Considerations..........................................16 | |||
| 11. References...................................................15 | 11. References...................................................16 | |||
| 11.1. Normative References....................................15 | 11.1. Normative References....................................16 | |||
| 11.2. Informative References..................................16 | 11.2. Informative References..................................17 | |||
| Appendix A. ASN.1 Module.........................................17 | Appendix A. ASN.1 Module.........................................18 | |||
| Author's Addresses...............................................19 | Authors' Addresses...............................................20 | |||
| 1. Introduction | 1. Introduction | |||
| Organizations that have implemented a security policy can issue | Organizations that have implemented a security policy can issue | |||
| certificates that include an indication of the clearance values held | certificates that include an indication of the clearance values held | |||
| by the subject. The Clearance attribute indicates the security | by the subject. The Clearance attribute indicates the security | |||
| policy, the clearance levels held by the subject, and additional | policy, the clearance levels held by the subject, and additional | |||
| authorization information held by the subject. This specification | authorization information held by the subject. This specification | |||
| makes use of the ASN.1 syntax for clearance from [3281bis]. | makes use of the ASN.1 syntax for clearance from [RFC3281bis]. | |||
| Clearance attribute may be placed in the subject directory attributes | Clearance attribute may be placed in the subject directory attributes | |||
| extension of a PKC or may be placed in a separate attribute | extension of a Public Key Certificate (PKC) or may be placed in a | |||
| certificate (AC). | separate attribute certificate (AC). | |||
| The placement of Clearance attribute in PKCs is desirable when the | The placement of Clearance attribute in PKCs is desirable when the | |||
| credentials such as PKCs need to be revoked when the clearance | credentials such as PKCs need to be revoked when the clearance | |||
| information changes or when clearance information is relatively | information changes or when clearance information is relatively | |||
| static, and clearance information can be verified as part of PKC | static, and clearance information can be verified as part of PKC | |||
| issuance process (e.g., using local databases). The placement of | issuance process (e.g., using local databases). The placement of | |||
| Clearance attribute in PKCs may also be made to simplify the | Clearance attribute in PKCs may also be made to simplify the | |||
| infrastructure, to reduce the infrastructure design cost, or to | infrastructure, to reduce the infrastructure design cost, or to | |||
| reduce the infrastructure operations cost. An example of placement | reduce the infrastructure operations cost. An example of placement | |||
| of Clearance attribute in PKCs in operational PKI is the Defense | of Clearance attribute in PKCs in operational Public Key | |||
| Messaging Service. An example of placement of attributes in PKCs is | Infrastructure (PKI) is the Defense Messaging Service. An example of | |||
| Qualified Certificates [RFC3739]. | placement of attributes in PKCs is Qualified Certificates [RFC3739]. | |||
| The placement of Clearance attribute in ACs is desirable when the | The placement of Clearance attribute in ACs is desirable when the | |||
| clearance information is relatively dynamic and changes in the | clearance information is relatively dynamic and changes in the | |||
| clearance information does not require revocation of credentials such | clearance information does not require revocation of credentials such | |||
| as PKCs, or the clearance information can not be verified as part of | as PKCs, or the clearance information can not be verified as part of | |||
| PKC issuance process. | PKC issuance process. | |||
| Since [3281bis] does not permit chain of ACs, the Authority | Since [RFC3281bis] does not permit chain of ACs, the Authority | |||
| Clearance Constraints extension may only appear in the PKCs of CA or | Clearance Constraints extension may only appear in the PKCs of | |||
| AA. The Authority Clearance Constraints extension may also appear | Certificate Authority (CA) or Attribute Authority (AA). The | |||
| in a TA or may be associated with a TA. | Authority Clearance Constraints extension may also appear in a trust | |||
| anchor (TA) or may be associated with a TA. | ||||
| Some organizations have multiple TAs, CAs, and/or AAs and these | Some organizations have multiple TAs, CAs, and/or AAs and these | |||
| organizations may wish to indicate to relying parties which clearance | organizations may wish to indicate to relying parties which clearance | |||
| values from a particular TA, CA, or AA should be accepted. For | values from a particular TA, CA, or AA should be accepted. For | |||
| example, consider the security policies described in [RFC3114], where | example, consider the security policies described in [RFC3114], where | |||
| a security policy has been defined for Amoco with three security | a security policy has been defined for Amoco with three security | |||
| classification values (HIGHLY CONFIDENTIAL, CONFIDENTIAL, and | classification values (HIGHLY CONFIDENTIAL, CONFIDENTIAL, and | |||
| GENERAL). To constrain a CA for just one security classification, the | GENERAL). To constrain a CA for just one security classification, the | |||
| Authority Clearance Constraints certificate extension would be | Authority Clearance Constraints certificate extension would be | |||
| included in the CA's PKC. | included in the CA's PKC. | |||
| Cross-certified domains can also make use of the Authority Clearance | Cross-certified domains can also make use of the Authority Clearance | |||
| Constraints certificate extension to indicate which clearance values | Constraints certificate extension to indicate which clearance values | |||
| should be acceptable to relying parties. | should be acceptable to relying parties. | |||
| This document augments the certification path validation rules for | ||||
| PKCs in [RFC5280] and ACs in [RFC3281bis]. | ||||
| 1.1. Terminology | 1.1. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
| 1.2. ASN.1 Syntax Notation | 1.2. ASN.1 Syntax Notation | |||
| All X.509 PKC [RFC5280] extensions are defined using ASN.1 [X.680]. | All X.509 PKC [RFC5280] extensions are defined using ASN.1 [X.680]. | |||
| All X.509 AC [3281bis] extensions are defined using ASN.1 [X.680]. | All X.509 AC [RFC3281bis] extensions are defined using ASN.1 [X.680]. | |||
| 2. Clearance Attribute | 2. Clearance Attribute | |||
| The Clearance attribute in a certificate indicates the clearances | The Clearance attribute in a certificate indicates the clearances | |||
| held by the subject. It uses the clearance attribute syntax from | held by the subject. It uses the clearance attribute syntax from | |||
| Section 4.4.6 of [3281bis], which is included below for convenience, | Section 4.4.6 of [RFC3281bis], which is included below for | |||
| in the Attributes field. A certificate MUST include either zero or | convenience, in the Attributes field. A certificate MUST include | |||
| one instance of the Clearance attribute. If the Clearance attribute | either zero or one instance of the Clearance attribute. If the | |||
| is present, it must contain a single value. | Clearance attribute is present, it MUST contain a single value. | |||
| The following object identifier identifies the Clearance attribute | The following object identifier identifies the Clearance attribute | |||
| (either in the subject directory attributes extension of a PKC or in | (either in the subject directory attributes extension of a PKC or in | |||
| the Attributes field of an AC): | the Attributes field of an AC): | |||
| id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) | id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) | |||
| ds(5) attributeTypes(4) clearance(55) } | ds(5) attributeTypes(4) clearance(55) } | |||
| The ASN.1 syntax for the Clearance attribute is as follows [PKI-ASN]: | The ASN.1 syntax for the Clearance attribute is as follows [PKI-ASN]: | |||
| Clearance ::= SEQUENCE { | Clearance ::= SEQUENCE { | |||
| policyId OBJECT IDENTIFIER, | policyId OBJECT IDENTIFIER, | |||
| classList ClassList DEFAULT {unclassified}, | classList ClassList DEFAULT {unclassified}, | |||
| securityCategories SET OF SecurityCategory OPTIONAL | securityCategories SET OF SecurityCategory | |||
| {{ SupportedSecurityCategories }} OPTIONAL | ||||
| } | } | |||
| ClassList ::= BIT STRING { | ClassList ::= BIT STRING { | |||
| unmarked (0), | unmarked (0), | |||
| unclassified (1), | unclassified (1), | |||
| restricted (2), | restricted (2), | |||
| confidential (3), | confidential (3), | |||
| secret (4), | secret (4), | |||
| topSecret (5) | topSecret (5) | |||
| } | } | |||
| SECURITY-CATEGORY ::= TYPE-IDENTIFIER | SECURITY-CATEGORY ::= TYPE-IDENTIFIER | |||
| SecurityCategory ::= SEQUENCE { | SecurityCategory { SECURITY-CATEGORY:Supported }::= SEQUENCE { | |||
| type [0] | type [0] IMPLICIT SECURITY-CATEGORY.&id({Supported}), | |||
| TYPE-IDENTIFIER.&id({SupportedSecurityCategories}), | value [1] EXPLICIT SECURITY-CATEGORY.&Type | |||
| value [1] | ({Supported}{@type}) | |||
| EXPLICIT TYPE-IDENTIFIER.&Type | ||||
| ({SupportedSecurityCategories}{@type}) | ||||
| } | } | |||
| NOTE: SecurityCategory is shown exactly as it is in [PKI-ASN]. That | ||||
| module is an EXPLICIT tagged module whereas the module contained in | ||||
| this document is an IMPLICIT tagged module. | ||||
| The Clearance attribute takes its meaning from Section 4.4.6 of | The Clearance attribute takes its meaning from Section 4.4.6 of | |||
| [3281bis], which is repeated here for convenience: | [RFC3281bis], which is repeated here for convenience: | |||
| - policyId identifies the security policy to which the clearance | - policyId identifies the security policy to which the clearance | |||
| relates. The policyId indicates the semantics of the classList | relates. The policyId indicates the semantics of the classList | |||
| and securityCategory fields. | and securityCategories fields. | |||
| - classlist identifies the security classifications. Six basic | - classList identifies the security classifications. Six basic | |||
| values are defined in bit positions 0 through 5 and more may be | values are defined in bit positions 0 through 5 and more may be | |||
| defined by an organizational security policy. | defined by an organizational security policy. | |||
| - securityCategories provides additional authorization information. | - securityCategories provides additional authorization information. | |||
| If a trust anchor's public key is used directly, then the Clearance | If a trust anchor's public key is used directly, then the Clearance | |||
| associated with the trust anchor, if any, should be used as the | associated with the trust anchor, if any, should be used as the | |||
| effective clearance (also defined as effective-clearance for a | effective clearance (also defined as effective-clearance for a | |||
| certification path). | certification path). | |||
| skipping to change at page 6, line 25 ¶ | skipping to change at page 6, line 31 ¶ | |||
| iso(1) identified-organization(3) dod(6) internet(1) security(5) | iso(1) identified-organization(3) dod(6) internet(1) security(5) | |||
| mechanisms(5) pkix(7) pe(1) 21 } | mechanisms(5) pkix(7) pe(1) 21 } | |||
| The ASN.1 syntax for the Authority Clearance Constraints certificate | The ASN.1 syntax for the Authority Clearance Constraints certificate | |||
| extension is as follows: | extension is as follows: | |||
| AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF | AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF | |||
| Clearance | Clearance | |||
| The syntax for Authority Clearance Constraints certificate extension | The syntax for Authority Clearance Constraints certificate extension | |||
| contains Clearance values that the CA or the AA asserts. The | contains Clearances that the CA or the AA asserts. The sequence MUST | |||
| sequence MUST NOT include more than one entry with the same policyId. | NOT include more than one entry with the same policyId. This | |||
| This constraint is enforced during Clearance and Authority Clearance | constraint is enforced during Clearance and Authority Clearance | |||
| Constraints Processing described below. If more than one entry with | Constraints Processing described below. If more than one entry with | |||
| the same policyId is present in AuthorityClearanceConstraints | the same policyId is present in AuthorityClearanceConstraints | |||
| certificate extension, the certification path is rejected. In | certificate extension, the certification path is rejected. | |||
| addition, each Clearance attribute in the SEQUENCE must not contain | ||||
| more than one value. | ||||
| 4. Clearance and Authority Clearance Constraints Processing in PKC | 4. Clearance and Authority Clearance Constraints Processing in PKC | |||
| This section describes the processing of certification path when | This section describes the processing of certification path when | |||
| Clearance is asserted in PKC. | Clearance is asserted in PKC. | |||
| User input, Authority Clearance Constraints certificate extension, | User input, Authority Clearance Constraints certificate extension, | |||
| and Clearance attribute processing determines the effective clearance | and Clearance attribute processing determines the effective clearance | |||
| (henceforth called effective-clearance) for the end PKC. User input, | (henceforth called effective-clearance) for the end PKC. User input, | |||
| Authority Clearance Constraints certificate extension in the TA and | Authority Clearance Constraints certificate extension in the TA and | |||
| skipping to change at page 7, line 33 ¶ | skipping to change at page 7, line 36 ¶ | |||
| state variable is updated by first processing Authority Clearance | state variable is updated by first processing Authority Clearance | |||
| Constraints associated with the trust anchor, and then each time an | Constraints associated with the trust anchor, and then each time an | |||
| intermediate PKC that contains an Authority Clearance Constraints | intermediate PKC that contains an Authority Clearance Constraints | |||
| certificate extension in the path is processed. | certificate extension in the path is processed. | |||
| When processing the end PKC, the value in the Clearance attribute in | When processing the end PKC, the value in the Clearance attribute in | |||
| the end PKC is intersected with the permitted-clearances state | the end PKC is intersected with the permitted-clearances state | |||
| variable. | variable. | |||
| The output of Clearance attribute and Authority Clearance Constraint | The output of Clearance attribute and Authority Clearance Constraint | |||
| certificate extensions processing is the effective-clearance, which | certificate extensions processing is the effective-clearance (which | |||
| could also be an empty list; and success or failure with reason code | could also be an empty list), and a status indicator of either | |||
| for failure. | success or failure. If the status indicator was failure, then the | |||
| process also returns a reason code. | ||||
| 4.1. Collecting Constraints | 4.1. Collecting Constraints | |||
| Authority Clearance Constraints are collected from the user input, | Authority Clearance Constraints are collected from the user input, | |||
| the trust anchor and the intermediate PKCs in a certification path. | the trust anchor and the intermediate PKCs in a certification path. | |||
| 4.1.1. Certification Path Processing | 4.1.1. Certification Path Processing | |||
| When processing Authority Clearance Constraints certificate extension | When processing Authority Clearance Constraints certificate extension | |||
| for the purposes of validating Clearance attribute in the end PKC, | for the purposes of validating Clearance attribute in the end PKC, | |||
| the processing described in this section or an equivalent algorithm | the processing described in this section or an equivalent algorithm | |||
| MUST be included in the certification path validation. The | MUST be performed in addition to the certification path validation. | |||
| processing is presented as additions to the certification path | ||||
| The processing is presented as additions to the certification path | ||||
| validation algorithm described in section 6 of [RFC5280]. Note that | validation algorithm described in section 6 of [RFC5280]. Note that | |||
| this RFC is fully consistent with [RFC5280]; however, it augments | this RFC is fully consistent with [RFC5280]; however, it augments | |||
| [RFC5280] with the following steps: | [RFC5280] with the following steps: | |||
| . Ability to provide and process Authority Clearance Constraints | . Ability to provide and process Authority Clearance Constraints | |||
| as an additional input to the certification path processing | as an additional input to the certification path processing | |||
| engine | engine | |||
| . Requirement to process Authority Clearance Constraints present | . Requirement to process Authority Clearance Constraints present | |||
| with Trust anchor information. | with Trust anchor information. | |||
| skipping to change at page 8, line 27 ¶ | skipping to change at page 8, line 30 ¶ | |||
| omit it. | omit it. | |||
| Trust anchor information may include the | Trust anchor information may include the | |||
| AuthorityClearanceConstraints structure to specify Authority | AuthorityClearanceConstraints structure to specify Authority | |||
| Clearance Constraints for the trust anchor. The trust anchor may be | Clearance Constraints for the trust anchor. The trust anchor may be | |||
| constrained or unconstrained. | constrained or unconstrained. | |||
| 4.1.1.2. Initialization | 4.1.1.2. Initialization | |||
| If user input includes AuthorityClearanceConstraints, set the | If user input includes AuthorityClearanceConstraints, set the | |||
| permitted-clearances to the input value, otherwise,, set the | permitted-clearances to the input value, otherwise, set the | |||
| permitted-clearances to special value all-clearances. | permitted-clearances to special value all-clearances. | |||
| If any of the Clearance attributes in the permitted-clearances | ||||
| contains more than one value, set effective-clearance to an empty | ||||
| list, set error code to "multiple values in input", and exit with | ||||
| failure. | ||||
| Examine the permitted-clearances for the same Policy ID appearing | Examine the permitted-clearances for the same Policy ID appearing | |||
| more then once. If a policyID appears more than once in the | more then once. If a policyId appears more than once in the | |||
| permitted-clearances state variable, set effective-clearance to an | permitted-clearances state variable, set effective-clearance to an | |||
| empty list, set error code to "multiple instances of same clearance", | empty list, set error code to "multiple instances of same clearance", | |||
| and exit with failure. | and exit with failure. | |||
| If the trust anchor does not contain an AuthorityClearanceConstraints | If the trust anchor does not contain an AuthorityClearanceConstraints | |||
| extension, continue at Section 4.1.1.3. Otherwise, execute the | extension, continue at Section 4.1.1.3. Otherwise, execute the | |||
| procedure described in Section 6 as an in-line macro by treating the | procedure described in Section 6 as an in-line macro by treating the | |||
| trust anchor as a PKC. | trust anchor as a PKC. | |||
| 4.1.1.3. Basic Certificate Processing | 4.1.1.3. Basic Certificate Processing | |||
| If the PKC is the last PKC (i.e., certificate n), skip the steps | If the PKC is the last PKC (i.e., certificate n), skip the steps | |||
| listed in this section. Otherwise, execute the procedure described | listed in this section. Otherwise, execute the procedure described | |||
| in Section 6. as an in-line macro. | in Section 6 as an in-line macro. | |||
| 4.1.1.4. Preparation for Certificate i+1 | 4.1.1.4. Preparation for Certificate i+1 | |||
| No additional action associated with the Clearance attribute or | No additional action associated with the Clearance attribute or | |||
| AuthorityClearanceConstraints certificate extensions is taken during | AuthorityClearanceConstraints certificate extensions is taken during | |||
| this phase of certification path validation as described in section 6 | this phase of certification path validation as described in section 6 | |||
| of [RFC5280]. | of [RFC5280]. | |||
| 4.1.1.5. Wrap-up Procedure | 4.1.1.5. Wrap-up Procedure | |||
| skipping to change at page 9, line 35 ¶ | skipping to change at page 9, line 35 ¶ | |||
| Set effective-clearance to the Clearance attribute in the end PKC. | Set effective-clearance to the Clearance attribute in the end PKC. | |||
| 4.1.1.5.1. Wrap Up Clearance | 4.1.1.5.1. Wrap Up Clearance | |||
| Examine effective-clearance and verify that it does not contain more | Examine effective-clearance and verify that it does not contain more | |||
| than one value. If effective-clearance contains more than one value, | than one value. If effective-clearance contains more than one value, | |||
| set effective-clearance to an empty list, set error code to "multiple | set effective-clearance to an empty list, set error code to "multiple | |||
| values", and exit with failure. | values", and exit with failure. | |||
| Let us say policyID in effective-clearance is X. | ||||
| If permitted-clearances is an empty list, set effective-clearance to | If permitted-clearances is an empty list, set effective-clearance to | |||
| an empty list and exit with success. | an empty list and exit with success. | |||
| If the permitted-clearances has special value of all-clearances, exit | If the permitted-clearances has special value of all-clearances, exit | |||
| with success. | with success. | |||
| If the policyID X in effective-clearance is absent from the | Let us say policyId in effective-clearance is X. | |||
| If the policyId X in effective-clearance is absent from the | ||||
| permitted-clearances, set effective-clearance to an empty list and | permitted-clearances, set effective-clearance to an empty list and | |||
| exit with success. | exit with success. | |||
| Assign those classList bits in effective-clearance a value of one (1) | Assign those classList bits in effective-clearance a value of one (1) | |||
| that have a value of one (1) both in effective-clearance and in the | that have a value of one (1) both in effective-clearance and in the | |||
| clearance structure in permitted-clearances associated with policyID | clearance structure in permitted-clearances associated with policyId | |||
| X. Assign all other classList bits in effective-clearance a value of | X. Assign all other classList bits in effective-clearance a value of | |||
| zero (0). | zero (0). | |||
| If none of the classList bits have a value of one (1) in effective- | If none of the classList bits have a value of one (1) in effective- | |||
| clearance, set effective-clearance to an empty list and exit with | clearance, set effective-clearance to an empty list and exit with | |||
| success. | success. | |||
| Set the securityCategories in effective-clearance to the intersection | Set the securityCategories in effective-clearance to the intersection | |||
| of securityCategories in effective-clearance and in permitted- | of securityCategories in effective-clearance and in permitted- | |||
| clearances using the algorithm described in Section 6. Note that | clearances using the algorithm described in Section 7. Note that an | |||
| empty an SET is represented by simply omitting the SET. | empty SET is represented by simply omitting the SET. | |||
| Exit with Success | Exit with Success. | |||
| 4.1.1.6. Outputs | 4.1.1.6. Outputs | |||
| If certification path validation processing succeeds, effective- | If certification path validation processing succeeds, effective- | |||
| clearance contains the effective clearance for the subject of the | clearance contains the effective clearance for the subject of the | |||
| certification path. Processing also returns success or failure | certification path. Processing also returns success or failure | |||
| indication and reason for failure, if applicable. | indication and reason for failure, if applicable. | |||
| 5. Clearance and Authority Clearance Constraints Processing in AC | 5. Clearance and Authority Clearance Constraints Processing in AC | |||
| skipping to change at page 11, line 36 ¶ | skipping to change at page 11, line 36 ¶ | |||
| the trust anchor and all the PKCs in a PKC certification path. | the trust anchor and all the PKCs in a PKC certification path. | |||
| 5.1.1. Certification Path Processing | 5.1.1. Certification Path Processing | |||
| When processing Authority Clearance Constraints certificate extension | When processing Authority Clearance Constraints certificate extension | |||
| for the purposes of validating Clearance in the AC, the processing | for the purposes of validating Clearance in the AC, the processing | |||
| described in this section or an equivalent algorithm MUST be included | described in this section or an equivalent algorithm MUST be included | |||
| in the certification path validation. The processing is presented as | in the certification path validation. The processing is presented as | |||
| additions to the PKC certification path validation algorithm | additions to the PKC certification path validation algorithm | |||
| described in section 6 of [RFC5280] for the AA PKC certification path | described in section 6 of [RFC5280] for the AA PKC certification path | |||
| and the algorithm described in section 5 of [3281bis] for the AC | and the algorithm described in section 5 of [RFC3281bis] for the AC | |||
| validation. Also see note related to [RFC5280 augmentation in | validation. Also see note related to [RFC5280] augmentation in | |||
| Section 4.1.1. | Section 4.1.1. | |||
| 5.1.1.1. Inputs | 5.1.1.1. Inputs | |||
| Same as Section 4.1.1.1. | Same as Section 4.1.1.1. | |||
| In addition, let us assume that the PKC certification path for the AA | In addition, let us assume that the PKC certification path for the AA | |||
| consists of n certificates. | consists of n certificates. | |||
| 5.1.1.2. Initialization | 5.1.1.2. Initialization | |||
| skipping to change at page 12, line 38 ¶ | skipping to change at page 12, line 38 ¶ | |||
| 5.1.1.5.1. Wrap Up Clearance | 5.1.1.5.1. Wrap Up Clearance | |||
| Same as Section 4.1.1.5.1. | Same as Section 4.1.1.5.1. | |||
| 5.1.1.6. Outputs | 5.1.1.6. Outputs | |||
| Same as Section 4.1.1.6. | Same as Section 4.1.1.6. | |||
| In addition, apply AC processing rules described in Section 5 of | In addition, apply AC processing rules described in Section 5 of | |||
| [3281bis]. | [RFC3281bis]. | |||
| 6. Computing Intersection of permitted-clearances and | 6. Computing Intersection of permitted-clearances and | |||
| AuthorityClearanceConstraints extension | AuthorityClearanceConstraints extension | |||
| Examine the PKC and verify that it does not contain more than one | Examine the PKC and verify that it does not contain more than one | |||
| instance of AuthorityClearanceConstraints extension. If the PKC | instance of AuthorityClearanceConstraints extension. If the PKC | |||
| contains more than one instance of AuthorityClearanceConstraints | contains more than one instance of AuthorityClearanceConstraints | |||
| extension, set effective-clearance to an empty list, set error code | extension, set effective-clearance to an empty list, set error code | |||
| to "multiple extension instances", and exit with failure. | to "multiple extension instances", and exit with failure. | |||
| If any of the Clearance attributes in the | ||||
| AuthorityClearanceConstraints extension contains more than one value, | ||||
| set effective-clearance to an empty list, set error code to "multiple | ||||
| values", and exit with failure. | ||||
| If the AuthorityClearanceConstraints certificate extension is not | If the AuthorityClearanceConstraints certificate extension is not | |||
| present in the PKC, no action is taken, and the permitted-clearances | present in the PKC, no action is taken, and the permitted-clearances | |||
| value is unchanged. | value is unchanged. | |||
| If the AuthorityClearanceConstraints certificate extension is present | If the AuthorityClearanceConstraints certificate extension is present | |||
| in the PKC, set the variable temp-clearances to | in the PKC, set the variable temp-clearances to | |||
| AuthorityClearanceConstraints certificate extension. Examine the | AuthorityClearanceConstraints certificate extension. Examine the | |||
| temp-clearances for the same Policy ID appearing more then once. If | temp-clearances for the same Policy ID appearing more then once. If | |||
| a policyID appears more than once in the temp-clearances state | a policyId appears more than once in the temp-clearances state | |||
| variable, set effective-clearance to an empty list, set error code to | variable, set effective-clearance to an empty list, set error code to | |||
| "multiple instances of same clearance", and exit with failure. | "multiple instances of same clearance", and exit with failure. | |||
| If the AuthorityClearanceConstraints certificate extension is present | If the AuthorityClearanceConstraints certificate extension is present | |||
| in the PKC and permitted-clearances contains the all-clearances | in the PKC and permitted-clearances contains the all-clearances | |||
| special value, then assign permitted-clearances the value of the | special value, then assign permitted-clearances the value of the | |||
| temp-clearances. | temp-clearances. | |||
| If the AuthorityClearanceConstraints certificate extension is present | If the AuthorityClearanceConstraints certificate extension is present | |||
| in the PKC and permitted-clearances does not contain the all- | in the PKC and permitted-clearances does not contain the all- | |||
| clearances special value, take the intersection of temp-clearances | clearances special value, take the intersection of temp-clearances | |||
| and permitted-clearances by repeating the following steps for each | and permitted-clearances by repeating the following steps for each | |||
| clearance in the permitted-clearances state variable: | clearance in the permitted-clearances state variable: | |||
| - If the policyID associated with the clearance is absent in the | - If the policyId associated with the clearance is absent in the | |||
| temp-clearances, delete the clearance structure associated with | temp-clearances, delete the clearance structure associated with | |||
| the policyID from the permitted-clearances state variable. | the policyID from the permitted-clearances state variable. | |||
| - If the policyID is present in the temp-clearances: | - If the policyId is present in the temp-clearances: | |||
| -- For every classList bit, assign the classList bit a value of | -- For every classList bit, assign the classList bit a value of | |||
| one (1) for the policyID in permitted-clearances state | one (1) for the policyId in permitted-clearances state | |||
| variable if the bit is one (1) in both the permitted- | variable if the bit is one (1) in both the permitted- | |||
| clearances state variable and the temp-clearances for that | clearances state variable and the temp-clearances for that | |||
| policyID; otherwise assign the bit a value of zero (0). | policyId; otherwise assign the bit a value of zero (0). | |||
| -- If no bits are one (1) for the classList, delete the clearance | -- If no bits are one (1) for the classList, delete the clearance | |||
| structure associated with the policyID from the permitted- | structure associated with the policyId from the permitted- | |||
| clearances state variable and skip the next step of processing | clearances state variable and skip the next step of processing | |||
| securityCategories. | securityCategories. | |||
| -- For the policyID in permitted-clearances, set the | -- For the policyId in permitted-clearances, set the | |||
| securityCategories to the intersection of securityCategories | securityCategories to the intersection of securityCategories | |||
| for the policyID in permitted-clearances and in temp- | for the policyId in permitted-clearances and in temp- | |||
| clearances using the algorithm described in Section 7. Note | clearances using the algorithm described in Section 7. Note | |||
| that an empty SET is represented by simply omitting the SET. | that an empty SET is represented by simply omitting the SET. | |||
| 7. Computing Intersection of securityCategories | 7. Computing Intersection of securityCategories | |||
| The algorithm described in here has the idempotency, associative, and | ||||
| commutative properties, like the rest of the processing rules in this | ||||
| document. | ||||
| This section describes how to compute the intersection of | This section describes how to compute the intersection of | |||
| securityCategories A and B. It uses the state variable temp-set. | securityCategories A and B. It uses the state variable temp-set. It | |||
| also uses temporary variables X and Y | ||||
| Set the SET temp-set to empty. | Set the SET temp-set to empty. | |||
| If SET A is empty (i.e., securityCategories is absent), return temp- | Set X = A and Y = B | |||
| If SET X is empty (i.e., securityCategories is absent), return temp- | ||||
| set. | set. | |||
| If SET B is empty (i.e., securityCategories is absent), return temp- | If SET Y is empty (i.e., securityCategories is absent), return temp- | |||
| set. | set. | |||
| For every element (i.e., securityCategory) in the SET A carry out the | For each type OID in X, if all the elements for the type OID in X and | |||
| if and only if all the elements for that type OID in Y are identical, | ||||
| add those elements to temp-set and delete those elements from X and | ||||
| Y. Note: identical means that if the element with the type OID and | ||||
| given value is present in X, it is also present in Y with the same | ||||
| type OID and given value and vice versa. Delete the elements from X | ||||
| and from Y. | ||||
| If SET X is empty (i.e., securityCategories is absent), return temp- | ||||
| set. | ||||
| If SET Y is empty (i.e., securityCategories is absent), return temp- | ||||
| set. | ||||
| For every element (i.e., SecurityCategory) in the SET X carry out the | ||||
| following steps: | following steps: | |||
| 1. If there is no element in SET B with the same Type OID as the | 1. If there is no element in SET Y with the same Type OID as the | |||
| type OID in the element from SET A, go to step 6. | type OID in the element from SET X, go to step 5. | |||
| 2. If there is an element in SET B with the same Type OID and value | 2. If there is an element in SET Y with the same Type OID and value | |||
| as in the element in SET A, carry out the following steps: | as in the element in SET X, carry out the following steps: | |||
| a) Add an element containing the Type OID and the value to the | a) If the element is not present in the SET temp-set, add an | |||
| SET temp-set. | element containing the Type OID and the value to the SET | |||
| temp-set. | ||||
| b) Delete all elements with the same Type OID and the same | 3. If the processing semantics of Type OID in the element in SET X | |||
| value from the SET B. | is not known, go to step 5. | |||
| c) Go to step 6. | 4. For each element in SET Y, do the following: | |||
| 3. If the processing semantics of Type OID in the element in SET A | a) If the Type OID of the element in SET Y is not the same as | |||
| is not known, go to step 6. | the element in SET X being processed, go to step 4.d. | |||
| 4. Perform Type OID specific intersection of the value in the | b) Perform Type OID specific intersection of the value in the | |||
| element in SET A with the values in the applicable elements in | element in SET X with the value in the element in SET Y. | |||
| SET B with the same Type OID. | ||||
| 5. If the intersection is not empty, add and element containing the | c) If the intersection is not empty, and the element | |||
| Type OID and intersection result as value to temp-set. | representing the Type OID and intersection value is not | |||
| already present in temp-set, add the element containing | ||||
| the Type OID and intersection value as an element to temp- | ||||
| set. | ||||
| 6. If more elements remain in SET A, process the next element | d) Continue Do | |||
| 5. If more elements remain in SET X, process the next element | ||||
| starting with step 1. | starting with step 1. | |||
| Return temp-set. | Return temp-set. | |||
| 8. Recommended securityCategories | 8. Recommended securityCategories | |||
| This RFC also include a recommended securityCategories as follows: | This RFC also include a recommended securityCategories as follows: | |||
| SecurityCategory ::= SEQUENCE { | recommended-category SECURITY-CATEGORY ::= | |||
| type [0] OID id-TBSL, | { BIT STRING IDENTIFIED BY OID } | |||
| value [1] BIT STRING | ||||
| } | The above structure is provided as an example. To use this | |||
| structure, the object identifier (OID) needs to be registered and the | ||||
| semantics of the bits in the bit string need to be enumerated. | ||||
| Note that Type specific intersection of two values for this Type will | Note that Type specific intersection of two values for this Type will | |||
| be simply setting the bits that are set in both values. If the | be simply setting the bits that are set in both values. If the | |||
| resulting intersection has none of the bits set, the intersection is | resulting intersection has none of the bits set, the intersection is | |||
| considered empty. | considered empty. | |||
| 9. Security Considerations | 9. Security Considerations | |||
| Certificate issuers must recognize that absence of the | Certificate issuers must recognize that absence of the | |||
| AuthorityClearanceConstraints in a CA or AA certificate means that in | AuthorityClearanceConstraints in a CA or AA certificate means that in | |||
| skipping to change at page 15, line 47 ¶ | skipping to change at page 16, line 21 ¶ | |||
| must also be privacy protected. | must also be privacy protected. | |||
| 10. IANA Considerations | 10. IANA Considerations | |||
| None. Please remove this section prior to publication as an RFC. | None. Please remove this section prior to publication as an RFC. | |||
| 11. References | 11. References | |||
| 11.1. Normative References | 11.1. Normative References | |||
| [PKI-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for PKIX", | [PKI-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for | |||
| draft-ietf-pkix-new-asn1-03, work-in-progress. | PKIX", draft-ietf-pkix-new-asn1-07, work-in-progress. | |||
| /*** RFC EDITOR: Please replace PKI-ASN with RFC#### when draft-ietf- | /*** RFC EDITOR: Please replace PKI-ASN with RFCXYZA when draft-ietf- | |||
| pkix-new-asn1 is published. | pkix-new-asn1 is published. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [3281bis] Farrell, S., Housely, R., and S. Turner, "An Internet | [RFC3281bis] Farrell, S., Housley, R., and S. Turner, "An Internet | |||
| Attribute Certificate Profile for Authorization: Update", | Attribute Certificate Profile for Authorization: | |||
| draft-ietf-pkix-3281update-04, work-in-progress. | Update", draft-ietf-pkix-3281update-05, work-in- | |||
| progress. | ||||
| /*** RFC EDITOR: Please replace 3281bis with RFCXYZA when draft-ietf- | /*** RFC EDITOR: Please replace RFC3281bis with RFCXYZA when draft- | |||
| pkix-3281update is published. | ietf-pkix-3281update is published. | |||
| [RFC5280] Cooper, D. et. al., "Internet X.509 Public Key | [RFC5280] Cooper, D. et. al., "Internet X.509 Public Key | |||
| Infrastructure Certificate and Certification Revocation | Infrastructure Certificate and Certification Revocation | |||
| List (CRL) Profile", RFC 5280, May 2008. | List (CRL) Profile", RFC 5280, May 2008. | |||
| [X.680] ITU-T Recommendation X.680 (2004) | ISO/IEC 8824-1:2004. | [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- | |||
| Information Technology - Abstract Syntax Notation One. | 1:2002. Information Technology - Abstract Syntax | |||
| Notation One. | ||||
| 11.2. Informative References | 11.2. Informative References | |||
| [RFC3114] Nicolls, W., "Implementing Company Classification Policy | [RFC3114] Nicolls, W., "Implementing Company Classification | |||
| with S/MIME Security Label", RFC3114, May 2002. | Policy with S/MIME Security Label", RFC3114, May 2002. | |||
| [RFC3739] Santesson, S. et. al., "Internet X.509 Public Key | [RFC3739] Santesson, S. et. al., "Internet X.509 Public Key | |||
| Infrastructure: Qualified Certificate Profile", RFC 3739, | Infrastructure: Qualified Certificate Profile", RFC | |||
| March 2004. | 3739, March 2004. | |||
| Appendix A. ASN.1 Module | Appendix A. ASN.1 Module | |||
| This appendix provides the normative ASN.1 definitions for | This appendix provides the normative ASN.1 definitions for | |||
| the structures described in this specification using ASN.1 as defined | the structures described in this specification using ASN.1 as defined | |||
| in X.680. | in X.680. | |||
| ClearanceConstraints { iso(1) identified-organization(3) dod(6) | ClearanceConstraints { iso(1) identified-organization(3) dod(6) | |||
| internet(1) security(5) mechanisms(5) pkix(7) mod(0) 46 } | internet(1) security(5) mechanisms(5) pkix(7) mod(0) 46 } | |||
| skipping to change at page 17, line 25 ¶ | skipping to change at page 18, line 25 ¶ | |||
| BEGIN | BEGIN | |||
| -- EXPORTS ALL -- | -- EXPORTS ALL -- | |||
| IMPORTS | IMPORTS | |||
| -- IMPORTS from [PKI-ASN] | -- IMPORTS from [PKI-ASN] | |||
| id-at-clearance, Clearance | id-at-clearance, Clearance | |||
| FROM PKIXAttributeCertificate | FROM PKIXAttributeCertificate-2009 | |||
| { iso(1) identified-organization(3) dod(6) internet(1) | { iso(1) identified-organization(3) dod(6) internet(1) | |||
| security(5) mechanisms(5) pkix(7) id-mod(0) | security(5) mechanisms(5) pkix(7) id-mod(0) | |||
| id-mod-attribute-cert(12) | id-mod-attribute-cert-02(47) | |||
| } | } | |||
| -- IMPORTS from [PKI-ASN] | -- IMPORTS from [PKI-ASN] | |||
| EXTENSION | EXTENSION, SECURITY-CATEGORY | |||
| FROM PKIX-CommonTypes | FROM PKIX-CommonTypes-2009 | |||
| { iso(1) identified-organization(3) dod(6) internet(1) | { iso(1) identified-organization(3) dod(6) internet(1) | |||
| security(5) mechanisms(5) pkix(7) id-mod(0) | security(5) mechanisms(5) pkix(7) id-mod(0) | |||
| id-mod-pkixCommon(43) | id-mod-pkixCommon-02(57) | |||
| } | } | |||
| ; | ; | |||
| -- Clearance attribute OID and syntax | -- Clearance attribute OID and syntax | |||
| -- The following is a '93 version for clearance. | -- The following is a '02 version for clearance. | |||
| -- It is included for convenience. | -- It is included for convenience. | |||
| -- id-at-clearance OBJECT IDENTIFIER ::= | -- id-at-clearance OBJECT IDENTIFIER ::= | |||
| -- { joint-iso-ccitt(2) ds(5) attributeTypes(4) clearance (55) } | -- { joint-iso-ccitt(2) ds(5) attributeTypes(4) clearance (55) } | |||
| -- Clearance ::= SEQUENCE { | -- Clearance ::= SEQUENCE { | |||
| -- policyId OBJECT IDENTIFIER, | -- policyId OBJECT IDENTIFIER, | |||
| -- classList ClassList DEFAULT {unclassified}, | -- classList ClassList DEFAULT {unclassified}, | |||
| -- securityCategories SET OF SecurityCategory OPTIONAL | -- securityCategories SET OF SecurityCategory | |||
| -- {{SupportSecurityCategories }} OPTIONAL | ||||
| -- } | -- } | |||
| -- ClassList ::= BIT STRING { | -- ClassList ::= BIT STRING { | |||
| -- unmarked (0), | -- unmarked (0), | |||
| -- unclassified (1), | -- unclassified (1), | |||
| -- restricted (2), | -- restricted (2), | |||
| -- confidential (3), | -- confidential (3), | |||
| -- secret (4), | -- secret (4), | |||
| -- topSecret (5) | -- topSecret (5) | |||
| -- } | -- } | |||
| -- SECURITY-CATEGORY ::= TYPE-IDENTIFIER | -- SECURITY-CATEGORY ::= TYPE-IDENTIFIER | |||
| -- SecurityCategory ::= SEQUENCE { | -- NOTE that the module SecurityCategory is taken from a module | |||
| -- type [0] | -- that uses EXPLICIT tags [PKI-ASN]. If Clearance was not imported | |||
| -- TYPE-IDENTIFIER.&id({SupportedSecurityCategories}), | -- from [PKI-ASN] and the comments were removed from the ASN.1 | |||
| -- value [1] | -- contained herein, then the IMPLICIT in type could also be removed | |||
| -- EXPLICIT TYPE-IDENTIFIER.&Type | -- with no impact on the encoding. | |||
| -- ({SupportedSecurityCategories}{@type}) | ||||
| -- SecurityCategory { SECURITY-CATEGORY:Supported } ::= SEQUENCE { | ||||
| -- type [0] IMPLICIT SECURITY-CATEGORY.&id({Supported}), | ||||
| -- value [1] EXPLICIT SECURITY-CATEGORY.&Type | ||||
| -- ({Supported}{@type}) | ||||
| -- } | -- } | |||
| -- Authority Clearance Constraints certificate extension OID | -- Authority Clearance Constraints certificate extension OID | |||
| -- and syntax | -- and syntax | |||
| id-pe-clearanceConstraints OBJECT IDENTIFIER ::= | id-pe-clearanceConstraints OBJECT IDENTIFIER ::= | |||
| { iso(1) identified-organization(3) dod(6) internet(1) security(5) | { iso(1) identified-organization(3) dod(6) internet(1) security(5) | |||
| mechanisms(5) pkix(7) pe(1) 21 } | mechanisms(5) pkix(7) pe(1) 21 } | |||
| authorityClearanceConstraints EXTENSION ::= { | authorityClearanceConstraints EXTENSION ::= { | |||
| SYNTAX AuthorityClearanceConstraints | SYNTAX AuthorityClearanceConstraints | |||
| IDENTIFIED BY id-pe-clearanceConstraints | IDENTIFIED BY id-pe-clearanceConstraints | |||
| } | } | |||
| AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance | AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance | |||
| END | END | |||
| Author's Addresses | Authors' Addresses | |||
| Sean Turner | Sean Turner | |||
| IECA, Inc. | IECA, Inc. | |||
| 3057 Nutley Street, Suite 106 | 3057 Nutley Street, Suite 106 | |||
| Fairfax, VA 22031 | Fairfax, VA 22031 | |||
| USA | USA | |||
| EMail: turners@ieca.com | EMail: turners@ieca.com | |||
| Santosh Chokhani | Santosh Chokhani | |||
| CygnaCom Solutions, Inc. | CygnaCom Solutions, Inc. | |||
| Email: SChokhani@cygnacom.com | EMail: SChokhani@cygnacom.com | |||
| End of changes. 77 change blocks. | ||||
| 143 lines changed or deleted | 176 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||