Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5913 IECA
Category: Standards Track S. Chokhani
ISSN: 2070-1721 Cygnacom Solutions
June 2010
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5913 IECA
Category: Standards Track S. Chokhani
ISSN: 2070-1721 Cygnacom Solutions
June 2010
Clearance Attribute and Authority Clearance Constraints Certificate Extension
许可属性和权限许可约束证书扩展
Abstract
摘要
This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate. The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject.
本文档定义了X.509证书中许可属性和权限许可约束扩展的语法和语义。“清除”属性用于指示主体持有的清除。许可属性可能出现在公钥证书的主题目录属性扩展或属性证书的属性字段中。信任锚（TA）、证书颁发机构（CA）公钥证书以及给定主题的证书路径中的属性颁发机构（AA）公钥证书中的权限清除约束证书扩展值约束主题的有效清除。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5913.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5913.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. ASN.1 Syntax Notation ......................................4
2. Clearance Attribute .............................................4
3. Authority Clearance Constraints Certificate Extension ...........5
4. Processing Clearance and Authority Clearance Constraints
in a PKC ........................................................6
4.1. Collecting Constraints .....................................7
4.1.1. Certification Path Processing .......................7
4.1.1.1. Inputs .....................................8
4.1.1.2. Initialization .............................8
4.1.1.3. Basic Certificate Processing ...............8
4.1.1.4. Preparation for Certificate i+1 ............9
4.1.1.5. Wrap-up Procedure ..........................9
4.1.1.5.1. Wrap Up Clearance ...............9
4.1.1.6. Outputs ...................................10
5. Clearance and Authority Clearance Constraints
Processing in AC ...............................................10
5.1. Collecting Constraints ....................................11
5.1.1. Certification Path Processing ......................11
5.1.1.1. Inputs ....................................11
5.1.1.2. Initialization ............................11
5.1.1.3. Basic PKC Processing ......................12
5.1.1.4. Preparation for Certificate i+1 ...........12
5.1.1.5. Wrap-up Procedure .........................12
5.1.1.5.1. Wrap Up Clearance ..............12
5.1.1.6. Outputs ...................................12
6. Computing the Intersection of permitted-clearances and
Authority Clearance Constraints Extension ......................12
7. Computing the Intersection of securityCategories ...............13
8. Recommended securityCategories .................................15
9. Security Considerations ........................................15
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................16
Appendix A. ASN.1 Module ..........................................17
Acknowledgments ...................................................19
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. ASN.1 Syntax Notation ......................................4
2. Clearance Attribute .............................................4
3. Authority Clearance Constraints Certificate Extension ...........5
4. Processing Clearance and Authority Clearance Constraints
in a PKC ........................................................6
4.1. Collecting Constraints .....................................7
4.1.1. Certification Path Processing .......................7
4.1.1.1. Inputs .....................................8
4.1.1.2. Initialization .............................8
4.1.1.3. Basic Certificate Processing ...............8
4.1.1.4. Preparation for Certificate i+1 ............9
4.1.1.5. Wrap-up Procedure ..........................9
4.1.1.5.1. Wrap Up Clearance ...............9
4.1.1.6. Outputs ...................................10
5. Clearance and Authority Clearance Constraints
Processing in AC ...............................................10
5.1. Collecting Constraints ....................................11
5.1.1. Certification Path Processing ......................11
5.1.1.1. Inputs ....................................11
5.1.1.2. Initialization ............................11
5.1.1.3. Basic PKC Processing ......................12
5.1.1.4. Preparation for Certificate i+1 ...........12
5.1.1.5. Wrap-up Procedure .........................12
5.1.1.5.1. Wrap Up Clearance ..............12
5.1.1.6. Outputs ...................................12
6. Computing the Intersection of permitted-clearances and
Authority Clearance Constraints Extension ......................12
7. Computing the Intersection of securityCategories ...............13
8. Recommended securityCategories .................................15
9. Security Considerations ........................................15
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................16
Appendix A. ASN.1 Module ..........................................17
Acknowledgments ...................................................19
Organizations that have implemented a security policy can issue certificates that include an indication of the clearance values held by the subject. The Clearance attribute indicates the security policy, the clearance levels held by the subject, and additional authorization information held by the subject. This specification makes use of the ASN.1 syntax for clearance from [RFC5912].
已实施安全策略的组织可以颁发证书，其中包括主体持有的许可值指示。许可属性表示安全策略、主体持有的许可级别以及主体持有的其他授权信息。本规范使用ASN.1语法从[RFC5912]获得许可。
The Clearance attribute may be placed in the subject directory attributes extension of a Public Key Certificate (PKC) or may be placed in a separate attribute certificate (AC).
许可属性可以放在公钥证书（PKC）的主题目录属性扩展中，也可以放在单独的属性证书（AC）中。
The placement of the Clearance attribute in PKCs is suitable 1) when the clearance information is relatively static and can be verified as part of the PKC issuance process (e.g., using local databases) or 2) when the credentials such as PKCs need to be revoked when the clearance information changes. The Clearance attribute may also be included to simplify the infrastructure, to reduce the infrastructure design cost, or to reduce the infrastructure operations cost. An example of placement of the Clearance attribute in PKCs in operational Public Key Infrastructure (PKI) is the Defense Messaging Service. An example of placement of attributes in PKCs is Qualified Certificates [RFC3739].
1）当许可信息相对静态且可作为PKC发布流程的一部分进行验证（例如，使用本地数据库）时，或2）当许可信息发生变化时，需要撤销PKC等凭证时，在PKCs中放置许可属性是合适的。为了简化基础设施、降低基础设施设计成本或降低基础设施运营成本，还可以包括清除属性。国防消息服务是将许可属性放置在PKCs中操作公钥基础设施（PKI）中的一个示例。PKCs中属性放置的一个示例是合格证书[RFC3739]。
The placement of Clearance attributes in ACs is desirable when the clearance information is relatively dynamic and changes in the clearance information do not require revocation of credentials such as PKCs, or the clearance information cannot be verified as part of the PKC issuance process.
当许可信息是相对动态的，并且许可信息的更改不需要撤销PKC等凭证，或者许可信息无法作为PKC发布过程的一部分进行验证时，需要在ACs中放置许可属性。
Since [RFC5755] does not permit a chain of ACs, the Authority Clearance Constraints extension may only appear in the PKCs of a Certification Authority (CA) or Attribute Authority (AA). The Authority Clearance Constraints extension may also appear in a trust anchor (TA) or may be associated with a TA.
由于[RFC5755]不允许ACs链，因此权限清除约束扩展只能出现在证书颁发机构（CA）或属性颁发机构（AA）的PKC中。授权许可约束扩展也可能出现在信任锚（TA）中，或者可能与TA关联。
Some organizations have multiple TAs, CAs, and/or AAs, and these organizations may wish to indicate to relying parties which clearance values from a particular TA, CA, or AA should be accepted. For example, consider the security policies described in [RFC3114], where a security policy has been defined for Amoco with three security classification values (HIGHLY CONFIDENTIAL, CONFIDENTIAL, and GENERAL). To constrain a CA for just one security classification, the Authority Clearance Constraints certificate extension would be included in the CA's PKC.
一些组织有多个TA、CA和/或AAs，这些组织可能希望向依赖方表明应接受特定TA、CA或AA的清除值。例如，考虑[RCFC1414]中描述的安全策略，其中已经为AMOCO定义了安全策略，具有三个安全分类值（高度机密性、机密性和一般性）。为了仅为一个安全分类约束CA，CA的PKC中将包含授权许可约束证书扩展。
Cross-certified domains can also make use of the Authority Clearance Constraints certificate extension to indicate which clearance values should be acceptable to relying parties.
交叉认证域还可以使用授权许可约束证书扩展来指示依赖方应接受哪些许可值。
This document augments the certification path validation rules for PKCs (in [RFC5280]) and ACs (in [RFC5755]).
本文档扩充了PKCs（在[RFC5280]中）和ACs（在[RFC5755]中）的认证路径验证规则。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
All X.509 PKC [RFC5280] extensions are defined using ASN.1 [X.680]. All X.509 AC [RFC5755] extensions are defined using ASN.1 [X.680]. Note that [X.680] is the 2002 version of ASN.1, which is the most recent version with freeware compiler support.
所有X.509 PKC[RFC5280]扩展都是使用ASN.1[X.680]定义的。所有X.509 AC[RFC5755]扩展都使用ASN.1[X.680]定义。请注意，[X.680]是ASN.1的2002版本，这是支持免费编译器的最新版本。
The Clearance attribute in a certificate indicates the clearances held by the subject. It uses the clearance attribute syntax, whose semantics are defined in [RFC5755], in the Attributes field. 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.
证书中的许可属性表示主体持有的许可。它在属性字段中使用清除属性语法，其语义在[RFC5755]中定义。证书必须包含零个或一个清除属性实例。如果存在“清除”属性，则该属性必须包含单个值。
The following object identifier identifies the Clearance attribute (either in the subject directory attributes extension of a PKC or in the Attributes field of an AC):
以下对象标识符标识清除属性（在PKC的主题目录属性扩展或AC的属性字段中）：
id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
ds(5) attributeTypes(4) clearance(55) }
id-at-clearance OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
ds(5) attributeTypes(4) clearance(55) }
The ASN.1 syntax for the Clearance attribute is defined in [RFC5912] and that RFC provides the normative definition. The ASN.1 syntax for Clearance attribute is as follows:
[RFC5912]中定义了清除属性的ASN.1语法，RFC提供了规范性定义。清除属性的ASN.1语法如下：
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory
{{ SupportedSecurityCategories }} OPTIONAL
}
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory
{{ SupportedSecurityCategories }} OPTIONAL
}
ClassList ::= BIT STRING {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
topSecret (5)
}
ClassList ::= BIT STRING {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
topSecret (5)
}
SECURITY-CATEGORY ::= TYPE-IDENTIFIER
SECURITY-CATEGORY ::= TYPE-IDENTIFIER
SecurityCategory { SECURITY-CATEGORY:Supported }::= SEQUENCE {
type [0] IMPLICIT SECURITY-CATEGORY.&id({Supported}),
value [1] EXPLICIT SECURITY-CATEGORY.&Type
({Supported}{@type})
}
SecurityCategory { SECURITY-CATEGORY:Supported }::= SEQUENCE {
type [0] IMPLICIT SECURITY-CATEGORY.&id({Supported}),
value [1] EXPLICIT SECURITY-CATEGORY.&Type
({Supported}{@type})
}
NOTE: SecurityCategory is shown exactly as it is in [RFC5912]. That module is an EXPLICIT tagged module, whereas the module contained in this document is an IMPLICIT tagged module.
注：SecurityCategory的显示与[RFC5912]中的显示完全相同。该模块是一个显式标记模块，而本文档中包含的模块是一个隐式标记模块。
The Clearance attribute takes its meaning from Section 4.4.6 of [RFC5755], which is repeated here for convenience:
清除属性的含义来自[RFC5755]第4.4.6节，为方便起见，此处重复该节：
- policyId identifies the security policy to which the clearance relates. The policyId indicates the semantics of the classList and securityCategories fields.
- policyId标识与许可相关的安全策略。policyId指示classList和securityCategories字段的语义。
- classList identifies the security classifications. Six basic values are defined in bit positions 0 through 5, and more may be defined by an organizational security policy.
- classList标识安全分类。位位置0到5中定义了六个基本值，组织安全策略可以定义更多的基本值。
- securityCategories provides additional authorization information.
- securityCategories提供了额外的授权信息。
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 effective clearance (also defined as effective-clearance for a certification path).
如果直接使用信任锚点的公钥，则与信任锚点关联的清除（如果有）应用作有效清除（也定义为证书路径的有效清除）。
The Authority Clearance Constraints certificate extension indicates to the relying party what clearances should be acceptable for the subject of the AC or the subject of the last certificate in a PKC certification path. It is only meaningful in a trust anchor, a CA PKC, or an AA PKC. A trust anchor, CA PKC, or AA PKC MUST include
当局许可限制证书扩展向依赖方指出，对于AC的主体或PKC认证路径中最后一个证书的主体，应接受哪些许可。它仅在信任锚、CA PKC或AA PKC中有意义。信任锚、CA PKC或AA PKC必须包括
either zero or one instance of the Authority Clearance Constraints certificate extension. The Authority Clearance Constraints certificate extension MAY be critical or non-critical.
权限许可约束证书扩展的零或一个实例。授权许可限制证书扩展可能是关键的或非关键的。
Absence of this certificate extension in a TA, a CA PKC, or an AA PKC indicates that clearance of the subject of the AC or the subject of the last certificate in a PKC certification path containing the TA, the CA, or the AA is not constrained by the respective TA, CA, or AA.
TA、CA PKC或AA PKC中缺少此证书扩展表示在包含TA、CA或AA的PKC证书路径中清除AC的主题或最后一个证书的主题不受相应TA、CA或AA的约束。
The following object identifier identifies the Authority Clearance Constraints certificate extension:
以下对象标识符标识授权许可约束证书扩展：
id-pe-authorityClearanceConstraints OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) pe(1) 21 }
id-pe-authorityClearanceConstraints OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) pe(1) 21 }
The ASN.1 syntax for the Authority Clearance Constraints certificate extension is as follows:
授权许可约束证书扩展的ASN.1语法如下：
AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF
Clearance
AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF
Clearance
The syntax for the Authority Clearance Constraints certificate extension contains Clearances that the CA or the AA asserts. The sequence MUST NOT include more than one entry with the same policyId. This constraint is enforced during Clearance and Authority Clearance Constraints Processing as described below. If more than one entry with the same policyId is present in the Authority Clearance Constraints certificate extension, the certification path is rejected.
授权许可约束证书扩展的语法包含CA或AA声明的许可。序列不得包含多个具有相同policyId的条目。此约束在清除和权限清除约束处理期间强制执行，如下所述。如果授权许可约束证书扩展中存在多个具有相同policyId的条目，则证书路径将被拒绝。
This section describes the certification path processing when Clearance is asserted in the PKC under consideration.
本节描述在考虑中的PKC中声明许可时的证书路径处理。
User input, the Authority Clearance Constraints certificate extension, and Clearance attribute processing determines the effective clearance (henceforth called effective-clearance) for the end PKC. User input and the Authority Clearance Constraints certificate extension in the TA and in each PKC (up to but not including the end PKC) in a PKC certification path impact the effective-clearance. If there is more than one path to the end PKC, each path is processed independently. The process involves two steps:
用户输入、权限许可约束证书扩展和许可属性处理确定最终PKC的有效许可（以下称为有效许可）。TA和PKC认证路径中每个PKC（直至但不包括最终PKC）中的用户输入和权限许可限制证书扩展会影响有效许可。如果有多条路径指向末端PKC，则每个路径都将独立处理。该过程包括两个步骤：
1) collecting the Authority Clearance Constraints; and
1) 收集当局的许可限制；和
2) using the Authority Clearance Constraints in the certification path and the Clearance in the end PKC to determine the effective-clearance for the subject of the end PKC.
2) 使用认证路径中的权限清除约束和末端PKC中的清除来确定末端PKC主体的有效清除。
Assuming a certification path consisting of n PKCs, the effective-clearance for the subject of the end PKC is the intersection of 1) the Clearance attribute in the subject PKC, 2) the Authority Clearance Constraints, if present, in the trust anchor, 3) user input, and 4) all Authority Clearance Constraints present in n-1 intermediate PKCs. Any effective-clearance calculation algorithm that performs this calculation and provides the same outcome as the one from the algorithm described herein is considered compliant with the requirements of this RFC.
假设认证路径由n个PKC组成，则最终PKC主体的有效许可是1）主体PKC中的许可属性、2）信任锚中的权限许可约束（如果存在）、3）用户输入和4）n-1中间PKC中存在的所有权限许可约束的交集。执行此计算并提供与本文所述算法相同结果的任何有效间隙计算算法均被视为符合本RFC的要求。
When processing a certification path, Authority Clearance Constraints are maintained in one state variable: permitted-clearances. When processing begins, permitted-clearances is initialized to the user input value or the special value all-clearances if Authority Clearance Constraints user input is not provided. The permitted-clearances state variable is updated by first processing Authority Clearance Constraints associated with the trust anchor, and then each time an intermediate PKC that contains an Authority Clearance Constraints certificate extension in the path is processed.
在处理认证路径时，授权许可约束保留在一个状态变量中：允许许可。当处理开始时，允许的间隙初始化为用户输入值，或如果未提供权限间隙约束用户输入，则初始化为特殊值所有间隙。首先处理与信任锚关联的权限许可约束，然后每次处理路径中包含权限许可约束证书扩展的中间PKC时，都会更新许可许可许可许可状态变量。
When processing the end PKC, the value in the Clearance attribute in the end PKC is intersected with the permitted-clearances state variable.
处理end PKC时，end PKC中“间隙”属性中的值与“允许间隙”状态变量相交。
The output of Clearance attribute and Authority Clearance Constraint certificate extension processing is the effective-clearance (which could also be an empty list), and a status indicator of either success or failure. If the status indicator is failure, then the process also returns a reason code.
清除属性和权限清除约束证书扩展处理的输出是有效清除（也可以是空列表），以及成功或失败的状态指示器。如果状态指示器为failure，则流程还将返回一个原因代码。
Authority Clearance Constraints are collected from the user input, the trust anchor, and the intermediate PKCs in a certification path.
权限清除约束从用户输入、信任锚和证书路径中的中间PKC收集。
When processing Authority Clearance Constraints certificate extensions for the purposes of validating a Clearance attribute in the end PKC, the processing described in this section or an equivalent algorithm MUST be performed in addition to the certification path validation.
当处理授权许可约束证书扩展以验证最终PKC中的许可属性时，除验证路径验证外，还必须执行本节中描述的处理或等效算法。
The processing is presented as an addition to the certification path validation algorithm described in Section 6 of [RFC5280]. Note that this RFC is fully consistent with [RFC5280]; however, it augments [RFC5280] with the following steps:
该处理作为[RFC5280]第6节所述认证路径验证算法的补充。请注意，此RFC与[RFC5280]完全一致；但是，它通过以下步骤扩充了[RFC5280]：
o Ability to provide and process Authority Clearance Constraints as an additional input to the certification path processing engine with Trust anchor information.
o 能够提供和处理权限许可约束，作为认证路径处理引擎的附加输入，并提供信任锚信息。
o Requirement to process Authority Clearance Constraints present with trust anchor information.
o 处理信任锚信息中存在的权限清除约束的要求。
User input may include an Authority Clearance Constraints structure or omit it.
用户输入可以包括权限许可约束结构，也可以省略它。
Trust anchor information may include the Authority Clearance Constraints structure to specify Authority Clearance Constraints for the trust anchor. In other words, the trust anchor may be constrained or unconstrained.
信任锚信息可以包括权限清除约束结构，以指定信任锚的权限清除约束。换言之，信托锚可能受到约束或不受约束。
If the user input includes Authority Clearance Constraints, set permitted-clearances to the input value; otherwise, set permitted-clearances to the special value all-clearances.
如果用户输入包括权限间隙约束，则将允许间隙设置为输入值；否则，将允许间隙设置为特殊值所有间隙。
Examine the permitted-clearances for the same Policy ID appearing more then once. If a policyId appears more than once in the permitted-clearances state variable, set effective-clearance to an empty list, set error code to "multiple instances of same clearance", and exit with failure.
检查同一保单ID多次出现的许可许可证。如果policyId在“允许的间隙”状态变量中多次出现，请将“有效间隙”设置为空列表，将错误代码设置为“相同间隙的多个实例”，并以失败退出。
If the trust anchor does not contain an Authority Clearance Constraints extension, continue at Section 4.1.1.3. Otherwise, execute the procedure described in Section 6 as an in-line macro by treating the trust anchor as a PKC.
如果信任锚不包含权限许可限制扩展，请继续第4.1.1.3节。否则，通过将信任锚点视为PKC，将第6节中描述的过程作为一个内嵌宏执行。
If the PKC is the last PKC (i.e., certificate n), skip the steps listed in this section. Otherwise, execute the procedure described in Section 6 as an in-line macro.
如果PKC是最后一个PKC（即证书n），请跳过本节中列出的步骤。否则，以内嵌宏的形式执行第6节中描述的过程。
No additional action associated with the Clearance attribute or the Authority Clearance Constraints certificate extensions is taken during this phase of certification path validation as described in Section 6 of [RFC5280].
在[RFC5280]第6节所述的认证路径验证阶段，不会采取与许可属性或机构许可约束证书扩展相关的其他操作。
To complete the processing, perform the following steps for the last PKC (i.e., certificate n).
要完成处理，请对最后一个PKC（即证书n）执行以下步骤。
Examine the PKC and verify that it does not contain more than one instance of the Clearance attribute. If the PKC contains more than one instance of the Clearance attribute, set effective-clearance to an empty list, set the error code to "multiple instances of an attribute", and exit with failure.
检查PKC并验证它不包含多个Clearance属性实例。如果PKC包含多个清除属性实例，请将有效清除设置为空列表，将错误代码设置为“属性的多个实例”，然后失败退出。
If the Clearance attribute is not present in the end PKC, set effective-clearance to an empty list and exit with success.
如果结束PKC中不存在清除属性，请将有效清除设置为空列表，并成功退出。
Set effective-clearance to the Clearance attribute in the end PKC.
将有效间隙设置为末端PKC中的间隙属性。
Examine effective-clearance and verify that it does not contain more than one value. If effective-clearance contains more than one value, set effective-clearance to an empty list, set error code to "multiple values", and exit with failure.
检查有效间隙并确认其不包含多个值。如果有效间隙包含多个值，则将有效间隙设置为空列表，将错误代码设置为“多个值”，并以失败退出。
If permitted-clearances is an empty list, set effective-clearance to an empty list and exit with success.
如果允许的间隙为空列表，则将有效间隙设置为空列表，并成功退出。
If permitted-clearances has the special value all-clearances, exit with success.
如果允许的间隙具有特殊值“所有间隙”，则成功退出。
Let us say policyId in effective-clearance is X.
让我们假设有效清除中的policyId是X。
If the policyId X in effective-clearance is absent from the permitted-clearances, set effective-clearance to an empty list and exit with success.
如果有效许可中的保单ID X不在允许的许可中，请将有效许可设置为空列表，并成功退出。
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 clearance structure in permitted-clearances associated with policyId X. Assign all other classList bits in effective-clearance a value of zero (0).
为有效清除中的类列表位分配一（1）个值，该值在有效清除中和与policyId X相关的允许清除中的清除结构中都具有一（1）个值。为有效清除中的所有其他类列表位分配一个零（0）值。
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 success.
如果有效清除中没有一个类列表位的值为1，则将有效清除设置为空列表并成功退出。
Set the securityCategories in effective-clearance to the intersection of securityCategories in effective-clearance and securityCategories for policyId X in permitted-clearances using the algorithm described in Section 7. Note that an empty SET is represented by simply omitting the SET.
使用第7节中描述的算法，将有效许可中的证券类别设置为有效许可中的证券类别与许可许可许可中的保单ID X的证券类别的交点。请注意，空集合仅通过省略集合来表示。
Exit with success.
成功地退出。
If certification path validation processing succeeds, effective-clearance contains the subject's effective clearance for this certification path. Processing also returns success or failure indication and reason for failure, if applicable.
如果认证路径验证处理成功，则有效许可包含受试者对此认证路径的有效许可。处理还返回成功或失败指示以及失败原因（如果适用）。
This section describes the certification path processing when Clearance is asserted in an AC. Relevant to processing are: one TA; 0 or more CA PKCs; 0 or 1 AA PKC; and 1 AC.
本节描述了在AC中断言许可时的认证路径处理。与处理相关的有：一个TA；0个或多个CA PKC；0或1aa蛋白激酶；和1 AC。
User input, Authority Clearance Constraints certificate extension, and Clearance attribute processing determine the effective clearance (henceforth called effective-clearance) for the subject of the AC. User input and the Authority Clearance Constraints certificate extensions in the TA and in each PKC (up to and including the AA PKC) in a certification path impact the effective-clearance. If there is more than one path to the AA PKC, each path is processed independently. The process involves two steps:
用户输入、权限许可约束证书扩展和许可属性处理确定AC主体的有效许可（以下称为有效许可）。TA和每个PKC（直至并包括AA PKC）中的用户输入和权限许可约束证书扩展在认证路径中，影响有效间隙。如果AA PKC有多条路径，则每个路径都将独立处理。该过程包括两个步骤：
1) collecting the Authority Clearance Constraints; and
1) 收集当局的许可限制；和
2) using the Authority Clearance Constraints in the PKC certification path and the Clearance in the AC to determine the effective-clearance for the subject of the AC.
2) 使用PKC认证路径中的权限许可约束和AC中的许可来确定AC主体的有效许可。
The effective-clearance for the subject of the AC is the intersection of 1) the Clearance attribute in the subject AC, 2) the Authority Clearance Constraints, if present, in trust anchor, 3) user input, and 4) all Authority Clearance Constraints present in the PKC certification path from the TA to the AA. Any effective-clearance calculation algorithm that performs this calculation and provides the same outcome as the one from the algorithm described herein is considered compliant with the requirements of this RFC.
AC主体的有效许可是1）主体AC中的许可属性、2）信任锚中的权限许可约束（如果存在）、3）用户输入和4）从TA到AA的PKC认证路径中存在的所有权限许可约束的交集。执行此计算并提供与本文所述算法相同结果的任何有效间隙计算算法均被视为符合本RFC的要求。
The Authority Clearance Constraints are maintained in one state variable: permitted-clearances. When processing begins, permitted-clearances is initialized to user input or the special value all-clearances if Authority Clearance Constraints user input is not provided. The permitted-clearances state variable is updated by first processing the Authority Clearance Constraints associated with the trust anchor, and then each time a PKC (other than AC holder PKC) that contains an Authority Clearance Constraints certificate extension in the path is processed.
当局间隙约束保留在一个状态变量中：允许间隙。当处理开始时，允许的间隙初始化为用户输入，或者如果未提供权限间隙约束用户输入，则初始化为特殊值“所有间隙”。首先处理与信任锚关联的权限许可约束，然后每次处理路径中包含权限许可约束证书扩展的PKC（AC持有者PKC除外），即可更新许可许可许可许可状态变量。
When processing the AC, the value in the Clearance attribute in the AC is intersected with the permitted-clearances state variable.
处理AC时，AC中“间隙”属性中的值与“允许间隙”状态变量相交。
The output of Clearance attribute and Authority Clearance Constraint certificate extension processing is the effective-clearance, which could also be an empty list; and success or failure with a reason code for failure.
清除属性和权限清除约束证书扩展处理的输出为有效清除，也可以为空列表；以及带有失败原因代码的成功或失败。
Authority Clearance Constraints are collected from the user input, the trust anchor, and all the PKCs in the AA PKC certification path.
权限清除约束从用户输入、信任锚和AA PKC证书路径中的所有PKC收集。
When processing Authority Clearance Constraints certificate extensions for the purpose of validating a Clearance attribute in the AC, the processing described in this section or an equivalent algorithm MUST be performed in addition to the certification path validation. The processing is presented as an addition to the PKC certification path validation algorithm described in Section 6 of [RFC5280] for the AA PKC certification path and the algorithm described in Section 5 of [RFC5755] for the AC validation. Also see the note related to [RFC5280] augmentation in Section 4.1.1.
当处理授权许可约束证书扩展以验证AC中的许可属性时，除验证路径验证外，还必须执行本节中描述的处理或等效算法。该处理作为[RFC5280]第6节中描述的用于AA PKC认证路径的PKC认证路径验证算法和[RFC5755]第5节中描述的用于AC验证的算法的补充。另请参见第4.1.1节中与[RFC5280]扩充相关的注释。
Same as Section 4.1.1.1.
与第4.1.1.1节相同。
In addition, let us assume that the PKC certification path for the AA consists of n certificates.
此外，假设AA的PKC认证路径由n个证书组成。
Same as Section 4.1.1.2.
与第4.1.1.2节相同。
Same as Section 4.1.1.3 except that the logic is applied to all n PKCs.
与第4.1.1.3节相同，但该逻辑适用于所有n个PKC。
Same as Section 4.1.1.4.
与第4.1.1.4节相同。
To complete the processing, perform the following steps for the AC.
要完成处理，请对空调执行以下步骤。
Examine the AC and verify that it does not contain more than one instance of the Clearance attribute. If the AC contains more than one instance of the Clearance attribute, set effective-clearance to an empty list, set the error code to "multiple instances of an attribute", and exit with failure.
检查AC并验证其不包含多个“清除”属性实例。如果AC包含多个清除属性实例，请将有效清除设置为空列表，将错误代码设置为“一个属性的多个实例”，然后失败退出。
If the Clearance attribute is not present in the AC, set effective-clearance to an empty list and exit with success.
如果AC中不存在清除属性，请将有效清除设置为空列表，并成功退出。
Set effective-clearance to the Clearance attribute in the AC.
将有效间隙设置为AC中的“间隙”属性。
Same as Section 4.1.1.5.1.
与第4.1.1.5.1节相同。
Same as Section 4.1.1.6.
与第4.1.1.6节相同。
In addition, apply AC processing rules described in Section 5 of [RFC5755].
此外，应用[RFC5755]第5节中描述的AC处理规则。
6. Computing the Intersection of permitted-clearances and Authority Clearance Constraints Extension
6. 计算允许净空和授权净空约束的交点
Examine the PKC and verify that it does not contain more than one instance of the Authority Clearance Constraints extension. If the PKC contains more than one instance of Authority Clearance Constraints extension, set effective-clearance to an empty list, set error code to "multiple extension instances", and exit with failure.
检查PKC并验证它不包含多个权限许可约束扩展实例。如果PKC包含多个权限许可约束扩展实例，请将有效许可设置为空列表，将错误代码设置为“多个扩展实例”，并以失败退出。
If the Authority Clearance Constraints certificate extension is not present in the PKC, no action is taken, and the permitted-clearances value is unchanged.
如果PKC中不存在授权间隙约束证书扩展，则不采取任何措施，且允许的间隙值不变。
If the Authority Clearance Constraints certificate extension is present in the PKC, set the variable temp-clearances to the value of the Authority Clearance Constraints certificate extension. Examine the temp-clearances for the same Policy ID appearing more then once. If a policyId appears more than once in the temp-clearances state variable, set effective-clearance to an empty list, set error code to "multiple instances of same clearance", and exit with failure.
如果PKC中存在授权许可约束证书扩展，请将可变临时许可设置为授权许可约束证书扩展的值。检查同一策略ID多次出现的临时许可。如果policyId在temp clearances状态变量中多次出现，请将有效间隙设置为空列表，将错误代码设置为“相同间隙的多个实例”，并以失败退出。
If the Authority Clearance Constraints certificate extension is present in the PKC and permitted-clearances contains the all-clearances special value, then assign permitted-clearances the value of temp-clearances.
如果PKC中存在授权间隙约束证书扩展，且允许间隙包含所有间隙特殊值，则将允许间隙指定为临时间隙值。
If the Authority Clearance Constraints certificate extension is present in the PKC and permitted-clearances does not contain the all-clearances special value, take the intersection of temp-clearances and permitted-clearances by repeating the following steps for each clearance in the permitted-clearances state variable:
如果PKC中存在机构间隙约束证书扩展，且允许间隙不包含“所有间隙”特殊值，则通过对“允许间隙”状态变量中的每个间隙重复以下步骤，取临时间隙和允许间隙的交点：
- If the policyId associated with the clearance is absent in the temp-clearances, delete the clearance structure associated with the policyID from the permitted-clearances state variable.
- 如果临时间隙中没有与间隙关联的policyId，请从允许间隙状态变量中删除与policyId关联的间隙结构。
- If the policyId is present in temp-clearances:
- 如果保单ID存在于临时许可中：
-- For every classList bit, assign the classList bit a value of one (1) for the policyId in the permitted-clearances state variable if the bit is one (1) in both the permitted-clearances state variable and the temp-clearances for that policyId; otherwise, assign the bit a value of zero (0).
--对于每个classList位，如果允许间隙状态变量和该policyId的临时间隙中的位均为一（1），则在允许间隙状态变量中为classList位的policyId分配一（1）个值；否则，将该位赋值为零（0）。
-- If no bits are one (1) for the classList, delete the clearance structure associated with the policyId from the permitted-clearances state variable and skip the next step of processing securityCategories.
--如果类列表中没有一（1）位，请从允许的清除状态变量中删除与policyId关联的清除结构，并跳过处理securityCategories的下一步。
-- For the policyId in permitted-clearances, set the securityCategories to the intersection of securityCategories for the policyId in permitted-clearances and in temp-clearances using the algorithm described in Section 7. Note that an empty SET is represented by simply omitting the SET.
--对于许可许可许可中的保单ID，使用第7节中描述的算法，将securityCategories设置为许可许可和临时许可中保单ID的securityCategories的交点。请注意，空集合仅通过省略集合来表示。
The algorithm described here has the idempotent, associative, and commutative properties.
这里描述的算法具有幂等性、结合性和交换性。
This section describes how to compute the intersection of securityCategories A and B. It uses the state variable temp-set. It also uses temporary variables X and Y.
本节介绍如何计算securityCategories A和B的交集。它使用状态变量temp set。它还使用临时变量X和Y。
Set the SET temp-set to empty.
将设置温度设置为空。
Set X = A and Y = B.
设置X=A和Y=B。
If SET X is empty (i.e., securityCategories is absent), return temp-set.
如果集合X为空（即不存在securityCategories），则返回临时集合。
If SET Y is empty (i.e., securityCategories is absent), return temp-set.
如果集合Y为空（即不存在securityCategories），则返回临时集合。
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.
对于X中的每个类型OID，如果X中的类型OID的所有元素以及当且仅当Y中该类型OID的所有元素都相同，则将这些元素添加到temp set并从X和Y中删除这些元素。注意：相同表示如果X中存在具有类型OID和给定值的元素，它也存在于Y中，具有相同类型OID和给定值，反之亦然。从X和Y中删除元素。
If SET X is empty (i.e., securityCategories is absent), return temp-set.
如果集合X为空（即不存在securityCategories），则返回临时集合。
If SET Y is empty (i.e., securityCategories is absent), return temp-set.
如果集合Y为空（即不存在securityCategories），则返回临时集合。
For every element (i.e., SecurityCategory) in the SET X, carry out the following steps:
对于集合X中的每个元素（即SecurityCategory），执行以下步骤：
1. If there is no element in SET Y with the same type OID as the type OID in the element from SET X, go to step 5.
1. 如果集合Y中没有与集合X中元素的OID类型相同的元素，请转至步骤5。
2. If there is an element in SET Y with the same type OID and value as in the element in SET X, carry out the following steps:
2. 如果集合Y中有一个元素的OID类型和值与集合X中的元素相同，请执行以下步骤：
a) If the element is not present in the SET temp-set, add an element containing the type OID and the value to the SET temp-set.
a) 如果SET temp集合中不存在该元素，请将包含OID类型和值的元素添加到SET temp集合中。
3. If the processing semantics of type OID in the element in SET X is not known, go to step 5.
3. 如果集合X中元素中OID类型的处理语义未知，请转至步骤5。
4. For each element in SET Y, do the following:
4. 对于集合Y中的每个元素，请执行以下操作：
a) If the type OID of the element in SET Y is not the same as the element in SET X being processed, go to step 4.d.
a) 如果集合Y中元素的OID类型与正在处理的集合X中元素的OID类型不同，请转至步骤4.d。
b) Perform type-OID-specific intersection of the value in the element in SET X with the value in the element in SET Y.
b) 将集合X中元素的值与集合Y中元素的值执行特定于OID类型的相交。
c) If the intersection is not empty, and the element 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.
c) 如果交集不是空的，并且表示OID类型和交集值的元素尚未出现在临时集中，请将包含OID类型和交集值的元素作为元素添加到临时集中。
d) Continue to the next element in SET Y.
d) 继续到集合Y中的下一个元素。
5. If more elements remain in SET X, process the next element starting with step 1.
5. 如果集合X中还有更多元素，则从步骤1开始处理下一个元素。
Return temp-set.
返回温度设置。
This RFC also includes a recommended securityCategories object as follows:
此RFC还包括推荐的securityCategories对象，如下所示：
recommended-category SECURITY-CATEGORY ::=
{ BIT STRING IDENTIFIED BY OID }
recommended-category SECURITY-CATEGORY ::=
{ BIT STRING IDENTIFIED BY OID }
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.
提供上述结构作为示例。要使用此结构，需要注册对象标识符（OID），并且需要枚举位字符串中位的语义。
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 resulting intersection has none of the bits set, the intersection is considered empty.
请注意，此类型的两个值的类型特定交集将只是设置两个值中设置的位。如果生成的交集未设置任何位，则交集被视为空。
Certificate issuers must recognize that absence of the Authority Clearance Constraints in a TA, in a CA certificate, or in an AA certificate means that in terms of the clearance, the subject Authority is not constrained.
证书颁发者必须认识到，TA、CA证书或AA证书中不存在授权许可约束意味着就许可而言，主体授权不受约束。
Absence of the Clearance attribute in a certificate means that the subject has not been assigned any clearance.
证书中缺少许可属性意味着未向受试者分配任何许可。
If there is no Clearance associated with a TA, it means that the TA has not been assigned any clearance.
如果没有与TA相关的间隙，则表示TA未分配任何间隙。
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
如果本地安全策略认为主体持有的许可或CA或AA支持的许可是敏感的，则许可属性或权限许可限制应仅为
included if the subject's and Authority's certificates can be privacy protected. Also in this case, distribution of trust anchors and associated Authority Clearance Constraints extension or Clearance must also be privacy protected.
如果受试者和权威机构的证书可以保护隐私，则包括在内。同样在这种情况下，信任锚的分发和相关的权限许可限制扩展或许可也必须受到隐私保护。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5280] Cooper, D. et. al., "Internet X.509 Public Key Infrastructure Certificate and Certification Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.等人，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010.
[RFC5755]Farrell，S.，Housley，R.，和S.Turner，“用于授权的互联网属性证书配置文件”，RFC 57552010年1月。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) RFC 5912, June 2010.
[RFC5912]Hoffman，P.和J.Schaad，“使用X.509（PKIX）RFC 5912的公钥基础设施的新ASN.1模块，2010年6月。
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. Information Technology - Abstract Syntax Notation One.
[X.680]ITU-T建议X.680（2002）| ISO/IEC 8824-1:2002。信息技术.抽象语法符号1。
[RFC3114] Nicolls, W., "Implementing Company Classification Policy with the S/MIME Security Label", RFC 3114, May 2002.
[RFC3114]Nicols，W.“使用S/MIME安全标签实施公司分类政策”，RFC 3114，2002年5月。
[RFC3739] Santesson, S., Nystrom, M., and T. Polk, "Internet X.509 Public Key Infrastructure: Qualified Certificates Profile", RFC 3739, March 2004.
[RFC3739]Santesson，S.，Nystrom，M.，和T.Polk，“互联网X.509公钥基础设施：合格证书档案”，RFC 37392004年3月。
This appendix provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in X.680.
本附录使用X.680中定义的ASN.1为本规范中描述的结构提供了规范性ASN.1定义。
ClearanceConstraints { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0) 46 }
ClearanceConstraints { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0) 46 }
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
IMPORTS
进口
-- IMPORTS from [RFC5912]
--从[RFC5912]进口
id-at-clearance, Clearance
FROM PKIXAttributeCertificate-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-attribute-cert-02(47)
}
id-at-clearance, Clearance
FROM PKIXAttributeCertificate-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-attribute-cert-02(47)
}
-- IMPORTS from [RFC5912]
--从[RFC5912]进口
EXTENSION, SECURITY-CATEGORY
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)
}
;
EXTENSION, SECURITY-CATEGORY
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)
}
;
-- Clearance attribute OID and syntax
--清除属性OID和语法
-- The following is a 2002 ASN.1 version for clearance.
-- It is included for convenience.
-- The following is a 2002 ASN.1 version for clearance.
-- It is included for convenience.
-- id-at-clearance OBJECT IDENTIFIER ::=
-- { joint-iso-ccitt(2) ds(5) attributeTypes(4) clearance (55) }
-- id-at-clearance OBJECT IDENTIFIER ::=
-- { joint-iso-ccitt(2) ds(5) attributeTypes(4) clearance (55) }
-- Clearance ::= SEQUENCE {
-- policyId OBJECT IDENTIFIER,
-- classList ClassList DEFAULT {unclassified},
-- securityCategories SET OF SecurityCategory
-- Clearance ::= SEQUENCE {
-- policyId OBJECT IDENTIFIER,
-- classList ClassList DEFAULT {unclassified},
-- securityCategories SET OF SecurityCategory
-- {{SupportSecurityCategories }} OPTIONAL
-- }
-- {{SupportSecurityCategories }} OPTIONAL
-- }
-- ClassList ::= BIT STRING {
-- unmarked (0),
-- unclassified (1),
-- restricted (2),
-- confidential (3),
-- secret (4),
-- topSecret (5)
-- }
-- ClassList ::= BIT STRING {
-- unmarked (0),
-- unclassified (1),
-- restricted (2),
-- confidential (3),
-- secret (4),
-- topSecret (5)
-- }
-- SECURITY-CATEGORY ::= TYPE-IDENTIFIER
-- SECURITY-CATEGORY ::= TYPE-IDENTIFIER
-- NOTE that the module SecurityCategory is taken from a module
-- that uses EXPLICIT tags [RFC5912]. If Clearance was not imported
-- from [RFC5912] and the comments were removed from the ASN.1
-- contained herein, then the IMPLICIT in type could also be removed
-- with no impact on the encoding.
-- NOTE that the module SecurityCategory is taken from a module
-- that uses EXPLICIT tags [RFC5912]. If Clearance was not imported
-- from [RFC5912] and the comments were removed from the ASN.1
-- contained herein, then the IMPLICIT in type could also be removed
-- with no impact on the encoding.
-- SecurityCategory { SECURITY-CATEGORY:Supported } ::= SEQUENCE {
-- type [0] IMPLICIT SECURITY-CATEGORY.&id({Supported}),
-- value [1] EXPLICIT SECURITY-CATEGORY.&Type
-- ({Supported}{@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
-- and syntax
-- Authority Clearance Constraints certificate extension OID
-- and syntax
id-pe-clearanceConstraints OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) pe(1) 21 }
id-pe-clearanceConstraints OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) pe(1) 21 }
authorityClearanceConstraints EXTENSION ::= {
SYNTAX AuthorityClearanceConstraints
IDENTIFIED BY id-pe-clearanceConstraints
}
authorityClearanceConstraints EXTENSION ::= {
SYNTAX AuthorityClearanceConstraints
IDENTIFIED BY id-pe-clearanceConstraints
}
AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance
AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance
END
终止
Acknowledgments
致谢
Many thanks go out to Mark Saaltink for his valuable contributions to this document.
非常感谢Mark Saaltink对本文件的宝贵贡献。
We would also like to thank Francis Dupont, Pasi Eronen, Adrian Farrel, Dan Romascanu, and Stefan Santesson for their reviews and comments.
我们还要感谢Francis Dupont、Pasi Eronen、Adrian Farrel、Dan Romascanu和Stefan Santesson的评论和评论。
Authors' Addresses
作者地址
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA，Inc.美国弗吉尼亚州费尔法克斯市努特利街3057号106室，邮编22031
EMail: turners@ieca.com
EMail: turners@ieca.com
Santosh Chokhani CygnaCom Solutions, Inc.
Santosh Chokhani CygnaCom解决方案公司。
EMail: SChokhani@cygnacom.com
EMail: SChokhani@cygnacom.com