Internet Engineering Task Force (IETF) S. Farrell
Request for Comments: 5755 Trinity College Dublin
Obsoletes: 3281 R. Housley
Category: Standards Track Vigil Security
ISSN: 2070-1721 S. Turner
IECA
January 2010
Internet Engineering Task Force (IETF) S. Farrell
Request for Comments: 5755 Trinity College Dublin
Obsoletes: 3281 R. Housley
Category: Standards Track Vigil Security
ISSN: 2070-1721 S. Turner
IECA
January 2010
An Internet Attribute Certificate Profile for Authorization
用于授权的Internet属性证书配置文件
Abstract
摘要
This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281.
本规范定义了在Internet协议中使用X.509属性证书的配置文件。属性证书可用于广泛的应用程序和环境，涵盖广泛的互操作性目标和更广泛的操作和保证要求。本文档的目标是为需要广泛互操作性和有限特殊用途需求的通用应用程序建立通用基线。该概要文件强调对Internet电子邮件、IPsec和WWW安全应用程序的属性证书支持。本文件淘汰了RFC 3281。
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/rfc5755.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5755.
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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Requirements Terminology ...................................5
1.2. AC Path Delegation .........................................5
1.3. Attribute Certificate Distribution ("Push" vs. "Pull") .....6
1.4. Document Structure .........................................7
2. Terminology .....................................................7
3. Requirements ....................................................8
4. Attribute Certificate Profile ...................................9
4.1. X.509 Attribute Certificate Definition ....................10
4.2. Profile of Standard Fields ................................12
4.2.1. Version ............................................13
4.2.2. Holder .............................................13
4.2.3. Issuer .............................................14
4.2.4. Signature ..........................................14
4.2.5. Serial Number ......................................14
4.2.6. Validity Period ....................................15
4.2.7. Attributes .........................................15
4.2.8. Issuer Unique Identifier ...........................16
4.2.9. Extensions .........................................16
4.3. Extensions ................................................17
4.3.1. Audit Identity .....................................17
4.3.2. AC Targeting .......................................18
4.3.3. Authority Key Identifier ...........................19
4.3.4. Authority Information Access .......................19
4.3.5. CRL Distribution Points ............................20
4.3.6. No Revocation Available ............................20
4.4. Attribute Types ...........................................21
4.4.1. Service Authentication Information .................21
4.4.2. Access Identity ....................................22
4.4.3. Charging Identity ..................................23
4.4.4. Group ..............................................23
4.4.5. Role ...............................................23
4.4.6. Clearance ..........................................24
4.5. Profile of AC Issuer's PKC ................................26
5. Attribute Certificate Validation ...............................27
6. Revocation .....................................................28
7. Optional Features ..............................................29
7.1. Attribute Encryption ......................................29
7.2. Proxying ..................................................31
7.3. Use of ObjectDigestInfo ...................................32
7.4. AA Controls ...............................................33
8. Security Considerations ........................................35
9. IANA Considerations ............................................36
1. Introduction ....................................................4
1.1. Requirements Terminology ...................................5
1.2. AC Path Delegation .........................................5
1.3. Attribute Certificate Distribution ("Push" vs. "Pull") .....6
1.4. Document Structure .........................................7
2. Terminology .....................................................7
3. Requirements ....................................................8
4. Attribute Certificate Profile ...................................9
4.1. X.509 Attribute Certificate Definition ....................10
4.2. Profile of Standard Fields ................................12
4.2.1. Version ............................................13
4.2.2. Holder .............................................13
4.2.3. Issuer .............................................14
4.2.4. Signature ..........................................14
4.2.5. Serial Number ......................................14
4.2.6. Validity Period ....................................15
4.2.7. Attributes .........................................15
4.2.8. Issuer Unique Identifier ...........................16
4.2.9. Extensions .........................................16
4.3. Extensions ................................................17
4.3.1. Audit Identity .....................................17
4.3.2. AC Targeting .......................................18
4.3.3. Authority Key Identifier ...........................19
4.3.4. Authority Information Access .......................19
4.3.5. CRL Distribution Points ............................20
4.3.6. No Revocation Available ............................20
4.4. Attribute Types ...........................................21
4.4.1. Service Authentication Information .................21
4.4.2. Access Identity ....................................22
4.4.3. Charging Identity ..................................23
4.4.4. Group ..............................................23
4.4.5. Role ...............................................23
4.4.6. Clearance ..........................................24
4.5. Profile of AC Issuer's PKC ................................26
5. Attribute Certificate Validation ...............................27
6. Revocation .....................................................28
7. Optional Features ..............................................29
7.1. Attribute Encryption ......................................29
7.2. Proxying ..................................................31
7.3. Use of ObjectDigestInfo ...................................32
7.4. AA Controls ...............................................33
8. Security Considerations ........................................35
9. IANA Considerations ............................................36
10. References ....................................................37
10.1. Reference Conventions ....................................37
10.2. Normative References .....................................37
10.3. Informative References ...................................38
Appendix A. Object Identifiers ....................................40
Appendix B. ASN.1 Module ..........................................41
Appendix C. Errata Report Submitted to RFC 3281 ...................47
Appendix D. Changes since RFC 3281 ................................48
10. References ....................................................37
10.1. Reference Conventions ....................................37
10.2. Normative References .....................................37
10.3. Informative References ...................................38
Appendix A. Object Identifiers ....................................40
Appendix B. ASN.1 Module ..........................................41
Appendix C. Errata Report Submitted to RFC 3281 ...................47
Appendix D. Changes since RFC 3281 ................................48
X.509 public key certificates (PKCs) [X.509-1997] [X.509-2000] [PKIXPROF] bind an identity and a public key. An attribute certificate (AC) is a structure similar to a PKC; the main difference being that the AC contains no public key. An AC may contain attributes that specify group membership, role, security clearance, or other authorization information associated with the AC holder.
X.509公钥证书（PKC）[X.509-1997][X.509-2000][PKIXPROF]绑定身份和公钥。属性证书（AC）是一种类似于PKC的结构；主要区别在于AC不包含公钥。AC可能包含指定组成员资格、角色、安全许可或与AC持有人相关的其他授权信息的属性。
The syntax for the AC is defined in Recommendation X.509, making the term "X.509 certificate" ambiguous.
AC的语法在建议X.509中定义，使得术语“X.509证书”模糊不清。
Some people constantly confuse PKCs and ACs. An analogy may make the distinction clear. A PKC can be considered to be like a passport: it identifies the holder, tends to last for a long time, and should not be trivial to obtain. An AC is more like an entry visa: it is typically issued by a different authority and does not last for as long a time. As acquiring an entry visa typically requires presenting a passport, getting a visa can be a simpler process.
有些人经常混淆PKC和ACs。打个比方就可以把区别弄清楚。PKC可以被视为一本护照：它可以识别持有人，往往持续很长时间，而且不应该是微不足道的。AC更像是入境签证：它通常由不同的机构签发，不会持续那么长时间。由于获得入境签证通常需要出示护照，因此获得签证可能是一个更简单的过程。
Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC). The placement of authorization information in PKCs is usually undesirable for two reasons. First, authorization information often does not have the same lifetime as the binding of the identity and the public key. When authorization information is placed in a PKC extension, the general result is the shortening of the PKC useful lifetime. Second, the PKC issuer is not usually authoritative for the authorization information. This results in additional steps for the PKC issuer to obtain authorization information from the authoritative source.
授权信息可以放在PKC扩展中，也可以放在单独的属性证书（AC）中。由于两个原因，通常不希望在PKCs中放置授权信息。首先，授权信息通常与身份和公钥的绑定不具有相同的生存期。当授权信息放在PKC扩展中时，通常的结果是缩短PKC的使用寿命。其次，PKC发行人通常不具有授权信息的权威性。这将导致PKC发行人从权威来源获取授权信息的额外步骤。
For these reasons, it is often better to separate authorization information from the PKC. Yet, authorization information also needs to be bound to an identity. An AC provides this binding; it is simply a digitally signed (or certified) identity and set of attributes.
出于这些原因，通常最好将授权信息与PKC分开。然而，授权信息也需要绑定到身份。AC提供此约束；它只是一个数字签名（或认证）身份和一组属性。
An AC may be used with various security services, including access control, data origin authentication, and non-repudiation.
AC可以与各种安全服务一起使用，包括访问控制、数据源认证和不可否认性。
PKCs can provide an identity to access control decision functions. However, in many contexts, the identity is not the criterion that is used for access control decisions; rather, the role or group-membership of the accessor is the criterion used. Such access control schemes are called role-based access control.
PKCs可以为访问控制决策功能提供身份。然而，在许多情况下，身份不是用于访问控制决策的标准；相反，访问器的角色或组成员身份是使用的标准。这种访问控制方案称为基于角色的访问控制。
When making an access control decision based on an AC, an access control decision function may need to ensure that the appropriate AC holder is the entity that has requested access. One way in which the linkage between the request or identity and the AC can be achieved is the inclusion of a reference to a PKC within the AC and the use of the private key corresponding to the PKC for authentication within the access request.
当根据AC做出访问控制决策时，访问控制决策职能部门可能需要确保适当的AC持有人是请求访问的实体。可以实现请求或身份与AC之间的链接的一种方法是在AC中包含对PKC的引用，并在访问请求中使用与PKC对应的私钥进行身份验证。
ACs may also be used in the context of a data origin authentication service and a non-repudiation service. In these contexts, the attributes contained in the AC provide additional information about the signing entity. This information can be used to make sure that the entity is authorized to sign the data. This kind of checking depends either on the context in which the data is exchanged or on the data that has been digitally signed.
ACs还可以在数据源认证服务和不可否认服务的上下文中使用。在这些上下文中，AC中包含的属性提供了有关签名实体的附加信息。此信息可用于确保实体有权签署数据。这种检查要么取决于交换数据的上下文，要么取决于经过数字签名的数据。
This document obsoletes [RFC3281]. Changes since [RFC3281] are listed in Appendix D.
本文件废除了[RFC3281]。附录D中列出了自[RFC3281]以来的变更。
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]中所述进行解释。
The X.509 standard [X.509-2000] defines authorization as the "conveyance of privilege from one entity that holds such privilege, to another entity". An AC is one authorization mechanism.
X.509标准[X.509-2000]将授权定义为“将特权从拥有该特权的一个实体转移到另一个实体”。AC是一种授权机制。
An ordered sequence of ACs could be used to verify the authenticity of a privilege asserter's privilege. In this way, chains or paths of ACs could be employed to delegate authorization.
ACs的有序序列可用于验证特权资产者特权的真实性。通过这种方式，可以使用ACs的链或路径来委托授权。
Since the administration and processing associated with such AC chains is complex and the use of ACs in the Internet today is quite limited, it is RECOMMENDED that implementations of this specification not use AC chains. Other (future) specifications may address the use of AC chains. This specification deals with the simple cases, where one authority issues all of the ACs for a particular set of attributes. However, this simplification does not preclude the use
由于与此类AC链相关的管理和处理是复杂的，并且当前在Internet上使用ACs的情况非常有限，因此建议本规范的实现不使用AC链。其他（未来）规范可能涉及交流链的使用。本规范处理简单的情况，其中一个机构针对一组特定属性发布所有ACs。然而，这种简化并不排除使用
of several different authorities, each of which manages a different set of attributes. For example, group membership may be included in one AC issued by one authority, and security clearance may be included in another AC issued by another authority.
由几个不同的机构组成，每个机构管理一组不同的属性。例如，集团成员资格可能包括在一个机构发布的一份AC中，安全许可可能包括在另一个机构发布的另一份AC中。
This means that conformant implementations are only REQUIRED to be able to process a single AC at a time. Processing of more than one AC, one after another, may be necessary. Note however, that validation of an AC MAY require validation of a chain of PKCs, as specified in [PKIXPROF].
这意味着一致性实现只需要能够一次处理一个AC。可能需要一个接一个地处理多个AC。然而，请注意，AC的验证可能需要验证PKC链，如[PKIXPROF]中所述。
As discussed above, ACs provide a mechanism to securely provide authorization information to, for example, access control decision functions. However, there are a number of possible communication paths for ACs.
如上所述，ACs提供了一种机制来安全地向例如访问控制决策功能提供授权信息。然而，ACs有许多可能的通信路径。
In some environments, it is suitable for a client to "push" an AC to a server. This means that no new connections between the client and server are required. It also means that no search burden is imposed on servers, which improves performance and that the AC verifier is only presented with what it "needs to know". The "push" model is especially suitable in inter-domain cases where the client's rights should be assigned within the client's "home" domain.
在某些环境中，客户机可以将AC“推送”到服务器。这意味着客户端和服务器之间不需要新的连接。这还意味着不会对服务器施加搜索负担，从而提高了性能，而且AC验证器只会得到“需要知道的”信息。“推送”模式特别适用于域间的情况，其中客户的权利应在客户的“主”域内分配。
In other cases, it is more suitable for a client to simply authenticate to the server and for the server to request or "pull" the client's AC from an AC issuer or a repository. A major benefit of the "pull" model is that it can be implemented without changes to the client or to the client-server protocol. The "pull" model is especially suitable for inter-domain cases where the client's rights should be assigned within the server's domain, rather than within the client's domain.
在其他情况下，客户机更适合向服务器进行简单的身份验证，而服务器则更适合从AC颁发者或存储库请求或“提取”客户机的AC。“pull”模型的一个主要优点是，它可以在不更改客户机或客户机-服务器协议的情况下实现。“拉”模型特别适用于域间情况，在这种情况下，客户端的权限应该在服务器的域内分配，而不是在客户端的域内分配。
There are a number of possible exchanges involving three entities: the client, the server, and the AC issuer. In addition, a directory service or other repository for AC retrieval MAY be supported.
有许多可能的交换涉及三个实体：客户端、服务器和AC颁发者。此外，还可能支持用于AC检索的目录服务或其他存储库。
Figure 1 shows an abstract view of the exchanges that may involve ACs. This profile does not specify a protocol for these exchanges.
图1显示了可能涉及ACs的交换的抽象视图。此配置文件没有为这些交换指定协议。
+--------------+
| | Server Acquisition
| AC issuer +<---------------------------+
| | |
+--+-----------+ |
^ |
| Client |
| Acquisition |
v v
+--+-----------+ +--+------------+
| | AC "push" | |
| Client +<------------------------| Server |
| | (part of app. protocol) | |
+--+-----------+ +--+------------+
^ ^
| Client | Server
| Lookup +--------------+ | Lookup
| | | |
+-------------->+ Repository +<--------+
| |
+--------------+
+--------------+
| | Server Acquisition
| AC issuer +<---------------------------+
| | |
+--+-----------+ |
^ |
| Client |
| Acquisition |
v v
+--+-----------+ +--+------------+
| | AC "push" | |
| Client +<------------------------| Server |
| | (part of app. protocol) | |
+--+-----------+ +--+------------+
^ ^
| Client | Server
| Lookup +--------------+ | Lookup
| | | |
+-------------->+ Repository +<--------+
| |
+--------------+
Figure 1: AC Exchanges
图1：交流交换机
Section 2 defines some terminology. Section 3 specifies the requirements that this profile is intended to meet. Section 4 contains the profile of the X.509 AC. Section 5 specifies rules for AC validation. Section 6 specifies rules for AC revocation checks. Section 7 specifies optional features that MAY be supported; however, support for these features is not required for conformance to this profile. Finally, the appendices contain the list of object identifiers (OIDs) required to support this specification and an ASN.1 module.
第2节定义了一些术语。第3节规定了本概要文件拟满足的要求。第4节包含X.509 AC的配置文件。第5节规定了AC验证的规则。第6节规定了AC撤销检查的规则。第7节规定了可支持的可选功能；但是，为了符合此概要文件的要求，不需要对这些功能的支持。最后，附录包含支持本规范和ASN.1模块所需的对象标识符（OID）列表。
For simplicity, we use the terms client and server in this specification. This is not intended to indicate that ACs are only to be used in client-server environments. For example, ACs may be used in the Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 context, where the mail user agent would be both a "client" and a "server" in the sense the terms are used here.
为了简单起见，我们在本规范中使用了客户机和服务器这两个术语。这并不意味着ACs仅用于客户机-服务器环境。例如，ACs可以在安全/多用途Internet邮件扩展（S/MIME）v3.2上下文中使用，其中邮件用户代理在这里使用的术语意义上既是“客户机”又是“服务器”。
Term Meaning
术语含义
AA Attribute Authority, the entity that issues the AC, synonymous in this specification with "AC issuer".
AA属性机构，发布AC的实体，在本规范中与“AC发行人”同义。
AC Attribute Certificate.
AC属性证书。
AC user Any entity that parses or processes an AC.
AC用户解析或处理AC的任何实体。
AC verifier Any entity that checks the validity of an AC and then makes use of the result.
AC验证器检查AC有效性并使用结果的任何实体。
AC issuer The entity that signs the AC: synonymous in this specification with "AA".
AC发行人签署AC的实体：在本规范中与“AA”同义。
AC holder The entity indicated (perhaps indirectly) in the Holder field of the AC.
AC持有人——在AC的持有人字段中指明的实体（可能是间接的）。
Client The entity that is requesting the action for which authorization checks are to be made.
客户端请求要进行授权检查的操作的实体。
Proxying In this specification, Proxying is used to mean the situation where an application server acts as an application client on behalf of a user. Proxying here does not mean granting of authority.
代理在本规范中，代理用于表示应用程序服务器代表用户充当应用程序客户端的情况。在这里代理并不意味着授权。
PKC Public Key Certificate - uses the ASN.1 type Certificate defined in X.509 and profiled in RFC 5280. This (non-standard) acronym is used in order to avoid confusion about the term "X.509 certificate".
PKC公钥证书-使用X.509中定义并在RFC 5280中分析的ASN.1类型证书。使用此（非标准）首字母缩略词是为了避免混淆术语“X.509证书”。
Server The entity that requires that the authorization checks are made.
服务器需要进行授权检查的实体。
This AC profile meets the following requirements.
此AC配置文件符合以下要求。
Time/Validity requirements:
时间/有效性要求：
1. Support for short-lived as well as long-lived ACs. Typical short-lived validity periods might be measured in hours, as opposed to months for PKCs. Short validity periods allow ACs to be useful without a revocation mechanism.
1. 支持短期和长期ACs。典型的短期有效期可能以小时为单位，而PKC则以月为单位。短有效期允许ACs在没有撤销机制的情况下发挥作用。
Attribute Types:
属性类型：
2. Issuers of ACs should be able to define their own attribute types for use within closed domains.
2. ACs的发行人应该能够定义自己的属性类型，以便在封闭域中使用。
3. Some standard attribute types, which can be contained within ACs, should be defined. Examples include "access identity", "group", "role", "clearance", "audit identity", and "charging identity".
3. 应该定义一些可以包含在ACs中的标准属性类型。示例包括“访问标识”、“组”、“角色”、“清除”、“审核标识”和“收费标识”。
4. Standard attribute types should be defined in a manner that permits an AC verifier to distinguish between uses of the same attribute in different domains. For example, the "Administrators group" as defined by "Baltimore" and the "Administrators group" as defined by "SPYRUS" should be easily distinguished.
4. 标准属性类型的定义方式应允许AC验证器区分同一属性在不同域中的使用。例如，“巴尔的摩”定义的“管理员组”和“SPYRUS”定义的“管理员组”应该很容易区分。
Targeting of ACs:
针对ACs：
5. It should be possible to "target" an AC at one, or a small number of, servers. This means that a trustworthy non-target server will reject the AC for authorization decisions.
5. 应该可以在一台或少量服务器上“瞄准”AC。这意味着可信的非目标服务器将拒绝AC进行授权决策。
Push vs. Pull
推还是拉
6. ACs should be defined so that they can either be "pushed" by the client to the server, or "pulled" by the server from a repository or other network service, including an online AC issuer.
6. 应定义ACs，以便客户机可以将其“推送”到服务器，或者服务器可以从存储库或其他网络服务（包括在线AC颁发者）中“拉送”ACs。
ACs may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability and limited special purpose requirements. In particular, the emphasis will be on supporting the use of attribute certificates for informal Internet electronic mail, IPsec, and WWW applications.
ACs可用于广泛的应用程序和环境，涵盖广泛的互操作性目标和更广泛的操作和保证要求。本文档的目标是为需要广泛互操作性和有限特殊用途需求的通用应用程序建立通用基线。特别是，重点将放在支持非正式Internet电子邮件、IPsec和WWW应用程序使用属性证书上。
This section presents a profile for ACs that will foster interoperability. This section also defines some private extensions for the Internet community.
本节介绍将促进互操作性的ACs概要。本节还定义了Internet社区的一些私有扩展。
While the ISO/IEC/ITU documents use the 1993 (or later) version of ASN.1, this document uses the 1988 ASN.1 syntax, as has been done for PKCs [PKIXPROF]. The encoded certificates and extensions from either ASN.1 version are bit-wise identical.
虽然ISO/IEC/ITU文件使用了1993年（或更高版本）的ASN.1，但本文件使用了1988年的ASN.1语法，就像PKCs[PKIXPROF]一样。ASN.1版本中的编码证书和扩展在位上完全相同。
Where maximum lengths for fields are specified, these lengths refer to the DER encoding and do not include the ASN.1 tag or length fields.
如果指定了字段的最大长度，则这些长度指的是DER编码，不包括ASN.1标记或长度字段。
Conforming implementations MUST support the profile specified in this section.
一致性实施必须支持本节中规定的概要文件。
X.509 contains the definition of an AC given below. All types that are not defined in this document can be found in [PKIXPROF].
X.509包含下面给出的AC定义。本文档中未定义的所有类型都可以在[PKIXPROF]中找到。
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion, -- version is v2
holder Holder,
issuer AttCertIssuer,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion, -- version is v2
holder Holder,
issuer AttCertIssuer,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
AttCertVersion ::= INTEGER { v2(1) }
AttCertVersion ::= INTEGER { v2(1) }
Holder ::= SEQUENCE {
baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of
-- the holder's Public Key Certificate
entityName [1] GeneralNames OPTIONAL,
-- the name of the claimant or role
objectDigestInfo [2] ObjectDigestInfo OPTIONAL
-- used to directly authenticate the holder,
-- for example, an executable
}
Holder ::= SEQUENCE {
baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of
-- the holder's Public Key Certificate
entityName [1] GeneralNames OPTIONAL,
-- the name of the claimant or role
objectDigestInfo [2] ObjectDigestInfo OPTIONAL
-- used to directly authenticate the holder,
-- for example, an executable
}
ObjectDigestInfo ::= SEQUENCE {
digestedObjectType ENUMERATED {
publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
-- otherObjectTypes MUST NOT
-- be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING
}
ObjectDigestInfo ::= SEQUENCE {
digestedObjectType ENUMERATED {
publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
-- otherObjectTypes MUST NOT
-- be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING
}
AttCertIssuer ::= CHOICE {
v1Form GeneralNames, -- MUST NOT be used in this
-- profile
v2Form [0] V2Form -- v2 only
}
AttCertIssuer ::= CHOICE {
v1Form GeneralNames, -- MUST NOT be used in this
-- profile
v2Form [0] V2Form -- v2 only
}
V2Form ::= SEQUENCE {
issuerName GeneralNames OPTIONAL,
baseCertificateID [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL
-- issuerName MUST be present in this profile
-- baseCertificateID and objectDigestInfo MUST NOT
-- be present in this profile
}
V2Form ::= SEQUENCE {
issuerName GeneralNames OPTIONAL,
baseCertificateID [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL
-- issuerName MUST be present in this profile
-- baseCertificateID and objectDigestInfo MUST NOT
-- be present in this profile
}
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL
}
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL
}
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime
}
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime
}
Although the Attribute syntax is defined in [PKIXPROF], we repeat the definition here for convenience.
虽然属性语法是在[PKIXPROF]中定义的，但为了方便起见，我们在这里重复定义。
Attribute ::= SEQUENCE {
type AttributeType,
values SET OF AttributeValue
-- at least one value is required
}
Attribute ::= SEQUENCE {
type AttributeType,
values SET OF AttributeValue
-- at least one value is required
}
AttributeType ::= OBJECT IDENTIFIER
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType
AttributeValue ::= ANY DEFINED BY AttributeType
Implementers should note that the DER encoding (see [X.509-1988], [X.690]) of the SET OF values requires ordering of the encodings of the values. Though this issue arises with respect to distinguished names, and has to be handled by [PKIXPROF] implementations, it is much more significant in this context, since the inclusion of multiple values is much more common in ACs.
实施者应注意，值集的DER编码（参见[X.509-1988]、[X.690]）要求对值的编码进行排序。尽管这个问题与可分辨名称有关，并且必须由[PKIXPROF]实现来处理，但在这种情况下，它更为重要，因为在ACs中包含多个值更为常见。
GeneralName offers great flexibility. To achieve interoperability, in spite of this flexibility, this profile imposes constraints on the use of GeneralName.
GeneralName提供了很大的灵活性。为了实现互操作性，尽管有这种灵活性，但此概要文件对GeneralName的使用施加了限制。
Conforming implementations MUST be able to support the dNSName, directoryName, uniformResourceIdentifier, and iPAddress options. This is compatible with the GeneralName requirements in [PKIXPROF] (mainly in Section 4.2.1.6). Implementations SHOULD also support the SRVName, as defined in [X509-SRV].
一致性实现必须能够支持dNSName、directoryName、uniformResourceIdentifier和iPAddress选项。这与[PKIXPROF]中的通用名称要求兼容（主要在第4.2.1.6节中）。实现还应支持[X509-SRV]中定义的SRVName。
Conforming implementations MUST NOT use the x400Address, ediPartyName, or registeredID options.
一致性实现不得使用x400Address、ediPartyName或registeredID选项。
Conforming implementations MAY use the otherName option to convey name forms defined in Internet Standards. For example, Kerberos [KRB] format names can be encoded into the otherName, using a Kerberos 5 principal name OID and a SEQUENCE of the Realm and the PrincipalName.
一致性实现可使用otherName选项传达互联网标准中定义的名称形式。例如，Kerberos[KRB]格式的名称可以使用Kerberos 5主体名称OID和领域和主体名称序列编码为otherName。
The version field MUST have the value of v2. That is, the version field is present in the DER encoding.
版本字段的值必须为v2。也就是说，版本字段存在于DER编码中。
Note: This version (v2) is not backwards compatible with the previous attribute certificate definition (v1) from the 1997 X.509 standard [X.509-1997], but is compatible with the v2 definition from X.509 (2000) [X.509-2000].
注：此版本（v2）与1997年X.509标准[X.509-1997]中先前的属性证书定义（v1）不向后兼容，但与X.509（2000）[X.509-2000]中的v2定义兼容。
The Holder field is a SEQUENCE allowing three different (optional) syntaxes: baseCertificateID, entityName, and objectDigestInfo. Where only one option is present, the meaning of the Holder field is clear.
Holder字段是一个允许三种不同（可选）语法的序列：baseCertificateID、entityName和objectDigestInfo。如果只有一个选项，则持有人字段的含义很清楚。
However, where more than one option is used, there is a potential for confusion as to which option is "normative", which is a "hint", etc. Since the correct position is not clear from [X.509-2000], this specification RECOMMENDS that only one of the options be used in any given AC.
但是，如果使用多个选项，则可能会混淆哪个选项是“规范性”选项，哪个选项是“提示”选项等。因为[X.509-2000]中不清楚正确的位置，本规范建议在任何给定AC中仅使用一个选项。
For any environment where the AC is passed in an authenticated message or session and where the authentication is based on the use of an X.509 PKC, the Holder field SHOULD use the baseCertificateID.
对于在经过身份验证的消息或会话中传递AC并且身份验证基于使用X.509 PKC的任何环境，Holder字段应使用baseCertificateID。
With the baseCertificateID option, the holder's PKC serialNumber and issuer MUST be identical to the AC Holder field. The PKC issuer MUST have a non-empty distinguished name that is to be present as the single value of the holder.baseCertificateID.issuer construct in the directoryName field. The AC holder.baseCertificateID.issuerUID field MUST only be used if the holder's PKC contains an issuerUniqueID field. If both the AC holder.baseCertificateID.issuerUID and the PKC issuerUniqueID fields are present, the same value MUST be present in both fields. Thus, the baseCertificateID is only usable with PKC profiles (like [PKIXPROF]) that mandate that the PKC issuer field contain a non-empty distinguished name value.
使用baseCertificateID选项，持有者的PKC序列号和颁发者必须与AC持有者字段相同。PKC颁发者必须具有非空的可分辨名称，该名称将作为holder.baseCertificateID.issuer构造的单个值出现在directoryName字段中。AC holder.baseCertificateID.issuerUID字段只能在持有人的PKC包含issuerUniqueID字段时使用。如果AC holder.baseCertificateID.issuerUID和PKC issuerUniqueID字段都存在，则两个字段中必须存在相同的值。因此，baseCertificateID仅可用于PKC配置文件（如[PKIXPROF]），该配置文件要求PKC issuer字段包含非空的可分辨名称值。
Note: An empty distinguished name is a distinguished name where the SEQUENCE OF relative distinguished names is of zero length. In a DER encoding, this has the value '3000'H.
注意：空的可分辨名称是相对可分辨名称序列长度为零的可分辨名称。在DER编码中，其值为“3000”H。
If the Holder field uses the entityName option and the underlying authentication is based on a PKC, the entityName MUST be the same as the PKC subject field or one of the values of the PKC subjectAltName field extension (if present). Note that [PKIXPROF] mandates that the subjectAltName extension be present if the PKC subject is an empty
如果Holder字段使用entityName选项，并且基础身份验证基于PKC，则entityName必须与PKC subject字段或PKC subjectAltName字段扩展（如果存在）的一个值相同。请注意，[PKIXPROF]要求如果PKC主题为空，则subjectAltName扩展名必须存在
distinguished name. See the Security Considerations section, which mentions some name collision problems that may arise when using the entityName option.
尊贵的名字。请参阅安全注意事项部分，其中提到了使用entityName选项时可能出现的一些名称冲突问题。
In any other case where the Holder field uses the entityName option, only one name SHOULD be present.
在Holder字段使用entityName选项的任何其他情况下，只应存在一个名称。
Implementations conforming to this profile are not required to support the use of the objectDigest field. However, Section 7.3 specifies how this optional feature MAY be used.
符合此概要文件的实现不需要支持objectDigest字段的使用。但是，第7.3节规定了如何使用此可选功能。
Any protocol conforming to this profile SHOULD specify which AC holder option is to be used and how this fits with the supported authentication schemes defined in that protocol.
符合此配置文件的任何协议都应指定使用哪种AC holder选项，以及该选项如何与该协议中定义的受支持认证方案相匹配。
ACs conforming to this profile MUST use the v2Form choice, which MUST contain one and only one GeneralName in the issuerName, which MUST contain a non-empty distinguished name in the directoryName field. This means that all AC issuers MUST have non-empty distinguished names. ACs conforming to this profile MUST omit the baseCertificateID and objectDigestInfo fields.
符合此配置文件的ACs必须使用v2Form选项，该选项必须在issuerName中包含且仅包含一个GeneralName，在directoryName字段中必须包含非空的可分辨名称。这意味着所有AC发行人必须具有非空的可分辨名称。符合此配置文件的ACs必须省略baseCertificateID和objectDigestInfo字段。
Part of the reason for the use of the v2Form containing only an issuerName is that it means that the AC issuer does not have to know which PKC the AC verifier will use for it (the AC issuer). Using the baseCertificateID field to reference the AC issuer would mean that the AC verifier would have to trust the PKC that the AC issuer chose (for itself) at AC creation time.
使用只包含issuerName的v2Form的部分原因是，它意味着AC发行人不必知道AC验证者将为其使用哪个PKC（AC发行人）。使用baseCertificateID字段引用AC颁发者将意味着AC验证者必须信任AC颁发者在AC创建时（为自己）选择的PKC。
Contains the algorithm identifier used to validate the AC signature.
包含用于验证AC签名的算法标识符。
This MUST be one of the signing algorithms defined in [PKIXALGS] or defined in any IETF-approved update to [PKIXALGS]. Conforming implementations MUST honor all MUST/SHOULD/MAY signing algorithm statements specified in [PKIXALGS] or IETF-approved updates to [PKIXALGS].
这必须是[PKIXALGS]中定义的签名算法之一，或在IETF批准的[PKIXALGS]更新中定义的签名算法之一。一致性实施必须遵守[PKIXALGS]或IETF批准的[PKIXALGS]更新中规定的所有必须/应该/可能的签名算法声明。
For any conforming AC, the issuer/serialNumber pair MUST form a unique combination, even if ACs are very short-lived.
对于任何一致性AC，发卡机构/序列号对必须形成唯一的组合，即使AC非常短暂。
AC issuers MUST force the serialNumber to be a positive integer, that is, the sign bit in the DER encoding of the INTEGER value MUST be zero -- this can be done by adding a leading (leftmost) '00'H octet if necessary. This removes a potential ambiguity in mapping between a string of octets and an integer value.
AC发卡机构必须强制serialNumber为正整数，也就是说，整数值的DER编码中的符号位必须为零——如果需要，可以通过添加前导（最左侧）“00”H八位字节来实现。这消除了八位字节字符串和整数值之间映射的潜在歧义。
Given the uniqueness and timing requirements above, serial numbers can be expected to contain long integers. AC users MUST be able to handle serialNumber values longer than 4 octets. Conformant ACs MUST NOT contain serialNumber values longer than 20 octets.
鉴于上述唯一性和时序要求，序列号可能包含长整数。AC用户必须能够处理长度超过4个八位字节的serialNumber值。符合条件的ACs不得包含长度超过20个八位字节的serialNumber值。
There is no requirement that the serial numbers used by any AC issuer follow any particular ordering. In particular, they need not be monotonically increasing with time. Each AC issuer MUST ensure that each AC that it issues contains a unique serial number.
没有要求任何AC发行人使用的序列号遵循任何特定的订购。特别是，它们不必随着时间单调增加。每个AC发卡机构必须确保其发行的每个AC都包含一个唯一的序列号。
The attrCertValidityPeriod (a.k.a. validity) field specifies the period for which the AC issuer certifies that the binding between the holder and the attributes fields will be valid.
attrCertValidityPeriod（也称为有效期）字段指定AC发卡机构证明持有人和属性字段之间的绑定有效的期限。
The generalized time type, GeneralizedTime, is a standard ASN.1 type for variable precision representation of time. The GeneralizedTime field can optionally include a representation of the time differential between the local time zone and Greenwich Mean Time.
广义时间类型GeneratedTime是时间的可变精度表示的标准ASN.1类型。GeneratedTime字段可以选择性地包括本地时区和格林威治标准时间之间的时差表示。
For the purposes of this profile, GeneralizedTime values MUST be expressed in Coordinated universal time (UTC) (also known as Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.
在本配置文件中，广义时间值必须以协调世界时（UTC）（也称为格林威治标准时间或Zulu）表示，并且必须包括秒（即时间为YYYYMMDDHHMMSSZ），即使秒数为零。GeneralizedTime值不能包含小数秒。
(Note: this is the same as specified in [PKIXPROF], Section 4.1.2.5.2.)
（注：这与[PKIXPROF]第4.1.2.5.2节中的规定相同。）
AC users MUST be able to handle an AC which, at the time of processing, has parts of its validity period or all its validity period in the past or in the future (a post-dated AC). This is valid for some applications, such as backup.
AC用户必须能够处理在处理时部分有效期或全部有效期在过去或将来的AC（过期AC）。这对某些应用程序有效，例如备份。
The attributes field gives information about the AC holder. When the AC is used for authorization, this will often contain a set of privileges.
属性字段提供有关空调支架的信息。当AC用于授权时，它通常包含一组权限。
The attributes field contains a SEQUENCE OF Attribute. Each Attribute contains the type of the attribute and a SET OF values. For a given AC, each AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That is, only one instance of each attribute can occur in a single AC, but each instance can be multi-valued.
属性字段包含一系列属性。每个属性都包含属性的类型和一组值。对于给定的AC，序列中的每个AttributeType对象标识符必须是唯一的。也就是说，单个AC中只能出现每个属性的一个实例，但每个实例可以是多值的。
AC users MUST be able to handle multiple values for all attribute types.
AC用户必须能够处理所有属性类型的多个值。
An AC MUST contain at least one attribute. That is, the SEQUENCE OF Attributes MUST NOT be of zero length.
AC必须至少包含一个属性。也就是说，属性序列的长度不能为零。
Some standard attribute types are defined in Section 4.4.
第4.4节定义了一些标准属性类型。
This field MUST NOT be used unless it is also used in the AC issuer's PKC, in which case it MUST be used. Note that [PKIXPROF] states that this field SHOULD NOT be used by conforming certification authorities (CAs), but that applications SHOULD be able to parse PKCs containing the field.
除非在AC发卡机构的PKC中也使用此字段，否则不得使用此字段，在这种情况下，必须使用此字段。请注意，[PKIXPROF]声明此字段不应由合格证书颁发机构（CA）使用，但应用程序应能够解析包含此字段的PKC。
The extensions field generally gives information about the AC as opposed to information about the AC holder.
扩展字段通常提供有关空调的信息，而不是有关空调支架的信息。
An AC that has no extensions conforms to the profile; however, Section 4.3 defines the extensions that MAY be used with this profile, and whether or not they may be marked critical. If any other critical extension is used, the AC does not conform to this profile. However, if any other non-critical extension is used, the AC does conform to this profile.
没有扩展的AC符合配置文件；但是，第4.3节定义了可用于此配置文件的扩展，以及它们是否可以标记为关键。如果使用任何其他关键扩展，则AC不符合此配置文件。但是，如果使用任何其他非关键扩展，AC确实符合此配置文件。
The extensions defined for ACs provide methods for associating additional attributes with holders. This profile also allows communities to define private extensions to carry information unique to those communities. Each extension in an AC may be designated as critical or non-critical. An AC-using system MUST reject an AC if it encounters a critical extension it does not recognize; however, a non-critical extension may be ignored if it is not recognized. Section 4.3 presents recommended extensions used within Internet ACs and standard locations for information. Communities may elect to use additional extensions; however, caution should be exercised in adopting any critical extensions in ACs that might prevent use in a general context.
为ACs定义的扩展提供了将附加属性与持有者关联的方法。此配置文件还允许社区定义专用扩展，以承载这些社区特有的信息。AC中的每个扩展可指定为关键或非关键。如果AC使用系统遇到其无法识别的关键扩展，则必须拒绝AC；但是，如果未识别非关键扩展，则可能会忽略它。第4.3节介绍了互联网ACs和标准位置中使用的推荐扩展，以供参考。社区可以选择使用额外的扩展；然而，在ACs中采用任何可能会妨碍在一般环境中使用的关键扩展时，应该谨慎。
In some circumstances, it is required (e.g., by data protection/data privacy legislation) that audit trails not contain records that directly identify individuals. This circumstance may make the use of the AC Holder field unsuitable for use in audit trails.
在某些情况下，要求（例如，数据保护/数据隐私立法）审计跟踪不包含直接识别个人的记录。这种情况可能导致AC Holder字段的使用不适合用于审计跟踪。
To allow for such cases, an AC MAY contain an audit identity extension. Ideally, it SHOULD be infeasible to derive the AC holder's identity from the audit identity value without the cooperation of the AC issuer.
考虑到这种情况，AC可能包含审核标识扩展。理想情况下，如果没有AC发行人的合作，从审计身份值中得出AC持有人的身份是不可行的。
The value of the audit identity, along with the AC issuer/serial, SHOULD then be used for audit/logging purposes. If the value of the audit identity is suitably chosen, a server/service administrator can use audit trails to track the behavior of an AC holder without being able to identify the AC holder.
审计标识的值以及AC颁发者/序列号应用于审计/记录目的。如果适当选择了审核标识的值，则服务器/服务管理员可以使用审核跟踪来跟踪AC持有者的行为，而无需识别AC持有者。
The server/service administrator in combination with the AC issuer MUST be able to identify the AC holder in cases where misbehavior is detected. This means that the AC issuer MUST be able to determine the actual identity of the AC holder from the audit identity.
服务器/服务管理员与AC发卡机构必须能够在检测到不当行为的情况下识别AC持有人。这意味着AC发行人必须能够根据审计身份确定AC持有人的实际身份。
Of course, auditing could be based on the AC issuer/serial pair; however, this method does not allow tracking of the same AC holder with multiple ACs. Thus, an audit identity is only useful if it lasts for longer than the typical AC lifetime. Auditing could also be based on the AC holder's PKC issuer/serial; however, this will often allow the server/service administrator to identify the AC holder.
当然，审计可以基于AC发卡机构/串行对；但是，此方法不允许跟踪具有多个AC的同一AC保持器。因此，审核标识只有在其持续时间超过典型AC寿命时才有用。审计也可以基于AC持有人的PKC发行人/序列号；但是，这通常允许服务器/服务管理员识别AC持有者。
As the AC verifier might otherwise use the AC holder or some other identifying value for audit purposes, this extension MUST be critical when used.
由于AC验证者可能会出于审计目的使用AC持有者或其他一些识别值，因此使用此扩展时必须非常关键。
Protocols that use ACs will often expose the identity of the AC holder in the bits on-the-wire. In such cases, an opaque audit identity does not make use of the AC anonymous; it simply ensures that the ensuing audit trails do not contain identifying information.
使用ACs的协议通常会在线路上的位中暴露AC持有者的身份。在这种情况下，不透明的审计身份不会使用AC匿名；它只是确保随后的审计跟踪不包含识别信息。
The value of an audit identity MUST be longer than zero octets. The value of an audit identity MUST NOT be longer than 20 octets.
审核标识的值必须大于零个八位字节。审核标识的值不得超过20个八位字节。
name id-pe-ac-auditIdentity OID { id-pe 4 } syntax OCTET STRING criticality MUST be TRUE
name id pe ac auditentity OID{id pe 4}语法八位字节字符串临界值必须为TRUE
To target an AC, the target information extension, imported from [X.509-2000], MAY be used to specify a number of servers/services. The intent is that the AC SHOULD only be usable at the specified servers/services. An (honest) AC verifier who is not amongst the named servers/services MUST reject the AC.
为针对AC，可使用从[X.509-2000]导入的目标信息扩展来指定多个服务器/服务。其目的是AC应仅在指定的服务器/服务上可用。不在指定服务器/服务中的（诚实的）AC验证者必须拒绝AC。
If this extension is not present, the AC is not targeted and may be accepted by any server.
如果不存在此扩展，则AC不是目标，任何服务器都可以接受。
In this profile, the targeting information simply consists of a list of named targets or groups.
在此配置文件中，目标信息仅由命名目标或组的列表组成。
The following syntax is used to represent the targeting information:
以下语法用于表示目标信息：
Targets ::= SEQUENCE OF Target
Targets ::= SEQUENCE OF Target
Target ::= CHOICE {
targetName [0] GeneralName,
targetGroup [1] GeneralName,
targetCert [2] TargetCert
}
Target ::= CHOICE {
targetName [0] GeneralName,
targetGroup [1] GeneralName,
targetCert [2] TargetCert
}
TargetCert ::= SEQUENCE {
targetCertificate IssuerSerial,
targetName GeneralName OPTIONAL,
certDigestInfo ObjectDigestInfo OPTIONAL
}
TargetCert ::= SEQUENCE {
targetCertificate IssuerSerial,
targetName GeneralName OPTIONAL,
certDigestInfo ObjectDigestInfo OPTIONAL
}
The targetCert CHOICE within the Target structure is only present to allow future compatibility with [X.509-2000] and MUST NOT be used.
目标结构中的targetCert选项仅用于允许将来与[X.509-2000]兼容，不得使用。
The targets check passes if the current server (recipient) is one of the targetName fields in the Targets SEQUENCE, or if the current server is a member of one of the targetGroup fields in the Targets SEQUENCE. In this case, the current server is said to "match" the targeting extension.
如果当前服务器（收件人）是目标序列中的一个targetName字段，或者当前服务器是目标序列中一个targetGroup字段的成员，则目标检查通过。在本例中，当前服务器被称为“匹配”目标扩展。
How the membership of a target within a targetGroup is determined is not defined here. It is assumed that any given target "knows" the names of the targetGroups to which it belongs or can otherwise determine its membership. For example, the targetGroup specifies a DNS domain, and the AC verifier knows the DNS domain to which it belongs. For another example, the targetGroup specifies "PRINTERS", and the AC verifier knows whether or not it is a printer or print server.
此处未定义如何确定targetGroup中目标的成员身份。假设任何给定目标“知道”其所属目标组的名称，或可以以其他方式确定其成员资格。例如，targetGroup指定一个DNS域，AC验证器知道它所属的DNS域。例如，targetGroup指定“打印机”，AC验证器知道它是打印机还是打印服务器。
Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF Targets". Conforming AC issuer implementations MUST only produce one "Targets" element. Conforming AC users MUST be able to accept a "SEQUENCE OF Targets". If more than one Targets element is found in an AC, the extension MUST be treated as if all Target elements had been found within one Targets element.
注：[X.509-2000]将扩展语法定义为“目标序列”。合格的AC发卡机构实施必须只产生一个“目标”元素。合格的AC用户必须能够接受“目标序列”。如果在AC中找到多个目标元素，则必须将扩展视为在一个目标元素中找到了所有目标元素。
name id-ce-targetInformation OID { id-ce 55 } syntax SEQUENCE OF Targets criticality MUST be TRUE
name id ce targetInformation OID{id ce 55}目标关键性的语法序列必须为TRUE
The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY be used to assist the AC verifier in checking the signature of the AC. The [PKIXPROF] description should be read as if "CA" meant "AC issuer". As with PKCs, this extension SHOULD be included in ACs.
[PKIXPROF]中描述的authorityKeyIdentifier扩展可用于协助AC验证者检查AC的签名。[PKIXPROF]描述应理解为“CA”表示“AC颁发者”。与PKCs一样，此扩展应包含在ACs中。
Note: An AC, where the issuer field used the baseCertificateID CHOICE, would not need an authorityKeyIdentifier extension, as it is explicitly linked to the key in the referred certificate. However, as this profile states (in Section 4.2.3), ACs MUST use the v2Form with issuerName CHOICE, this duplication does not arise.
注意：如果颁发者字段使用baseCertificateID选项，则AC不需要authorityKeyIdentifier扩展，因为它显式链接到引用证书中的密钥。但是，正如该概要文件所述（在第4.2.3节中），ACs必须使用v2Form和issuerName选项，不会出现这种重复。
name id-ce-authorityKeyIdentifier OID { id-ce 35 } syntax AuthorityKeyIdentifier criticality MUST be FALSE
名称id ce authorityKeyIdentifier OID{id ce 35}语法authorityKeyIdentifier临界值必须为FALSE
The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be used to assist the AC verifier in checking the revocation status of the AC. Support for the id-ad-caIssuers accessMethod is OPTIONAL by this profile since AC chains are not expected.
[PKIXPROF]中定义的authorityInfoAccess扩展可用于协助AC验证器检查AC的吊销状态。此配置文件可选支持id ad caIssuers访问方法，因为不需要AC链。
The following accessMethod is used to indicate that revocation status checking is provided for this AC, using the Online Certificate Status Protocol (OCSP) defined in [OCSP]:
以下accessMethod用于指示使用[OCSP]中定义的联机证书状态协议（OCSP）为此AC提供吊销状态检查：
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
The accessLocation MUST contain a URI, and the URI MUST contain an HTTP URL [HTTP-URL] that specifies the location of an OCSP responder. The AC issuer MUST, of course, maintain an OCSP responder at this location.
accessLocation必须包含URI，并且URI必须包含指定OCSP响应程序位置的HTTP URL[HTTP-URL]。当然，AC发卡机构必须在此位置维护OCSP响应程序。
name id-ce-authorityInfoAccess OID { id-pe 1 } syntax AuthorityInfoAccessSyntax criticality MUST be FALSE
名称id ce authorityInfoAccess OID{id pe 1}语法AuthorityInfoAccessSyntax criticality必须为FALSE
The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY be used to assist the AC verifier in checking the revocation status of the AC. See Section 6 for details on revocation.
[PKIXPROF]中描述的crlDistributionPoints扩展可用于协助AC验证器检查AC的撤销状态。有关撤销的详细信息，请参阅第6节。
If the crlDistributionPoints extension is present, then exactly one distribution point MUST be present. The crlDistributionPoints extension MUST use the DistributionPointName option, which MUST contain a fullName, which MUST contain a single name form. That name MUST contain either a distinguished name or a URI. The URI MUST be either an HTTP URL [HTTP-URL] or a Lightweight Directory Access Protocol (LDAP) URL [LDAP-URL].
如果存在crlDistributionPoints扩展，则必须仅存在一个分发点。crlDistributionPoints扩展必须使用DistributionPointName选项，该选项必须包含全名，而全名必须包含单一名称表单。该名称必须包含可分辨名称或URI。URI必须是HTTP URL[HTTP-URL]或轻型目录访问协议（LDAP）URL[LDAP-URL]。
name id-ce-cRLDistributionPoints OID { id-ce 31 } syntax CRLDistributionPoints criticality MUST be FALSE
名称id ce cRLDistributionPoints OID{id ce 31}语法cRLDistributionPoints临界值必须为FALSE
The noRevAvail extension, defined in [X.509-2000], allows an AC issuer to indicate that no revocation information will be made available for this AC.
[X.509-2000]中定义的NOREVAIVAL扩展允许AC发行人指示不会为该AC提供撤销信息。
This extension MUST be non-critical. An AC verifier that does not understand this extension might be able to find a revocation list from the AC issuer, but the revocation list will never include an entry for the AC.
此扩展必须是非关键的。不了解此扩展的AC验证器可能能够从AC颁发者找到吊销列表，但吊销列表将永远不会包含AC的条目。
name id-ce-noRevAvail OID { id-ce 56 } syntax NULL (i.e., '0500'H is the DER encoding) criticality MUST be FALSE
name id ce noRevAvail OID{id ce 56}语法NULL（即'0500'H是DER编码）临界值必须为FALSE
Some of the attribute types defined below make use of the IetfAttrSyntax type, also defined below. The reasons for using this type are:
下面定义的一些属性类型使用了IetfAttrSyntax类型，也在下面定义。使用此类型的原因如下：
1. It allows a separation between the AC issuer and the attribute policy authority. This is useful for situations where a single policy authority (e.g., an organization) allocates attribute values, but where multiple AC issuers are deployed for performance or other reasons.
1. 它允许在AC颁发者和属性策略机构之间进行分离。这对于单个策略颁发机构（例如组织）分配属性值，但由于性能或其他原因部署了多个AC颁发者的情况非常有用。
2. The syntaxes allowed for values are restricted to OCTET STRING, OBJECT IDENTIFIER, and UTF8String, which significantly reduces the complexity associated with matching more general syntaxes. All multi-valued attributes using this syntax are restricted so that each value MUST use the same choice of value syntax. For example, AC issuers must not use one value with an oid and a second value with a string.
2. 允许值使用的语法仅限于八位字节字符串、对象标识符和UTF8String，这大大降低了与匹配更一般语法相关的复杂性。所有使用此语法的多值属性都受到限制，因此每个值必须使用相同的值选择语法。例如，AC发卡机构不得将一个值与oid一起使用，第二个值与字符串一起使用。
IetfAttrSyntax ::= SEQUENCE {
policyAuthority [0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE {
octets OCTET STRING,
oid OBJECT IDENTIFIER,
string UTF8String
}
}
IetfAttrSyntax ::= SEQUENCE {
policyAuthority [0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE {
octets OCTET STRING,
oid OBJECT IDENTIFIER,
string UTF8String
}
}
In the descriptions below, each attribute type is either tagged "Multiple Allowed" or "One Attribute value only; multiple values within the IetfAttrSyntax". This refers to the SET OF AttributeValues; the AttributeType still only occurs once, as specified in Section 4.2.7.
在下面的描述中，每个属性类型被标记为“允许多个”或“仅一个属性值；IetfAttrSyntax中的多个值”。这是指属性值的集合；根据第4.2.7节的规定，AttributeType仍然只出现一次。
The SvceAuthInfo attribute identifies the AC holder to the server/service by a name, and the attribute MAY include optional service specific authentication information. Typically, this will contain a username/password pair for a "legacy" application.
SvceAuthInfo属性通过名称标识服务器/服务的AC持有者，该属性可能包括可选的特定于服务的身份验证信息。通常，这将包含“遗留”应用程序的用户名/密码对。
This attribute provides information that can be presented by the AC verifier to be interpreted and authenticated by a separate application within the target system. Note that this is a different use to that intended for the accessIdentity attribute in 4.4.2 below.
此属性提供可由AC验证器呈现的信息，这些信息将由目标系统内的单独应用程序进行解释和验证。请注意，这与下面4.4.2中的accessIdentity属性的用途不同。
This attribute type will typically be encrypted when the authInfo field contains sensitive information, such as a password (see Section 7.1).
当authInfo字段包含敏感信息（如密码）时，通常会加密此属性类型（请参见第7.1节）。
name id-aca-authenticationInfo OID { id-aca 1 } syntax SvceAuthInfo values Multiple allowed
名称id aca身份验证信息OID{id aca 1}语法SvceAuthInfo值允许多个
SvceAuthInfo ::= SEQUENCE {
service GeneralName,
ident GeneralName,
authInfo OCTET STRING OPTIONAL
}
SvceAuthInfo ::= SEQUENCE {
service GeneralName,
ident GeneralName,
authInfo OCTET STRING OPTIONAL
}
The accessIdentity attribute identifies the AC holder to the server/service. For this attribute the authInfo field MUST NOT be present.
accessIdentity属性标识服务器/服务的AC持有者。对于此属性，authInfo字段不得存在。
This attribute is intended to be used to provide information about the AC holder, that can be used by the AC verifier (or a larger system of which the AC verifier is a component) to authorize the actions of the AC holder within the AC verifier's system. Note that this is a different use to that intended for the svceAuthInfo attribute described in 4.4.1 above.
该属性旨在提供有关AC持有者的信息，AC验证器（或AC验证器是其组成部分的更大系统）可使用该信息来授权AC持有者在AC验证器系统内的操作。请注意，这与上面4.4.1中描述的svceAuthInfo属性的用途不同。
name id-aca-accessIdentity OID { id-aca 2 } syntax SvceAuthInfo values Multiple allowed
名称id aca accessIdentity OID{id aca 2}语法SvceAuthInfo值允许多个
The chargingIdentity attribute identifies the AC holder for charging purposes. In general, the charging identity will be different from other identities of the holder. For example, the holder's company may be charged for service.
chargingIdentity属性用于识别用于充电的AC保持架。一般而言，充电身份将不同于持有人的其他身份。例如，持有人的公司可能会收取服务费。
name id-aca-chargingIdentity OID { id-aca 3 } syntax IetfAttrSyntax values One Attribute value only; multiple values within the IetfAttrSyntax
名称id aca chargingIdentity OID{id aca 3}语法IetfAttrSyntax仅值一个属性值；IetfAttrSyntax中的多个值
The group attribute carries information about group memberships of the AC holder.
group属性包含有关AC持有者的组成员身份的信息。
name id-aca-group OID { id-aca 4 } syntax IetfAttrSyntax values One Attribute value only; multiple values within the IetfAttrSyntax
名称id aca组OID{id aca 4}语法IetfAttrSyntax值仅一个属性值；IetfAttrSyntax中的多个值
The role attribute, specified in [X.509-2000], carries information about role allocations of the AC holder.
[X.509-2000]中指定的角色属性包含有关AC持有者角色分配的信息。
The syntax used for this attribute is:
此属性使用的语法为：
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
The roleAuthority field MAY be used to specify the issuing authority for the role specification certificate. There is no requirement that a role specification certificate necessarily exists for the roleAuthority. This differs from [X.500-2000], where the roleAuthority field is assumed to name the issuer of a role specification certificate. For example, to distinguish the administrator role as defined by "Baltimore" from that defined by "SPYRUS", one could put the value "urn:administrator" in the roleName field and the value "Baltimore" or "SPYRUS" in the roleAuthority field.
roleAuthority字段可用于指定角色规范证书的颁发机构。不要求roleAuthority必须存在角色规范证书。这与[X.500-2000]不同，在[X.500-2000]中，假设roleAuthority字段指定角色规范证书的颁发者。例如，为了区分“Baltimore”定义的管理员角色与“SPYRUS”定义的管理员角色，可以在roleName字段中输入值“urn:administrator”，在roleAuthority字段中输入值“Baltimore”或“SPYRUS”。
The roleName field MUST be present, and roleName MUST use the uniformResourceIdentifier CHOICE of the GeneralName.
roleName字段必须存在，并且roleName必须使用GeneralName的uniformResourceIdentifier选项。
name id-at-role OID { id-at 72 } syntax RoleSyntax values Multiple allowed
角色OID处的名称id{72处的id}语法角色语法允许多个值
The clearance attribute, specified in [X.501-1993], carries clearance (associated with security labeling) information about the AC holder.
[X.501-1993]中规定的“许可”属性包含AC持有人的许可（与安全标签相关）信息。
The policyId field is used to identify the security policy to which the clearance relates. The policyId indicates the semantics of the classList and securityCategories fields.
policyId字段用于标识与许可相关的安全策略。policyId指示classList和securityCategories字段的语义。
This specification includes the classList field exactly as it is specified in [X.501-1993]. Additional security classification values, and their position in the classification hierarchy, may be defined by a security policy as a local matter or by bilateral agreement. The basic security classification hierarchy is, in ascending order: unmarked, unclassified, restricted, confidential, secret, and top-secret.
本规范包含的类列表字段与[X.501-1993]中的规定完全相同。其他安全分类值及其在分类层次结构中的位置可由安全策略作为本地事项或双边协议定义。基本安全分类层次结构按升序为：未标记、未分类、受限、机密、机密和绝密。
An organization can develop its own security policy that defines security classification values and their meanings. However, the BIT STRING positions 0 through 5 are reserved for the basic security classification hierarchy.
组织可以制定自己的安全策略，定义安全分类值及其含义。但是，位字符串位置0到5是为基本安全分类层次结构保留的。
If present, the SecurityCategory field provides further authorization information. The security policy identified by the policyId field indicates the syntaxes that are allowed to be present in the securityCategories SET. An OBJECT IDENTIFIER identifies each of the allowed syntaxes. When one of these syntaxes is present in the securityCategories SET, the OBJECT IDENTIFIER associated with that syntax is carried in the SecurityCategory.type field.
如果存在，SecurityCategory字段将提供进一步的授权信息。policyId字段标识的安全策略表示允许在securityCategories集中出现的语法。对象标识符标识每个允许的语法。当这些语法之一出现在securityCategories集合中时，与该语法关联的对象标识符将携带在SecurityCategory.type字段中。
The object identifier for the clearance attribute from [RFC3281] is:
[RFC3281]中清除属性的对象标识符为：
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
clearance (55) }
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
clearance (55) }
The associated syntax was originally (and erroneously) defined in [RFC3281] as:
相关语法最初（且错误地）在[RFC3281]中定义为：
Clearance ::= SEQUENCE {
policyId [0] OBJECT IDENTIFIER,
classList [1] ClassList DEFAULT {unclassified},
securityCategories [2] SET OF SecurityCategory OPTIONAL
}
Clearance ::= SEQUENCE {
policyId [0] OBJECT IDENTIFIER,
classList [1] ClassList DEFAULT {unclassified},
securityCategories [2] SET OF SecurityCategory OPTIONAL
}
But, it was later corrected (to restore conformance with [X.509-1997]) to:
但是，后来修改为（恢复与[X.509-1997]的一致性）：
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
The object identifier for the clearance attribute from [X.509-1997] is:
[X.509-1997]中清除属性的对象标识符为：
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
The associated syntax is as follows:
相关语法如下所示：
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
Implementations MUST support the clearance attribute as defined in [X.501-1997]. Implementations SHOULD support decoding the clearance syntax from [RFC3281] and the errata report against it (see Appendix C). Implementations MUST NOT output the clearance attribute as defined in [RFC3281].
实施必须支持[X.501-1997]中定义的清除属性。实施应支持解码[RFC3281]中的清除语法以及针对该语法的勘误表报告（见附录C）。实施不得输出[RFC3281]中定义的清除属性。
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)
}
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] EXPLICIT ANY DEFINED BY type
}
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] EXPLICIT ANY DEFINED BY type
}
-- Note that in [RFC3281], the SecurityCategory syntax was as
-- follows:
--
-- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT OBJECT IDENTIFIER,
-- value [1] ANY DEFINED BY type
-- }
--
-- The removal of the IMPLICIT from the type line and the
-- addition of the EXPLICIT to the value line result in
-- no changes to the encodings.
-- This is the same as the original syntax, which was defined
-- using the MACRO construct, as follows:
-- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type
-- }
--
-- SECURITY-CATEGORY MACRO ::=
-- BEGIN
-- TYPE NOTATION ::= type | empty
-- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
-- END
-- Note that in [RFC3281], the SecurityCategory syntax was as
-- follows:
--
-- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT OBJECT IDENTIFIER,
-- value [1] ANY DEFINED BY type
-- }
--
-- The removal of the IMPLICIT from the type line and the
-- addition of the EXPLICIT to the value line result in
-- no changes to the encodings.
-- This is the same as the original syntax, which was defined
-- using the MACRO construct, as follows:
-- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type
-- }
--
-- SECURITY-CATEGORY MACRO ::=
-- BEGIN
-- TYPE NOTATION ::= type | empty
-- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
-- END
name { id-at-clearance }
OID { joint-iso-ccitt(2) ds(5) attribute-type (4)
clearance (55) }
syntax Clearance -- imported from [X.501-1997]
values Multiple allowed
name { id-at-clearance }
OID { joint-iso-ccitt(2) ds(5) attribute-type (4)
clearance (55) }
syntax Clearance -- imported from [X.501-1997]
values Multiple allowed
The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage extension in the PKC MUST NOT explicitly indicate that the AC issuer's public key cannot be used to validate a digital signature. In order to avoid confusion regarding serial numbers and revocations,
AC发卡机构的PKC必须符合[PKIXPROF]，PKC中的keyUsage扩展不得明确表示AC发卡机构的公钥不能用于验证数字签名。为了避免关于序列号和撤销的混淆，
an AC issuer MUST NOT also be a PKC Issuer. That is, an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST NOT have a basicConstraints extension with the cA boolean set to TRUE.
AC发卡机构不得同时也是PKC发卡机构。也就是说，AC发卡机构不能同时是CA。因此，AC颁发者的PKC不能具有cA布尔值设置为TRUE的basicConstraints扩展。
This section describes a basic set of rules that all valid ACs MUST satisfy. Some additional checks are also described, which AC verifiers MAY choose to implement.
本节描述了所有有效ACs必须满足的一组基本规则。还描述了AC验证器可选择实现的一些附加检查。
To be valid, an AC MUST satisfy all of the following:
为有效，AC必须满足以下所有条件：
1. Where the holder uses a PKC to authenticate to the AC verifier, the AC holder's PKC MUST be found, and the entire certification path of that PKC MUST be verified in accordance with [PKIXPROF]. As noted in the Security Considerations section, if some other authentication scheme is used, AC verifiers need to be very careful mapping the identities (authenticated identity, holder field) involved.
1. 如果持证人使用PKC向AC验证者进行认证，则必须找到AC持证人的PKC，并且必须根据[PKIXPROF]验证该PKC的整个认证路径。如安全注意事项一节所述，如果使用其他身份验证方案，AC验证者需要非常小心地映射所涉及的身份（已验证身份、持有者字段）。
2. The AC signature must be cryptographically correct, and the AC issuer's entire PKC certification path MUST be verified in accordance with [PKIXPROF].
2. AC签名必须是加密正确的，并且AC发卡机构的整个PKC认证路径必须按照[PKIXPROF]进行验证。
3. The AC issuer's PKC MUST also conform to the profile specified in Section 4.5 above.
3. AC发行人的PKC还必须符合上述第4.5节规定的配置文件。
4. The AC issuer MUST be directly trusted as an AC issuer (by configuration or otherwise).
4. 必须直接信任AC发卡机构作为AC发卡机构（通过配置或其他方式）。
5. The time for which the AC is being evaluated MUST be within the AC validity. If the evaluation time is equal to either notBeforeTime or notAfterTime, then the AC is timely and this check succeeds. Note that in some applications, the evaluation time MAY not be the same as the current time.
5. 评估AC的时间必须在AC有效期内。如果评估时间等于notBeforeTime或notAfterTime，则AC是及时的，此检查成功。请注意，在某些应用程序中，评估时间可能与当前时间不同。
6. The AC targeting check MUST pass as specified in Section 4.3.2.
6. AC目标检查必须按照第4.3.2节的规定通过。
7. If the AC contains an unsupported critical extension, the AC MUST be rejected.
7. 如果AC包含不受支持的关键扩展，则必须拒绝AC。
Support for an extension in this context means:
在此上下文中对扩展的支持意味着：
1. The AC verifier MUST be able to parse the extension value.
1. AC验证器必须能够解析扩展值。
2. Where the extension value causes the AC to be rejected, the AC verifier MUST reject the AC.
2. 如果扩展值导致AC被拒绝，AC验证器必须拒绝AC。
Additional Checks:
其他检查：
1. The AC MAY be rejected on the basis of further AC verifier configuration. For example, an AC verifier may be configured to reject ACs that contain or lack certain attributes.
1. 可以基于进一步的AC验证器配置来拒绝AC。例如，AC验证器可被配置为拒绝包含或缺少某些属性的AC。
2. If the AC verifier provides an interface that allows applications to query the contents of the AC, then the AC verifier MAY filter the attributes from the AC on the basis of configured information. For example, an AC verifier might be configured not to return certain attributes to certain servers.
2. 如果AC验证器提供允许应用程序查询AC的内容的接口，则AC验证器可以基于配置的信息从AC过滤属性。例如，AC验证器可能被配置为不向某些服务器返回某些属性。
In many environments, the validity period of an AC is less than the time required to issue and distribute revocation information. Therefore, short-lived ACs typically do not require revocation support. However, long-lived ACs and environments where ACs enable high value transactions MAY require revocation support.
在许多环境中，AC的有效期小于发布和分发吊销信息所需的时间。因此，短期ACs通常不需要撤销支持。但是，长寿命的ACs和ACs支持高价值事务的环境可能需要撤销支持。
Two revocation schemes are defined, and the AC issuer should elect the one that is best suited to the environment in which the AC will be employed.
定义了两种撤销方案，AC发行人应选择最适合AC使用环境的方案。
"Never revoke" scheme:
“永不撤销”计划：
ACs may be marked so that the relying party understands that no revocation status information will be made available. The noRevAvail extension is defined in Section 4.3.6, and the noRevAvail extension MUST be present in the AC to indicate use of this scheme.
可以标记ACs，以便依赖方理解不会提供撤销状态信息。第4.3.6节中定义了诺雷瓦瓦延伸，并且诺雷瓦瓦延伸必须出现在AC中，以表明使用了该方案。
Where no noRevAvail is present, the AC issuer is implicitly stating that revocation status checks are supported, and some revocation method MUST be provided to allow AC verifiers to establish the revocation status of the AC.
如果不存在NOREVAIVAL，则AC发卡机构暗示支持撤销状态检查，并且必须提供一些撤销方法，以允许AC验证者建立AC的撤销状态。
"Pointer in AC" scheme:
“AC中的指针”方案：
ACs may "point" to sources of revocation status information, using either an authorityInfoAccess extension or a crlDistributionPoints extension within the AC.
ACs可以使用AC中的authorityInfoAccess扩展或crlDistributionPoints扩展“指向”撤销状态信息的源。
For AC users, the "never revoke" scheme MUST be supported, and the "pointer in AC" scheme SHOULD be supported. If only the "never revoke" scheme is supported, then all ACs that do not contain a noRevAvail extension, MUST be rejected.
对于AC用户，必须支持“从不撤销”方案，并且应支持“AC中的指针”方案。如果仅支持“从不撤销”方案，则必须拒绝所有不包含noRevAvail扩展的ACs。
For AC issuers, the "never revoke" scheme MUST be supported. If all ACs that will ever be issued by that AC issuer contain a noRevAvail extension, the "pointer in AC" scheme need not be supported. If any AC can be issued that does not contain the noRevAvail extension, the "pointer in AC" scheme MUST be supported.
对于AC发行人，必须支持“从不撤销”方案。如果该AC发行人将发行的所有AC都包含noRevAvail扩展，则不需要支持“AC中的指针”方案。如果可以发出任何不包含noRevAvail扩展名的AC，则必须支持“AC中的指针”方案。
An AC MUST NOT contain both a noRevAvail extension and a "pointer in AC".
AC不得同时包含NOREVAIVAL扩展名和“AC中的指针”。
An AC verifier MAY use any source for AC revocation status information.
AC验证器可以使用AC撤销状态信息的任何源。
This section specifies features that MAY be implemented. Conformance to this profile does NOT require support for these features; however, if these features are offered, they MUST be offered as described below.
本节指定了可以实现的功能。符合此配置文件不需要支持这些功能；但是，如果提供了这些功能，则必须按照以下说明提供这些功能。
AC attributes MAY need to be encrypted if the AC is carried in the clear within an application protocol or the AC contains sensitive information (e.g., username/password).
如果AC在应用程序协议中以明文形式携带，或者AC包含敏感信息（例如用户名/密码），则可能需要对AC属性进行加密。
When a set of attributes is to be encrypted within an AC, the Cryptographic Message Syntax, EnvelopedData structure [CMS] is used to carry the ciphertext and associated per-recipient keying information.
当一组属性要在AC中加密时，加密消息语法EnvelopedData structure[CMS]用于携带密文和相关的每个收件人密钥信息。
This type of attribute encryption is targeted. Before the AC is signed, the attributes are encrypted for a set of predetermined recipients.
这种类型的属性加密是有针对性的。在AC被签名之前，对一组预定接收者的属性进行加密。
Within EnvelopedData, the encapsulatedContentInfo identifies the content type carried within the ciphertext. In this case, the contentType field of encapsulatedContentInfo MUST contain id-ct-attrCertEncAttrs, which has the following value:
在EnvelopedData中，封装的ContentInfo标识密文中携带的内容类型。在这种情况下，封装ContentInfo的contentType字段必须包含id ct attrCertEncAttrs，该id具有以下值：
attrCertEncAttrs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-ct(1) 14 }
attrCertEncAttrs OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-ct(1) 14 }
The ciphertext is included in the AC as the value of an encAttrs attribute. Only one encAttrs attribute can be present in an AC; however, the encAttrs attribute MAY be multi-valued, and each of its values will contain an independent EnvelopedData.
密文作为encAttrs属性的值包含在AC中。一个AC中只能存在一个encAttrs属性；但是，encAttrs属性可以是多值的，并且其每个值都将包含一个独立的EnvelopedData。
Each value can contain a set of attributes (each possibly a multi-valued attribute) encrypted for a set of predetermined recipients.
每个值可以包含一组为一组预定收件人加密的属性（每个属性可能是多值属性）。
The cleartext that is encrypted has the type:
加密的明文具有以下类型：
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
The DER encoding of the ACClearAttrs structure is used as the encryptedContent field of the EnvelopedData. The DER encoding MUST be embedded in an OCTET STRING.
ACClearAttrs结构的DER编码用作信封数据的encryptedContent字段。DER编码必须嵌入到八位字节字符串中。
The acIssuer and acSerial fields are present to prevent ciphertext stealing. When an AC verifier has successfully decrypted an encrypted attribute, it MUST then check that the AC issuer and serialNumber fields contain the same values. This prevents a malicious AC issuer from copying ciphertext from another AC (without knowing its corresponding plaintext).
存在acIssuer和acSerial字段以防止密文窃取。当AC验证器成功解密加密属性时，它必须检查AC issuer和serialNumber字段是否包含相同的值。这可以防止恶意AC颁发者从另一个AC复制密文（而不知道其对应的明文）。
The procedure for an AC issuer when encrypting attributes is illustrated by the following (any other procedure that gives the same result MAY be used):
AC发卡机构加密属性时的程序如下所示（可使用给出相同结果的任何其他程序）：
1. Identify the sets of attributes that are to be encrypted for each set of recipients.
1. 标识要为每组收件人加密的属性集。
2. For each attribute set that is to be encrypted:
2. 对于要加密的每个属性集：
2.1. Create an EnvelopedData structure for the data for this set of recipients.
2.1. 为此收件人集的数据创建信封数据结构。
2.2. Encode the ContentInfo containing the EnvelopedData as a value of the encAttrs attribute.
2.2. 将包含EnvelopedData的ContentInfo编码为encAttrs属性的值。
2.3. Ensure the cleartext attributes are not present in the to-be-signed AC.
2.3. 确保待签名AC中不存在明文属性。
3. Add the encAttrs (with its multiple values) to the AC.
3. 将encattr（及其多个值）添加到AC。
Note that there may be more than one attribute of the same type (the same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain the same attribute type both in clear and in encrypted form (and indeed several times if the different recipients are associated with more than one EnvelopedData). For example, an AC could contain a cleartext clearance attribute saying the holder is cleared to SECRET,
请注意，解密后可能会有多个相同类型（相同对象标识符）的属性。也就是说，一个AC可以包含相同的属性类型，包括明文和加密的属性类型（如果不同的收件人与多个EnvelopedData关联，则可能包含多次）。例如，AC可能包含明文清除属性，表示持有人已被清除为机密，
and, in addition, an encrypted clearance attribute whose value is some higher clearance that's not allowed to be known everywhere. One approach implementers may choose, would be to merge attribute values following decryption in order to re-establish the "once only" constraint.
此外，还有一个加密的清除属性，它的值是不允许到处都知道的更高的清除率。实现者可能选择的一种方法是在解密后合并属性值，以便重新建立“仅一次”约束。
name id-aca-encAttrs OID { id-aca 6} syntax ContentInfo values Multiple Allowed
name id aca encAttrs OID{id aca 6}语法ContentInfo值允许多个
If an AC contains attributes apparently encrypted for the AC verifier, then the decryption process failure MUST cause the AC to be rejected.
如果AC包含明显为AC验证器加密的属性，则解密过程失败必须导致AC被拒绝。
When a server acts as a client for another server on behalf of the AC holder, the server MAY need to proxy an AC. Such proxying MAY have to be done under the AC issuer's control, so that not every AC is proxiable and so that a given proxiable AC can be proxied in a targeted fashion. Support for chains of proxies (with more than one intermediate server) MAY also be required. Note that this does not involve a chain of ACs.
当服务器代表AC持有人充当另一台服务器的客户端时，服务器可能需要代理AC。此类代理可能必须在AC发行人的控制下完成，以便不是每个AC都是可代理的，并且可以以目标方式代理给定的可代理AC。还可能需要支持代理链（具有多个中间服务器）。请注意，这并不涉及ACs链。
In order to meet this requirement, we define another extension, ProxyInfo, similar to the targeting extension.
为了满足这个需求，我们定义了另一个扩展ProxyInfo，类似于目标扩展。
When this extension is present, the AC verifier MUST check that the entity from which the AC was received was allowed to send it and that the AC is allowed to be used by this verifier.
当存在此扩展时，AC验证器必须检查接收AC的实体是否允许发送该扩展，以及该验证器是否允许使用该AC。
The proxying information is a list in which each item is a list of targeting information. If the verifier and the sender of the AC are both named in the same proxy list, the AC can then be accepted (the exact rule is given below).
代理信息是一个列表，其中每个项目都是目标信息列表。如果AC的验证者和发送者都在同一个代理列表中，则AC可以被接受（下面给出了确切的规则）。
The effect is that the AC holder can send the AC to any valid target, which can then only proxy to targets that are in one of the same proxy lists as itself.
其效果是，AC持有人可以将AC发送给任何有效的目标，然后该目标只能代理与自身位于同一代理列表中的目标。
The following data structure is used to represent the targeting/proxying information:
以下数据结构用于表示目标/代理信息：
ProxyInfo ::= SEQUENCE OF Targets
ProxyInfo ::= SEQUENCE OF Targets
Targets is explained in Section 4.3.2. As in the case of targeting, the targetCert CHOICE MUST NOT be used.
第4.3.2节对目标进行了解释。与目标设定一样，不得使用targetCert选项。
A proxy check succeeds if either one of the conditions below is met:
如果满足以下任一条件，则代理检查成功：
1. The identity of the sender, as established by the underlying authentication service, matches the Holder field of the AC, and the current server "matches" any one of the proxy sets. Recall that "matches" is as defined Section 4.3.2.
1. 由基础身份验证服务建立的发送方标识与AC的Holder字段匹配，并且当前服务器“匹配”任何一个代理集。回想一下，“匹配”的定义见第4.3.2节。
2. The identity of the sender, as established by the underlying authentication service, "matches" one of the proxy sets (call it set "A"), and the current server is one of the targetName fields in the set "A", or the current server is a member of one of the targetGroup fields in set "A".
2. 由基础身份验证服务建立的发送方标识“匹配”其中一个代理集（称为集“A”），并且当前服务器是集“A”中的一个targetName字段，或者当前服务器是集“A”中一个targetGroup字段的成员。
When an AC is proxied more than once, a number of targets will be on the path from the original client, which is normally, but not always, the AC holder. In such cases, prevention of AC "stealing" requires that the AC verifier MUST check that all targets on the path are members of the same proxy set. It is the responsibility of the AC-using protocol to ensure that a trustworthy list of targets on the path is available to the AC verifier.
当AC被代理多次时，许多目标将位于原始客户端的路径上，而原始客户端通常（但不总是）是AC持有者。在这种情况下，防止AC“窃取”要求AC验证器必须检查路径上的所有目标是否为同一代理集的成员。AC使用协议的责任是确保AC验证器可以使用路径上可靠的目标列表。
name id-pe-ac-proxying OID { id-pe 10 } syntax ProxyInfo criticality MUST be TRUE
名称id pe ac代理OID{id pe 10}语法代理信息关键性必须为TRUE
In some environments, it may be required that the AC is not linked either to an identity (via entityName) or to a PKC (via baseCertificateID). The objectDigestInfo CHOICE in the Holder field allows support for this requirement.
在某些环境中，可能要求AC不链接到标识（通过entityName）或PKC（通过baseCertificateID）。Holder字段中的objectDigestInfo选项允许支持此要求。
If the holder is identified with the objectDigestInfo field, then the AC version field MUST contain v2 (the integer 1).
如果使用objectDigestInfo字段标识持有者，则AC版本字段必须包含v2（整数1）。
The idea is to link the AC to an object by placing a hash of that object into the Holder field of the AC. For example, this allows production of ACs that are linked to public keys rather than names. It also allows production of ACs that contain privileges associated with an executable object such as a Java class. However, this profile only specifies how to use a hash over a public key or PKC. That is, conformant ACs MUST NOT use the otherObjectTypes value for the digestedObjectType.
其思想是将AC链接到一个对象，方法是将该对象的散列放入AC的Holder字段中。例如，这允许生成链接到公钥而不是名称的AC。它还允许生成包含与可执行对象（如Java类）关联的特权的ACs。但是，此配置文件仅指定如何在公钥或PKC上使用哈希。也就是说，符合条件的ACs不能对digestedObjectType使用otherObjectTypes值。
To link an AC to a public key, the hash must be calculated over the representation of that public key, which would be present in a PKC, specifically, the input for the hash algorithm MUST be the DER encoding of a SubjectPublicKeyInfo representation of the key.
要将AC链接到公钥，必须在PKC中存在的公钥表示上计算散列，具体来说，散列算法的输入必须是密钥的SubjectPublicKeyInfo表示的DER编码。
Note: this includes the AlgorithmIdentifier as well as the BIT STRING. The rules given in [PKIXALGS] for encoding keys MUST be followed. In this case, the digestedObjectType MUST be publicKey and the otherObjectTypeID field MUST NOT be present.
注意：这包括算法标识符以及位字符串。必须遵循[PKIXALGS]中给出的密钥编码规则。在这种情况下，digestedObjectType必须是publicKey，而otherObjectTypeID字段不得存在。
Note that if the public key value used as input to the hash function has been extracted from a PKC, it is possible that the SubjectPublicKeyInfo from that PKC is NOT the value that should be hashed. This can occur if Digital Signature Algorithm (DSA) Dss-parms are inherited as described in Section 2.3.2 of [PKIXALGS]. The correct input for hashing in this context will include the value of the parameters inherited from the CA's PKC, and thus may differ from the SubjectPublicKeyInfo present in the PKC.
请注意，如果用作哈希函数输入的公钥值是从PKC中提取的，则该PKC中的SubjectPublicKeyInfo可能不是应进行哈希处理的值。如果按照[PKIXALGS]第2.3.2节所述继承数字签名算法（DSA）Dss parms，则可能发生这种情况。在此上下文中，哈希的正确输入将包括从CA的PKC继承的参数值，因此可能不同于PKC中的SubjectPublicKeyInfo。
Implementations that support this feature MUST be able to handle the representations of public keys for the algorithms specified in Section 2.3 of [PKIXALGS].
支持此功能的实现必须能够处理[PKIXALGS]第2.3节中指定算法的公钥表示。
In order to link an AC to a PKC via a digest, the digest MUST be calculated over the DER encoding of the entire PKC, including the signature value. In this case, the digestedObjectType MUST be publicKeyCert and the otherObjectTypeID field MUST NOT be present.
为了通过摘要将AC链接到PKC，必须在整个PKC的DER编码（包括签名值）上计算摘要。在这种情况下，digestedObjectType必须是publicKeyCert，并且otherObjectTypeID字段不得存在。
During AC validation, a relying party has to answer the question: is this AC issuer trusted to issue ACs containing this attribute? The AAControls PKC extension MAY be used to help answer the question. The AAControls extension is intended to be used in CA and AC issuer PKCs.
在AC验证期间，依赖方必须回答以下问题：是否信任此AC颁发者颁发包含此属性的AC？AAControls PKC扩展可用于帮助回答此问题。AAControls扩展旨在用于CA和AC发卡机构PKC。
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE
}
AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE
}
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
The AAControls extension is used as follows:
AAControls扩展的使用方式如下：
The pathLenConstraint, if present, is interpreted as in [PKIXPROF]. It restricts the allowed distance between the AA CA (a CA directly trusted to include AAControls in its PKCs), and the AC issuer.
pathLenConstraint（如果存在）在[PKIXPROF]中解释为。它限制AA CA（直接受信任的CA，可在其PKC中包含AAControls）与AC颁发者之间的允许距离。
The permittedAttrs field specifies a list of attribute types that any AC issuer below this AA CA is allowed to include in ACs. If this field is not present, it means that no attribute types are explicitly allowed.
permittedAttrs字段指定允许此AA CA下的任何AC颁发者包含在ACs中的属性类型列表。如果此字段不存在，则表示不允许显式使用属性类型。
The excludedAttrs field specifies a list of attribute types that no AC issuer below this AA CA is allowed to include in ACs. If this field is not present, it means that no attribute types are explicitly disallowed.
excludedAttrs字段指定属性类型列表，此AA CA下的AC颁发者不允许包含在ACs中。如果此字段不存在，则表示不明确禁止任何属性类型。
The permitUnSpecified field specifies how to handle attribute types that are not present in either the permittedAttrs or excludedAttrs fields. TRUE (the default) means that any unspecified attribute type is allowed in ACs; FALSE means that no unspecified attribute type is allowed.
PermitTunSpecified字段指定如何处理permittedAttrs或excludedAttrs字段中不存在的属性类型。TRUE（默认值）表示ACs中允许任何未指定的属性类型；FALSE表示不允许使用未指定的属性类型。
When AAControls are used, the following additional checks on an AA's PKC chain MUST all succeed for the AC to be valid:
使用AAControls时，AA的PKC链上的以下附加检查必须全部成功才能使AC有效：
1. Some CA on the AC's certificate path MUST be directly trusted to issue PKCs that precede the AC issuer in the certification path; call this CA the "AA CA".
1. 必须直接信任AC证书路径上的某些CA，才能在证书路径中颁发位于AC颁发者之前的PKC；将此CA称为“AA CA”。
2. All PKCs on the path from the AA CA, down to and including the AC issuer's PKC, MUST contain an AAControls extension; however, the PKC of the AA CA need not contain this extension.
2. 从AA CA到AC发行人PKC（包括AC发行人PKC）路径上的所有PKC必须包含AAControls扩展；但是，AA CA的PKC不需要包含此扩展。
3. Only those attributes in the AC that are allowed, according to all of the AAControls extension values in all of the PKCs from the AA CA to the AC issuer, may be used for authorization decisions; all other attributes MUST be ignored. This check MUST be applied to the list of attributes following attribute decryption, and the id-aca-encAttrs type MUST also be checked.
3. 根据从AA CA到AC发卡机构的所有PKC中的所有AAControls扩展值，只有AC中允许的属性可用于授权决策；必须忽略所有其他属性。此检查必须应用于属性解密后的属性列表，并且还必须检查id aca encAttrs类型。
name id-pe-aaControls OID { id-pe 6 } syntax AAControls criticality MAY be TRUE
名称id pe aaControls OID{id pe 6}语法aaControls criticality可能为TRUE
The protection afforded for private keys is a critical factor in maintaining security. Failure of AC issuers to protect their private keys will permit an attacker to masquerade as them, potentially generating false ACs or revocation status. Existence of bogus ACs and revocation status will undermine confidence in the system. If the compromise is detected, all ACs issued by the AC issuer MUST be revoked. Rebuilding after such a compromise will be problematic, so AC issuers are advised to implement a combination of strong technical measures (e.g., tamper-resistant cryptographic modules) and appropriate management procedures (e.g., separation of duties) to avoid such an incident.
为私钥提供的保护是维护安全性的一个关键因素。AC颁发者未能保护其私钥将允许攻击者伪装成他们，可能产生虚假的ACs或吊销状态。虚假ACs和吊销状态的存在将破坏对系统的信心。如果检测到泄露，则必须撤销AC发行人发行的所有AC。此类妥协后的重建将产生问题，因此建议AC发行人实施强有力的技术措施（如防篡改加密模块）和适当的管理程序（如职责分离）相结合，以避免此类事件。
Loss of an AC issuer's private signing key may also be problematic. The AC issuer would not be able to produce revocation status or perform AC renewal. AC issuers are advised to maintain secure backup for signing keys. The security of the key backup procedures is a critical factor in avoiding key compromise.
AC发行人的私人签名密钥丢失也可能有问题。AC发卡机构将无法生成吊销状态或执行AC续订。建议AC发行人维护签名密钥的安全备份。密钥备份过程的安全性是避免密钥泄露的关键因素。
The availability and freshness of revocation status will affect the degree of assurance that should be placed in a long-lived AC. While long-lived ACs expire naturally, events may occur during its natural lifetime that negate the binding between the AC holder and the attributes. If revocation status is untimely or unavailable, the assurance associated with the binding is clearly reduced.
吊销状态的可用性和新鲜度将影响应放置在长寿命AC中的保证程度。虽然长寿命AC自然过期，但在其自然生存期内可能会发生否定AC持有者和属性之间绑定的事件。如果撤销状态不及时或不可用，则与绑定相关的保证将明显减少。
The binding between an AC holder and attributes cannot be stronger than the cryptographic module implementation and algorithms used to generate the signature. Short key lengths or weak hash algorithms will limit the utility of an AC. AC issuers are encouraged to note advances in cryptology so they can employ strong cryptographic techniques.
AC持有者和属性之间的绑定不能强于用于生成签名的加密模块实现和算法。短密钥长度或弱散列算法将限制AC的实用性。鼓励AC发行人注意密码学的进步，以便他们能够使用强大的加密技术。
Inconsistent application of name comparison rules may result in acceptance of invalid targeted or proxied ACs, or rejection of valid ones. The X.500 series of specifications defines rules for comparing distinguished names. These rules require comparison of strings without regard to case, character set, multi-character white space substrings, or leading and trailing white space. This specification and [PKIXPROF] relaxes these requirements, requiring support for binary comparison at a minimum.
名称比较规则的不一致应用可能导致接受无效的目标或代理ACs，或拒绝有效的ACs。X.500系列规范定义了用于比较可分辨名称的规则。这些规则要求比较字符串，而不考虑大小写、字符集、多字符空格子字符串或前导和尾随空格。本规范和[PKIXPROF]放宽了这些要求，至少需要支持二进制比较。
AC issuers MUST encode the distinguished name in the AC holder.entityName field identically to the distinguished name in the holder's PKC. If different encodings are used, implementations of this specification may fail to recognize that the AC and PKC belong to the same entity.
AC发卡机构必须将AC holder.entityName字段中的可分辨名称编码为与持有人PKC中的可分辨名称相同的名称。如果使用不同的编码，本规范的实现可能无法识别AC和PKC属于同一实体。
If an attribute certificate is tied to the holder's PKC using the baseCertificateID component of the Holder field and the PKI in use includes a rogue CA with the same issuer name specified in the baseCertificateID component, this rogue CA could issue a PKC to a malicious party, using the same issuer name and serial number as the proper holder's PKC. Then the malicious party could use this PKC in conjunction with the AC. This scenario SHOULD be avoided by properly managing and configuring the PKI so that there cannot be two CAs with the same name. Another alternative is to tie ACs to PKCs using the publicKeyCert type in the ObjectDigestInfo field. Failing this, AC verifiers have to establish (using other means) that the potential collisions cannot actually occur, for example, the Certificate Practice Statements (CPSs) of the CAs involved may make it clear that no such name collisions can occur.
如果属性证书使用持有者字段的baseCertificateID组件绑定到持有者的PKC，并且使用中的PKI包含具有baseCertificateID组件中指定的相同颁发者名称的恶意CA，则该恶意CA可能会向恶意方颁发PKC，使用与正确持有人PKC相同的发卡机构名称和序列号。然后，恶意方可以将此PKC与AC一起使用。应通过正确管理和配置PKI来避免这种情况，以便不会有两个具有相同名称的CA。另一种选择是使用ObjectDigestInfo字段中的publicKeyCert类型将ACs与PKCs绑定。如果不能做到这一点，AC验证者必须（使用其他方法）确定潜在冲突实际上不会发生，例如，相关CA的证书实践声明（CPS）可能会明确指出不会发生此类名称冲突。
Implementers MUST ensure that following validation of an AC, only attributes that the issuer is trusted to issue are used in authorization decisions. Other attributes, which MAY be present MUST be ignored. Given that the AAControls PKC extension is optional to implement, AC verifiers MUST be provided with this information by other means. Configuration information is a likely alternative means. This becomes very important if an AC verifier trusts more than one AC issuer.
实施者必须确保在AC验证之后，授权决策中仅使用发卡机构受信任可以发布的属性。必须忽略可能存在的其他属性。鉴于AAControls PKC扩展是可选的，必须通过其他方式向AC验证器提供此信息。配置信息是一种可能的替代方法。如果AC验证者信任多个AC颁发者，这一点就变得非常重要。
There is often a requirement to map between the authentication supplied by a particular security protocol (e.g., TLS, S/MIME) and the AC holder's identity. If the authentication uses PKCs, then this mapping is straightforward. However, it is envisaged that ACs will also be used in environments where the holder may be authenticated using other means. Implementers SHOULD be very careful in mapping the authenticated identity to the AC holder, especially when the authenticated identity does not come from a public key certificate as link between identity and AC may not be as "strong".
通常需要在特定安全协议（如TLS、S/MIME）提供的身份验证和AC持有人的身份之间进行映射。如果身份验证使用PKCs，则此映射非常简单。然而，设想ACs也将用于可使用其他方式认证持有人的环境中。实现者在将经过身份验证的身份映射到AC持有者时应该非常小心，特别是当经过身份验证的身份不是来自公钥证书时，因为身份和AC之间的链接可能不那么“强”。
Attributes and attribute certificate extensions are identified by object identifiers (OIDs). Many of the OIDs used in this document are copied from X.509 [X.509-2000]. Other OIDs were assigned from an arc delegated by the IANA to the PKIX working group. No further action by the IANA is necessary for this document or any anticipated updates.
属性和属性证书扩展由对象标识符（OID）标识。本文档中使用的许多OID都是从X.509[X.509-2000]复制而来的。其他OID由IANA委托给PKIX工作组的arc分配。IANA无需对本文件或任何预期更新采取进一步行动。
[PKIXALGS] refers to [RFC3279], [RFC4055], [RFC5480], and [RFC5756].
[PKIXALGS]指的是[RFC3279]、[RFC4055]、[RFC5480]和[RFC5756]。
[Err302] RFC Errata, Errata ID 302, RFC 3281, http://www.rfc-editor.org.
[Err302]RFC勘误表，勘误表ID 302，RFC 3281，http://www.rfc-editor.org.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 56522009年9月。
[HTTP-URL] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[HTTP-URL]Housley，R.和P.Hoffman，“Internet X.509公钥基础设施操作协议：FTP和HTTP”，RFC 25851999年5月。
[LDAP-URL] Smith, M., Ed., and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[LDAP-URL]Smith，M.，Ed.，和T.Howes，“轻量级目录访问协议（LDAP）：统一资源定位器”，RFC45162006年6月。
[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月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279]Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RFC4055]Schaad，J.，Kaliski，B.，和R.Housley，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件中使用的RSA加密的其他算法和标识符”，RFC 4055，2005年6月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 54802009年3月。
[RFC5756] Turner, S. Brown, D., Yiu, K., Housley, R., and T. Polk, "Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters", RFC 5756, January 2010.
[RFC5756]Turner，S.Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“RSAES-OAEP和RSASSA-PSS算法参数的更新”，RFC 57562010年1月。
[PKIXPROF] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[PKIXPROF]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[X509-SRV] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, August 2007.
[X509-SRV]Santesson，S.，“互联网X.509公钥基础设施主体服务名称表达的备选名称”，RFC 4985，2007年8月。
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
[X.680]ITU-T建议X.680（2002）| ISO/IEC 8824-1:2002，信息技术-抽象语法符号1（ASN.1）：基本符号规范。
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X.690]ITU-T建议X.690（2002）| ISO/IEC 8825-1:2002，信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范。
[KRB] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[KRB]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[LDAP] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[LDAP]Sermersheim，J.，Ed.，“轻量级目录访问协议（LDAP）：协议”，RFC45112006年6月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[RFC3281]Farrell，S.和R.Housley，“用于授权的Internet属性证书配置文件”，RFC 3281，2002年4月。
[X.500-2000] ITU-T Recommendation X.500 (2000) | ISO/IEC 9594-1:2000, Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services.
[X.500-2000]ITU-T建议X.500（2000）| ISO/IEC 9594-1:2000，信息技术-开放系统互连-目录：概念、模型和服务概述。
[X.501-1993] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1993, Information technology - Open Systems Interconnection - The Directory: Models.
[X.501-1993]ITU-T建议X.501（1993）| ISO/IEC 9594-2:1993，信息技术-开放系统互连-目录：模型。
[X.501-1997] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997, Information technology - Open Systems Interconnection - The Directory: Models.
[X.501-1997]ITU-T建议X.501（1997）| ISO/IEC 9594-2:1997，信息技术-开放系统互连-目录：模型。
[X.509-1988] CCITT Recommendation X.509: The Directory - Authentication Framework, 1988.
[X.509-1988]CCITT建议X.509：目录认证框架，1988年。
[X.509-1997] ITU-T Recommendation X.509: The Directory - Authentication Framework, 1997.
[X.509-1997]ITU-T建议X.509：目录认证框架，1997年。
[X.509-2000] ITU-T Recommendation X.509: The Directory - Public-Key and Attribute Certificate Frameworks, 2000.
[X.509-2000]ITU-T建议X.509：目录-公钥和属性证书框架，2000年。
This (normative) appendix lists the new object identifiers that are defined in this specification. Some of these are required only for support of optional features and are not required for conformance to this profile. This specification mandates support for OIDs that have arc elements with values that are less than 2^32, (i.e., they MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less than 2^31 (i.e., less than or equal to 2,147,483,647). This allows each arc element to be represented within a single 32-bit word. Implementations MUST also support OIDs where the length of the dotted decimal (see [LDAP], Section 4.1.2) string representation can be up to 100 bytes (inclusive). Implementations MUST be able to handle OIDs with up to 20 elements (inclusive). AAs SHOULD NOT issue ACs that contain OIDs that breach these requirements.
本（规范性）附录列出了本规范中定义的新对象标识符。其中一些仅用于支持可选功能，而不用于符合此配置文件。本规范要求支持具有值小于2^32（即，它们必须介于0和4294967295之间，包括0和4294967295之间）且应小于2^31（即，小于或等于2147483647）的弧元素的OID。这允许在单个32位字中表示每个arc元素。实现还必须支持OID，其中点十进制（见[LDAP]，第4.1.2节）字符串表示的长度最多可达100字节（含100字节）。实现必须能够处理多达20个元素（包括）的OID。AAs不应发布包含违反这些要求的OID的ACs。
The following OIDs are imported from [PKIXPROF]:
以下OID是从[PKIXPROF]导入的：
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-mod OBJECT IDENTIFIER ::= { id-pkix 0 }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
The following new ASN.1 module OID is defined:
定义了以下新的ASN.1模块OID：
id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 }
id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 }
The following AC extension OIDs are defined:
定义了以下AC扩展OID：
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
The following PKC extension OIDs are defined:
定义了以下PKC扩展OID：
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
The following attribute OIDs are defined:
定义了以下属性OID：
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-at-role OBJECT IDENTIFIER ::= { id-at 72 }
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
clearance (55) }
id-at-role OBJECT IDENTIFIER ::= { id-at 72 }
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
clearance (55) }
As noted in Section 4.4.6, there are two OIDs for id-at-clearance.
如第4.4.6节所述，间隙处的id有两个OID。
This appendix describes data objects used by conforming PKI components in an "ASN.1-like" syntax [X.680]. This syntax is a hybrid of the 1988 and 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 UNIVERSAL Types UniversalString, BMPString, and UTF8String.
本附录以“ASN.1-like”语法[X.680]描述了一致性PKI组件使用的数据对象。这种语法是1988年和1993年ASN.1语法的混合。1988年的ASN.1语法由1993年的通用类型UniversalString、BMPString和UTF8String扩展而成。
The ASN.1 syntax does not permit the inclusion of type statements in the ASN.1 module, and the 1993 ASN.1 standard does not permit use of the new UNIVERSAL types in modules using the 1988 syntax. As a result, this module does not conform to either version of the ASN.1 standard.
ASN.1语法不允许在ASN.1模块中包含类型语句，1993年ASN.1标准不允许在使用1988语法的模块中使用新的通用类型。因此，该模块不符合ASN.1标准的任何版本。
This appendix may be converted into 1988 ASN.1 by replacing the definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
本附录可转换为1988年ASN.1，方法是将通用类型的定义替换为1988年的“任何”。
PKIXAttributeCertificate-2008 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-attribute-cert-v2(61) }
PKIXAttributeCertificate-2008 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-attribute-cert-v2(61) }
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
IMPORTS
进口
-- IMPORTed module OIDs MAY change if [PKIXPROF] changes
-- PKIX Certificate Extensions
-- IMPORTed module OIDs MAY change if [PKIXPROF] changes
-- PKIX Certificate Extensions
Attribute, AlgorithmIdentifier, CertificateSerialNumber,
Extensions, UniqueIdentifier, id-pkix, id-pe, id-kp, id-ad, id-at
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(18) }
Attribute, AlgorithmIdentifier, CertificateSerialNumber,
Extensions, UniqueIdentifier, id-pkix, id-pe, id-kp, id-ad, id-at
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(18) }
GeneralName, GeneralNames, id-ce, AuthorityKeyIdentifier,
AuthorityInfoAccessSyntax, CRLDistributionPoint
FROM PKIX1Implicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(19) }
GeneralName, GeneralNames, id-ce, AuthorityKeyIdentifier,
AuthorityInfoAccessSyntax, CRLDistributionPoint
FROM PKIX1Implicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(19) }
ContentInfo
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) }
ContentInfo
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) }
;
;
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 }
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 }
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 }
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 }
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 }
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 }
-- { id-aca 5 } is reserved
--{id aca 5}已保留
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 }
id-at-role OBJECT IDENTIFIER ::= { id-at 72}
id-at-role OBJECT IDENTIFIER ::= { id-at 72}
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
id-at-clearance OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) }
-- Uncomment the following declaration and comment the above line if
-- using the id-at-clearance attribute as defined in [RFC3281]
-- Uncomment the following declaration and comment the above line if
-- using the id-at-clearance attribute as defined in [RFC3281]
-- id-at-clearance OBJECT IDENTIFIER ::= {
-- joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
-- clearance (55) }
-- id-at-clearance OBJECT IDENTIFIER ::= {
-- joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
-- clearance (55) }
-- Uncomment this if using a 1988 level ASN.1 compiler
--如果使用1988级ASN.1编译器，请取消对此的注释
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING
}
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion, -- version is v2
holder Holder,
issuer AttCertIssuer,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
AttributeCertificateInfo ::= SEQUENCE {
version AttCertVersion, -- version is v2
holder Holder,
issuer AttCertIssuer,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attrCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
AttCertVersion ::= INTEGER { v2(1) }
AttCertVersion ::= INTEGER { v2(1) }
Holder ::= SEQUENCE {
baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of
-- the holder's Public Key Certificate
entityName [1] GeneralNames OPTIONAL,
-- the name of the claimant or role
objectDigestInfo [2] ObjectDigestInfo OPTIONAL
-- used to directly authenticate the
-- holder, for example, an executable
}
Holder ::= SEQUENCE {
baseCertificateID [0] IssuerSerial OPTIONAL,
-- the issuer and serial number of
-- the holder's Public Key Certificate
entityName [1] GeneralNames OPTIONAL,
-- the name of the claimant or role
objectDigestInfo [2] ObjectDigestInfo OPTIONAL
-- used to directly authenticate the
-- holder, for example, an executable
}
ObjectDigestInfo ::= SEQUENCE {
digestedObjectType ENUMERATED {
publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
-- otherObjectTypes MUST NOT
-- MUST NOT be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING
}
ObjectDigestInfo ::= SEQUENCE {
digestedObjectType ENUMERATED {
publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
-- otherObjectTypes MUST NOT
-- MUST NOT be used in this profile
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING
}
AttCertIssuer ::= CHOICE {
v1Form GeneralNames, -- MUST NOT be used in this
-- profile
v2Form [0] V2Form -- v2 only
}
AttCertIssuer ::= CHOICE {
v1Form GeneralNames, -- MUST NOT be used in this
-- profile
v2Form [0] V2Form -- v2 only
}
V2Form ::= SEQUENCE {
issuerName GeneralNames OPTIONAL,
baseCertificateID [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL
-- issuerName MUST be present in this profile
-- baseCertificateID and objectDigestInfo MUST
-- NOT be present in this profile
}
V2Form ::= SEQUENCE {
issuerName GeneralNames OPTIONAL,
baseCertificateID [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL
-- issuerName MUST be present in this profile
-- baseCertificateID and objectDigestInfo MUST
-- NOT be present in this profile
}
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL
}
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL
}
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime
}
AttCertValidityPeriod ::= SEQUENCE {
notBeforeTime GeneralizedTime,
notAfterTime GeneralizedTime
}
Targets ::= SEQUENCE OF Target
Targets ::= SEQUENCE OF Target
Target ::= CHOICE {
targetName [0] GeneralName,
targetGroup [1] GeneralName,
targetCert [2] TargetCert
}
Target ::= CHOICE {
targetName [0] GeneralName,
targetGroup [1] GeneralName,
targetCert [2] TargetCert
}
TargetCert ::= SEQUENCE {
targetCertificate IssuerSerial,
targetName GeneralName OPTIONAL,
certDigestInfo ObjectDigestInfo OPTIONAL
}
TargetCert ::= SEQUENCE {
targetCertificate IssuerSerial,
targetName GeneralName OPTIONAL,
certDigestInfo ObjectDigestInfo OPTIONAL
}
IetfAttrSyntax ::= SEQUENCE {
policyAuthority [0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE {
octets OCTET STRING,
oid OBJECT IDENTIFIER,
string UTF8String
}
}
IetfAttrSyntax ::= SEQUENCE {
policyAuthority [0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE {
octets OCTET STRING,
oid OBJECT IDENTIFIER,
string UTF8String
}
}
SvceAuthInfo ::= SEQUENCE {
service GeneralName,
ident GeneralName,
authInfo OCTET STRING OPTIONAL
}
SvceAuthInfo ::= SEQUENCE {
service GeneralName,
ident GeneralName,
authInfo OCTET STRING OPTIONAL
}
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
RoleSyntax ::= SEQUENCE {
roleAuthority [0] GeneralNames OPTIONAL,
roleName [1] GeneralName
}
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
-- Uncomment the following lines to support deprecated clearance
-- syntax and comment out previous Clearance.
-- Uncomment the following lines to support deprecated clearance
-- syntax and comment out previous Clearance.
-- Clearance ::= SEQUENCE {
-- policyId [0] OBJECT IDENTIFIER,
-- classList [1] ClassList DEFAULT {unclassified},
-- securityCategories [2] SET OF SecurityCategory OPTIONAL
-- }
-- Clearance ::= SEQUENCE {
-- policyId [0] OBJECT IDENTIFIER,
-- classList [1] ClassList DEFAULT {unclassified},
-- securityCategories [2] SET OF SecurityCategory 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)
}
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] EXPLICIT ANY DEFINED BY type
}
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] EXPLICIT ANY DEFINED BY type
}
-- Note that in [RFC3281] the syntax for SecurityCategory was
-- as follows:
--
-- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT OBJECT IDENTIFIER,
-- value [1] ANY DEFINED BY type
-- }
--
-- The removal of the IMPLICIT from the type line and the
-- addition of the EXPLICIT to the value line result in
-- no changes to the encoding.
-- Note that in [RFC3281] the syntax for SecurityCategory was
-- as follows:
--
-- SecurityCategory ::= SEQUENCE {
-- type [0] IMPLICIT OBJECT IDENTIFIER,
-- value [1] ANY DEFINED BY type
-- }
--
-- The removal of the IMPLICIT from the type line and the
-- addition of the EXPLICIT to the value line result in
-- no changes to the encoding.
AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE
}
AAControls ::= SEQUENCE {
pathLenConstraint INTEGER (0..MAX) OPTIONAL,
permittedAttrs [0] AttrSpec OPTIONAL,
excludedAttrs [1] AttrSpec OPTIONAL,
permitUnSpecified BOOLEAN DEFAULT TRUE
}
AttrSpec ::= SEQUENCE OF OBJECT IDENTIFIER
AttrSpec ::= SEQUENCE OF OBJECT IDENTIFIER
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
ProxyInfo ::= SEQUENCE OF Targets
ProxyInfo ::= SEQUENCE OF Targets
END
终止
The following is the errata report submitted against RFC 3281, posted online as [Err302].
以下是根据RFC 3281提交的勘误表报告，在线发布为[Err302]。
Status: Verified
状态：已验证
Type: Technical
类型：技术
Reported By: Stephen Farrell
报道人：斯蒂芬·法雷尔
Date Reported: 2003-03-07
报告日期：2003-03-07
Section 4.4.6 says:
第4.4.6节规定：
Clearance ::= SEQUENCE {
policyId [0] OBJECT IDENTIFIER,
classList [1] ClassList DEFAULT {unclassified},
securityCategories [2] SET OF SecurityCategory OPTIONAL
}
Clearance ::= SEQUENCE {
policyId [0] OBJECT IDENTIFIER,
classList [1] ClassList DEFAULT {unclassified},
securityCategories [2] SET OF SecurityCategory OPTIONAL
}
It should say:
它应该说：
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
Clearance ::= SEQUENCE {
policyId OBJECT IDENTIFIER,
classList ClassList DEFAULT {unclassified},
securityCategories SET OF SecurityCategory OPTIONAL
}
Notes:
笔记：
The differences in tagging arose due to an unnoticed technical corrigendum (TC-2) being applied to the X.501 document during preparation of RFC 3281. The X.501 format is the correct form and will be included in a future update of RFC 3281. Implementers SHOULD modify their decoding functions to accept either format and, even if claiming RFC 3281 conformance, SHOULD output the (correct) X.501 format pending the issuing of a corrected RFC at which point the incorrect RFC 3281 format will no longer be specified.
由于在RFC 3281编制过程中对X.501文件应用了未被注意的技术勘误表（TC-2），因此产生了标签差异。X.501格式是正确的格式，将包含在RFC 3281的未来更新中。实施者应修改其解码功能以接受任何一种格式，并且，即使声称RFC 3281符合性，也应在发出纠正的RFC之前输出（正确的）X.501格式，此时将不再指定错误的RFC 3281格式。
1. Created a new Section 1.1 "Terminology", renumbered Sections 1.1-1.3 to 1.2-1.4, and moved first paragraph of Section 1 to Section 1.1.
1. 创建新的第1.1节“术语”，将第1.1-1.3节重新编号为1.2-1.4节，并将第1节第一段移至第1.1节。
2. In Section 1.2, rephrased first sentence in third paragraph.
2. 在第1.2节中，将第三段中的第一句话改写。
3. In Section 2, replaced S/MIME v3 with S/MIME v3.2.
3. 在第2节中，将S/MIME v3替换为S/MIME v3.2。
4. In Section 4.1, moved "," from the right of the ASN.1 comment to the left of the ASN.1 comment on the line describing version in the AttributeCertificateInfo structure. Replaced reference to X.208 with X.690.
4. 在第4.1节中，在描述AttributeCertificateInfo结构中版本的行中，将“，”从ASN.1注释的右侧移至ASN.1注释的左侧。将对X.208的参考替换为X.690。
5. In Section 4.2, replaced pointer to 4.2.1.7 of RFC 3280 with pointer to 4.2.1.6 of RFC 5280. Added requirement to support subject alternative name choice SRVName.
5. 在第4.2节中，将指向RFC 3280的4.2.1.7的指针替换为指向RFC 5280的4.2.1.6的指针。增加了支持主题备选名称选择SRVName的要求。
6. In Section 4.3.2, replaced "Confirming" with "Conforming".
6. 在第4.3.2节中，将“确认”替换为“符合”。
7. In Section 4.3.4, replaced reference to RFC 1738, URL, with references to [HTTP-URL], "authorityInformationAccess" with "authorityInfoAccess", and "NOT REQUIRED" with "OPTIONAL."
7. 在第4.3.4节中，将对RFC 1738，URL的引用替换为[HTTP-URL]，“authorityInformationAccess”替换为“authorityInfoAccess”，“NOT REQUIRED”替换为“OPTIONAL”
8. In Section 4.3.5, replaced "HTTP or an LDAP" with "HTTP [HTTP-URL] or an LDAP [LDAP-URL]". Also, replaced "CRLDistPointsSyntax" with "CRLDistributionPoints".
8. 在第4.3.5节中，将“HTTP或LDAP”替换为“HTTP[HTTP-URL]或LDAP[LDAP-URL]”。此外，将“CRLDistPointsSyntax”替换为“CRLDistributionPoints”。
9. In Section 4.4.6, added text to address having two OIDs for the same syntax and two syntaxes for one OID.
9. 在第4.4.6节中，为地址添加了文本，其中两个OID用于相同的语法，两个语法用于一个OID。
10. In Section 5, replaced "When the extension value SHOULD cause" with "When the extension value causes".
10. 在第5节中，将“当扩展值引起”替换为“当扩展值引起”。
11. In Section 7.1, replaced text that described encapsulating encrypted attribute with corrected text. Clarified that attributes can appear more than once if they apply to different recipients. Reworded last paragraph to more clearly describe the failure case.
11. 在第7.1节中，将描述封装加密属性的文本替换为更正文本。阐明了如果属性应用于不同的收件人，则它们可能会出现多次。改写了最后一段，以更清楚地描述故障案例。
12. In Section 7.3, updated references to point to RFC 3279.
12. 在第7.3节中，更新了参考文献，指向RFC 3279。
13. In Section 8, updated last paragraph to better explain why implementers need to be careful when mapping authenticated identities to the AC holder.
13. 在第8节中，更新了最后一段，以更好地解释为什么实现者在将经过身份验证的身份映射到AC持有者时需要小心。
14. Updated References: a) split references into informative/normative references b) added reference to RFC 3281 c) replaced reference to X.501:1993 with X.501:1997 d) replaced reference to RFC 1510 with RFC 4120 e) replaced reference to RFC 1738 with RFC 4516 and 2585 f) replaced reference to RFC 2251 with RFC 4511 g) replaced reference to RFC 2459 with RFC 5280 h) replaced reference to RFC 2630 with RFC 5652 i) replaced reference to X.208-1988 with X.690 j) added reference to X.680 k) added reference to RFC 4985 l) expanded reference to RFC 3279 by adding RFC 5480 and RFC 4055, which update RFC 3279 m) deleted spurious reference to CMC, CMP, ESS, RFC 2026, X.209-88, and X.501:1988.
14. 更新的参考文献：a）将参考文献拆分为信息性/规范性参考文献b）添加对RFC 3281的参考文献c）将对X.501:1993的参考文献替换为X.501:1997 d）将对RFC 1510的参考文献替换为RFC 4120 e）将对RFC 1738的参考文献替换为RFC 4516和2585 f）将对RFC 2251的参考文献替换为RFC 4511 g）将对RFC 2459的参考文献替换为使用RFC 5280 h）将RFC 2630的参考替换为RFC 5652 i）将X.208-1988的参考替换为X.690 j）将X.680 k的参考添加到RFC 4985 l）将RFC 3279的参考添加到RFC 5480和RFC 4055中，从而将RFC 3279 m更新）删除CMC、CMP、ESS、RFC 2026、X.209-88和X.501:1988的虚假参考。
15. In Appendix A, added second clearance attribute object identifier.
15. 在附录A中，添加了第二个间隙属性对象标识符。
16. Appendix B, updated ASN.1 with changes 3, 8, 9, and 11: a) New OID for ASN.1 module. b) Updated module OIDs for PKIX1Explicit88 and PKIX1Implicit88. c) Added imports from PKIX1Implicit88 for AuthorityKeyIdentifier, AuthorityInfoAccessSyntax, CRLDistributionPoint. d) Added imports from CryptographicMessageSyntax2004 for ContentInfo. e) Added comments and commented out ASN.1 for old clearance attribute syntax. f) Added preamble to ASN.1, which is taken from Appendix A of RFC 5280.
16. 附录B，更新了ASN.1，修改了3、8、9和11：a）ASN.1模块的新OID。b） 已更新PKIx1显式88和PKIx1隐式88的模块OID。c） 添加了从PKIX1Implicit88导入的AuthorityKeyIdentifier、AuthorityInfoAccessSyntax、CRLDistributionPoint。d） 为ContentInfo添加了从CryptographicMessageSyntax2004导入的内容。e） 为旧的清除属性语法添加注释并注释掉ASN.1。f） 增加了ASN.1的序言，该序言摘自RFC 5280附录A。
17. Added Appendix C.
17. 增加附录C。
Authors' Addresses
作者地址
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA EMail: turners@ieca.com
Sean Turner IECA，Inc.美国弗吉尼亚州费尔法克斯市努特利街3057号106室邮编：22031电子邮件：turners@ieca.com
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
Russ Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州20170美国电子邮件：housley@vigilsec.com
Stephen Farrell Distributed Systems Group Computer Science Department Trinity College Dublin Ireland EMail: stephen.farrell@cs.tcd.ie
斯蒂芬·法雷尔分布式系统集团计算机科学系都柏林三一学院爱尔兰电子邮件：斯蒂芬。farrell@cs.tcd.ie