< draft-turner-caclearanceconstraints-00.txt   draft-turner-caclearanceconstraints-01.txt >
Network Working Group Sean Turner Network Working Group Sean Turner
Internet Draft IECA Internet Draft IECA
Intended Status: Standard Track Santosh Chokhani Intended Status: Standard Track Santosh Chokhani
Orion Security Solutions CygnaCom Solutions
Expires: June 5, 2008 December 5, 2007 Expires: January 14, 2009 July 14, 2008
Clearance and CA Clearance Constraints Certificate Extensions Clearance and CA Clearance Constraints Certificate Extensions
draft-turner-caclearanceconstraints-00.txt draft-turner-caclearanceconstraints-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 June 5, 2008. This Internet-Draft will expire on January 14, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines the syntax and semantics for the Clearance and This document defines the syntax and semantics for the Clearance
the Certification Authority (CA) Clearance Constraints X.509 attribute and the Authority Clearance Constraints extension in X.509
certificate extensions. The Clearance certificate extension is used certificates. The Clearance attribute is used to indicate the
to indicate the clearance held by the subject. The CA Clearance clearance held by the subject. The Clearance attribute may appear in
Constraints certificate extension values in a Trust Anchor (TA) and the subject directory attributes extension of a public key
the CAs in a certification path constrain the effective Clearance of certificate or in the attributes field of an attribute certificate.
the subject of the last certificate in the certification path. The Authority Clearance Constraints certificate extension values in a
Trust Anchor (TA), a CA public key certificate, and an Attribute
Authority (AA) attribute certificate in a certification path
constrain the effective Clearance of the subject of the last
certificate in the certification path.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
1.1. Terminology...............................................3 1.1. Terminology...............................................3
1.2. ASN.1 Syntax Notation.....................................3 1.2. ASN.1 Syntax Notation.....................................3
2. Clearance Certificate Extension................................3 2. Clearance Attribute............................................3
3. CA Clearance Constraints Certificate Extension.................4 3. Authority Clearance Constraints Certificate Extension..........4
4. Clearance and CA Clearance Constraints Processing..............5 4. Clearance and Authority Clearance Constraints Processing.......5
4.1. Collecting Constraints....................................6 4.1. Collecting Constraints....................................6
4.1.1. Certification Path Processing........................6 4.1.1. Certification Path Processing........................6
4.1.1.1. Inputs..........................................6 4.1.1.1. Inputs..........................................6
4.1.1.2. Initialization..................................6 4.1.1.2. Initialization..................................6
4.1.1.2.1. Basic Certificate Processing...............7 4.1.1.3. Basic Certificate Processing....................7
4.1.1.2.2. Preparation for Certificate i+1............8 4.1.1.4. Preparation for Certificate i+1.................8
4.1.1.2.3. Wrap-up Procedure..........................8 4.1.1.5. Wrap-up Procedure...............................8
4.1.1.2.4. Outputs....................................9 4.1.1.6. Outputs.........................................9
5. Security Considerations........................................9 5. Application of Algorithm to Attribute Certificates.............9
6. IANA Considerations...........................................10 6. Security Considerations.......................................10
7. References....................................................10 7. IANA Considerations...........................................10
7.1. Normative References.....................................10 8. References....................................................10
7.2. Informative References...................................10 8.1. Normative References.....................................10
Appendix A. ASN.1 Module.........................................11 8.2. Informative References...................................11
Appendix A. ASN.1 Module.........................................12
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 certificate extension indicates the by the subject. The Clearance attribute indicates the security
security policy, the clearance levels held by the subject, and policy, the clearance levels held by the subject, and additional
additional authorization information held by the subject. This authorization information held by the subject. This specification
specification makes use of the ASN.1 syntax for clearance from makes use of the ASN.1 syntax for clearance from [RFC3281].
[RFC3281].
Some organizations have multiple TAs and/or CAs, 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 or CA should be accepted. For example, values from a particular TA, CA, or AA should be accepted. For
consider the security policies described in [RFC3114], where a example, consider the security policies described in [RFC3114], where
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
CA Clearance Constraints certificate extension would be included in Authority Clearance Constraints certificate extension would be
the CA's certificate. included in the CA's certificate.
Cross-certified domains can also make use of the CA 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.
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 certificate [RFC3280] extensions are defined using ASN.1 All X.509 public key certificate [RFC5280] extensions are defined
[X.680, X.690]. using ASN.1 [X.680]. All X.509 attribute certificate [RFC3281]
extensions are defined using ASN.1 [X.680].
2. Clearance Certificate Extension 2. Clearance Attribute
The Clearance certificate extension in a certificate indicates the The Clearance attribute in a certificate indicates the clearances
clearances held by the subject. It uses the clearance attribute held by the subject. It uses the clearance attribute syntax from
syntax from Section 4.4.6 of [RFC3281] in the Subject Directory Section 4.4.6 of [RFC3281], which is included below for convenience,
Attributes extension. The Clearance certificate extension MUST never in the Attributes field. A certificate MUST include either zero or
be marked critical. It is only meaningful if at least one of the one instance of the Clearance attribute.
following key usage bits is set: digital signature, non-repudiation,
key transport, or key agreement. A certificate MUST include either
zero or one instance of the Clearance certificate extension.
The following object identifier identifies the Clearance certificate The following object identifier identifies the Clearance attribute
extension: (either in the subject directory attributes extension of a public key
certificate or in the Attributes field of an attribute certificate):
id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
ds(5) module(1) selected-attribute-types(5) clearance(55) } ds(5) module(1) selected-attribute-types(5) clearance(55) }
The ASN.1 syntax for the Clearance certificate extension is as The ASN.1 syntax for the Clearance attribute is as follows:
follows:
Clearance ::= SEQUENCE { Clearance ::= SEQUENCE {
policyId [0] OBJECT IDENTIFIER, policyId [0] OBJECT IDENTIFIER,
classList [1] ClassList DEFAULT {unclassified}, classList [1] ClassList DEFAULT {unclassified},
securityCategories [2] SET OF SecurityCategory OPTIONAL securityCategories [2] SET OF SecurityCategory 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)
} }
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
type [0] IMPLICIT OBJECT IDENTIFIER, type [0] IMPLICIT OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type value [1] ANY DEFINED BY type
} }
The fields in Clearance certificate extension take their meaning from The Clearance attribute takes its meaning from Section 4.4.6 of
Section 4.4.6 of [RFC3281], which is repeated here for convenience: [RFC3281], 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 securityCategory 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).
3. CA Clearance Constraints Certificate Extension 3. Authority Clearance Constraints Certificate Extension
The CA Clearance Constraints certificate extension indicates to the The Authority Clearance Constraints certificate extension indicates
relying party what clearances should be acceptable for the subject of to the relying party what clearances should be acceptable for the
the last certificate in the certification path containing the TA or subject of the last certificate in the certification path containing
the CA. It is only meaningful in trust anchor or CA certificates. A the TA, the CA, or the AA. It is only meaningful in trust anchor, CA
trust anchor or CA certificate MUST include either zero or one certificates, or AA certificates. A trust anchor, CA certificate, or
instance of the CA Clearance Constraints certificate extension. The AA certificate MUST include either zero or one instance of the
CA Clearance Constraints certificate extension MAY be critical or Authority Clearance Constraints certificate extension. The Authority
non-critical. Clearance Constraints certificate extension MAY be critical or non-
critical.
Absence of this certificate extension in a CA certificate or in a TA Absence of this certificate extension in a TA, in a CA certificate,
indicates that clearance of the subject of the last certificate in or in an AA certificate indicates that clearance of the subject of
the certification path containing the CA or the TA is not constrained the last certificate in the certification path containing the TA, the
by the respective CA or TA. CA or the AA is not constrained by the respective TA, CA or AA.
The following object identifier identifies the CA Clearance The following object identifier identifies the Authority Clearance
Constraints certificate extension: Constraints certificate extension:
id-ce-caClearanceConstraints OBJECT IDENTIFIER ::= { id-TBSL } id-ce-authorityClearanceConstraints OBJECT IDENTIFIER ::= {
id-TBSL }
The ASN.1 syntax for the CA Clearance Constraints certificate The ASN.1 syntax for the Authority Clearance Constraints certificate
extension is as follows: extension is as follows:
CAClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX)
OF Clearance
The syntax for CA Clearance Constraints certificate extension The syntax for Authority Clearance Constraints certificate extension
contains Clearance values that the CA asserts. The sequence MUST NOT contains Clearance values that the CA or the AA asserts. The
include more than one entry with the same policyId. This constraint sequence MUST NOT include more than one entry with the same policyId.
is enforced during Clearance and CA Clearance Constraints Processing This constraint is enforced during Clearance and Authority Clearance
described below. If more than one entry with the same policyId is Constraints Processing described below. If more than one entry with
present in CAClearanceConstraints certificate extension, the the same policyId is present in AuthorityClearanceConstraints
certification path is rejected. certificate extension, the certification path is rejected.
4. Clearance and CA Clearance Constraints Processing 4. Clearance and Authority Clearance Constraints Processing
CA Clearance Constraints certificate extension processing determines Authority Clearance Constraints certificate extension processing
the effective clearance (henceforth called effective-clearance) for determines the effective clearance (henceforth called effective-
the end certificate. CA Clearance Constraints certificate extension clearance) for the end certificate. Authority Clearance Constraints
in the TA and in each certificate up to but not including the end certificate extension in the TA and in each certificate up to but not
certificate in a certification path impact the effective-clearance. including the end certificate in a certification path impact the
If there is more than one path to the end-entity certificate, each effective-clearance. If there is more than one path to the end-
path is processed independently. The process involves two steps: entity certificate, each path is processed independently. The
process involves two steps:
1) collecting the CA Clearance Constraints; and 1) collecting the Authority Clearance Constraints; and
2) using CA Clearance Constraints in the certification path and the 2) using Authority Clearance Constraints in the certification path
Clearance in the end certificate to determine the effective- and the Clearance in the end certificate to determine the
clearance for the subject of the end certificate. effective-clearance for the subject of the end certificate.
Assuming a certification path consisting of n certificates, the Assuming a certification path consisting of n certificates, the
effective-clearance for the subject of the end certificate is the effective-clearance for the subject of the end certificate is the
intersection of Clearance in the subject certificate, CA Clearance intersection of Clearance in the subject certificate, Authority
Constraints, if present, in trust anchor and all CA Clearance Clearance Constraints, if present, in trust anchor and all Authority
Constraints present in intermediate certificates. Any effective- Clearance Constraints present in intermediate certificates. Any
clearance calculation algorithm that performs this calculation and effective-clearance calculation algorithm that performs this
provides the same outcome as the one from the algorithm described calculation and provides the same outcome as the one from the
herein is considered compliant with the requirements of this RFC. algorithm described herein is considered compliant with the
requirements of this RFC.
When processing a certification path, CA Clearance Constraints are When processing a certification path, Authority Clearance Constraints
maintained in one state variable: permitted-clearances. When are maintained in one state variable: permitted-clearances. When
processing begins, permitted-clearances is initialized to the special processing begins, permitted-clearances is initialized to the special
value all-clearances if CA Clearance Constraints certificate value all-clearances if Authority Clearance Constraints certificate
extension is not present in the trust anchor, otherwise this value is extension is not present in the trust anchor, otherwise this value is
initialized to CA Clearance Constraints associated with the trust initialized to Authority Clearance Constraints associated with the
anchor. The permitted-clearances state variable is updated each time trust anchor. The permitted-clearances state variable is updated
an intermediate certificate that contains a CA Clearance Constraints each time an intermediate certificate that contains an Authority
certificate extension in the path is processed. Clearance Constraints certificate extension in the path is processed.
When processing the end certificate, the value in the Clearance When processing the end certificate, the value in the Clearance
certificate extension in the end certificate is intersected with the certificate extension in the end certificate is intersected with the
permitted-clearances state variable. permitted-clearances state variable.
The output of Clearance and CA Clearance Constraint certificate The output of Clearance and Authority Clearance Constraint
extensions processing is the effective-clearance, which could also be certificate extensions processing is the effective-clearance, which
an empty list; and success or failure with reason code for failure. could also be an empty list; and success or failure with reason code
for failure.
4.1. Collecting Constraints 4.1. Collecting Constraints
CA Clearance Constraints are collected from the trust anchor and the Authority Clearance Constraints are collected from the trust anchor
intermediate certificates in a certification path. and the intermediate certificates in a certification path.
4.1.1. Certification Path Processing 4.1.1. Certification Path Processing
When processing CA Clearance Constraints certificate extension for When processing Authority Clearance Constraints certificate extension
the purposes of validating Clearance in the end certificate, the for the purposes of validating Clearance in the end certificate, the
processing described in this section or an equivalent algorithm MUST processing described in this section or an equivalent algorithm MUST
be included in the certification path validation. The processing is be included in the certification path validation. The processing is
presented as additions to the certification path validation algorithm presented as additions to the certification path validation algorithm
described in section 6 of [RFC3280]. described in section 6 of [RFC5280].
4.1.1.1. Inputs 4.1.1.1. Inputs
Trust anchor information may include the CAClearanceConstraints Trust anchor information may include the
structure to specify CA Clearance Constraints for the trust anchor. AuthorityClearanceConstraints structure to specify Authority
The trust anchor may be constrained or unconstrained. Clearance Constraints for the trust anchor. The trust anchor may be
constrained or unconstrained.
4.1.1.2. Initialization 4.1.1.2. Initialization
Examine the trust anchor and verify that it does not contain more Examine the trust anchor information and verify that it does not
than one instance of CAClearanceConstraints extension. If the trust contain more than one instance of AuthorityClearanceConstraints
anchor contains more than one instance of CAClearanceConstraints extension. If the trust anchor information contains more than one
extension, set effective-clearance to an empty list, set error code instance of AuthorityClearanceConstraints extension, set effective-
to "multiple extension instances", and exit with failure. clearance to an empty list, set error code to "multiple extension
instances", and exit with failure.
Create a state variable named permitted-clearances. If the trust Create a state variable named permitted-clearances. If the trust
anchor contains a CAClearanceConstraints extension, then the initial anchor contains an AuthorityClearanceConstraints extension, then the
value of permitted-clearances is the CAClearanceConstraints extension initial value of permitted-clearances is the
from the trust anchor. AuthorityClearanceConstraints extension from the trust anchor.
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-clearance state variable, set effective-clearance to an permitted-clearance 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 a CAClearanceConstraints If the trust anchor does not contain an AuthorityClearanceConstraints
extension, the permitted-clearances variable is assigned the special extension, the permitted-clearances variable is assigned the special
value all-clearances. value all-clearances.
4.1.1.2.1. Basic Certificate Processing 4.1.1.3. Basic Certificate Processing
If the certificate is the last certificate (i.e., certificate n), If the certificate is the last certificate (i.e., certificate n),
skip the steps listed in this section. skip the steps listed in this section.
Examine the certificate and verify that it does not contain more than Examine the certificate and verify that it does not contain more than
one instance of CAClearanceConstraints extension. If the certificate one instance of AuthorityClearanceConstraints extension. If the
contains more than one instance of CAClearanceConstraints extension, certificate contains more than one instance of
set effective-clearance to an empty list, set error code to "multiple AuthorityClearanceConstraints extension, set effective-clearance to
extension instances", and exit with failure. an empty list, set error code to "multiple extension instances", and
exit with failure.
If the CAClearanceConstraints certificate extension is not present in If the AuthorityClearanceConstraints certificate extension is not
the certificate, no action is taken, and the permitted-clearances present in the certificate, no action is taken, and the permitted-
value is unchanged. clearances value is unchanged.
If the CAClearanceConstraints certificate extension is present in the If the AuthorityClearanceConstraints certificate extension is present
certificate, set the variable temp-clearances to in the certificate, set the variable temp-clearances to
CAClearanceConstraints certificate extension. Examine the temp- AuthorityClearanceConstraints certificate extension. Examine the
clearances for the same Policy ID appearing more then once. If a temp-clearances for the same Policy ID appearing more then once. If
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 CAClearanceConstraints certificate extension is present in the If the AuthorityClearanceConstraints certificate extension is present
certificate and permitted-clearances contains the all-clearances in the certificate and permitted-clearances contains the all-
special value, then assign permitted-clearances the value of the clearances special value, then assign permitted-clearances the value
temp-clearances. of the temp-clearances.
If the CAClearanceConstraints certificate extension is present in the If the AuthorityClearanceConstraints certificate extension is present
certificate and permitted-clearances does not contain the all- in the certificate 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:
skipping to change at page 8, line 22 skipping to change at page 8, line 34
-- 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.
-- Calculate securityCategories intersection in accordance with -- Calculate securityCategories intersection in accordance with
guidelines associated with the security policy represented by guidelines associated with the security policy represented by
the policyID. the policyID.
4.1.1.2.2. Preparation for Certificate i+1 4.1.1.4. Preparation for Certificate i+1
No additional action associated with the Clearance or No additional action associated with the Clearance attribute or
CAClearanceConstraints certificate extensions is taken during this AuthorityClearanceConstraints certificate extensions is taken during
phase of certification path validation as described in section 6 of this phase of certification path validation as described in section 6
[RFC3280]. of [RFC5280].
4.1.1.2.3. Wrap-up Procedure 4.1.1.5. Wrap-up Procedure
To complete the processing, perform the following steps for the last To complete the processing, perform the following steps for the last
certificate (i.e., certificate n). certificate (i.e., certificate n).
Examine the certificate and verify that it does not contain more than Examine the certificate and verify that it does not contain more than
one instance of Clearance extension. If the certificate contains one instance of Clearance attribute. If the certificate contains
more than one instance of Clearance extension, set effective- more than one instance of Clearance attribute, set effective-
clearance to an empty list, set error code to "multiple extension clearance to an empty list, set error code to "multiple instances of
instances", and exit with failure. an attribute", and exit with failure.
If the Clearance certificate extension is not present in the end If the Clearance attribute is not present in the end certificate, set
certificate, set effective-clearance to an empty list and exit with effective-clearance to an empty list and exit with success.
success.
Set effective-clearance to the value from the Clearance certificate Set effective-clearance to the value from the Clearance attribute in
extension in the end certificate. Let us say policyID in effective- the end certificate. Let us say policyID in effective-clearance is
clearance is X. X.
If permitted-clearance is an empty list, set effective-clearance to If permitted-clearance 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-clearance has special value of all-clearances, exit If the permitted-clearance has special value of all-clearances, exit
with success. with success.
If the policyID X in effective-clearance is absent from the If the policyID X in effective-clearance is absent from the
permitted-clearance, set effective-clearance to an empty list and permitted-clearance, set effective-clearance to an empty list and
exit with success. exit with success.
skipping to change at page 9, line 29 skipping to change at page 9, line 39
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 securityCategories in effective-clearance as an intersection of Set securityCategories in effective-clearance as an intersection of
the securityCategories in the effective-clearance and the securityCategories in the effective-clearance and
securityCategories in the permitted-clearances for policyID X as securityCategories in the permitted-clearances for policyID X as
defined by the policyID X. defined by the policyID X.
Exit with Success Exit with Success
4.1.1.2.4. 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. Security Considerations 5. Application of Algorithm to Attribute Certificates
The algorithm presented in Section 4 is public key certificate
centric. Its application to attribute certificates is
straightforward as described below.
If the current [RFC3281] constraint of not having chain of attribute
certificate chain is observed, the AC Issuer (i.e., AA) Authority
Clearance Constraints is used as the TA Authority Clearance
Constraints for the initialization step described in Section 4.1.1.2.
Since there is no intermediate steps, sections 4.1.1.3. and 4.1.1.4.
will not be executed.
If the current [RFC3281] constraint of not having chain of attribute
certificate chain is removed, the Source of Authority in the
Attribute Certificate chain becomes the TA for the purpose of Section
4.
6. Security Considerations
Certificate issuers must recognize that absence of the Certificate issuers must recognize that absence of the
CAClearanceConstraints in a CA certificate means that in terms of the AuthorityClearanceConstraints in a CA or AA certificate means that in
clearance, the subject CA is not constrained. terms of the clearance, the subject Authority is not constrained.
Absence of Clearance extension in a certificate means that the Absence of Clearance attribute in a certificate means that the
subject has not been assigned any clearance. subject has not been assigned any clearance.
If there is no Clearance associated with a TA, it means that the TA If there is no Clearance associated with a TA, it means that the TA
has not been assigned any clearance. has not been assigned any clearance.
If the local security policy considers the clearance held by a If the local security policy considers the clearance held by a
subject or those supported by a CA to be sensitive, then the subject or those supported by a CA or AA to be sensitive, then the
Clearance or CA Clearance Constraints should only be included if the Clearance attribute or Authority Clearance Constraints should only be
subject's and CA's certificate can be privacy protected. Also in included if the subject's and Authority's certificate can be privacy
this case, distribution of trust anchors and associated CA Clearance protected. Also in this case, distribution of trust anchors and
Constraints extension or Clearance must also be privacy protected. associated Authority Clearance Constraints extension or Clearance
must also be privacy protected.
6. IANA Considerations 7. IANA Considerations
None. Please remove this section prior to publication as an RFC. None. Please remove this section prior to publication as an RFC.
7. References 8. References
7.1. Normative References 8.1. Normative References
[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.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [RFC5280] Cooper, D. et. al., "Internet X.509 Public Key
X.509 Public Key Infrastructure Certificate and Infrastructure Certificate and Certification Revocation
Certification Revocation List (CRL) Profile", RFC 3280, List (CRL) Profile", RFC 5280, May 2008.
April 2002.
[RFC3281] Farrell, S., and Housley, R., "An Internet Attribute [RFC3281] Farrell, S., and Housley, R., "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April Certificate Profile for Authorization", RFC 3281, April
2002. 2002.
[X.680] ITU-T Recommendation X.680: Information Technology - [X.680] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1997.
Abstract Syntax Notation One, 1997. Information Technology - Abstract Syntax Notation One.
[X.690] ITU-T Recommendation X.690 Information Technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER), 1997.
7.2. Informative References 8.2. Informative References
[RFC3114] Nicolls, W., "Implementing Company Classification Policy [RFC3114] Nicolls, W., "Implementing Company Classification Policy
with S/MIME Security Label", RFC3114, May 2002. with S/MIME Security Label", RFC3114, May 2002.
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.
Clearance-CAClearanceConstraints93 { id-TBSL } Clearance-AuthorityClearanceConstraints93 { id-TBSL }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL -- -- EXPORTS ALL --
IMPORTS IMPORTS
-- IMPORTS from RFC3281 -- IMPORTS from [RFC3281]
Clearance id-at-clearance, Clearance
FROM PKIXAttributeCertificate FROM PKIXAttributeCertificate
{ 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(12)
} }
-- IMPORTS from [RFC5280]
EXTENSION EXTENSION
FROM PKIX1Explicit93 FROM PKIX1Explicit93
{ 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-pkix1-explicit-93(3) id-pkix1-explicit-93(3)
} }
; ;
-- Clearance certificate extension OID and syntax -- Clearance attribute OID and syntax
clearance EXTENSION ::= {
SYNTAX Clearance
IDENTIFIED BY id-at-clearance
}
-- The following is a '93 version for clearance. -- The following is a '93 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) module(1) selected-attribute-types(5) -- { joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
-- clearance (55) -- clearance (55)
-- } -- }
-- Clearance ::= SEQUENCE { -- Clearance ::= SEQUENCE {
-- policyId [0] OBJECT IDENTIFIER, -- policyId [0] OBJECT IDENTIFIER,
-- classList [1] ClassList DEFAULT {unclassified}, -- classList [1] ClassList DEFAULT {unclassified},
-- securityCategories [2] SET OF SecurityCategory OPTIONAL -- securityCategories [2] SET OF SecurityCategory OPTIONAL
-- } -- }
-- ClassList ::= BIT STRING { -- ClassList ::= BIT STRING {
-- unmarked (0), -- unmarked (0),
-- unclassified (1), -- unclassified (1),
-- restricted (2), -- restricted (2),
skipping to change at page 12, line 31 skipping to change at page 13, line 28
-- SECURITY-CATEGORY ::= TYPE-IDENTIFIER -- SECURITY-CATEGORY ::= TYPE-IDENTIFIER
-- SecurityCategory ::= SEQUENCE { -- SecurityCategory ::= SEQUENCE {
-- type [0] -- type [0]
-- IMPLICIT TYPE-IDENTIFIER.&id({SupportedSecurityCategories}), -- IMPLICIT TYPE-IDENTIFIER.&id({SupportedSecurityCategories}),
-- value [1] -- value [1]
-- TYPE-IDENTIFIER.&Type({SupportedSecurityCategories}{@type}) -- TYPE-IDENTIFIER.&Type({SupportedSecurityCategories}{@type})
-- } -- }
-- CA Clearance Constraints certificate extension OID and syntax -- Authority Clearance Constraints certificate extension OID
-- and syntax
id-ce-caClearanceConstraints OBJECT IDENTIFIER ::= { id-TBSL } id-ce-AuthorityClearanceConstraints OBJECT IDENTIFIER ::= { id-TBSL }
caClearanceConstraints EXTENSION ::= { AuthorityClearanceConstraints EXTENSION ::= {
SYNTAX CAClearanceConstraints SYNTAX AuthorityClearanceConstraints
IDENTIFIED BY id-ce-caClearanceConstraints IDENTIFIED BY id-ce-AuthorityClearanceConstraints
} }
CAClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance
AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance
END END
Author's Addresses Author's 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
Orion Security Solutions, Inc. CygnaCom Solutions, Inc.
Email: chokhani@orionsec.com Email: schokhani@ocygnacom.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 14, line 42 skipping to change at page 15, line 42
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
 End of changes. 81 change blocks. 
207 lines changed or deleted 227 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/