Clearance Attribute and Authority Clearance Constraints Certificate Extension
Extracted elements (24)
Any effective-clearance calculation algorithm that computes the intersection of the subject's Clearance, the TA's ACC, user input, and all intermediate CA/AA ACC extensions, and produces the same outcome as the algorithm described herein, is considered compliant. This allows implementors flexibility in the order or structure of the computation.
Placement of the Clearance attribute in PKCs is preferred when clearance information is relatively static, can be verified during PKC issuance (e.g., using local databases), or when revocation of the PKC itself is acceptable when clearance changes. Placement in ACs is preferred when clearance information is dynamic and changes should not trigger PKC revocation, or when clearance cannot be verified at PKC issuance time.
Since RFC 5755 does not permit a chain of ACs, the Authority Clearance Constraints extension may only appear in PKCs of a CA or AA (not in ACs themselves). The extension may also appear in or be associated with a trust anchor.
This document augments the certification path validation rules for PKCs defined in RFC 5280 and for ACs defined in RFC 5755. It adds the ability to provide and process Authority Clearance Constraints as an additional input to the certification path processing engine and requires processing of Authority Clearance Constraints present with trust anchor information.
A certificate MUST include either zero or one instance of the Clearance attribute. If the Clearance attribute is present, it MUST contain a single value.
A trust anchor, CA PKC, or AA PKC MUST include either zero or one instance of the Authority Clearance Constraints certificate extension. The sequence MUST NOT include more than one entry with the same policyId; if duplicates exist, the certification path is rejected.
The Authority Clearance Constraints certificate extension MAY be critical or non-critical.
When processing Authority Clearance Constraints certificate extensions to validate a Clearance attribute in an end PKC, the processing described in Section 4.1.1 or an equivalent algorithm MUST be performed in addition to the certification path validation.
When processing Authority Clearance Constraints for validating a Clearance attribute in an AC, the processing described in Section 5.1.1 or an equivalent algorithm MUST be performed in addition to the certification path validation.
A recommended securityCategories object is defined as 'recommended-category SECURITY-CATEGORY ::= { BIT STRING IDENTIFIED BY OID }'. The type-specific intersection for this type is a bitwise AND of the two BIT STRING values; an all-zeros result is treated as an empty intersection.
The Clearance attribute indicates the security policy, clearance levels, and additional authorization information held by the certificate subject. It may appear in the subject directory attributes extension of a PKC or in the attributes field of an AC. Its three fields are: policyId (identifies the security policy), classList (security classifications), and securityCategories (additional authorization information).
The intersection of permitted-clearances and an Authority Clearance Constraints extension is computed by: checking for duplicate policyIds (fail if found); if permitted-clearances is all-clearances, assign temp-clearances directly; otherwise intersect by AND-ing classList bits per policyId and computing securityCategories intersection per Section 7, removing any policyId with no remaining classList bits.
The securityCategories intersection algorithm has idempotent, associative, and commutative properties. It computes an intersection of two SETs by: first adding elements with identical type OID and value in both sets; then for known type OIDs performing type-specific intersection; unknown type OIDs are excluded from the intersection result.
The Authority Clearance Constraints certificate extension is identified by OID id-pe-authorityClearanceConstraints (also aliased id-pe-clearanceConstraints in the ASN.1 module) ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) pe(1) 21 }.
The Clearance attribute is identified by OID id-at-clearance ::= { joint-iso-ccitt(2) ds(5) attributeTypes(4) clearance(55) }, defined in RFC 5912 as the normative source.
Absence of the Authority Clearance Constraints extension in a TA, CA certificate, or AA certificate means that the subject Authority is not constrained with respect to clearance. Absence of the Clearance attribute in a certificate means the subject has not been assigned any clearance.
If the local security policy considers the clearance held by a subject or those supported by a CA or AA to be sensitive, then the Clearance attribute or Authority Clearance Constraints should only be included if the subject's and Authority's certificates can be privacy protected. Distribution of trust anchors and associated Authority Clearance Constraints must also be privacy protected in this case.
AC certification path processing collects Authority Clearance Constraints from the user input, trust anchor, and all PKCs in the AA PKC certification path (including the AA PKC itself). The AC's Clearance attribute is then intersected with the resulting permitted-clearances state variable to produce effective-clearance.
PKC certification path processing maintains a single state variable permitted-clearances, initialized to user input or all-clearances. The variable is updated by processing the trust anchor's ACC extension and each intermediate PKC's ACC extension. At wrap-up, the end PKC's Clearance is intersected with permitted-clearances to yield effective-clearance. Outputs: effective-clearance and success/failure with reason code.
Wrap Up Clearance procedure: verify effective-clearance has at most one value; if permitted-clearances is empty list, return empty effective-clearance with success; if all-clearances, return success; otherwise intersect classList bits (AND) and securityCategories between effective-clearance and permitted-clearances for the matching policyId. If no classList bits remain set, return empty effective-clearance.
Wrap-up procedure for PKC: verify end PKC has at most one Clearance attribute (else fail with 'multiple instances'); if absent, effective-clearance is empty and exit success; otherwise set effective-clearance to the Clearance attribute and perform the Wrap Up Clearance procedure (Section 4.1.1.5.1) to intersect with permitted-clearances.
AuthorityClearanceConstraints is encoded as a SEQUENCE SIZE (1..MAX) OF Clearance, identified by OID id-pe-authorityClearanceConstraints ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) pe(1) 21 }.
ClassList is a BIT STRING with six named bits: unmarked(0), unclassified(1), restricted(2), confidential(3), secret(4), topSecret(5). Additional bits may be defined by an organizational security policy.
The Clearance attribute is encoded as an ASN.1 SEQUENCE with fields: policyId (OBJECT IDENTIFIER), classList (ClassList BIT STRING, DEFAULT {unclassified}), and securityCategories (SET OF SecurityCategory, OPTIONAL). The OID id-at-clearance is joint-iso-ccitt(2) ds(5) attributeTypes(4) clearance(55).