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。このモデルの下で発行されるエンドエンティティ（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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
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と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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）または登録局（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は、典型的には、標準的な方法で、（証明書に対応する公開鍵の）秘密鍵の所有者を識別するのに役立ちます。公開鍵、識別、および関連情報509で指定されるようにCAとして作用する実体によって署名されている[11]、インターネットで使用するためのプロファイルとして[2]。過去十年間の間に、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は、依拠当事者に開示されている（例えば、ウェブサイトまたは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のいずれかは、原則的に、一方的に実際のユーザー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.
この文書で説明するアーキテクチャ、構文、およびプロトコルの規則は、匿名証明書が発行され、プライバシーと、それが発行された人に個別に匿名証明書をマッピングするための条件付き能力との間のバランスを提供した方法で、既存の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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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は、（インターネットPKI規格と整合条件付きで追跡可能になる[9]、[8]従来の変名証明書と区別され次のシナリオで示すように、ときに追加の制約が課されます。
- 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は、本当の身元を確認せずに匿名証明書を発行した場合、それは証明書が虐待に匿名性を発行されたユーザーは、それが提供している場合不十分な償還請求を提供し、追跡不可能です。 （でも該当ユーザーへの匿名証明書を追跡する能力なしに、証明書は常に取り消すことができますが、これは虐待に十分な応答ではないかもしれません。）
- 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は、匿名証明書を発行しますが、本当の身元を確認し、そのIDの記録を維持した場合、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.
ブラインド発行者（BI）および匿名発行者（AI）：TACは、エンドエンティティ（EE）スプリット責任モードで動作するエンティティのペアによって発行された証明書です。ペアは、例えば、それらは、単一の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は、シリアル番号などの割り当てはTACの発行を行うために秘密鍵証明-の所持（POP）のチェック、それによって発行されたすべての証明書の中で名前一意性チェックを含め、CAに共通する機能を実行します、AIは、共同TACの署名を作成するために、安全なチャネルを介して、BIと相互作用し、そしてユーザに署名された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 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は、地理的に離れた施設で異なる組織によって運営することができ、かつ異なるスタッフによって管理されます。その結果、1は、匿名性を確保するための手続きのセキュリティコントロールにのみ依存しているモノリシック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のために定義されています。これを達成する方法の詳細については、問題のアルゴリズムに依存し、したがって、ここでは説明されていません。読者はRSAしきい値署名を実装するための手順が記載されている[15]と呼ばれます。 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に署名するために使用される秘密鍵は正確に2株、BIが保有する1とAIが保有する1に分割されています。どちらの株式は、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党にそれを返します。最初のパーティは、例えば、基礎となるデータにハッシュ値を署名を生成するために、それは最初の場所でランダムな値が適用された暗号を反転します。
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).
これらの証明書は、（BIおよびAIによって形成される）CAを表し、他の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を必要とし、レコードの（データベース）のキーとなるUSERキーと呼ばれます。 USERキー値は、その値からユーザーの本当の身元を推測する（AIを含む）任意の外部エンティティを許可する方法で生成してはなりません。 （ユーザ名は、USERキー値を生成する一方向ハッシュアルゴリズムへの入力として使用される場合、追加のランダムデータは、単純な推測攻撃を防ぐための入力として使用されなければならない。）USERキーに関連付けられているこのデータベースで有効期限です。有効期限は、一部の取引所でのセッション・レベルのリプレイ攻撃を拒否するために、ユーザーが開始した場合、ガベージコレクトデータベースレコードに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.)
USERキーがランダムまたは擬似ランダムな値であることが推奨されます。 BIは、外部のパーティにUSERキーを渡し、または外部パーティ（例えば、AI）からUSERキーを受け入れ、値がデジタル署名されたCMSオブジェクトに埋め込まれたタイムスタンプを伴って、トークンと呼ばれるたびに前述。トークンに署名はBIによって生成されます。 （使用された証明書は、CMSでの使用に適しちょうど証明書であり、そしてTACを検証するために使用される分割鍵証明書ではないことに注意してください。）
The following ASN.1 syntax represents the UserKey and an expiration time:
次のASN.1構文は、USERキーと有効期限を表します。
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の値は、グリニッジ標準時（ズールー）で発現されなければならない秒（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 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で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.
トークンは、2つの目的があります。 TACの発行時には、トークンはAIへの要求は、BIに登録されたユーザから送信されました（したがって、使用者の正体と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.
トークンは、e-コンテンツ（EncapsulatedContentInfo）はUSERキーからなり、配列でBI、によって署名されたID-吉舎-TACトークンとのSignedData CMSのSignedDataのオブジェクトを保持しているコンテンツ[6]のcontentTypeのと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'
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は、プロファイル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.
ユーザは、[4] [3]又はCMC PKCS10、例えば、標準的な形式の証明書要求を作成します。証明書のサブジェクトフィールドは、ユーザによって生成された仮名が含まれています。 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.
証明書要求を構築した後、ユーザーが安全なチャネルを経由して、AIに、ステップ2からのトークンと一緒に、それを送信します。このチャネルは暗号化されなければならないと一方通行はつまり、ユーザーはそれが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-吉舎-TACする必要があります（CertificationRequestInfo.attributes）の属性として実施されます。トークンはATTRTYPEがCMC [4]の形式におけるID-吉舎-TACでなければなりませんattrValues（証明書要求コントロール）に設定されています。 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はどちらもキーがこれまでに公開されている公開鍵暗号ペアからキーを使用してハッシュ値をブラインド。このペアから他のキーは「非盲」に署名したハッシュ値にステップ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は、双方向認証され、暗号化されたチャネルを介して、BIにTokenandBlindHashのCMS ContentInfoオブジェクトを送信します。双方向認証と暗号化は、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は、e-コンテンツ（EncapsulatedContentInfo）はトークンからなる配列であるAI、によって署名されたID-吉舎-TAC-tokenandblindhashとのSignedData CMSのSignedDataのオブジェクトを保持しているコンテンツ[6]のcontentTypeのとCMS ContentInfo、ありますそして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'
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 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は、トークンからUSERキー値が存在することを確認するために、そのデータベースをチェックし、トークンは、以前に証明書の発行を許可するために使用されていないこと。
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は盲目証明書のハッシュを署名するしきい値秘密署名鍵のシェアを使用し、バックAIへのCMSのSignedDataを返します。 SignedDataのe-コンテンツは、トークンとPartiallySignedCertificateHashからなる配列です。
The following ASN.1 syntax represents the Token and PartiallySignedCertificateHash:
次のASN.1構文は、トークンとPartiallySignedCertificateHashを表します。
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からの（e-コンテンツトークンとPartiallySignedCertificateHashからなる配列である）TokenandBlindHashのトークン値です。
PartiallySignedCertificateHash is the signature value generated by BI's share of the threshold private signature key on BlindedCertificateHash from Step 4.
PartiallySignedCertificateHashは、ステップ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.
TokenandPartiallySignedCertificateHashは、ID-吉舎-tokenandpartially-TACおよびe-コンテンツ（EncapsulatedContentInfo）はトークンからなる配列であり、BI、によって署名のSignedData CMSのSignedDataのオブジェクトを保持しているコンテンツ[6]のcontentTypeのとCMS ContentInfoでありますそして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'
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は、プロファイル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.
TokenandPartiallySignedCertificateHashを受信すると、AIは、BIによって生成され、PartiallySignedCertificateHash上の署名を検証して、BIへの未処理の要求のリストに対してトークンと一致します。 AI次いで「非ブラインド」blindHashValue、これは部分的に署名された証明書のハッシュを明らかにするステップ4で用いられる鍵ペアから他のキーを使用して。 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.
ユーザは（証明書に主要な用法と一致し、拡張キー使用法（EKU）の値）X.509証明書を利用する任意のPKI対応アプリケーションまたはプロトコルを有する証明書を使用してもよいです。ユーザーが証明書発行処理の遅れに対応するために準備されるべきであることに注意してください。例えば、ユーザはステップ3の終わりに証明書要求を送信した後、ユーザーとAIとの間の接続は、いつか失敗する可能性があり、この問題が発生した場合は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には、そのユーザーの身元を追跡することが可能です。ユーザの真の識別にTACをマッピングする4段階のプロセスは、以下の説明及び図2に示されています。
C +---------------+
+<-------->| Blind |
| D | Issuer (BI)|
| +---------------+
+---------+ |
| Relying |<---------->|
| Party | |
+---------+ |
| A +----------------+
+<-------->| Anonymity |
B | Issuer (AI) |
+----------------+
Figure 2. Revealing a TAC User's Real Identity
TACのユーザーの正体を明らかにし、図2
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ための第二の証明書を作成します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証明書はcRLSignがKeyUsage拡張ではなくKeyCertSignがビットにビットを設定しています。それは一方的にCRLを発行できるように、この証明書の秘密鍵は、AIによって開催されます。
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（識別名）は、CRL発行者は、TACの発行者と同じエンティティであるという考えを補強CA証明書、両方で同じになり、このCRLは、間接CRLないこと。 CRL発行者は、すべての証明書自体を発行しないので、何の可能シリアル番号の競合はありません。これは、TAC CA証明書に基づいて発行されたCA証明書のみとなります（したがって、それはBIとAIが共同で署名されます）。私たちは、それはあまりにもBIとAIによって署名される必要があるとして、このCA証明書のCRLは、同様に長寿命にすることをお勧めします。各EE TAC証明書は、依拠当事者のみCRL CAをカバーCRL対このCRLをチェックするために知っていることを確認するために、このCAによって発行されたCRLを指すCRL配布ポイントを含まなければなりません（AIがのTACの失効ステータスを伝えるために、[13]オンライン証明書状態プロトコル（OCSP）を使用している場合は、同等の手順が採用されている。）それは、後に失効が保証されていなかったと判断された場合は、新しい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は、発行処理（ステップ5と上記6）の間にAIとBIの間に渡されたトークンを見つけるために、TACにシリアル番号に基づいて、例えば、そのデータベースを検索します。 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は、トークンから抽出されたUSERキー値を使用してデータベースを検索します。 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:
このプロファイルは、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は、この発行者によって発行された証明書のコンテキスト内で一意であるサブジェクト名を生成します。件名フィールドが既に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
PKCS10 [3]キーをOIDと値の構造は、キーに依存されているキーと値のペアとして属性フィールドを定義する属性。属性フィールドは、トークンを保持し、以下に定義されたID-吉舎-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.
このプロファイルは、彼らがのTACに関連して、[4] CMCでCMS上で証明書管理で証明書要求メッセージをリファイン。
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要求は、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 1としてのSerialNumber [5]は、このフィールドは、CAによって割り当てられ、このプロファイルでは省略されなければなりません。
SigningAlgorithm As per CRMF [5], this field is assigned by the CA and MUST be omitted in this profile.
CRMF 1としてSigningAlgorithm [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.
このプロファイルは、証明書要求コントロールに表示されることの制約を洗練：トークンがATTRTYPEがID-吉舎-TACする必要があります（CertRequest.controlsで）attrValuesに設定されています。
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は、TAC証明書の有効期間はどうあるべきか、長い慎重に検討CAことをお勧めします。 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- 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.
このドキュメントでは、証明書の更新や再入力のための規定を行いません。私たちは、TACのユーザーがさらに連携の可能性を低減するために、定期的に新しいのTACを取得をお勧めします。また、低級レベルのプロトコル、または他の、アプリケーション固有の手段によって搬送される情報を介してユーザのアイデンティティを決定することが可能であってもよいです。例えば、利用者のIPアドレスは、彼を識別するために使用される可能性があります。このような理由から、私たちは、TACが匿名でWebサービスにアクセスするために主に使用されることをお勧めします。同じ（匿名）サブジェクト名が含まれている2つの証明書（暗号化と署名のいずれかの1）を発行する規定はないため、この文書で説明したTACアーキテクチャは、S / MIMEを使用するための証明書を使用できないことに注意してください。ユーザーがサイト（および彼の身元を隠すしない）、サイトの預金、ユーザーのブラウザのキャッシュに「クッキー」を訪問し、ユーザーが後でサイトを訪問し、匿名性の推定で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が異なる寿命の証明書を提供している場合、それは不当に利用者の匿名性を損なわないように、AIにBIからこの情報を通信する必要があります。
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.
このアーキテクチャは、対応する実ユーザIDにTACをリンクするUSERキーを使用しています。 USERキーは、ユーザーの本当のアイデンティティを決定するために検査することができないことを確実にするための方法で生成されます。 BIデータベースは、実際のユーザーIDにUSERキーをマッピングし、AIのデータベースは、USERキーにTACをマップ：USERキー値は、2つの異なるデータベースで維持されています。 USERキーは常にトークン、署名されたデータオブジェクトで運ばれます。トークンは、BIは、USERキーの値を推測に基づいて攻撃を防ぐために、その信憑性を検証できるようにするために署名されています。トークンはまた、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は、彼らが採用しきい値暗号方式は、キー分割が行われている方法に基づいて、当事者のいずれかに利点を提供しないことを保証しなければならない。）ブラインド署名が機能の分離を維持するために、しきい値暗号で使用され、すなわち、 AIによって発行されたTACのハッシュ値を学習からBIを防ぐために。
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.
AIとBIの間、および被害の当事者とAIとBIのすべての間でユーザーおよびBIやAIの間のメッセージ交換は、安全なチャンネルを利用します。これらのチャネルは、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に証明書をトレースになり、被害当事者に間違ったUSERキーを返却する機会があります。 BIによって維持されるデータベースは、TACにUSERキーに関連するすべての情報を意図的に無知であるので、これは、この種のいずれかの方式では避けられないように見えます。
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対象がデータを保持し、このの妥協の結果として、彼のアイデンティティの不正使用の可能性を測るのに役立ちます。また、実ユーザIDに証明書を結ぶデータが破壊される前に、疑惑の乱用は、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）、ステファンSantesson（ACC-sec.com）、ジムSchaad（ソアリングホーク）、デビッド・A・クーパー（NIST）、SeokLaeリー、ジョンヒョンペク、SoonTaeパーク（KISA）、Taekyoungクォン（世宗大学）、 JungHeeチョン（ソウル大学）、およびYongDaeキム（ミネソタ大学）が大幅にTACの概念に動作するように貢献していると、セキュリティ上の問題を特定しました。彼らのコメントは、文書の成熟度を高めました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、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.マイヤーズ、 "CMSオーバー証明書の管理（CMC）"、RFC 5272、2008年6月。
[5] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
Schaad、J.、 "インターネットX.509公開鍵暗号基盤証明書要求メッセージ・フォーマット（CRMF）"、RFC 4211、2005年9月[5]。
[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、プレナムプレス、ページ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、ISO / IEC 9594から8、2001として2000年3月にも利用できます。
[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.プラットナー、及びD.ハチソン、 "ペンネーム電子商取引のためのアーキテクチャ"、電子商取引の情報エージェント、PPに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.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[14] Philip MacKenzie and Michael K. Reiter, "Two-Party Generation of DSA Signature", Crypto 2001.
[14]フィリップ・マッケンジーとマイケルK.ライター、「二大政党世代DSAの署名」、暗号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唐、 "知能とセキュリティ"、CIS 2005、パートII、スプリンガー、頁186-191、2005年に "簡易秘密の共有に基づく単純なしきい値のRSA署名方式"、。
[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クォン、ユング喜チョン、Yongdaeキム、在イル・リー、「プライバシー保護の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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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.、エド。、RFC 3850、2004年7月、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.1証明書の取り扱い"。
Appendix A. Traceable Anonymous Certificate ASN.1 Modules
付録A.トレーサブル匿名証明書ASN.1モジュール
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. --
- - 著作権（C）2009 IETF信託として特定の人物 - コードの作者。全著作権所有。 - - 以下のことを提供変更なし、許可されている - - 再配布およびまたはとともに、ソースおよびバイナリ形式での使用条件が満たされる： - - - ソースコードの再配布は、上記保持しなければならない - 著作権表示を、この条件のリストおよび以下 - 免責事項。 - - - 著作権表示、条件および以下のリスト - - ドキュメントの免責事項及び/又は他の材料提供 - 分布とバイナリ形式で再配布は、上記を再現しなければなりません。 - - - インターネット協会、IETFやIETFトラストの名称、またどちらも - 特定なしに、本ソフトウェアから派生した製品の宣伝 - - 事前の書面による許可の特定の貢献者の名前は、推奨またはするために使用することができます。 - - - - 「AS IS」協力者、いかなる明示または黙示の保証、 - - 含むがこれらに限定されない、の黙示の保証 - 商品性およびフィットネスの本ソフトウェアは著作権所有BY提供され特定の目的があります - 放棄。 NO EVENTの著作権所有者または貢献者はないものと - いかなる直接的、間接的、間接的、偶発的、特別、 - 例示的、または間接的損害（INCLUDINGは、限定されるものではない - には、代替商品またはサービスの調達、使用の損失、 - DATA、事業の中断など）原因で生じたON - OUTを使用 - （ANY WAYで発生する）過失を含むもしくはその他不法行為 - 責任、それが契約、厳格責任のいずれか理論そのような損害の可能性 - 本ソフトウェアの、たとえ性について知らさ。 - - ASN.1モジュールのこのバージョンはRFC 5636の一部です。 - 完全な適法な通知についてはRFC自体を参照してください。 -
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.
- すべてのエクスポート - 他のASN.1モジュールで使用 - このモジュールで定義されたタイプと値はのためにエクスポートされます。他のアプリケーションが使用することができます - それらを独自の目的のために。
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) }
- RFC 3280からの輸入[PROFILE]、付録A.1のAlgorithmIdentifier、証明書、CertificateListの、CertificateSerialNumber、名前PKIX1Explicit88 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（FROM 5）PKIX（7）MOD（0）pkix1、明示的な（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)}
- CryptographicMessageSyntax2004 FROM CMS ContentInfo、のSignedDataから輸入{ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（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
終わり
Appendix B. TAC Message Exchanges over Transport Layer Security
トランスポート層セキュリティオーバー付録B. TACのメッセージ交換
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のハンドシェイク部分は、Exchangeの各タイプを保護するために使用する方法について説明します。具体的な暗号スイートは、ここでの使用のために指定されていないことに注意してください。一般的にそうであるようにスイートの選択は、クライアントとサーバー次第です。
B.1. Message Exchanges between a User and the BI or the AI
B.1。ユーザーおよびBIやAIの間でのメッセージ交換
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
ユーザ及びBI又はAIとの間の図3 TACメッセージ交換
B.2. Message Exchanges between the BI and the AI
B.2。 BIとAIの間でのメッセージ交換
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がそれぞれのIDを確認できるように認証されます。
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
BIとAIとの間の図4 TACメッセージ交換
B.3. Message Exchanges between the Aggrieved Party and the AI or the BI
B.3。被害を受けた党とAIやBIの間のメッセージ交換
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
被害を受けた党とBIやAIの間に図5. TACのメッセージ交換
Appendix C. Cryptographic Message Syntax Profile for TAC Token
TACトークン付録C.暗号メッセージ構文のプロフィール
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 }
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を使用します。
C.1. Signed-Data Content Type
C.1。署名付き-データコンテンツの種類
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:
次のように署名されたデータのコンテンツタイプの要素は次のとおりです。
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.
CRLは、CRLの要素を省略しなければなりません。
signerInfos This element is defined in Appendix C.1.2.
signerInfosこの要素は、付録C.1.2に定義されています。
C.1.1. encapContentInfo
C.1.1。 encapContentInfo
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.
TACトークン用のeContentTypeザの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.
e-コンテンツTACトークンの内容は、USERキーとタイムアウトのDERでエンコードされたシーケンスです。
C.1.2. signerInfos
C.1.2。 signerInfos
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はSubjectKeyIdentifierでなければなりません。
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パーク韓国インターネット振興院78、カラク洞、市松坡区ソウル、韓国の電子メール：shpark@kisa.or.kr
Haeryong Park Korea Internet & Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, Korea EMail: hrpark@kisa.or.kr
Haeryongパーク韓国インターネット振興院78、カラク洞、市松坡区ソウル、韓国の電子メール：hrpark@kisa.or.kr
YooJae Won Korea Internet & Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, Korea EMail: yjwon@kisa.or.kr
YooJaeウォン韓国インターネット振興院78、カラク洞、市松坡区ソウル、韓国の電子メール：yjwon@kisa.or.kr
JaeIl Lee Korea Internet & Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, Korea EMail: jilee@kisa.or.kr
JaeIlリー韓国インターネット振興院78、カラク洞、市松坡区ソウル、韓国の電子メール：jilee@kisa.or.kr
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 EMail: kent@bbn.com
スティーブン・ケントBBNテクノロジーズ10モールトンストリートケンブリッジ、MA 02138 Eメール：kent@bbn.com