Network Working Group S. Park
Request for Comments: 5636 H. Park
Category: Experimental Y. Won
J. Lee
KISA
S. Kent
BBN Technologies
August 2009
Network Working Group S. Park
Request for Comments: 5636 H. Park
Category: Experimental Y. Won
J. Lee
KISA
S. Kent
BBN Technologies
August 2009
Traceable Anonymous Certificate
可追踪匿名证书
Abstract
摘要
This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272). The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer). The end entity (EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs).
本文档定义了一种实用的体系结构和协议，用于为请求并使用包含假名的X.509证书的用户提供隐私，同时仍保留将此类证书映射到请求该证书的真实用户的能力。该体系结构与IETF证书请求格式兼容，如PKCS10（RFC 2986）和CMC（RFC 5272）。该体系结构将颁发证书所涉及的机构分开：一个用于验证私钥的所有权（盲颁发者），另一个用于验证证书的内容（匿名颁发者）。在此模型下颁发的终端实体（EE）证书称为可跟踪匿名证书（TAC）。
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. General Overview ................................................4
3. Requirements ....................................................5
4. Traceable Anonymous Certificate Model ...........................6
5. Issuing a TAC ...................................................7
5.1. Steps in Issuing a TAC .....................................8
5.2. Mapping a TAC to a User's Real Identity ...................15
5.3. TAC Request Message Format Profile ........................17
5.3.1. PKCS10 Profile .....................................17
5.3.2. CMC Profile ........................................18
6. Security Considerations ........................................19
7. Acknowledgments ................................................21
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................22
Appendix A. Traceable Anonymous Certificate ASN.1 Modules .........24
Appendix B. TAC Message Exchanges over Transport Layer Security ...26
B.1. Message Exchanges between a User and the BI or the AI .....26
B.2. Message Exchanges between the BI and the AI ...............27
B.3. Message Exchanges between the Aggrieved Party and the AI
or the BI .................................................27
Appendix C. Cryptographic Message Syntax Profile for TAC Token ....28
C.1. Signed-Data Content Type ..................................28
C.1.1. encapContentInfo ...................................29
C.1.2. signerInfos ........................................29
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. General Overview ................................................4
3. Requirements ....................................................5
4. Traceable Anonymous Certificate Model ...........................6
5. Issuing a TAC ...................................................7
5.1. Steps in Issuing a TAC .....................................8
5.2. Mapping a TAC to a User's Real Identity ...................15
5.3. TAC Request Message Format Profile ........................17
5.3.1. PKCS10 Profile .....................................17
5.3.2. CMC Profile ........................................18
6. Security Considerations ........................................19
7. Acknowledgments ................................................21
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................22
Appendix A. Traceable Anonymous Certificate ASN.1 Modules .........24
Appendix B. TAC Message Exchanges over Transport Layer Security ...26
B.1. Message Exchanges between a User and the BI or the AI .....26
B.2. Message Exchanges between the BI and the AI ...............27
B.3. Message Exchanges between the Aggrieved Party and the AI
or the BI .................................................27
Appendix C. Cryptographic Message Syntax Profile for TAC Token ....28
C.1. Signed-Data Content Type ..................................28
C.1.1. encapContentInfo ...................................29
C.1.2. signerInfos ........................................29
Public Key Infrastructure (PKI) provides a powerful means of authenticating individuals, organizations, and computers (e.g., web servers). However, when individuals use certificates to access resources on the public Internet, there are legitimate concerns about personal privacy, and thus there are increasing demands for privacy-enhancing techniques on the Internet.
公钥基础设施（PKI）提供了对个人、组织和计算机（如web服务器）进行身份验证的强大手段。然而，当个人使用证书访问公共互联网上的资源时，对个人隐私的担忧是合理的，因此对互联网上的隐私增强技术的需求越来越大。
In a PKI, an authorized entity such as a Certification Authority (CA) or a Registration Authority (RA) may be perceived, from a privacy perspective, as a "big brother", even when a CA issues a certificate containing a Subject name that is a pseudonym. This is because such entities can always map a pseudonym in a certificate they issued to the name of the real user to whom it was issued. This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it.
在PKI中，从隐私角度来看，认证机构（CA）或注册机构（RA）等授权实体可能会被视为“老大哥”，即使CA颁发的证书包含的主体名称是假名。这是因为这些实体总是可以将他们颁发的证书中的笔名映射到颁发证书的真实用户的名称。本文档定义了一种实用的体系结构和协议，用于为请求并使用包含假名的X.509证书的用户提供隐私，同时仍保留将此类证书映射到请求该证书的真实用户的能力。
A PKI typically serves to identify the holder of a private key (to the corresponding public key in a certificate), in a standard fashion. The public key, identity, and related information are signed by an entity acting as a CA as specified in X.509 [11] and as profiled for use in the Internet [2]. During the past decade, PKIs have been widely deployed to support various types of communications and transactions over the Internet.
PKI通常用于以标准方式识别私钥（证书中对应的公钥）的持有者。公钥、标识和相关信息由X.509[11]中规定的CA实体签名，并在Internet中使用[2]。在过去十年中，公钥基础设施被广泛部署，以支持互联网上的各种通信和交易。
However, with regard to privacy on the Internet, a PKI is generally not supportive of privacy, at least in part because of the following issues:
然而，关于互联网上的隐私，PKI通常不支持隐私，至少部分原因是以下问题：
- A certificate typically contains in the Subject field the true identity of the user to whom it was issued. This identity is disclosed to a relying party (e.g., a web site or the recipient of an S/MIME message [18]) whenever the certificate holder presents it in a security protocol that requires a user to present a certificate. In some protocols, e.g., TLS, a user's certificate is sent via an unencrypted channel prior to establishing a secure communication capability.
- 证书的主题字段中通常包含证书颁发给的用户的真实身份。每当证书持有人在要求用户出示证书的安全协议中出示该身份时，就会向依赖方（例如，网站或S/MIME消息的接收者[18]）披露该身份。在一些协议中，例如TLS，在建立安全通信能力之前，通过未加密的信道发送用户的证书。
- A certificate often is published by the CA, for example, in a directory system that may be widely accessible.
- 证书通常由CA发布，例如，在可广泛访问的目录系统中。
- An anonymous (end entity) certificate [9] is one that indicates that the holder's true identity is not represented in the subject field. (Such a certificate might more accurately be called "pseudonymous" since an X.509 certificate must contain an identifier to comply with PKI format standards, and a CA must not issue multiple certificates with the same Subject name to different entities. However, we use the more common term "anonymous" throughout this document to refer to such certificates.) Issuance of anonymous certificates could enhance user privacy.
- 匿名（最终实体）证书[9]表示持有人的真实身份未在“主题”字段中表示。（这种证书可以更准确地称为“假名”，因为X.509证书必须包含符合PKI格式标准的标识符，CA不得向不同实体颁发具有相同主题名称的多个证书。但是，我们使用更常见的术语“匿名”发布匿名证书可以增强用户隐私。
There is however, a need to balance privacy and accountability when issuing anonymous certificates. If a CA/RA is unable to map an anonymous certificate to the real user to whom it was issued, the user might abuse the anonymity afforded by the certificate because there would be no recourse for relying parties.
然而，在颁发匿名证书时，需要平衡隐私和责任。如果CA/RA无法将匿名证书映射到向其颁发证书的真实用户，用户可能会滥用证书提供的匿名性，因为依赖方将没有追索权。
A CA or RA generally would be able to map an anonymous certificate to the user to whom it was issued, to avoid such problems. To do so, the CA/RA would initially identify the user and maintain a database that relates the user's true identity to the pseudonym carried in the certificate's Subject field.
CA或RA通常能够将匿名证书映射到向其颁发证书的用户，以避免此类问题。为此，CA/RA将首先识别用户并维护一个数据库，该数据库将用户的真实身份与证书的主题字段中携带的笔名联系起来。
In a traditional PKI, there is a nominal separation of functions between a RA and a CA, but in practice these roles are often closely coordinated. Thus, either the RA or CA could, in principle, unilaterally map an autonomous certificate to the real user identity.
在传统的PKI中，RA和CA之间存在名义上的功能分离，但在实践中，这些角色通常是密切协调的。因此，原则上，RA或CA都可以单方面将自主证书映射到真实用户身份。
The architecture, syntax, and protocol conventions described in this document allow anonymous certificates to be issued and used in existing PKIs in a way that provides a balance between privacy and a conditional ability to map an anonymous certificate to the individual to whom it was issued.
本文档中描述的体系结构、语法和协议约定允许在现有PKI中发布和使用匿名证书，其方式在隐私和有条件地将匿名证书映射到向其颁发证书的个人之间提供了平衡。
An anonymous certificate (Traceable Anonymous Certificate) in this document is issued by a pair of entities that operate in a split responsibility mode: a Blind Issuer (BI) and an Anonymity Issuer (AI). The conditional traceability offered by this model assumes strong separation between the RA and CA roles, and employs technical means (threshold cryptography and "blinded" signatures), to facilitate that separation. (A blinded signature is one in which the value being signed is not made visible to the signer, via cryptographic means. Additional details are provided later.)
本文档中的匿名证书（可追踪匿名证书）由一对以分离责任模式运行的实体颁发：盲颁发者（BI）和匿名颁发者（AI）。该模型提供的条件可追溯性假设RA和CA角色之间存在很强的分离，并采用技术手段（阈值加密和“盲”签名）来促进这种分离。（盲签名是指通过加密手段使签名者看不到被签名的值的签名。其他详细信息将在后面提供。）
The AI has knowledge of the certificate issued to the user, but no knowledge of the user's real identity. The BI knows the user's real identity, but has no knowledge of the certificate issued to that user. Only if the AI and BI collaborate can they map the TAC issued to a user to the real identity of that user.
AI知道颁发给用户的证书，但不知道用户的真实身份。BI知道用户的真实身份，但不知道向该用户颁发的证书。只有AI和BI合作，他们才能将发给用户的TAC映射到该用户的真实身份。
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 RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
This section defines the notion of a Traceable Anonymous Certificate (referred to as TAC or anonymous certificate in this document). It is distinguished from a conventional pseudonymous certificate [8, 9] in that a TAC containing a pseudonym in the Subject field will be conditionally traceable (as defined that it is not trivial to design a system that issues anonymous certificates, consistent with Internet PKI standards, when additional constraints are imposed, as illustrated by the following scenarios.
本节定义了可追踪匿名证书（在本文档中称为TAC或匿名证书）的概念。它与传统的笔名证书[8,9]的区别在于，在主题字段中包含笔名的TAC将有条件地可追踪（如定义所示，当施加额外的限制时，设计一个与互联网PKI标准一致的匿名证书颁发系统并非易事，如以下场景所示。
- If a CA issues an anonymous certificate without verifying a true identity, it is untraceable, which provides inadequate recourse if the user to whom the certificate was issued abuses the anonymity it provides. (Even without the ability to trace an anonymous
- 如果CA在未验证真实身份的情况下发布匿名证书，则无法对其进行跟踪，如果向其颁发证书的用户滥用其提供的匿名性，则无法提供足够的追索权。（即使没有追踪匿名者的能力
certificate to the corresponding user, the certificate can always be revoked, but this may not be a sufficient response to abuse.)
将证书颁发给相应的用户时，可以随时吊销证书，但这可能不是对滥用的充分响应。）
- If a CA issues an anonymous certificate but verifies the real identity and maintains a record of that identity, the CA can link the pseudonym in the Subject field to the real identity, hence a potential "big brother" problem [12].
- 如果CA颁发匿名证书，但验证真实身份并保留该身份的记录，则CA可以将主题字段中的笔名链接到真实身份，因此可能存在“老大哥”问题[12]。
- If the CA issues a certificate with a certificate containing a user-selected Subject name, and does not verify the user's identity, the certificate is effectively untraceable.
- 如果CA颁发的证书包含用户选择的使用者名称，并且未验证用户的身份，则该证书实际上是不可跟踪的。
- If the CA issues an anonymous certificate using a blind signature (see below), the CA cannot verify the contents of the certificate, making the certificate untraceable and essentially forgeable. (If a CA signs a certificate without examining its content, even after verifying a user's identity, certificates issued by the CA are essentially forgeable.)
- 如果CA使用盲签名（见下文）颁发匿名证书，CA将无法验证证书的内容，从而使证书不可追踪且基本上可伪造。（如果CA在未检查其内容的情况下签署证书，即使在验证用户身份后，CA颁发的证书基本上也是可伪造的。）
To address the issues described above, we extend the simple separation-of-authority concept already defined in the RA/CA PKI model. First we restate the requirements in a more precise and concise fashion, and introduce a basic model for achieving the goals from a more general perspective [16].
为了解决上述问题，我们扩展了RA/CA PKI模型中已经定义的简单的权限分离概念。首先，我们以更精确和简洁的方式重申需求，并从更一般的角度介绍实现目标的基本模型[16]。
This document describes a new separation-of-authority model and protocols for certificate issuance in a way that enables issuing Traceable Anonymous Certificates, while maintaining compatibility with the standards used in existing PKIs. To do this, the following requirements must be satisfied.
本文档描述了一种新的证书颁发权限分离模型和协议，该模型和协议允许颁发可跟踪的匿名证书，同时保持与现有PKI中使用的标准的兼容性。为此，必须满足以下要求。
- The Traceable Anonymous Certificate MUST be a syntactically valid X.509 certificate in which the Subject field contains a pseudonym.
- 可跟踪匿名证书必须是语法有效的X.509证书，其中“主题”字段包含假名。
- There must be technical means to counter a claim by a malicious user who later denies having participated in the activities that resulted in issuing a TAC. Specifically, when a user is identified and requests issuance of a TAC, the mechanisms employed MUST ensure that the user to whom the TAC is issued is the one who requested the TAC (unless that user transfers the private key to another party, unknown to the RA/CA).
- 必须有技术手段来反击恶意用户的索赔，该用户后来否认参与了导致发布TAC的活动。具体而言，当识别用户并请求颁发TAC时，所采用的机制必须确保向其颁发TAC的用户是请求TAC的用户（除非该用户将私钥转移给RA/CA未知的另一方）。
- The traceability and revocation functions MUST support the linkage between a user's true identity and the pseudonym in a certificate issued to the user. Thus, the solution MUST enable determining a true identity from the anonymous certificate, upon agreement among the authorities who collaborated to issue the certificate.
- 可追溯性和撤销功能必须支持用户的真实身份与颁发给用户的证书中的假名之间的链接。因此，解决方案必须能够在合作颁发证书的机构之间达成协议后，从匿名证书中确定真实身份。
A TAC is an end entity (EE) certificate issued by a pair of entities that operate in a split responsibility mode: a Blind Issuer (BI) and an Anonymity Issuer (AI). The pair appear as a single CA to the outside world, e.g., they are represented by a single CA certificate. The public key in the CA certificate is used to verify certificates issued by this CA in the normal fashion, i.e., a relying party processes a TAC just like any other EE certificates.
TAC是一种终端实体（EE）证书，由一对以分离责任模式运行的实体颁发：盲颁发者（BI）和匿名颁发者（AI）。对外部世界而言，这对证书是作为单个CA显示的，例如，它们由单个CA证书表示。CA证书中的公钥用于以正常方式验证此CA颁发的证书，即依赖方与任何其他EE证书一样处理TAC。
In this model, the BI acts as a RA. It interacts with a user to verify the user's "real" identity, just like a normal RA. The BI maintains a database that can be used to map a TAC to the user to whom it was issued, but only with the cooperation of the AI.
在此模型中，BI充当RA。它与用户交互以验证用户的“真实”身份，就像普通RA一样。BI维护一个数据库，该数据库可用于将TAC映射到向其发出TAC的用户，但必须得到AI的合作。
This mapping will be initiated only if there is evidence that the user to whom the TAC was issued has abused the anonymity provided by the TAC.
只有当有证据表明TAC所针对的用户滥用了TAC提供的匿名性时，才会启动此映射。
The AI acts as a CA. It validates a certificate request submitted by the user, using a standard certificate request format such as PKCS10. The AI performs the functions common to a CA, including a private-key proof-of-possession (PoP) check, a name uniqueness check among all certificates issued by it, assignment of a serial number, etc. To effect issuance of the TAC, the AI interacts with the BI, over a secure channel, to jointly create the signature on the TAC, and sends the signed TAC to the user.
AI充当CA。它使用标准证书请求格式（如PKCS10）验证用户提交的证书请求。AI执行CA共有的功能，包括私钥占有证明（PoP）检查、其颁发的所有证书中的名称唯一性检查、序列号分配等。为了实现TAC的颁发，AI通过安全通道与BI交互，共同在TAC上创建签名，并将签名的TAC发送给用户。
The AI does this without learning the user's real identity (either from the user or from the BI).
AI在不了解用户真实身份（无论是从用户还是从BI）的情况下执行此操作。
The result of this split functionality between the BI and the AI is that neither can unilaterally act to reveal the real user identity. The AI has knowledge of the certificate issued to the user, but no knowledge of the user's real identity. The BI knows the user's real identity, but has no knowledge of the certificate issued to that user. Only if the AI and BI collaborate can they map the TAC issued to a user to the real identity of that user.
BI和AI之间这种分离功能的结果是，两者都不能单方面行动来揭示真实的用户身份。AI知道颁发给用户的证书，但不知道用户的真实身份。BI知道用户的真实身份，但不知道向该用户颁发的证书。只有AI和BI合作，他们才能将发给用户的TAC映射到该用户的真实身份。
This system is not perfect. For example, it assumes that the AI and BI collaborate to reveal a user's real identity only under appropriate circumstances. The details of the procedural security
这一制度并不完善。例如，它假设AI和BI只有在适当的情况下才能合作揭示用户的真实身份。程序性担保的细节
means by which this assurance is achieved are outside the scope of this document. Nonetheless, there are security benefits to adopting this model described in this document, based on the technical approach used to enable separation of the BI and AI functions.
实现该保证的方式不在本文件范围内。尽管如此，基于用于分离BI和AI功能的技术方法，采用本文档中描述的模型具有安全优势。
For example, the BI and AI can be operated by different organizations in geographically separate facilities, and managed by different staff. As a result, one can have higher confidence in the anonymity offered to a user by the system, as opposed to a monolithic CA operating model that relies only on procedural security controls to ensure anonymity.
例如，BI和AI可以由不同的组织在地理位置不同的设施中操作，并由不同的员工管理。因此，人们可以对系统提供给用户的匿名性有更高的信心，而不是只依赖程序安全控制来确保匿名性的单一CA操作模型。
The follow subsections describe the procedures and the protocols employed to issue a TAC. To begin, BI and AI collaborate to generate a public key pair (that represents the CA as seen by relying parties) using a threshold signature scheme. Such schemes have been defined for RSA. The details of how this is accomplished depend on the algorithm in question, and thus are not described here. The reader is referred to [15] where procedures for implementing RSA threshold signatures are described. A DSA-based threshold signature scheme will be incorporated into a future version of TAC [14].
以下小节描述了发布TAC所采用的程序和协议。首先，BI和AI协作使用门限签名方案生成公钥对（表示依赖方看到的CA）。这类方案是为RSA定义的。如何实现这一点的细节取决于所讨论的算法，因此这里不进行描述。读者可参考[15]，其中描述了实现RSA门限签名的过程。基于DSA的门限签名方案将被纳入未来版本的TAC[14]。
Note that this split signing model for certificate issuance is an especially simple case of a threshold signature; the private key used to sign a TAC is divided into exactly two shares, one held by the BI and one held by the AI. Both shares must be used, serially, to create a signature on a TAC. After the key pair for the (nominal) CA has been generated and the private key split between the BI and the AI, the public key is published, e.g., in a self-signed certificate that represents the TAC CA.
请注意，用于证书颁发的拆分签名模型是阈值签名的一个特别简单的情况；用于签署TAC的私钥分为两部分，一部分由BI持有，另一部分由AI持有。必须连续使用这两个共享来在TAC上创建签名。生成（标称）CA的密钥对并在BI和AI之间分割私钥之后，公开密钥被发布，例如，在表示TAC CA的自签名证书中。
Another public-key cryptographic function that is an essential part of this system is called "blind signing". To create a blind signature, one party encrypts a value to be signed, e.g., a hash value of a certificate, and passes it to the signer. The signer digitally signs the encrypted value, and returns it to the first party. The first party inverts the encryption it applied with the random value in the first place, to yield a signature on the underlying data, e.g., a hash value.
另一个公钥加密功能是该系统的重要组成部分，称为“盲签名”。为了创建盲签名，一方加密要签名的值，例如证书的哈希值，并将其传递给签名者。签名者对加密值进行数字签名，并将其返回给第一方。第一方首先使用随机值反转其应用的加密，以在基础数据上生成签名，例如哈希值。
This technique enables the signer to digitally sign a message, without seeing the content of the message. This is the simplest approach to blind signing; it requires that the public key needed to invert the encryption not be available to the blind signer. Other blind signing techniques avoid the need for this restriction, but are more complex.
此技术使签名者能够对消息进行数字签名，而不必查看消息的内容。这是盲签名最简单的方法；它要求盲签名者不能使用反转加密所需的公钥。其他盲签名技术避免了这种限制，但更为复杂。
The tricky part of a cryptographic blinding function is that is must be associative and commutative, with regard to a public-key signature function. Let B be a blinding function, B-INV is its inverse, and S is a public-key signature. The following relationship must hold: B-INV( S (B (X) ) ) = B-INV( B( S (X) ) ) = S (X). RSA can be used to blind a value with random value and to sign a blinded value because the modular exponentiation operation used by RSA for both signature and for encryption is associative and commutative.
加密盲函数的棘手部分是，就公钥签名函数而言，它必须是关联的和可交换的。设B为盲函数，B-INV为其逆函数，S为公钥签名。以下关系必须保持：B-INV（S（B（X））=B-INV（B（S（X））=S（X）。RSA可用于对具有随机值的值进行盲运算，并对盲值进行签名，因为RSA用于签名和加密的模幂运算是关联的和可交换的。
The TAC issuance process described below requires an ability for the BI, the AI, and the user to employ secure communication channels between one another.
下面描述的TAC发布过程要求BI、AI和用户能够在彼此之间使用安全通信信道。
Use of TLS [17] is one suitable means to establish such channels, although other options also are acceptable. To this end, this document assumes TLS as the default secure communication channel, and thus requires that the BI and the AI have X.509 certificates that represent them.
使用TLS[17]是建立此类通道的一种合适方法，尽管也可以接受其他选项。为此，本文档假设TLS是默认的安全通信通道，因此要求BI和AI具有代表它们的X.509证书。
These certificates are independent of the certificate that represents the CA (formed by the BI and the AI) and may be either self-signed or issued by other CA(s).
这些证书独立于代表CA的证书（由BI和AI组成），可以是自签名的，也可以是由其他CA颁发的。
Appendix B provides a top-level description of the application of TLS to these message exchanges.
附录B提供了TLS应用于这些消息交换的顶层描述。
Figure 1 depicts the procedures for issuing a TAC. The lines represent steps in the issuance process, and the numbers refer to these steps.
图1描述了发布TAC的过程。行表示发行流程中的步骤，数字表示这些步骤。
1 +---------------+
+<-------->| Blind |
| 2 | Issuer (BI)|
| +---------------+
+-------+ | ^
| user |<------------>| 4 | 5
+-------+ | v
| 3 +----------------+
+--------->| |
| | Anonymity |
| | Issuer (AI) |
+<-------- | |
6 +----------------+
1 +---------------+
+<-------->| Blind |
| 2 | Issuer (BI)|
| +---------------+
+-------+ | ^
| user |<------------>| 4 | 5
+-------+ | v
| 3 +----------------+
+--------->| |
| | Anonymity |
| | Issuer (AI) |
+<-------- | |
6 +----------------+
Figure 1. TAC Issuance Procedures
图1。交谘会发出程序
Step 1:
步骤1：
A user authenticates himself to the BI. This may be effected via an in-person meeting or electronically. The same sorts of procedures that RAs use for normal certificate issuance are used here. Such procedures are not standardized, and thus they are not described here in detail. For purposes of the TAC architecture, we require the BI to establish a record in a database for the user and to generate a (locally) unique identifier, called the UserKey, that will serve as a (database) key for the record. The UserKey value MUST NOT be generated in a fashion that permits any external entity (including the AI) to infer a user's real identity from its value. (For example, if the user's name is used as an input to a one-way hash algorithm to generate the UserKey value, then additional random data must be used as an input to prevent simple guessing attacks.) Associated with the UserKey in this database is an expiration time. The expiration time is used by the BI and AI to reject session-level replay attacks in some exchanges, and to enable the BI and AI to garbage-collect database records if a user initiates but does not complete the certificate request process.
用户向BI验证自己的身份。这可以通过亲自会议或电子方式实现。这里使用RAs用于正常证书颁发的相同类型的过程。此类程序未标准化，因此此处不详细描述。出于TAC体系结构的目的，我们要求BI在数据库中为用户建立一个记录，并生成一个（本地）唯一标识符，称为UserKey，该标识符将用作记录的（数据库）密钥。用户密钥值的生成方式不得允许任何外部实体（包括AI）从其值推断用户的真实身份。（例如，如果用户名用作单向散列算法的输入以生成UserKey值，则必须使用额外的随机数据作为输入以防止简单的猜测攻击。）与此数据库中的UserKey关联的是过期时间。BI和AI使用过期时间来拒绝某些交换中的会话级重播攻击，并在用户启动但未完成证书请求过程时使BI和AI能够垃圾收集数据库记录。
It is RECOMMENDED that the UserKey be a random or pseudo-random value. Whenever the BI passes a UserKey to an external party, or accepts the UserKey from an external party (e.g., the AI), the value is embedded in a digitally signed CMS object called a Token, accompanied by the timestamp noted above. The signature on a Token is generated by the BI. (Note that the certificate used is just a certificate suitable for use with CMS, and is NOT the split-key certificate used to verify TAC.)
建议用户密钥为随机或伪随机值。每当BI将用户密钥传递给外部方，或从外部方（例如AI）接受用户密钥时，该值就会嵌入到称为令牌的数字签名CMS对象中，并附带上述时间戳。令牌上的签名由BI生成。（请注意，所使用的证书只是适用于CMS的证书，而不是用于验证TAC的拆分密钥证书。）
The following ASN.1 syntax represents the UserKey and an expiration time:
以下ASN.1语法表示用户密钥和过期时间：
UserKey ::= OCTET STRING
Timeout ::= GeneralizedTime
UserKey ::= OCTET STRING
Timeout ::= GeneralizedTime
In the context of this specification, the GeneralizedTime value MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (YYYYMMDDHHMMSSZ).
在本规范的上下文中，GeneralizedTime值必须以格林威治标准时间（Zulu）表示，并且必须包括秒（YYYYMMDDHHMMSSZ）。
Step 2:
步骤2：
BI presents to the user a data structure called a Token. The Token must be conveyed to the user via a secure channel, e.g., in person or via a secure communication channel. The secure channel is required here to prevent a wiretapper from being able to
BI向用户呈现一种称为令牌的数据结构。令牌必须通过安全通道传送给用户，例如亲自传送或通过安全通信通道传送。此处需要安全通道，以防止窃听器
acquire the Token. For example, if the user establishes a one-way authenticated TLS session to the BI in Step 1, this session could be used to pass the Token back to the user.
获取令牌。例如，如果用户在步骤1中建立到BI的单向认证TLS会话，则该会话可用于将令牌传递回用户。
The Token serves two purposes. During TAC issuance, the Token is used to verify that a request to the AI has been submitted by a user who is registered with the BI (and thus there is a record in the BI's database with the real identity of the user). This is necessary to ensure that the TAC can later be traced to the user. If there is a request to reveal the real identity of a user, the AI will release the Token to the entity requesting that a TAC be traced, and that entity will pass the Token to the BI, to enable tracing the TAC. If the BI does not perform its part of the certificate issuance procedure (in Step 6) before the Token expires, the BI can delete the Token from the database as a means of garbage collection. The timeout value in a Token is selected by the BI.
代币有两个用途。在TAC发布期间，令牌用于验证已向BI注册的用户已向AI提交请求（因此BI的数据库中存在具有用户真实身份的记录）。这是必要的，以确保TAC稍后可以跟踪到用户。如果存在揭示用户真实身份的请求，AI将向请求跟踪TAC的实体释放令牌，该实体将向BI传递令牌，以启用跟踪TAC。如果BI在令牌过期之前没有执行其证书颁发过程的一部分（在步骤6中），BI可以从数据库中删除令牌作为垃圾收集的一种方式。令牌中的超时值由BI选择。
The Token is a ContentInfo with a contentType of id-kisa-tac-token and a content that holds a SignedData of CMS SignedData object [6], signed by the BI, where the eContent (EncapsulatedContentInfo) is a SEQUENCE consisting of the UserKey and Timeout, and eContentType MUST be id-data.
令牌是一个ContentInfo，其contentType id为kisa tac令牌，内容包含由BI签名的CMS SignedData对象[6]的SignedData，其中eContent（封装的ContentInfo）是一个由用户密钥和超时组成的序列，eContentType必须是id数据。
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- OBJECT IDENTIFIER : id-data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
-- DER encoded with the input of 'SEQUENCE of the UserKey and
-- Timeout'
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- OBJECT IDENTIFIER : id-data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
-- DER encoded with the input of 'SEQUENCE of the UserKey and
-- Timeout'
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
The signature (SignatureValue of SignerInfo) is generated using the BI's private signature key, corresponding to the public key present in the BI's certificate. (Note that this certificate is just a certificate suitable for use with TLS, and is NOT the split-key certificate used to verify a TAC.) The certificate (or certificates) MUST be present. Appendix A provides the ASN.1 syntax for the Token, as a profiled CMS ContentInfo object. Appendix C provides the CMS SignedData object profile for wrapping the Token.
签名（SignerInfo的SignatureValue）是使用BI的私有签名密钥生成的，与BI证书中的公钥相对应。（请注意，此证书只是适合与TLS一起使用的证书，而不是用于验证TAC的拆分密钥证书。）证书（或多个证书）必须存在。附录A提供了令牌的ASN.1语法，作为一个配置文件CMS ContentInfo对象。附录C提供了用于包装令牌的CMS SignedData对象配置文件。
Token ::= ContentInfo
Token ::= ContentInfo
Upon receipt of the Token, the user SHOULD verify the signature using the BI public key and note the Timeout value to ensure that the certificate request process is completed prior to that time.
收到令牌后，用户应使用BI公钥验证签名，并记录超时值，以确保证书请求过程在该时间之前完成。
Step 3:
步骤3：
The user prepares a certificate request in a standard format, e.g., PKCS10 [3] or CMC [4]. The Subject field of the certificate contains a pseudonym generated by the user. It is anticipated that the CA (BI + AI) may provide software for users to employ in constructing certificate requests.
用户以标准格式准备证书请求，例如PKCS10[3]或CMC[4]。证书的“主题”字段包含用户生成的笔名。预计CA（BI+AI）可以为用户提供软件，用于构造证书请求。
If so, then this software can generate a candidate Subject name to minimize the likelihood of a collision. If the user selects a candidate pseudonym without such support, the likelihood of a subject name collision probably will be greater, increasing the likelihood that the certificate request will be rejected or that the AI will have to generate a pseudonym for the user.
如果是这样，那么该软件可以生成一个候选主题名称，以最小化冲突的可能性。如果用户在没有此类支持的情况下选择候选笔名，则使用者名称冲突的可能性可能会更大，从而增加证书请求被拒绝或AI必须为用户生成笔名的可能性。
After constructing the certificate request, the user sends it, along with the Token from Step 2, to the AI, via a secure channel. This channel MUST be encrypted and one-way authenticated, i.e., the user MUST be able to verify that it is communicating with the AI, but the AI MUST NOT be able to verify the real identity of the user. Typical use of TLS for secure web site access satisfies this requirement. The certificate request of PKCS10 [3] or CMC [4] carries the Token from Step 2.
在构造证书请求之后，用户通过安全通道将其与步骤2中的令牌一起发送到AI。该通道必须经过加密和单向认证，即用户必须能够验证其是否与AI通信，但AI不得验证用户的真实身份。TLS用于安全网站访问的典型用途满足此要求。PKCS10[3]或CMC[4]的证书请求携带步骤2中的令牌。
The Token is carried as an attribute in a certificate request (CertificationRequestInfo.attributes) where the attrType MUST be id-kisa-tac below in PKCS10 format. The Token is set to attrValues (Certificate Request Controls) where the attrType MUST be id-kisa-tac in CMC [4] format. The TAC request message profile is described in the section 5.3.
令牌作为证书请求（CertificationRequestInfo.attributes）中的一个属性携带，其中attrType必须是PKCS10格式的id kisa tac。令牌设置为attrValues（证书请求控制），其中attrType必须为CMC[4]格式的id kisa tac。第5.3节描述了TAC请求消息配置文件。
Step 4:
步骤4：
The AI, upon receipt of the certificate request containing a Token, verifies that the request is consistent with the processing defined for the request format (PKCS10). If a Subject name is present, it verifies that the proposed pseudonym is unique. The AI also verifies the signature on the Token and, if it is valid, checks the Timeout value to reject a replay attack based on a "timed-out" Token.
AI在收到包含令牌的证书请求后，验证该请求是否与为请求格式（PKCS10）定义的处理一致。如果存在受试者名称，它将验证建议的笔名是否唯一。AI还验证令牌上的签名，如果签名有效，则检查超时值以拒绝基于“超时”令牌的重播攻击。
A Token with an old Timeout value is rejected out-of-hand by the AI. (After a Token's Timeout time is reached, the AI deletes the Token from its cache.) Next, the AI compares the received Token against a cache of recent (i.e., not "timed out"), validated Tokens. The AI matches the resubmitted request to the original request, and responds accordingly. For example, if a duplicate is detected, the certificate request can be rejected as a replay.
AI会立即拒绝具有旧超时值的令牌。（到达令牌超时时间后，AI从其缓存中删除令牌。）接下来，AI将接收到的令牌与最近（即，未“超时”）验证令牌的缓存进行比较。AI将重新提交的请求与原始请求相匹配，并做出相应的响应。例如，如果检测到重复，则可以作为重播拒绝证书请求。
If the Subject field contains a Subject name already issued by the AI, the AI MUST either reject the certificate request, or substitute a pseudonym it generates, depending on the policy of the TAC CA. If the certificate request is acceptable, the AI assigns a serial number and constructs a tbsCertificate (i.e., the final form of the certificate payload, ready to be signed).
如果Subject字段包含AI已发布的Subject名称，AI必须拒绝证书请求，或替换其生成的假名，具体取决于TAC CA的策略。如果证书请求可接受，AI将分配序列号并构造tbsCertificate（即证书有效载荷的最终形式，准备签字）。
The AI then computes a hash over this data structure and blinds the hash value. (The AI blinds the hash value using a key from a public-key encryption pair where neither key is ever made public. The other key from this pair is used by the AI in Step 6 to "un-blind" the signed hash value.)
AI然后计算该数据结构上的哈希值，并将哈希值置盲。（AI使用公钥加密对中的一个密钥对哈希值进行盲处理，其中两个密钥均未公开。AI在步骤6中使用该对中的另一个密钥对签名哈希值进行“解盲”。）
The AI sends the CMS ContentInfo object of TokenandBlindHash to the BI, via a two-way authenticated and encrypted channel. The two-way authentication and encryption is required to ensure that the AI is sending these values to the BI, to allow the BI to verify that the values were transmitted by the AI, and to prevent a wiretapper from acquiring the Token. A TLS session in which both parties employ certificates to authenticate one another is the RECOMMENDED way to achieve this communication.
AI通过双向认证和加密通道将TokenandBlindHash的CMS ContentInfo对象发送给BI。需要双向身份验证和加密，以确保AI向BI发送这些值，允许BI验证值是否由AI传输，并防止有线窃听器获取令牌。双方使用证书相互验证的TLS会话是实现此通信的推荐方式。
The TokenandBlindHash is a CMS ContentInfo with a contentType of id-kisa-tac-tokenandblindhash and a content that holds a SignedData of CMS SignedData object [6], signed by the AI, where the eContent (EncapsulatedContentInfo) is a SEQUENCE consisting of the Token and BlindedCertificateHash, and eContentType MUST be id-data.
TokenandBlindHash是一个CMS ContentInfo，其contentType为id kisa tac TokenandBlindHash，内容包含由AI签名的CMS SignedData对象[6]的SignedData，其中eContent（封装的ContentInfo）是一个由Token和BlindedCertificateHash组成的序列，eContentType必须是id数据。
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- OBJECT IDENTIFIER : id-data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
-- DER encoded with the input of 'SEQUENCE of the Token and
-- BlindedCertificateHash'
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- OBJECT IDENTIFIER : id-data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
-- DER encoded with the input of 'SEQUENCE of the Token and
-- BlindedCertificateHash'
The signature (SignatureValue of SignerInfo) is generated using the AI's private signature key, corresponding to the public key present in the AI's certificate. (Note that this certificate is just a certificate suitable for use with TLS, and is NOT the split-key certificate used to issue a TAC.) The certificate (or certificates) MUST be present.
签名（SignerInfo的SignatureValue）是使用AI的私有签名密钥生成的，与AI证书中的公钥相对应。（请注意，此证书只是适合与TLS一起使用的证书，而不是用于颁发TAC的分割密钥证书。）证书（或多个证书）必须存在。
The following ASN.1 syntax represents the Token and BlindedCertificateHash:
以下ASN.1语法表示令牌和BlindedCertificateHash：
Token ::= ContentInfo
BlinedCertificateHash ::= OCTET STRING
Token ::= ContentInfo
BlinedCertificateHash ::= OCTET STRING
Token is the value of ContentInfo in the certificate request message (CertificationRequestInfo.attributes) from Step 3.
Token是步骤3中证书请求消息（CertificationRequestInfo.attributes）中ContentInfo的值。
BlindedCertificateHash is the blinded hash value for the tbsCertificate.
BlindedCertificateHash是tbsCertificate的盲哈希值。
Appendix A provides the ASN.1 syntax for the Token, as a profiled CMS ContentInfo object. Appendix C provides the CMS SignedData object profile for wrapping the Token.
附录A提供了令牌的ASN.1语法，作为一个配置文件CMS ContentInfo对象。附录C提供了用于包装令牌的CMS SignedData对象配置文件。
TokenandBlindHash ::= ContentInfo
TokenandBlindHash ::= ContentInfo
Step 5:
步骤5：
The BI receives the Token and blinded certificate hash via the secure channel described above. First the BI verifies the signature on the TokenandBlindHash generated by AI and then verifies the signature on the Token to ensure that it is a legitimate Token generated by the BI. Next, the BI checks its database to ensure that the UserKey value from the Token is present and that the Token has not been used to authorize issuance of a certificate previously.
BI通过上述安全通道接收令牌和盲证书哈希。首先，BI验证AI生成的TokenandBlindHash上的签名，然后验证令牌上的签名，以确保它是BI生成的合法令牌。接下来，BI检查其数据库，以确保令牌中的UserKey值存在，并且该令牌以前没有用于授权证书的颁发。
This check is performed to ensure that the BI has authenticated the user and entered the user's real identity into the BI's database. Each Token authorizes issuance of only one certificate, so the check also ensures that the same Token has not been used to authorize issuance of more than one certificate. These checks ensure that the certificate issued by the AI to this user will be traceable, if needed.
执行此检查以确保BI已对用户进行身份验证，并将用户的真实身份输入BI的数据库。每个令牌仅授权颁发一个证书，因此该检查还确保同一令牌未被用于授权颁发多个证书。这些检查确保AI向该用户颁发的证书在需要时可追溯。
The BI uses its share of the threshold private signature key to sign the blinded certificate hash and returns the CMS SignedData back to the AI. The eContent of the SignedData is a SEQUENCE consisting of the Token and PartiallySignedCertificateHash.
BI使用其共享的门限私有签名密钥对盲证书哈希进行签名，并将CMS SignedData返回给AI。SignedData的eContent是由令牌和PartiallySignedCertificateHash组成的序列。
The following ASN.1 syntax represents the Token and PartiallySignedCertificateHash:
以下ASN.1语法表示令牌和PartiallySignedCertificateHash：
Token ::= ContentInfo
PartiallySignedCertificateHash ::= OCTET STRING
Token ::= ContentInfo
PartiallySignedCertificateHash ::= OCTET STRING
Token is the token value of the TokenandBlindHash (where the eContent is a SEQUENCE consisting of the Token and PartiallySignedCertificateHash) from Step 4.
Token是步骤4中TokenandBlindHash的令牌值（其中eContent是由令牌和PartiallySignedCertificateHash组成的序列）。
PartiallySignedCertificateHash is the signature value generated by BI's share of the threshold private signature key on BlindedCertificateHash from Step 4.
PartiallySignedCertificateHash是由BI在步骤4中的BlindedCertificateHash上共享阈值私有签名密钥生成的签名值。
The TokenandPartiallySignedCertificateHash is a CMS ContentInfo with a contentType of id-kisa-tac-tokenandpartially and a content that holds a SignedData of CMS SignedData object [6], signed by the BI, where the eContent (EncapsulatedContentInfo) is a SEQUENCE consisting of the Token and PartiallySignedCertificateHash, and eContentType MUST be id-data.
TokenandPartiallySignedCertificateHash是一个CMS ContentInfo，其内容类型为id kisa tac tokenandpartially，内容包含CMS SignedData对象[6]的SignedData，由BI签名，其中eContent（封装的ContentInfo）是一个由Token和PartiallySignedCertificateHash组成的序列，和eContentType必须是id数据。
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- OBJECT IDENTIFIER : id-data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
-- DER encoded with the input of 'SEQUENCE of the Token and
-- PartiallySignedCertificateHash'
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- OBJECT IDENTIFIER : id-data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
-- DER encoded with the input of 'SEQUENCE of the Token and
-- PartiallySignedCertificateHash'
The signature (SignatureValue of SignerInfo) is generated using the BI's private signature key, corresponding to the public key present in the BI's certificate. (Note that this certificate is just a certificate suitable for use with TLS, and is NOT the split-key certificate used to issue a TAC.) The certificate (or certificates) MUST be present. Appendix A provides the ASN.1 syntax for the Token, as a profiled CMS SignedData object. Appendix C provides the CMS SignedData object profile for wrapping the Token.
签名（SignerInfo的SignatureValue）是使用BI的私有签名密钥生成的，与BI证书中的公钥相对应。（请注意，此证书只是适合与TLS一起使用的证书，而不是用于颁发TAC的分割密钥证书。）证书（或多个证书）必须存在。附录A提供了令牌的ASN.1语法，作为配置文件CMS SignedData对象。附录C提供了用于包装令牌的CMS SignedData对象配置文件。
TokenandPartiallySignedCertificateHash ::= ContentInfo
TokenandPartiallySignedCertificateHash ::= ContentInfo
Step 6:
步骤6：
Upon receipt of the TokenandPartiallySignedCertificateHash, the AI verifies the signature on the PartiallySignedCertificateHash, generated by BI and then matches the Token against its list of outstanding requests to the BI. The AI then "un-blinds" the blindHashValue, using the other key from the key pair employed in Step 4. This reveals the partially signed certificate hash. The AI then applies its part of the split private key to complete the signature of the certificate for the user.
在收到令牌和PartiallySignedCertificateHash后，AI验证BI生成的PartiallySignedCertificateHash上的签名，然后将令牌与BI的未完成请求列表进行匹配。然后，AI使用步骤4中使用的密钥对中的另一个密钥“解除盲”blindHashValue。这将显示部分签名的证书哈希。AI然后应用其分割私钥的一部分为用户完成证书的签名。
It records the certificate and the Token value in its database, to enable later tracing of the certificate to the real user identity, if needed. The AI transmits the completed certificate to the user, via the response message from the request protocol employed by the user in Step 3, PKCS10.
它将证书和令牌值记录在其数据库中，以便在需要时将证书跟踪到真实的用户身份。AI通过来自用户在步骤3 PKCS10中使用的请求协议的响应消息将完成的证书发送给用户。
The user may now employ the certificate with any PKI-enabled application or protocol that makes use of X.509 certificates (consistent with the key usage, and Extended Key Usage (EKU) values in the certificate). Note that the user should be prepared to accommodate delays in the certificate issuance process. For example, a connection between the user and the AI might fail sometime after the user submits a certificate request at the end of Step 3 and before the AI returns the certificate at the end of Step 6. If this happens, the user should resubmit the request. The AI and BI retain sufficient state to be able to match the resubmitted request to the original request, and respond accordingly. If the process failed in steps 5 or 6, the AI returns an error indication to the user.
用户现在可以将证书与使用X.509证书（与证书中的密钥使用和扩展密钥使用（EKU）值一致）的任何启用PKI的应用程序或协议一起使用。请注意，用户应准备好适应证书颁发过程中的延迟。例如，在用户在步骤3结束时提交证书请求之后以及AI在步骤6结束时返回证书之前，用户与AI之间的连接可能会失败。如果发生这种情况，用户应重新提交请求。AI和BI保持足够的状态，以便能够将重新提交的请求与原始请求相匹配，并做出相应的响应。如果过程在步骤5或6中失败，AI将向用户返回错误指示。
If a user to whom a TAC has been issued abuses the anonymity provided by the TAC, the TAC can be traced to the identity of that user. Mapping a TAC to a user's real identity is a four-step process, described below and illustrated in Figure 2.
如果获得TAC的用户滥用TAC提供的匿名性，则TAC可以追踪到该用户的身份。将TAC映射到用户的真实身份是一个四步过程，如下所述，如图2所示。
C +---------------+
+<-------->| Blind |
| D | Issuer (BI)|
| +---------------+
+---------+ |
| Relying |<---------->|
| Party | |
+---------+ |
| A +----------------+
+<-------->| Anonymity |
B | Issuer (AI) |
+----------------+
C +---------------+
+<-------->| Blind |
| D | Issuer (BI)|
| +---------------+
+---------+ |
| Relying |<---------->|
| Party | |
+---------+ |
| A +----------------+
+<-------->| Anonymity |
B | Issuer (AI) |
+----------------+
Figure 2. Revealing a TAC User's Real Identity
图2。透露TAC用户的真实身份
Step A:
步骤A：
The AI verifies the assertion by an aggrieved party that a TAC user has abused the anonymity provided by his TAC. The procedures used by AI to verify that such abuse has occurred are outside the scope of this document. No protocol is defined here for the interaction between the aggrieved party and AI. The only technical requirement is that the TAC of the offending user be provided to the AI. If the AI determines that there is sufficient evidence of abuse to trace the TAC to the user, the AI revokes the TAC, by listing its serial number on the next Certificate Revocation List (CRL) issued by the AI.
AI验证了受害方关于TAC用户滥用其TAC提供的匿名性的断言。AI用于核实此类滥用行为是否发生的程序不在本文件范围内。这里没有为受害方和AI之间的交互定义协议。唯一的技术要求是向AI提供违规用户的TAC。如果AI确定有足够的滥用证据将TAC追踪到用户，则AI通过在AI发布的下一个证书撤销列表（CRL）上列出其序列号来撤销TAC。
An AI unilaterally manages the CRL for a TAC. Because RFC 5280 implementations are not required to process indirect CRLs, we create a second certificate for the CA, under the TAC CA. Revoked EE certificates issued by the TAC CA are recorded on this CRL and validated using this second CA certificate.
AI单方面为TAC管理CRL。因为处理间接CRL不需要RFC 5280实现，所以我们在TAC CA下为CA创建第二个证书。TAC CA颁发的吊销EE证书记录在此CRL上，并使用第二个CA证书进行验证。
This CA certificate will have the cRLSign bit set in the KeyUsage extension, but not the keyCertSign bit. The private key for this certificate will be held by the AI, so that it can issue CRLs unilaterally.
此CA证书将在KeyUsage扩展中设置cRLSign位，但不设置keyCertSign位。此证书的私钥将由AI持有，以便它可以单方面颁发CRL。
The Subject DN (Distinguished Name) will be the same in both CA certificates, which reinforces the notion that the CRL issuer is the same entity as the TAC issuer, and that this CRL is not an indirect CRL. Because the CRL issuer does not issue any certificates itself, there is no possible serial number conflict. This will be the only CA certificate issued under the TAC CA certificate (and thus it will be signed jointly by the BI and AI). We recommend that the CRL for this CA certificate be similarly long-lived, as it too needs to be signed by the BI and AI. Each EE TAC certificate MUST contain a CRL Distribution Point that points to the CRL issued by this CA, to ensure that relying parties know to check this CRL vs. the CRL that covers only the CRL CA. (If the AI uses the Online Certificate Status Protocol (OCSP) [13] to convey the revocation status of TACs, an equivalent procedure is employed.) If it is later determined that the revocation was not warranted, a new TAC can be issued, to preserve the anonymity of the user in future transactions.
两个CA证书中的主题DN（可分辨名称）将相同，这加强了CRL颁发者与TAC颁发者是同一实体的概念，并且该CRL不是间接CRL。由于CRL颁发者本身不颁发任何证书，因此不存在可能的序列号冲突。这将是根据TAC CA证书颁发的唯一CA证书（因此将由BI和AI共同签署）。我们建议此CA证书的CRL同样具有长寿命，因为它也需要由BI和AI签名。每个EE TAC证书必须包含指向该CA颁发的CRL的CRL分发点，以确保依赖方知道检查该CRL与仅覆盖CRL CA的CRL。（如果AI使用在线证书状态协议（OCSP）[13]传达TAC的撤销状态，则采用等效程序。）如果后来确定撤销没有得到保证，则可以发布新的TAC，以在将来的交易中保持用户的匿名性。
Step B:
步骤B：
The AI searches its database, e.g., based on the serial number in the TAC, to locate the Token that was passed between the AI and BI during the issuance process (Steps 5 and 6 above). The AI passes this Token to the aggrieved party via an encrypted and two-way authenticated channel. Encryption is required to prevent disclosure of the Token, and two-way authentication is required to ensure that the aggrieved party and the AI know that they are communicating with each other. Two-way authenticated TLS is the RECOMMENDED means of implementing this channel, though other approaches are allowed.
AI搜索其数据库，例如，基于TAC中的序列号，以定位在发行过程中AI和BI之间传递的令牌（上述步骤5和6）。AI通过加密和双向认证通道将该令牌传递给受害方。需要加密以防止令牌泄露，并且需要双向身份验证以确保受害方和AI知道他们正在相互通信。双向认证TLS是实现此通道的推荐方法，但也允许使用其他方法。
Steps C and D:
步骤C和D：
The aggrieved party transits the Token to the BI, via an encrypted and two-way authenticated channel. The channel MUST be encrypted to prevent disclosure of the Token, and two-way authentication is required to ensure that the aggrieved party and the BI know that
受害方通过加密和双向认证通道将令牌传输给BI。通道必须加密以防止令牌泄露，并且需要双向身份验证以确保受害方和BI知道这一点
they are communicating with each other. If specified by the Certificate Policy (CP) for the TAC CA, the BI will independently determine that there is sufficient evidence of abuse to trace the TAC to the user, before proceeding. The BI verifies its signature on the Token, to verify that this is a Token generated by it and presumably released to the aggrieved party by the AI. Next, the BI searches its database using the UserKey value extracted from the Token. The BI retrieves the user's real identity and provides it to the aggrieved party. (By requiring the aggrieved party to interact with both the AI and the BI, the BI can verify that it is dealing with an aggrieved party, not with the AI acting unilaterally.)
他们正在互相交流。如果由TAC CA的证书策略（CP）指定，BI将在继续之前独立确定有足够的滥用证据来跟踪用户的TAC。BI验证其在令牌上的签名，以验证这是由BI生成的令牌，并可能由AI释放给受害方。接下来，BI使用从令牌中提取的UserKey值搜索其数据库。BI检索用户的真实身份并将其提供给受害方。（通过要求受害方与AI和BI进行互动，BI可以验证它是在与受害方打交道，而不是与单方面行动的AI打交道。）
TAC request MAY use either PKCS10 or CMC. An AI MUST support PKCS10 and MAY support CMC.
TAC请求可以使用PKCS10或CMC。AI必须支持PKCS10，并且可能支持CMC。
This profile refines the specification in PKCS10 [3], as it relates to TAC. A Certificate Request Message object, formatted according to PKCS10, is passed to the AI.
此概要文件细化了PKCS10[3]中与TAC相关的规范。将根据PKCS10格式化的证书请求消息对象传递给AI。
This profile applies the following additional constraints to fields that may appear in a CertificationRequestInfo:
此配置文件将以下附加约束应用于可能出现在CertificationRequestInfo中的字段：
Version This field is mandatory and MUST have the value 0.
版本此字段是必填字段，必须具有值0。
Subject This field MUST be present. If the value of this field is empty, the AI will generate a subject name that is unique in the context of certificates issued by this issuer. If the Subject field contains a Subject name already issued by the AI, the AI MUST either reject the certificate request, or substitute a pseudonym it generates, depending on the policy of the TAC CA.
主题此字段必须存在。如果此字段的值为空，则AI将生成一个在该颁发者颁发的证书上下文中唯一的使用者名称。如果Subject字段包含AI已发布的Subject名称，则AI必须拒绝证书请求，或替换其生成的假名，具体取决于TAC CA的策略。
SubjectPublicKeyInfo This field specifies the subject's public key and the algorithm with which the key is used.
SubjectPublicKeyInfo此字段指定主题的公钥以及使用该密钥的算法。
Attributes PKCS10 [3] defines the attributes field as key-value pairs where the key is an OID and the value's structure depends on the key. The attribute field MUST include the id-kisa-tac attribute, which holds the Token and is defined below. The
Attributes PKCS10[3]将属性字段定义为键-值对，其中键是OID，值的结构取决于键。属性字段必须包含id kisa tac属性，该属性保存令牌，定义如下。这个
Attributes field MAY also contain X509v3 Certificate Extensions and any PKCS9 [7] extensionRequest attributes that the subscriber would like to have included in the certificate. The profile for extensions in certificate requests is specified in RFC 5280 [2].
属性字段还可能包含X509v3证书扩展和订阅服务器希望包含在证书中的任何PKCS9[7]extensionRequest属性。RFC 5280[2]中指定了证书请求中扩展的配置文件。
This profile refines the Certificate Request messages in Certificate Management over CMS in CMC [4], as they relate to TACs.
此配置文件细化了CMC[4]中CMS证书管理中的证书请求消息，因为它们与TAC相关。
A Certificate Request message, formatted according to CMC [4], is passed to the AI.
将根据CMC[4]格式化的证书请求消息传递给AI。
With the exception of the public-key-related fields, the CA is permitted to alter any requested field when issuing a corresponding certificate.
除公钥相关字段外，CA可以在颁发相应证书时更改任何请求的字段。
This profile recommends the full PKI Request of the two types of PKI requests (Simple or Full PKI Request), and the PKI Request SHOULD be encapsulated in SignedData with an eContentType of id-cct-PKIData.
此配置文件建议两种类型的PKI请求（简单或完整PKI请求）中的完整PKI请求，并且PKI请求应封装在SignedData中，并带有eContentType id cct PKI数据。
This profile applies the following additional constraints to fields that may appear in a Certificate Request Template of Certificate Request Message Format (CRMF) [5]:
此配置文件对可能出现在证书请求消息格式（CRMF）[5]的证书请求模板中的字段应用以下附加约束：
Version This field MAY be absent, or MAY specify the request of a Version 3 Certificate. It SHOULD be omitted.
版本此字段可能不存在，或者可能指定对版本3证书的请求。应该省略它。
SerialNumber As per CRMF [5], this field is assigned by the CA and MUST be omitted in this profile.
根据CRMF[5]的序列号，此字段由CA分配，必须在此配置文件中省略。
SigningAlgorithm As per CRMF [5], this field is assigned by the CA and MUST be omitted in this profile.
根据CRMF[5]的签名算法，此字段由CA分配，必须在此配置文件中省略。
Issuer This field is assigned by the CA and MUST be omitted in this profile.
发卡机构此字段由CA分配，在此配置文件中必须省略。
Validity This field MAY be omitted. If omitted, the AI will issue a Certificate with Validity dates as determined by the TAC CA policy. If specified, then the CA MAY override the requested values with dates as determined by the TAC CA policy.
有效性此字段可以省略。如果省略，AI将颁发一份证书，其有效日期由TAC CA政策确定。如果指定，则CA可以使用TAC CA策略确定的日期覆盖请求的值。
Subject This field MUST be present. If the value of this field is empty, the AI MUST generate a subject name that is unique in the context of certificates issued by this issuer. If the Subject field contains a Subject name already issued by the AI, the AI MUST either reject the certificate request, or substitute a pseudonym it generates, depending on the policy of the TAC CA.
主题此字段必须存在。如果此字段的值为空，则AI必须生成在该颁发者颁发的证书上下文中唯一的使用者名称。如果Subject字段包含AI已发布的Subject名称，则AI必须拒绝证书请求，或替换其生成的假名，具体取决于TAC CA的策略。
PublicKey This field MUST be present.
公钥此字段必须存在。
This profile also refines constraints that may appear in a Certificate Request controls: The Token is set to attrValues (in CertRequest.controls) where the attrType MUST be id-kisa-tac.
此配置文件还细化了证书请求控件中可能出现的约束：令牌设置为attrValues（在CertRequest.controls中），其中attrType必须为id kisa tac。
See Section 5.3.1, "PKCS10 Profile", for the certification request formats based on PKCS10.
关于基于PKCS10的认证申请格式，请参见第5.3.1节“PKCS10配置文件”。
The anonymity provided by the architecture and protocols defined in this document is conditional. Moreover, if the user employs the same TAC for multiple transactions (with the same or different parties), the transactions can be linked through the use of the same TAC. Thus, the anonymity guarantee is "weak" even though the user's real identity is still hidden.
本文档中定义的体系结构和协议提供的匿名性是有条件的。此外，如果用户对多个交易（同一方或不同方）使用相同的TAC，则可以通过使用相同的TAC链接交易。因此，即使用户的真实身份仍然被隐藏，匿名性保证也是“弱的”。
To achieve stronger anonymity, a user may acquire multiple TACs, through distinct iterations of the protocol. Since each TAC is generated independently, it should not be possible for a relying party to discover a link between pseudonyms unless the tracing feature of this scheme is invoked. If the TAC has a long validity interval, this increases the probability that the identity of a TAC user will be discovered, e.g., as a result of linking user transactions across multiple servers. Thus, we recommend that each TAC CA consider carefully how long the validity for a TAC certificate should be. In the course of issuing a TAC, the AI and the user interact directly. Thus, the AI may have access to lower-layer information (e.g., an IP address) that might reveal the user's identity. A user concerned about this sort of possible identity compromise should use appropriate measures to conceal such information, e.g., a network anonymity service such as Tor [10].
为了实现更强的匿名性，用户可以通过协议的不同迭代获得多个TAC。由于每个TAC都是独立生成的，因此依赖方不可能发现假名之间的链接，除非调用此方案的跟踪功能。如果TAC具有较长的有效性间隔，则这增加了发现TAC用户身份的概率，例如，由于跨多个服务器链接用户事务。因此，我们建议每个TAC CA仔细考虑TAC证书的有效期应该是多长。在发布TAC的过程中，AI和用户直接交互。因此，AI可以访问可能揭示用户身份的较低层信息（例如，IP地址）。关注此类可能的身份泄露的用户应使用适当的措施隐藏此类信息，例如，Tor等网络匿名服务[10]。
This document makes no provisions for certificate renewal or rekey; we recommend TAC users acquire new TACs periodically, to further reduce the likelihood of linkage. It also may be possible to determine the identity of a user via information carried by lower-
本文件未对证书续期或重新注册作出规定；我们建议TAC用户定期获取新的TAC，以进一步降低链接的可能性。还可以通过较低层承载的信息来确定用户的身份-
level protocols, or by other, application-specific means. For example, the IP address of the user might be used to identify him. For this reason, we recommend that a TAC be used primarily to access web services with anonymity. Note that the TAC architecture described in this document is not capable of using certificates for use with S/MIME, because there is no provision to issue two certificates (one for encryption and one for signatures) that contain the same (anonymous) Subject name. An analogous problem might arise if a user visits a site (and does not conceal his identity), the site deposits a "cookie" into the user's browser cache, and the user later visits a site and employs a TAC with the presumption of anonymity.
级别协议，或通过其他特定于应用程序的方式。例如，可以使用用户的IP地址来识别他。因此，我们建议TAC主要用于匿名访问web服务。请注意，本文档中描述的TAC体系结构不能将证书用于S/MIME，因为没有规定颁发包含相同（匿名）使用者名称的两个证书（一个用于加密，一个用于签名）。如果用户访问一个站点（并且不隐藏其身份），该站点将“cookie”存放到用户的浏览器缓存中，并且用户随后访问一个站点并使用假定匿名的TAC，则可能会出现类似的问题。
The use of a TAC is a tool to help a user preserve anonymity, but it is not, per se, a guarantee of anonymity. We recommend that each TAC CA issue certificates with only one lifetime, in order to avoid the complexity that might arise otherwise. If a TAC CA offered certificates with different lifetimes, then it would need to communicate this information from the BI to AI in a way that does not unduly compromise the anonymity of the user.
TAC的使用是帮助用户保持匿名性的工具，但它本身并不能保证匿名性。我们建议每个TAC CA只颁发一个生存期的证书，以避免否则可能出现的复杂性。如果TAC CA提供具有不同生存期的证书，那么它将需要以不过度损害用户匿名性的方式将此信息从BI传递给AI。
This architecture uses the UserKey to link a TAC to the corresponding real user identity. The UserKey is generated in a fashion to ensure that it cannot be examined to determine a user's real identity. UserKey values are maintained in two distinct databases: the BI database maps a UserKey to a real user identity, and the AI database maps a TAC to a UserKey. The UserKey is always carried in a signed data object, a Token. The Token is signed to allow the BI to verify its authenticity, to prevent attacks based on guessing UserKey values. The Token also carries a Timeout value to allow the AI and BI to reject session-level replay attacks, and to facilitate garbage collection of AI and BI databases.
该体系结构使用UserKey将TAC链接到相应的真实用户身份。用户密钥的生成方式确保无法通过检查来确定用户的真实身份。UserKey值在两个不同的数据库中维护：BI数据库将UserKey映射到真实用户身份，AI数据库将TAC映射到UserKey。用户密钥始终携带在签名数据对象（令牌）中。对令牌进行签名以允许BI验证其真实性，从而防止基于猜测用户密钥值的攻击。令牌还带有超时值，以允许AI和BI拒绝会话级重播攻击，并促进AI和BI数据库的垃圾收集。
Threshold cryptography is employed to enable strong separation of the BI and AI functions, and to ensure that both must cooperate to issue certificates under the aegis of a TAC CA. (The AI and BI must ensure that the threshold cryptographic scheme they employ does not provide an advantage to either party based on the way the key-splitting is effected.) Blind signatures are used with threshold cryptography to preserve the separation of functions, i.e., to prevent the BI from learning the hash value of the TAC issued by the AI.
阈值加密技术用于实现BI和AI功能的强大分离，并确保两者必须在TAC CA的支持下合作颁发证书。（AI和BI必须确保他们采用的阈值加密方案不会根据密钥拆分的方式对任何一方提供优势。）盲签名与阈值加密一起使用，以保持函数分离，即防止BI学习AI发布的TAC的哈希值。
Message exchanges between a user and the BI or the AI, between the AI and BI, and between an aggrieved party and the AI and BI all make use of secure channels. These channels are encrypted to prevent disclosure of the Token value and of the pseudonym in the TAC request and response and in a tracing request. The channels are two-way authenticated to allow the AI and BI to verify their respective identities when communication with one another, and one-way
用户与BI或AI之间、AI与BI之间以及受害方与AI与BI之间的消息交换都使用安全通道。这些通道经过加密，以防止在TAC请求和响应以及跟踪请求中泄露令牌值和假名。通道是双向认证的，允许AI和BI在相互通信时验证各自的身份，并且是单向的
authenticated to allow the user to verify their identities when he communicates with them. Two-way authentication is employed for communication between an aggrieved party and the AI and BI, to allow all parties to verify the identity of one another.
通过身份验证，允许用户在与他们通信时验证他们的身份。双向认证用于受害方与AI和BI之间的通信，以允许所有各方验证彼此的身份。
There is an opportunity for the AI to return the wrong UserKey to an aggrieved party, which will result in tracing a certificate to the wrong real user identity. This appears to be unavoidable in any scheme of this sort, since the database maintained by the BI is intentionally ignorant of any info relating a UserKey to a TAC.
AI有机会将错误的用户密钥返回给受害方，这将导致跟踪证书到错误的真实用户身份。这在任何此类方案中似乎都是不可避免的，因为BI维护的数据库故意不知道用户密钥与TAC相关的任何信息。
A TAC CA MUST describe in its CP how long it will retain the data about certificates it issued, beyond the lifetime of these certificates. This will help a prospective TAC subject gauge the likelihood of unauthorized use of his identity as a result of a compromise of this retained data. It also alerts relying parties of the timeframe (after expiration of a certificate) in which an alleged abuse must be brought to the attention of the AI and BI, before the data linking a certificate to the real user identity is destroyed.
TAC CA必须在其CP中说明在这些证书的生命周期之外，它将保留有关其颁发的证书的数据多长时间。这将有助于潜在的TAC受试者评估由于该保留数据的泄露而导致未经授权使用其身份的可能性。它还提醒依赖方在销毁将证书与真实用户身份链接的数据之前（证书到期后）必须提请AI和BI注意的时间范围。
Tim Polk (NIST), Stefan Santesson (ACC-sec.com), Jim Schaad (Soaring Hawk), David A. Cooper (NIST), SeokLae Lee, JongHyun Baek, SoonTae Park (KISA), Taekyoung Kwon (Sejong University), JungHee Cheon (Seoul National University), and YongDae Kim (Minnesota University) have significantly contributed to work on the concept of TAC and have identified security issues. Their comments enhanced the maturity of the document.
Tim Polk（NIST）、Stefan Santesson（ACC sec.com）、Jim Schaad（翱翔的鹰）、David A.Cooper（NIST）、SeokLae Lee、钟云白、SoonTae Park（KISA）、跆拳道（世宗大学）、郑希昌（首尔国立大学）和金永大（明尼苏达大学）对TAC概念的工作做出了重大贡献，并确定了安全问题。他们的评论提高了文件的成熟度。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] 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.
[2] Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[3] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[3] Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范版本1.7”，RFC 2986，2000年11月。
[4] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[4] Schaad，J.和M.Myers，“CMS（CMC）的证书管理”，RFC 52722008年6月。
[5] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[5] Schaad，J.，“Internet X.509公钥基础设施证书请求消息格式（CRMF）”，RFC 4211，2005年9月。
[6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[6] Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[7] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000.
[7] Nystrom，M.和B.Kaliski，“PKCS#9：选定对象类和属性类型版本2.0”，RFC 29852000年11月。
[8] S. Brands, "Rethinking public key infrastructures and digital certificates - Building in Privacy", PhD thesis, Eindhoven Institute of Technology, Eindhoven, The Netherlands, 1999.
[8] 美国Brands，“重新思考公钥基础设施和数字证书——在隐私中构建”，博士论文，埃因霍温理工学院，荷兰埃因霍温，1999年。
[9] D. Chaum, "Blind signature system", CRYPTO '83, Plenum Press, page 153, 1984.
[9] D.Chaum，“盲签名系统”，CRYPTO'83，全会出版社，第153页，1984年。
[10] "Tor: anonymity online", http://www.torproject.org.
[10] “Tor：匿名在线”，http://www.torproject.org.
[11] X.509, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, March 2000. Also available as ISO/IEC 9594-8, 2001.
[11] X.509，“信息技术-开放系统互连-目录：公钥和属性证书框架”，ITU-T建议X.509，2000年3月。也可作为ISO/IEC 9594-82001提供。
[12] S. Rafaeli, M. Rennhard, L. Mathy, B. Plattner, and D. Hutchison, "An Architecture for Pseudonymous e-Commerce", AISB'01 Symposium on Information Agents for Electronic Commerce, pp. 33-41, 2001.
[12] S.Rafaeli、M.Rennhard、L.Mathy、B.Plattner和D.Hutchison，“假名电子商务架构”，AISB'01电子商务信息代理研讨会，第33-41页，2001年。
[13] 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.
[13] 迈尔斯，M.，安克尼，R.，马尔帕尼，A.，加尔佩林，S.，和C.亚当斯，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC2560，1999年6月。
[14] Philip MacKenzie and Michael K. Reiter, "Two-Party Generation of DSA Signature", Crypto 2001.
[14] Philip MacKenzie和Michael K.Reiter，“DSA签名的两方生成”，Crypto 2001。
[15] Shaohua Tang, "Simple Threshold RSA Signature Scheme Based on Simple Secret Sharing", in "Computational Intelligence and Security", CIS 2005, Part II, Springer, pp. 186-191, 2005.
[15] 唐少华，“基于简单秘密共享的简单门限RSA签名方案”，载于“计算智能与安全”，CIS 2005，第二部分，Springer，第186-191页，2005年。
[16] Taekyoung Kwon, Jung Hee Cheon, Yongdae Kim, Jae-Il Lee, "Privacy Protection in PKIs: A Separation-of-Authority Approach", in "Information Security Applications", WISA 2006, Springer, pp. 297-311, 2007.
[16] 跆拳道，郑希昌，金永大，李在日，“PKI中的隐私保护：一种权力分离方法”，摘自“信息安全应用”，WISA 2006，斯普林格，第297-311页，2007年。
[17] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[17] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[18] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[18] Ramsdell，B.，编辑，“安全/多用途Internet邮件扩展（S/MIME）版本3.1证书处理”，RFC 38502004年7月。
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
--
-- Copyright (c) 2009 IETF Trust and the persons identified as
-- authors of the code. All rights reserved.
--
-- Redistribution and use in source and binary forms, with or
-- without modification, are permitted provided that the following
-- conditions are met:
--
-- - Redistributions of source code must retain the above
-- copyright notice, this list of conditions and the following
-- disclaimer.
--
-- - Redistributions in binary form must reproduce the above
-- copyright notice, this list of conditions and the following
-- disclaimer in the documentation and/or other materials provided
-- with the distribution.
--
-- - Neither the name of Internet Society, IETF or IETF Trust, nor
-- the names of specific contributors, may be used to endorse or
-- promote products derived from this software without specific
-- prior written permission.
--
--
--
-- THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
-- CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES,
-- INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
-- DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
-- BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
-- EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
-- TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-- DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
-- ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
-- OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-- POSSIBILITY OF SUCH DAMAGE.
--
-- This version of the ASN.1 module is part of RFC 5636;
-- see the RFC itself for full legal notices.
--
--
-- Copyright (c) 2009 IETF Trust and the persons identified as
-- authors of the code. All rights reserved.
--
-- Redistribution and use in source and binary forms, with or
-- without modification, are permitted provided that the following
-- conditions are met:
--
-- - Redistributions of source code must retain the above
-- copyright notice, this list of conditions and the following
-- disclaimer.
--
-- - Redistributions in binary form must reproduce the above
-- copyright notice, this list of conditions and the following
-- disclaimer in the documentation and/or other materials provided
-- with the distribution.
--
-- - Neither the name of Internet Society, IETF or IETF Trust, nor
-- the names of specific contributors, may be used to endorse or
-- promote products derived from this software without specific
-- prior written permission.
--
--
--
-- THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
-- CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES,
-- INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
-- DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
-- BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
-- EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
-- TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-- DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
-- ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
-- OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
-- POSSIBILITY OF SUCH DAMAGE.
--
-- This version of the ASN.1 module is part of RFC 5636;
-- see the RFC itself for full legal notices.
--
BEGIN
开始
-- EXPORTS All
-- The types and values defined in this module are exported for
-- use in the other ASN.1 modules. Other applications may use
-- them for their own purposes.
-- EXPORTS All
-- The types and values defined in this module are exported for
-- use in the other ASN.1 modules. Other applications may use
-- them for their own purposes.
IMPORTS
进口
-- Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier, Certificate, CertificateList,
CertificateSerialNumber, Name FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
-- Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier, Certificate, CertificateList,
CertificateSerialNumber, Name FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
-- Imports from CMS
ContentInfo, SignedData FROM
CryptographicMessageSyntax2004{ iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24)}
-- Imports from CMS
ContentInfo, SignedData FROM
CryptographicMessageSyntax2004{ iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24)}
UserKey ::= OCTET STRING
UserKey ::= OCTET STRING
Timeout ::= GeneralizedTime
Timeout ::= GeneralizedTime
BlinedCertificateHash ::= OCTET STRING
BlinedCertificateHash ::= OCTET STRING
PartiallySignedCertificateHash ::= OCTET STRING
PartiallySignedCertificateHash ::= OCTET STRING
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- OBJECT IDENTIFIER : id-data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType, -- OBJECT IDENTIFIER : id-data
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
Token ::= ContentInfo
Token ::= ContentInfo
TokenandBlindHash ::= ContentInfo
TokenandBlindHash ::= ContentInfo
TokenandPartiallySignedCertificateHash ::= ContentInfo
TokenandPartiallySignedCertificateHash ::= ContentInfo
id-KISA OBJECT IDENTIFIER ::= {iso(1) member-body(2) korea(410)
kisa(200004)}
id-KISA OBJECT IDENTIFIER ::= {iso(1) member-body(2) korea(410)
kisa(200004)}
id-npki OBJECT IDENTIFIER ::= {id-KISA 10}
id-npki OBJECT IDENTIFIER ::= {id-KISA 10}
id-attribute OBJECT IDENTIFIER ::= {id-npki 1}
id-attribute OBJECT IDENTIFIER ::= {id-npki 1}
id-kisa-tac OBJECT IDENTIFIER ::= {id-attribute 1}
id-kisa-tac OBJECT IDENTIFIER ::= {id-attribute 1}
id-kisa-tac-token OBJECT IDENTIFIER ::= { id-kisa-tac 1}
id-kisa-tac-token OBJECT IDENTIFIER ::= { id-kisa-tac 1}
id-kisa-tac-tokenandblindbash OBJECT IDENTIFIER ::= { id-kisa-tac 2}
id-kisa-tac-tokenandblindbash OBJECT IDENTIFIER ::= { id-kisa-tac 2}
id-kisa-tac-tokenandpartially OBJECT IDENTIFIER ::= { id-kisa-tac 3}
id-kisa-tac-tokenandpartially OBJECT IDENTIFIER ::= { id-kisa-tac 3}
END
终止
TAC message exchanges between a user and the BI or the AI, between the AI and BI, and between an aggrieved party and the AI and BI all make use of secure channels to prevent disclosure of the Token value and of the pseudonym in the TAC request and response and in a tracing request. The Transport Layer Security Protocol v1.2 (TLS) [17] is a suitable security protocol to protect these message exchanges, and this document recommends use of TLS to protect these exchanges. The following text describes how the handshake part of TLS should be employed to protect each type of exchange. Note that no specific cipher suites are specified for use here; the choice of suites is up to the client and servers, as is commonly the case.
用户和BI或AI之间、AI和BI之间以及受害方和AI和BI之间的TAC消息交换都利用安全信道来防止在TAC请求和响应以及跟踪请求中泄露令牌值和假名。传输层安全协议v1.2（TLS）[17]是保护这些消息交换的合适安全协议，本文档建议使用TLS保护这些交换。下面的文本描述了如何使用TLS的握手部分来保护每种类型的交换。请注意，此处未指定要使用的特定密码套件；套件的选择取决于客户机和服务器，这是常见的情况。
The channels between a User and the BI or the AI are one-way authenticated to allow the user to verify their identities when he communicates with them.
用户与BI或AI之间的通道经过单向身份验证，允许用户在与BI或AI通信时验证其身份。
User BI or AI
用户BI或AI
ClientHello -------->
ClientHello -------->
ServerHello
Certificate
<-------- ServerHelloDone
ClientKeyExchange
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<--------- Finished
TAC Message <---------> TAC Message
ServerHello
Certificate
<-------- ServerHelloDone
ClientKeyExchange
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<--------- Finished
TAC Message <---------> TAC Message
Figure 3. TAC Message exchanges between a User and the BI or the AI
图3。用户与BI或AI之间的TAC消息交换
The channels between the BI and the AI are two-way authenticated to allow the AI and BI to verify their respective identities when communication with one another.
BI和AI之间的通道经过双向认证，以允许AI和BI在相互通信时验证各自的身份。
BI AI
比爱
ClientHello -------->
ServerHello
Certificate
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<--------- Finished
TAC Message <---------> TAC Message
ClientHello -------->
ServerHello
Certificate
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<--------- Finished
TAC Message <---------> TAC Message
Figure 4. TAC Message exchanges between BI and AI
图4。BI和AI之间的TAC消息交换
The channels between a User and the BI or the AI are two-way authenticated, to allow both parties to verify the identity of one another.
用户和BI或AI之间的通道是双向认证的，以允许双方验证彼此的身份。
User BI or AI
用户BI或AI
ClientHello -------->
ServerHello
Certificate
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<--------- Finished
TAC Message <---------> TAC Message
ClientHello -------->
ServerHello
Certificate
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<--------- Finished
TAC Message <---------> TAC Message
Figure 5. TAC Message Exchanges between an Aggrieved Party and the BI or the AI
图5。受害方与BI或AI之间的TAC消息交换
Using the Cryptographic Message Syntax(CMS)[6], TAC Token is a type of signed-data object. The general format of a CMS object is:
使用加密消息语法（CMS）[6]，TAC令牌是一种签名数据对象。CMS对象的一般格式为：
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
As a TAC is a signed-data object, it uses the corresponding OID, 1.2.840.113549.1.1.2.
由于TAC是有符号数据对象，因此它使用相应的OID 1.2.840.113549.1.1.2。
According to the CMS specification, the signed-data content type shall have ASN.1 type SignedData:
根据CMS规范，签名数据内容类型应具有ASN.1类型签名数据：
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
SignerInfos ::= SET OF SignerInfo
The elements of the signed-data content type are as follows:
签名数据内容类型的元素如下所示：
Version The version is the syntax version number. It MUST be 3, corresponding to the signerInfo structure having version number 3.
版本版本是语法版本号。它必须是3，对应于版本号为3的signerInfo结构。
digestAlgorithms This field specifies digest Algorithms.
digestAlgorithms此字段指定摘要算法。
encapContentInfo This element is defined in Appendix C.1.1.
encapContentInfo附录C.1.1中定义了该元素。
certificates The certificates element MUST be included and MUST contain only the single PKI EE certificate needed to validate this CMS Object. The CertificateSet type is defined in section 10 of RFC3852 [6].
证书必须包含certificates元素，并且必须仅包含验证此CMS对象所需的单个PKI EE证书。RFC3852[6]第10节定义了证书集类型。
crls The crls element MUST be omitted.
crls必须省略crls元素。
signerInfos This element is defined in Appendix C.1.2.
签名人本要素在附录C.1.2中定义。
encapContentInfo is the signed content, consisting of a content type identifier and the content itself.
encapContentInfo是已签名的内容，由内容类型标识符和内容本身组成。
EncapsulatedContentInfo ::= SEQUENCE{
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
EncapsulatedContentInfo ::= SEQUENCE{
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIER
ContentType ::= OBJECT IDENTIFIER
The elements of this signed content type are as follows:
此签名内容类型的元素如下所示：
eContentType The ContentType for an TAC Token is id-data and has the numerical value of 1.2.840.113549.1.7.1.
eContentType TAC令牌的ContentType是id数据，其数值为1.2.840.113549.1.7.1。
eContent The content of a TAC Token is the DER-encoded SEQUENCE of UserKey and Timeout.
eContent TAC令牌的内容是用户密钥和超时的DER编码序列。
SignerInfo is defined under CMS as:
签名信息在CMS下定义为：
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
The contents of the SignerInfo element are as follows:
SignerInfo元素的内容如下：
Version The version number MUST be 3, corresponding with the choice of SubjectKeyIdentifier for the sid.
版本版本号必须为3，与sid的SubjectKeyIdentifier选项相对应。
sid The sid is defined as:
sid将sid定义为：
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
For a TAC Token, the sid MUST be a SubjectKeyIdentifier.
对于TAC令牌，sid必须是SubjectKeyIdentifier。
digestAlgorithm This field specifies digest Algorithms.
digestAlgorithm此字段指定摘要算法。
signedAttrs The signedAttr element MUST be omitted.
signedAttr必须省略signedAttr元素。
SignatureAlgorithm This field specifies the signature Algorithm.
SignatureAlgorithm此字段指定签名算法。
Signature The signature value is defined as:
签名签名值定义为：
SignatureValue ::= OCTET STRING
SignatureValue ::= OCTET STRING
The signature characteristics are defined by the digest and signature algorithms.
签名特征由摘要和签名算法定义。
UnsignedAttrs unsignedAttrs MUST be omitted.
UnsignedAttrs必须省略UnsignedAttrs。
Authors' Addresses
作者地址
SangHwan Park Korea Internet & Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, Korea EMail: shpark@kisa.or.kr
韩国首尔松帕谷Garak Dong SangHwan Park韩国互联网与安全局78电子邮件：shpark@kisa.or.kr
Haeryong Park Korea Internet & Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, Korea EMail: hrpark@kisa.or.kr
韩国首尔松巴谷Garak Dong Haeryong Park韩国互联网与安全局78电子邮件：hrpark@kisa.or.kr
YooJae Won Korea Internet & Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, Korea EMail: yjwon@kisa.or.kr
YooJae Won Korea Internet&Security Agency 78，韩国首尔松帕谷Garak Dong电子邮件：yjwon@kisa.or.kr
JaeIl Lee Korea Internet & Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, Korea EMail: jilee@kisa.or.kr
JaeIl Lee韩国互联网与安全局78号，韩国首尔松帕谷Garak Dong电子邮件：jilee@kisa.or.kr
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 EMail: kent@bbn.com
Stephen Kent BBN Technologies马萨诸塞州剑桥莫尔顿街10号02138电子邮件：kent@bbn.com