[要約] RFC 5636は、トレース可能な匿名証明書に関する標準化されたプロトコルを提案しています。その目的は、匿名性を保ちながらも証明書のトレース可能性を実現することです。
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証明書を要求および使用するユーザーにプライバシーを提供するための実用的なアーキテクチャとプロトコルを定義し、そのような証明書を要求した実際のユーザーにマッピングする機能を保持しています。アーキテクチャは、PKCS10（RFC 2986）やCMC（RFC 5272）などのIETF証明書要求形式と互換性があります。アーキテクチャは、証明書の発行に関与する当局を分離します。1つは、証明書の内容（匿名発行者）を検証するための秘密鍵（ブラインド発行者）の所有権を検証するための1つです。このモデルの下で発行されたEnd Entity（EE）証明書は、Traceable Anonymous証明書（TACS）と呼ばれます。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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
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がCAが「ビッグブラザー」を「ビッグブラザー」として、プライバシーの観点から、認定機関（CA）や登録機関（RA）などの承認されたエンティティが認識される場合があります。仮名です。これは、そのようなエンティティが、発行された実際のユーザーの名前に発行した証明書に常に仮名をマッピングできるためです。このドキュメントでは、仮名を含む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は、標準的な方法で、秘密鍵の所有者（証明書の対応する公開鍵に対して）を特定するのに役立ちます。公開鍵、ID、および関連情報は、X.509 [11]で指定されており、インターネットで使用するためにプロファイルされているように、CAとして機能するエンティティによって署名されます[2]。過去10年間、PKIはインターネット上のさまざまな種類の通信とトランザクションをサポートするために広く展開されてきました。
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.
- 通常、証明書には、サブジェクトフィールドに、発行されたユーザーの真の身元が含まれます。このIDは、証明書所有者がユーザーに証明書を提示する必要があるセキュリティプロトコルで提示するたびに、頼る当事者（例：Webサイトまたは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.
- 匿名（End Entity）証明書[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のいずれかが、原則として、自律証明書を実際のユーザーIDに一方的にマッピングできます。
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.
このドキュメントで説明されているアーキテクチャ、構文、およびプロトコル規則により、匿名の証明書を発行および使用することができます。これにより、プライバシーと匿名の証明書を発行された個人にマッピングする条件付き能力のバランスを提供します。
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をそのユーザーの実際のIDにマッピングできる場合にのみ。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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または匿名証明書と呼ばれる）の概念を定義します。それは、サブジェクトフィールドに仮名を含むTACが条件付きで追跡可能であるという点で、従来の仮名証明書[8、9]と区別されます（インターネット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 certificate to the corresponding user, the certificate can always be revoked, but this may not be a sufficient response to abuse.)
- CAが真のIDを確認せずに匿名の証明書を発行する場合、それは追跡不能であり、証明書が発行されたユーザーが提供する匿名性を乱用する場合、不十分な頼みを提供します。（対応するユーザーに匿名の証明書をトレースする能力がなくても、証明書はいつでも取り消すことができますが、これは虐待に対する十分な応答ではないかもしれません。）
- 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は主題分野の仮名を実際のアイデンティティにリンクすることができます。
- 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.
- トレーサビリティおよび取り消し関数は、ユーザーに発行された証明書のユーザーの真のIDと仮名との間のリンケージをサポートする必要があります。したがって、ソリューションは、証明書を発行するために協力した当局間の合意により、匿名証明書から真の身元を決定できるようにする必要があります。
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は、AIの協力によってのみTACをユーザーにマッピングするために使用できるデータベースを維持します。
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は、Private-Key Proof-of-Possession（POP）チェック、ITによって発行されたすべての証明書の間の名前の一意性チェック、シリアル番号の割り当てなどを含む、CAに共通する関数を実行します。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の間のこの分割機能の結果は、実際のユーザーIDを明らかにするために一方的に作用することもできないということです。AIには、ユーザーに発行された証明書に関する知識がありますが、ユーザーの実際の身元に関する知識はありません。BIはユーザーの実際のアイデンティティを知っていますが、そのユーザーに発行された証明書の知識はありません。AIとBIのコラボレーションが、ユーザーに発行されたTACをそのユーザーの実際のIDにマッピングできる場合にのみ。
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 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.
このシステムは完璧ではありません。たとえば、AIとBIが協力して、適切な状況下でのみユーザーの実際のアイデンティティを明らかにすると想定しています。この保証が達成される手続き上のセキュリティ手段の詳細は、このドキュメントの範囲外です。それにもかかわらず、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を表す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が保持している1株とAIが保持している1株と正確に2株に分割されます。両方の株を、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.
このシステムの重要な部分であるもう1つのパブリックキー暗号化機能は、「ブラインドサイン」と呼ばれます。盲目の署名を作成するために、1つの当事者は、署名される値（例えば証明書のハッシュ値）を暗号化し、署名者に渡します。署名者は暗号化された値にデジタルで署名し、それを最初のパーティに返します。ファーストパーティは、最初にランダム値で適用した暗号化を反転し、基礎となるデータ（たとえばハッシュ値）に署名をもたらします。
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]の使用は、そのようなチャネルを確立するための適切な手段の1つですが、他のオプションも受け入れられます。この目的のために、このドキュメントは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（S）によって自己署名または発行される場合があります。
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 +----------------+
Figure 1. TAC Issuance Procedures
図1. TAC発行手順
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を含む）がユーザーの実際のアイデンティティをその値から推測できるようにする方法で生成されてはなりません。（たとえば、ユーザーの名前が一方向ハッシュアルゴリズムへの入力として使用されてユーザーキー値を生成する場合、追加のランダムデータを入力として使用する必要があります。）このデータベースのユーザーキーに関連付けられています。有効期限です。有効期限は、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など）からuserkeyを受け入れるたびに、値は上記のタイムスタンプを伴うデジタル署名されたCMSオブジェクトに埋め込まれます。トークンの署名はBIによって生成されます。（使用される証明書は、CMSで使用するのに適した証明書であり、TACの検証に使用されるスプリットキー証明書ではないことに注意してください。）
The following ASN.1 syntax represents the UserKey and an expiration time:
次のASN.1構文は、ユーザーキーと有効期限を表します。
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).
この仕様のコンテキストでは、一般化された時間の値はグリニッジ平均時間（Zulu）で表現する必要があり、秒（yyyymmdhhmmssz）を含める必要があります。
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 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.
BIは、トークンと呼ばれるデータ構造をユーザーに提示します。トークンは、安全なチャネル、たとえば直接または安全な通信チャネルを介してユーザーに伝達する必要があります。ここでは、盗聴者がトークンを取得できないようにするために、ここでは安全なチャネルが必要です。たとえば、ユーザーがステップ1で一方向認証TLSセッションをBIに確立した場合、このセッションを使用してトークンをユーザーに戻すことができます。
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.
トークンは2つの目的を果たします。TAC発行中、トークンは、BIに登録されているユーザーによってAIへの要求が提出されたことを確認するために使用されます（したがって、ユーザーの実際のアイデンティティを含むBIのデータベースにレコードがあります）。これは、TACを後でユーザーにトレースできるようにするために必要です。ユーザーの実際のアイデンティティを明らかにするリクエストがある場合、AIはTACをトレースすることを要求し、エンティティがTACをトレースできるようにトークンをBIに渡すことを要求するエンティティにトークンをリリースします。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.
トークンは、Id-kisa-tac-tokenのコンテンツタイプを備えたcontentinfoと、cms signeddataオブジェクトの署名data [6]を保持するコンテンツであり、biが署名したコンテンツであり、econtent（cancopturatedcontentinfo）はユーザーキーとsequenceであるシーケンスです。タイムアウト、およびecontentTypeはid-dataでなければなりません。
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 }
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.
Signature（SignerinfoのSignatureValue）は、BIの証明書に存在する公開鍵に対応するBIのプライベート署名キーを使用して生成されます。（この証明書は、TLSでの使用に適した証明書であり、TACの検証に使用されるスプリットキー証明書ではないことに注意してください。）証明書（または証明書）が存在する必要があります。付録Aは、プロファイルされたCMS ContentInfoオブジェクトとして、トークンのASN.1構文を提供します。付録Cは、トークンをラッピングするためのCMS SignedDataオブジェクトプロファイルを提供します。
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はユーザーの実際のアイデンティティを確認できない必要があります。安全なWebサイトアクセスのための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.
トークンは、ATTRTYPEがPKCS10形式で以下のID-Kisa-TACでなければならない証明書リクエスト（certificationRequestinfo.attributes）の属性として運ばれます。トークンは、ATTRTYPEがCMC [4]形式のID-Kisa-TACでなければならないアトラッチ（証明書要求コントロール）に設定されています。TAC要求メッセージプロファイルは、セクション5.3で説明されています。
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).
サブジェクトフィールドにAIがすでに発行したサブジェクト名が含まれている場合、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は、どちらのキーも公開されていないパブリックキー暗号化ペアのキーを使用してハッシュ値をブラインドします。このペアのもう1つのキーは、ステップ6のAIによって署名されたハッシュ値を「非盲検」に使用します。））
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は、Id-kisa-tac-tokenandblindhashのコンテンツタイプを備えたCMS Contentinfoと、AIが署名したCMS SignedDataオブジェクト[6]の署名dataを保持するコンテンツです。blindedcertificatehash、およびecontenttypeはid-dataでなければなりません。
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.
Signature（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 is the value of ContentInfo in the certificate request message (CertificationRequestInfo.attributes) from Step 3.
トークンは、ステップ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は、プロファイルされたCMS ContentInfoオブジェクトとして、トークンのASN.1構文を提供します。付録Cは、トークンをラッピングするためのCMS SignedDataオブジェクトプロファイルを提供します。
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はデータベースをチェックして、トークンからのユーザーキー値が存在し、トークンが以前に証明書の発行を許可するために使用されていないことを確認します。
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がユーザーを認証し、ユーザーの実際のIDをBIのデータベースに入力したことを確認するために実行されます。各トークンは1つの証明書のみの発行を承認するため、チェックにより、同じトークンが複数の証明書の発行を承認するために使用されていないことも保証されます。これらのチェックにより、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は、トークンと部分的に配信されたcertificatehashで構成されるシーケンスです。
The following ASN.1 syntax represents the Token and PartiallySignedCertificateHash:
次のASN.1構文は、トークンと部分的に配信されたCertificateHashを表します。
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.
トークンは、ステップ4からのトークンアンドブリンドハッシュのトークン値です（エコネントはトークンと部分的に配信されたCertificateHashからなるシーケンスです）。
PartiallySignedCertificateHash is the signature value generated by BI's share of the threshold private signature key on BlindedCertificateHash from Step 4.
Partivally -SignedCertificateHashは、ステップ4のBlindedCertificateHashのしきい値プライベート署名キーのBIのシェアによって生成される署名値です。
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.
tokenandpartivitivitysignedcertificatehashは、Id-kisa-tac-tokenandantandpartiallyのコンテンツタイプのCMS Contentinfoと、cms SignedDataオブジェクトの署名data [6]を保持するコンテンツであり、biが署名します。部分的に署名したCertificateHash、およびecontentTypeはid-dataでなければなりません。
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.
Signature（SignerinfoのSignatureValue）は、BIの証明書に存在する公開鍵に対応するBIのプライベート署名キーを使用して生成されます。（この証明書は、TLSでの使用に適した証明書であり、TACの発行に使用されるスプリットキー証明書ではないことに注意してください。）証明書（または証明書）が存在する必要があります。付録Aは、プロファイルされたCMS SignedDataオブジェクトとして、トークンのASN.1構文を提供します。付録Cは、トークンをラッピングするためのCMS SignedDataオブジェクトプロファイルを提供します。
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.
aiは、tokenandpartially -signedcertificatehashを受信すると、BIによって生成された部分的に配信された担当者の署名を検証し、その後、未払いのリクエストのリストと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.
必要に応じて、証明書を実際のユーザーIDに後からトレースすることができるように、データベースに証明書とトークン値を記録します。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証明書を使用するPKI対応アプリケーションまたはプロトコルで証明書を採用することができます（主要な使用法と一致し、証明書の主要な使用法（EKU）値を拡張します）。ユーザーは、証明書発行プロセスの遅延に対応するために準備する必要があることに注意してください。たとえば、ユーザーとAIの間の接続は、ユーザーがステップ3の終了時に証明書リクエストを提出し、AIがステップ6の終了時に証明書を返す前に失敗する可能性があります。リクエスト。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はそのユーザーのIDに由来することができます。TACをユーザーの実際のアイデンティティにマッピングすることは、以下で説明し、図2に示す4段階のプロセスです。
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の間の相互作用についてプロトコルは定義されていません。唯一の技術的要件は、問題のあるユーザーのTACがAIに提供されることです。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を一方的に管理します。RFC 5280の実装は間接CRLを処理するために必要ではないため、TAC CAの下でCAの2番目の証明書を作成します。TAC CAによって発行された取り消されたEE証明書は、このCRLに記録され、この2番目の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.
主題DN（著名な名前）は両方のCA証明書で同じであり、CRL発行者がTAC発行者と同じエンティティであり、このCRLが間接CRLではないという概念を強化します。CRL発行者は証明書自体を発行しないため、シリアル番号の競合は不可能です。これは、TAC CA証明書の下で発行された唯一のCA証明書になります（したがって、BIとAIが共同で署名します）。このCA証明書のCRLは、BIとAIによって署名する必要があるため、同様に長命であることをお勧めします。各EE TAC証明書には、このCAが発行したCRLを指すCRL配布ポイントを含める必要があります。（AIがオンライン証明書ステータスプロトコル（OCSP）[13]を使用してTACSの取り消しステータスを伝える場合、同等の手順が採用されます。）後で取消が保証されていないと判断された場合、新しい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 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.)
激しいパーティーは、暗号化された双方向の認証されたチャネルを介して、トークンをBIに通過します。トークンの開示を防ぐためにチャネルを暗号化する必要があります。また、双方向認証が必要であり、双方向の認証が必要であり、BIが互いに通信していることを確認する必要があります。TAC CAの証明書ポリシー（CP）によって指定された場合、BIは、先に進む前に、ユーザーにTACを追跡するのに十分な虐待の証拠があると独立して決定します。BIはトークンの署名を検証し、これがそれによって生成されたトークンであり、おそらくAIによって苦しめられたパーティーにリリースされたトークンであることを確認します。次に、BIはトークンから抽出されたユーザーキー値を使用してデータベースを検索します。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.
このプロファイルは、TACに関連するPKCS10 [3]の仕様を改良します。PKCS10に従ってフォーマットされた証明書要求メッセージオブジェクトは、AIに渡されます。
This profile applies the following additional constraints to fields that may appear in a CertificationRequestInfo:
このプロファイルは、認定Requestinfoに表示される可能性のあるフィールドに次の追加の制約を適用します。
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は、この発行者が発行した証明書のコンテキストで一意の件名を生成します。サブジェクトフィールドにAIがすでに発行したサブジェクト名が含まれている場合、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 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].
属性PKCS10 [3]は、キーがOIDであり、値の構造がキーに依存するキー値のペアとして属性フィールドを定義します。属性フィールドには、トークンを保持し、以下に定義するID-Kisa-TAC属性を含める必要があります。属性フィールドには、x509v3証明書拡張機能と、サブスクライバーが証明書に含めたいと思うPKCS9 [7] extensionRrequest属性を含めることもできます。証明書要求の拡張機能のプロファイルは、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を超える証明書管理における証明書要求メッセージをTACSに関連付けるため、証明書要求メッセージを改善します。
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.
このプロファイルは、2種類のPKIリクエストの完全なPKIリクエスト（シンプルまたは完全なPKIリクエスト）を推奨し、PKIリクエストはID-CCT-PKIDATAのecontentTypeを使用してSignedDataにカプセル化する必要があります。
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.
singingalgorithm 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は、この発行者が発行した証明書のコンテキストで一意の件名を生成する必要があります。サブジェクトフィールドにAIがすでに発行したサブジェクト名が含まれている場合、AIは証明書要求を拒否するか、TAC CAのポリシーに応じて生成する仮名を置き換える必要があります。
PublicKey This field MUST be present.
PublicKeyこのフィールドは存在する必要があります。
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.
また、このプロファイルは、証明書要求コントロールに表示される可能性のある制約を改善します。トークンは、atttypeがid-kisa-tacでなければならないアトロバース（certreasteest.controls）に設定されます。
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ユーザーのIDが発見される確率が増加します。したがって、各TAC CAは、TAC証明書の有効性がどれくらいの期間であるかを慎重に検討することをお勧めします。TACの発行の過程で、AIとユーザーは直接対話します。したがって、AIは、ユーザーのIDを明らかにする可能性のある低層情報（例：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- 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.
このドキュメントは、証明書の更新またはRekeyの規定を作成していません。TACユーザーは、リンケージの可能性をさらに減らすために、定期的に新しいTACを取得することをお勧めします。また、低レベルのプロトコル、またはその他のアプリケーション固有の手段によって運ばれる情報を介してユーザーのIDを決定することも可能です。たとえば、ユーザーのIPアドレスを使用して彼を識別することができます。このため、TACを主に匿名でWebサービスにアクセスするために使用することをお勧めします。このドキュメントに記載されているTACアーキテクチャは、S/MIMEで使用するために証明書を使用することはできないことに注意してください。同じ（匿名の）件名を含む2つの証明書（暗号化用と署名用）を発行する規定はないためです。ユーザーがサイトにアクセスし（および自分の身元を隠さない）、サイトがユーザーのブラウザキャッシュに「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.
このアーキテクチャは、ユーザーキーを使用して、TACを対応する実際のユーザーIDにリンクします。userkeyは、ユーザーの実際のアイデンティティを決定するために検査できないことを確認するために、方法で生成されます。ユーザーキーの値は、2つの異なるデータベースで維持されます。BIデータベースは、ユーザーキーを実際のユーザーIDにマッピングし、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 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.
ユーザーとBIまたはAIの間、AIとBIの間、および苦しんでいるパーティーとAIとBIの間のメッセージ交換はすべて、安全なチャネルを利用します。これらのチャネルは、TACリクエストと応答、およびトレースリクエストのトークン値と仮名の開示を防ぐために暗号化されています。チャネルは、AIとBIが互いに通信時にそれぞれのアイデンティティを検証できるようにするために双方向認証されており、ユーザーが通信するときにユーザーがアイデンティティを確認できるように認証されています。双方向認証は、被害者と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が間違ったユーザーキーを苦しんでいるパーティーに戻す機会があり、その結果、間違った実際のユーザーIDに証明書を追跡することになります。これは、この種のどのスキームでも避けられないように見えます。なぜなら、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.
ティム・ポーク（NIST）、ステファン・サンテッソン（ACC--sec.com）、ジム・シェアド（ソアリング・ホーク）、デビッド・A・クーパー（NIST）、ソクラエ・リー、ジョンヒョン・ベク、ソンテパーク（キサ）、テキオン・クォン（セジョン大学）、Junghee Cheon（Seoul National University）、およびYongdae Kim（ミネソタ大学）は、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）プロファイル」、RFC5280、2008年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 5272、2008年6月。
[5] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[5] Schaad、J。、「インターネットX.509公開キーインフラストラクチャ証明書リクエストメッセージフォーマット（CRMF）」、RFC 4211、2005年9月。
[6] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[6] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、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 2985、2000年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] S.ブランド、「公開キーインフラストラクチャとデジタル証明書の再考 - プライバシーの建設」、博士論文、アインドホーフェン工科大学、アインドホーフェン、オランダ、1999年。
[9] D. Chaum, "Blind signature system", CRYPTO '83, Plenum Press, page 153, 1984.
[9] D. Chaum、「ブラインドシグネチャーシステム」、Crypto '83、Plenum Press、Page 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-8、2001としても利用可能です。
[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.ラファエリ、M。レンハード、L。マシー、B。プラットナー、およびD.ハチソン、「仮名eコマースのための建築」、電子商取引のための情報エージェントに関するAISB'01シンポジウム、pp。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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S。、およびC. Adams、「X.509インターネット公開キーインフラオンライン証明書ステータスプロトコル」、RFC 2560、1999年6月。
[14] Philip MacKenzie and Michael K. Reiter, "Two-Party Generation of DSA Signature", Crypto 2001.
[14] フィリップ・マッケンジーとマイケル・K・ライター、「DSA署名の2つのパーティ世代」、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] Shaohua Tang、「Computational Intelligence and Security」、CIS 2005、Part II、Springer、pp。186-191、2005の「単純な秘密共有に基づく単純なしきい値RSA署名スキーム」、「Computational Intelligence and Security」、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] Taekyoung Kwon、Jung Hee Cheon、Yongdae Kim、Jae-Il Lee、「PKISにおけるプライバシー保護：Authority of-authority Approach」、「Information Security Applications」、Wisa 2006、Springer、pp。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、「The Transport Layer Security（TLS）Protocolバージョン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.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1証明書処理」、RFC 3850、2004年7月。
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.
--
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.
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 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
Timeout ::= GeneralizedTime
BlinedCertificateHash ::= OCTET STRING
PartiallySignedCertificateHash ::= OCTET STRING
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 }
Token ::= ContentInfo
TokenandBlindHash ::= ContentInfo
TokenandPartiallySignedCertificateHash ::= ContentInfo
id-KISA OBJECT IDENTIFIER ::= {iso(1) member-body(2) korea(410)
kisa(200004)}
id-npki OBJECT IDENTIFIER ::= {id-KISA 10}
id-attribute OBJECT IDENTIFIER ::= {id-npki 1}
id-kisa-tac OBJECT IDENTIFIER ::= {id-attribute 1}
id-kisa-tac-token OBJECT IDENTIFIER ::= { id-kisa-tac 1}
id-kisa-tac-tokenandblindbash OBJECT IDENTIFIER ::= { id-kisa-tac 2}
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.
TACメッセージは、ユーザーとBIまたはAIの間、AIとBIの間、および苦しんでいるパーティーとAIとBIの間で安全なチャネルを利用して、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の間のチャネルは、ユーザーが彼らと通信するときにアイデンティティを確認できるようにするために一方向認証されています。
User BI or AI
ユーザーBIまたはAI
ClientHello -------->
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
bi ai
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
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トークンは署名されたDATAオブジェクトの一種です。CMSオブジェクトの一般的な形式は次のとおりです。
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
As a TAC is a signed-data object, it uses the corresponding OID, 1.2.840.113549.1.1.2.
TACは署名されたDATAオブジェクトであるため、対応する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があります。
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
The elements of the signed-data content type are as follows:
署名されたDATAコンテンツタイプの要素は次のとおりです。
Version The version is the syntax version number. It MUST be 3, corresponding to the signerInfo structure having version number 3.
バージョンバージョンは構文バージョン番号です。バージョン番号3を持つSignerinfo構造に対応する3でなければなりません。
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].
証明書証明書要素を含める必要があり、この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.
SignerInfosこの要素は、付録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 }
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トークンのコンテンツタイプはID-DATAであり、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トークンの内容は、userkeyとタイムアウトのderエンコードされたシーケンスです。
SignerInfo is defined under CMS as:
SignerInfoは、CMSで次のように定義されています。
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.
バージョンバージョン番号は、SIDのSubjectKeyIdentifierの選択に対応する3である必要があります。
sid The sid is defined as:
sid sidは次のように定義されています。
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
For a TAC Token, the sid MUST be a SubjectKeyIdentifier.
TACトークンの場合、SIDは件名のIdentideidifierでなければなりません。
digestAlgorithm This field specifies digest Algorithms.
Digestalgorithmこのフィールドは、ダイジェストアルゴリズムを指定します。
signedAttrs The signedAttr element MUST be omitted.
signedattrs signedattr要素は省略する必要があります。
SignatureAlgorithm This field specifies the signature Algorithm.
SignatureAlgorithmこのフィールドは、署名アルゴリズムを指定します。
Signature The signature value is defined as:
署名署名値は次のように定義されます。
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
Sanghwan Park Korea Internet＆Security Agency 78、Garak-Dong、Songpa-Gu、Seoul、Korea Email：shpark@kisa.or.kr
Haeryong Park Korea Internet & Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, Korea EMail: hrpark@kisa.or.kr
Haeryong Park Korea Internet＆Security Agency 78、Garak-Dong、Songpa-Gu、Seoul、Korea Email：hrpark@kisa.or.kr
YooJae Won Korea Internet & Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, Korea EMail: yjwon@kisa.or.kr
ユジェは韓国インターネット＆セキュリティエージェンシー78、ガラックドン、ソンパグ、ソウル、韓国のメール：yjwon@kisa.or.kr
JaeIl Lee Korea Internet & Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, Korea EMail: jilee@kisa.or.kr
Jaeil Lee Korea Internet＆Security Agency 78、Garak-Dong、Songpa-gu、Seoul、Koreaメール：jilee@kisa.or.kr
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 EMail: kent@bbn.com
Stephen Kent BBN Technologies 10 Moulton Street Cambridge、MA 02138メール：kent@bbn.com