[要約] RFC 4683は、インターネットX.509公開鍵基盤の主体識別方法（SIM）に関する規格であり、主体の識別方法を定義しています。その目的は、主体の識別を効率的かつ信頼性の高い方法で行うことです。
Network Working Group J. Park
Request for Comments: 4683 J. Lee
Category: Standards Track H. Lee
KISA
S. Park
BCQRE
T. Polk
NIST
October 2006
Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
インターネットX.509公開キーインフラストラクチャ件名識別方法（SIM）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate.
このドキュメントでは、証明書の主題に依存している識別子を含めるためのサブジェクト識別方法（SIM）を定義します。
The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier.
SIMは、特定の証明書の主題が特定の機密識別子に対応する人物であるかどうかを判断するために、当事者に依存することで使用できるオプションの機能です。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Key Words ..................................................5
2. Symbols .........................................................6
3. Requirements ....................................................6
3.1. Security Requirements ......................................6
3.2. Usability Requirements .....................................7
3.3. Solution ...................................................7
4. Procedures ......................................................8
4.1. SII and SIItype ............................................8
4.2. User Chosen Password .......................................9
4.3. Random Number Generation ...................................9
4.4. Generation of SIM ..........................................9
4.5. Encryption of PEPSI .......................................10
4.6. Certification Request .....................................10
4.7. Certification .............................................11
5. Definition .....................................................11
5.1. SIM Syntax ................................................11
5.2. PEPSI .....................................................12
5.3. Encrypted PEPSI ...........................................12
6. Example Usage of SIM ...........................................13
7. Name Constraints ...............................................13
8. Security Considerations ........................................14
9. Acknowledgements ...............................................15
10. IANA Considerations ...........................................15
11. References ....................................................15
11.1. Normative References .....................................15
11.2. Informative References ...................................15
Appendix A. "Compilable" ASN.1 Module, 1988 Syntax ...............18
A Certification Authority (CA) issues X.509 public key certificates to bind a public key to a subject. The subject is specified through one or more subject names in the "subject" or "subjectAltName" fields of a certificate. The "subject" field contains a hierarchically structured distinguished name. The "subjectAltName field" may contain an electronic mail address, IP address, or other name forms that correspond to the subject.
認定機関（CA）は、X.509公開鍵証明書を発行して、公開鍵を主題に結合します。主題は、証明書の「件名」または「subjectaltname」フィールドの1つ以上のサブジェクト名を介して指定されます。「サブジェクト」フィールドには、階層的に構造化された識別名が含まれています。「subjectaltnameフィールド」には、電子メールアドレス、IPアドレス、またはサブジェクトに対応するその他の名前フォームが含まれる場合があります。
For each particular CA, a subject name corresponds to a unique person, device, group, or role. The CA will not knowingly issue certificates to multiple entities under the same subject name. That is, for a particular certificate issuer, all currently valid certificates asserting the same subject name(s) are bound to the same entity.
特定のCAごとに、サブジェクト名は一意の人、デバイス、グループ、または役割に対応しています。CAは、同じ件名名の下で複数のエンティティに証明書を故意に発行しません。つまり、特定の証明書発行者の場合、同じサブジェクト名を主張するすべての有効な証明書が同じエンティティに拘束されます。
Where the subject is a person, the name that is specified in the subject field of the certificate may reflect the name of the individual and affiliated entities (e.g., their corporate affiliation). In reality, however, there are individuals or corporations that have the same or similar names. It may be difficult for a relying party (e.g., a person or application) to associate the certificate with a specific person or organization based solely on the subject name. This ambiguity presents a problem for many applications.
被験者が個人である場合、証明書の件名フィールドで指定されている名前は、個人および提携エンティティの名前（たとえば、企業の所属）を反映する場合があります。しかし、実際には、同じまたは類似した名前を持つ個人または企業があります。頼る当事者（例：個人または申請）が証明書を件名のみに基づいて特定の個人または組織に関連付けることは困難かもしれません。このあいまいさは、多くのアプリケーションに問題を提示します。
In some cases, applications or relying parties need to ensure that the subject of certificates issued by different CAs are in fact the same entity. This requirement may be met by including a "permanent identifier" in all certificates issued to the same subject, which is unique across multiple CAs. By comparing the "permanent identifier", the relying party may identify certificates from different CAs that are bound to the same subject. This solution is defined in [RFC 4043].
場合によっては、アプリケーションまたは頼る当事者は、異なるCAによって発行された証明書の対象が実際に同じエンティティであることを確認する必要があります。この要件は、同じ主題に発行されたすべての証明書に「永久識別子」を含めることで満たすことができます。これは、複数のCAにわたって一意です。「永久識別子」を比較することにより、頼る当事者は、同じ主題に拘束されている異なるCAからの証明書を特定することができます。このソリューションは[RFC 4043]で定義されています。
In many cases, a person's or corporation's identifier (e.g., a Social Security Number) is regarded as sensitive, private, or personal data. Such an identifier cannot simply be included as part of the subject field, since its disclosure may lead to misuse. Therefore, privacy-sensitive identifiers of this sort should not be included in certificates in plaintext form.
多くの場合、個人または企業の識別子（たとえば、社会保障番号）は、敏感な、プライベート、または個人データと見なされています。このような識別子は、その開示が誤用につながる可能性があるため、主題分野の一部として単純に含めることはできません。したがって、この種のプライバシーに敏感な識別子をプレーンテキスト形式の証明書に含めるべきではありません。
On the other hand, such an identifier is not actually a secret. People choose to disclose these identifiers for certain classes of transactions. For example, a person may disclose a Social Security Number to open a bank account or obtain a loan. This is typically corroborated by presenting physical credentials (e.g., a driver's license) that confirm the person's name or address.
一方、そのような識別子は実際には秘密ではありません。人々は、特定のクラスのトランザクションについてこれらの識別子を開示することを選択します。たとえば、人は社会保障番号を開示して銀行口座を開設したり、ローンを取得したりする場合があります。これは通常、人の名前または住所を確認する物理的な資格情報（運転免許証など）を提示することによって裏付けられます。
To support such applications in an online environment, relying parties need to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. Ideally, applications would leverage the applicants' electronic credential (e.g., the X.509 public key certificate) to corroborate this identifier, but the subject field of a certificate often does not provide sufficient information.
オンライン環境でそのようなアプリケーションをサポートするには、当事者に依存することで、特定の証明書の主題が特定の機密識別子に対応する人であるかどうかを判断する必要があります。理想的には、アプリケーションは、申請者の電子資格（X.509公開証明書など）をこの識別子を裏付けて裏付けるために活用しますが、証明書の主題フィールドは十分な情報を提供しないことがよくあります。
To fulfill these demands, this specification defines the Subject Identification Method (SIM) and the Privacy-Enhanced Protected Subject Information (PEPSI) format for including a privacy sensitive identifier in a certificate. Although other solutions for binding privacy-sensitive identifiers to a certificate could be developed, the method specified in this document has especially attractive properties. This specification extends common PKI practices and mechanisms to allow privacy-sensitive identifiers to be included in the certificate as well. The SIM mechanism also permits the subject to control exposure of the sensitive identifier; when the subject chooses to expose the sensitive identifier, relying parties can verify the binding. Specifically:
これらの要求を満たすために、この仕様では、証明書にプライバシーに敏感な識別子を含めるための主題識別方法（SIM）とプライバシー強化された保護されたサブジェクト情報（PEPSI）形式を定義します。プライバシーに敏感な識別子を証明書に拘束する他のソリューションを開発することができますが、このドキュメントで指定されている方法には、特に魅力的なプロパティがあります。この仕様は、一般的なPKIプラクティスとメカニズムを拡張して、プライバシーに敏感な識別子も証明書に含めることができます。SIMメカニズムにより、被験者は敏感な識別子の曝露を制御することもできます。被験者が機密識別子を公開することを選択したとき、頼る当事者はバインディングを検証できます。具体的には：
(1) A Public Key Infrastructure (PKI) depends upon a trusted third party -- the CA -- to bind one or more identities to a public key. Traditional PKI implementations bind X.501 distinguished names to the public key, but identity may also be specified in terms of RFC 822 addresses or DNS names. The SIM specification allows the same trusted third party -- the CA -- that binds a name to the public key to include a privacy-sensitive identifier in the certificate as well. Since the relying party (RP) already trusts the CA to issue certificates, it is a simple extension to cover verification and binding of a sensitive identifier as well. This binding could be established separately, by another trusted third party, but this would complicate the infrastructure.
(1) 公開キーインフラストラクチャ（PKI）は、1つ以上のアイデンティティを公開キーに結合するために、信頼できる第三者（CA）に依存します。従来のPKI実装は、X.501の識別名を公開鍵に結合しますが、IDはRFC 822アドレスまたはDNS名の観点からも指定される場合があります。SIM仕様により、同じ信頼できるサードパーティ（CA）が公開キーに結合して、証明書にプライバシーに敏感な識別子も含めることができます。頼る当事者（RP）はすでにCAが証明書を発行することを信頼しているため、機密識別子の検証と拘束力もカバーするための簡単な拡張機能です。この拘束力は、別の信頼できる第三者によって個別に確立できますが、これはインフラストラクチャを複雑にするでしょう。
(2) This specification leverages standard PKI extensions to achieve new functional goals with a minimum of new code. This specification encodes the sensitive identifier in the otherName field in the alternative subject name extension. Since otherName field is widely used, this solution leverages a certificate field that is often populated and processed. (For example, smart card logon implementations generally rely upon names encoded in this field.) Whereas implementations of this specification will require some SIM-specific code, an alternative format would increase cost without enhancing security. In addition, that has no impact on implementations that do not process sensitive identifiers.
(2) この仕様は、標準のPKI拡張機能を活用して、最小限の新しいコードで新しい機能目標を達成します。この仕様は、代替件名名拡張機能の他の名前フィールドの敏感な識別子をエンコードします。otherNameフィールドは広く使用されているため、このソリューションは、多くの場合、多くの場合、処理される証明書フィールドを活用します。（たとえば、スマートカードログオンの実装は、一般にこのフィールドでエンコードされた名前に依存しています。）この仕様の実装には、SIM固有のコードが必要になりますが、代替形式はセキュリティを強化することなくコストを増加させます。さらに、それは機密性のある識別子を処理しない実装に影響を与えません。
(3) By explicitly binding the public key to the identifier, this specification allows the relying party to confirm the claimant's identifier and confirm that the claimant is the subject of that identifier. That is, proof of possession of the private key confirms that the claimant is the same person whose identity was confirmed by the PKI (CA or RA, depending upon the architecture).
(3) 公開鍵を識別子に明示的に拘束することにより、この仕様により、頼る当事者は請求者の識別子を確認し、請求者がその識別子の対象であることを確認できます。つまり、秘密鍵の所持の証明は、請求者がPKIによってアイデンティティが確認されたのと同じ人物であることを確認します（アーキテクチャに応じてCAまたはRA）。
To achieve the same goal in a separate message (e.g., a signed and encrypted Secure MIME (S/MIME) object), the message would need to be bound to the certificate or an identity in the certificate (e.g., the X.501 distinguished name). The former solution is problematic, since certificates expire. The latter solution may cause problems if names are ever reused in the infrastructure. An explicit binding in the certificate is a simpler solution, and more reliable.
別のメッセージで同じ目標を達成するには（署名済みおよび暗号化されたセキュアMIME（S/MIME）オブジェクトなど）、メッセージを証明書または証明書のIDにバインドする必要があります（例：X.501の著名な識別名前）。証明書が期限切れになるため、前者のソリューションには問題があります。後者のソリューションは、インフラストラクチャで名前が再利用される場合、問題を引き起こす可能性があります。証明書の明示的なバインディングは、より単純なソリューションであり、より信頼性が高くなります。
(4) This specification allows the subject of the privacy-sensitive identifier to control the distribution and level of security applied to the identifier. The identifier is only disclosed when the subject chooses to disclose it, even if the certificate is posted in a public directory. By choosing a strong password, the subject can ensure that the identifier is protected against brute force attacks. This specification permits subjects to selectively disclose an identifier where they deem it appropriate, which is consistent with common use of such identifiers.
(4) この仕様により、プライバシーに敏感な識別子の主題は、識別子に適用されるセキュリティの分布とレベルを制御できます。識別子は、証明書がパブリックディレクトリに投稿されていても、被験者が開示することを選択した場合にのみ開示されます。強力なパスワードを選択することにより、被験者は識別子がブルートフォース攻撃から保護されていることを確認できます。この仕様により、被験者は、適切だと判断した識別子を選択的に開示することができます。これは、そのような識別子の一般的な使用と一致しています。
(5) Certificates that contain a sensitive identifier may still be used to support other applications. A party that obtains a certificate containing a sensitive identifier, but to whom the subject does not choose to disclose the identifier, must perform a brute force attack to obtain the identifier. By selecting a strong hash algorithm, this attack becomes computationally infeasible. Moreover, when certificates include privacy-sensitive identifiers as described in this specification, each certificate must be attacked separately. Finally, the subjects can use this mechanism to prove they possess a certificate containing a particular type of identifier without actually disclosing it to the relying party.
(5) 機密識別子を含む証明書は、他のアプリケーションをサポートするために使用される場合があります。機密識別子を含む証明書を取得するが、被験者が識別子を開示することを選択しない証明書を取得する当事者は、識別子を取得するためにブルートフォース攻撃を実行する必要があります。強力なハッシュアルゴリズムを選択することにより、この攻撃は計算的に実行不可能になります。さらに、証明書にこの仕様で説明されているプライバシーに敏感な識別子が含まれる場合、各証明書は個別に攻撃する必要があります。最後に、被験者はこのメカニズムを使用して、実際に依存者に開示することなく、特定のタイプの識別子を含む証明書を所有していることを証明できます。
This feature MUST be used only in conjunction with protocols that make use of digital signatures generated using the subject's private key.
この機能は、被験者の秘密鍵を使用して生成されたデジタル署名を使用するプロトコルと組み合わせてのみ使用する必要があります。
In addition, this document defines an Encrypted PEPSI (EPEPSI) so that sensitive identifier information can be exchanged during certificate issuance processes without disclosing the identifier to an eavesdropper.
さらに、このドキュメントでは、暗号化されたPepsi（Epepsi）を定義しているため、識別子を盗聴者に開示せずに、感度のある識別子情報を証明書発行プロセス中に交換できます。
This document is organized as follows:
このドキュメントは次のように整理されています。
- Section 3 establishes security and usability requirements; - Section 4 provides an overview of the mechanism; - Section 5 defines syntax and generation rules; and - Section 6 provides example use cases.
- セクション3では、セキュリティとユーザビリティの要件を確立します。 - セクション4では、メカニズムの概要を示します。 - セクション5では、構文と生成のルールを定義します。および - セクション6では、例のユースケースを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
The following cryptography symbols are defined in this document.
次の暗号記号は、このドキュメントで定義されています。
H() Cryptographically secure hash algorithm. SHA-1 [FIPS 180-1] or a more secure hash function is required.
h（）暗号化的に保護されたハッシュアルゴリズム。SHA-1 [FIPS 180-1]またはより安全なハッシュ関数が必要です。
SII Sensitive Identification Information (e.g., Social Security Number).
SIIに敏感な識別情報（例：社会保障番号）。
SIItype Object Identifier that identifies the type of SII.
SIIのタイプを識別するSIITYPEオブジェクト識別子。
P A user-chosen password.
Pユーザーが選択したパスワード。
R The random number value generated by a Registration Authority (RA).
r登録機関（RA）によって生成された乱数値。
PEPSI Privacy-Enhanced Protected Subject Information. Calculated from the input value P, R, SIItype, SII using two iteration of H().
Pepsiプライバシー強化された保護されたサブジェクト情報。H（）の2つの反復を使用して、入力値p、r、siitype、siiから計算されます。
E() The encryption algorithm to encrypt the PEPSI value.
e（）暗号化アルゴリズムは、ペプシ値を暗号化します。
EPEPSI Encrypted PEPSI.
Epepsi暗号化されたペプシ。
D() The decryption algorithm to decrypt the EPEPSI.
d（）depepsiを復号化するための復号化アルゴリズム。
We make the following assumptions about the context in which SIM and PEPSI are to be employed:
SimとPepsiを採用するコンテキストについて、次の仮定を行います。
- Alice, a certificate holder, with a sensitive identifier SIIa (such as her Social Security Number) - Bob, a relying party who will require knowledge of Alice's SIIa - Eve, an attacker who acquires Alice's certificate - An RA to whom Alice must divulge her SIIa - A CA who will issue Alice's certificate
- 敏感な識別子SIIA（彼女の社会保障番号など）を備えた証明書所有者のアリス - アリスのSIIAの知識を必要とする頼りのパーティーであるボブ - アリスの証明書を取得する攻撃者 - アリスが彼女を漏らさなければならないRAにSIIA-アリスの証明書を発行するCA
We wish to design SIM and PEPSI, using a password that Alice chooses, that has the following properties:
Aliceが選択したパスワードを使用して、SIMとPepsiを設計したいと考えています。次のプロパティがあります。
- Alice can prove her SII, SIIa to Bob.
- アリスは彼女のSII、SIIAからボブを証明することができます。
- Eve has a large work factor to determine Alice's SIIa from Alice's certificate, even if Alice chooses a weak password, and a very large work factor if Alice chooses a good password. - Even if Eve can determine SIIa, she has an equally hard problem to find any other SII values from any other PEPSI; that is, there is nothing she can pre-compute that helps her attack PEPSIs in other certificates, and nothing she learns from a successful attack that helps in any other attack. - The CA does not learn Alice's SIIa except in the case where the CA needs to validate the SII passed by the RA. - The CA can treat the SIM as an additional name form in the "subjectAltName" extension with no special processing. - Alice cannot find another SII (SIIx), and a password (P), that will allow her to use her certificate to assert a false SII.
- イブには、アリスが弱いパスワードを選択したとしても、アリスの証明書からアリスのSIIAを決定する大きな作業要因があり、アリスが良いパスワードを選択した場合、非常に大きな作業要因があります。 - たとえイブがSIIAを決定できる場合でも、彼女は他のペプシから他のSII値を見つけるのに等しく難しい問題を抱えています。つまり、他の証明書でペプシスを攻撃するのに役立つ彼女が事前計算できるものは何もありません。また、他の攻撃に役立つ成功した攻撃から学ぶことはありません。-CAは、CAがRAで通過したSIIを検証する必要がある場合を除き、アリスのSIIAを学習しません。-CAは、特別な処理なしで「subjectaltname」拡張機能の追加名形式としてSIMを扱うことができます。-Aliceは、別のSII（SIIX）とパスワード（P）を見つけることができません。これにより、証明書を使用して偽のSIIを主張することができます。
In addition to the security properties stated above, we have the following usability requirements:
上記のセキュリティプロパティに加えて、次のユーザビリティ要件があります。
- When SIM and PEPSI are used, any custom processing occurs at the relying party. Alice can use commercial off-the-shelf software (e.g., a standard browser) without modification in conjunction with a certificate containing a SIM value.
- SimとPepsiを使用すると、頼りになるパーティでカスタム処理が行われます。Aliceは、SIM値を含む証明書と組み合わせて変更することなく、商用オフシェルフソフトウェア（標準ブラウザーなど）を使用できます。
We define SIM as: R || PEPSI
where PEPSI = H(H( P || R || SIItype || SII))
The following steps describe construction and use of SIM:
次の手順では、SIMの構築と使用について説明します。
1. Alice picks a password P, and gives P, SIItype, and SII to the RA (via a secure channel). 2. The RA validates SIItype and SII; i.e., it determines that the SII value is correctly associated with the subject and the SIItype is correct. 3. The RA generates a random value R. 4. The RA generates the SIM = (R || PEPSI) where PEPSI = H(H(P || R || SIItype || SII)). 5. The RA sends the SIM to Alice by some out-of-band means and also passes it to the CA. 6. Alice sends a certRequest to CA. The CA generates Alice's certificate including the SIM as a form of otherName from the GeneralName structure in the subjectAltName extension. 7. Alice sends Bob her Cert, as well as P, SIItype, and SII. The latter values must be communicated via a secure communication channel, to preserve their confidentiality.
1. アリスはパスワードPを選択し、P、SIITYPE、およびSIIをRAに与えます（安全なチャネルを介して）。2. RAはsiitypeおよびsiiを検証します。つまり、SII値が被験者に正しく関連付けられており、SIITYPEが正しいと判断します。3. RAはランダムな値Rを生成します。4。RAはSim =（r || Pepsi）を生成します。ここで、pepsi = h（p || r || siitype || sii））。5. RAは、いくつかの帯域外の手段によってSIMをアリスに送り、それをCAに渡します。6.アリスはCERTESTをCAに送ります。CAは、SIMを含むAliceの証明書を生成します。SimperAltname拡張機能の一般名構造の他の名前の形式です。7.アリスは、ボブに彼女の証明書と、p、siitype、およびsiiを送ります。後者の値は、機密性を維持するために、安全な通信チャネルを介して伝達する必要があります。
8. Bob can compute PEPSI' = H(H(P || R || SIItype || SII)) and compare SIM' = R || PEPSI' to the SIM value in Alice's certificate, thereby verifying SII.
8. ボブはpepsi '= h（h（p || r || siitype || sii））を計算でき、sim' = r ||を比較できます。Aliceの証明書のSIM値へのPepsi 'これにより、SIIが検証されます。
If Alice's SII value is not required by Bob (Bob already knows Alice's SII and does not require it), then steps 7 and 8 are as follows:
AliceのSII値がBobに必要でない場合（BobはすでにAliceのSIIを知っており、それを必要としていません）、ステップ7と8は次のとおりです。
7. Alice sends Bob her Cert and P. P must be sent via a secure communication channel, to preserve its confidentiality. 8. Bob can compute PEPSI' = H(H(P || R || SIItype || SII)) and compare SIM' = R || PEPSI' to the value in the SIM, thereby verifying SII.
7. アリスはボブに彼女の証明書を送り、P。Pは、その機密性を維持するために、安全な通信チャネルを介して送られなければなりません。8. BobはPepsi '= H（h（p || r || siitype || sii））を計算でき、Sim' = r ||を比較できます。Pepsi 'SIMの値に、それによりSIIが検証されます。
If Alice wishes to prove she is the subject of an RA-validated identifier, without disclosing her identifier to Bob, then steps 7 and 8 are as follows:
アリスが彼女がra validated識別子の対象であることを証明したい場合、彼女の識別子をボブに開示せずに、ステップ7と8は次のとおりです。
7. Alice sends the intermediate value H(P || R || SIItype || SII) and her certificate to Bob. 8. Bob can get R from the SIM in the certificate, then compute H (intermediate value) and compare it to the value in SIM, thereby verifying Alice's knowledge of P and SII.
7. アリスは中間値h（p || r || siitype || sii）と彼女の証明書をボブに送信します。8. Bobは、証明書のSIMからRを取得し、H（中間値）を計算し、SIMの値と比較して、AliceのPとSIIの知識を検証できます。
Eve has to exhaustively search the H(P || R || SIItype || SII) space to find Alice's SII. This is a fairly hard problem even if Alice uses a poor password, because of the size of R (as specified later), and a really hard problem if Alice uses a fairly good password (see Section 8).
イブは、h（p || r || siitype || sii）スペースを徹底的に検索して、アリスのSIIを見つける必要があります。AliceがRのサイズ（後で指定）のためにパスワードが悪い場合でも、これはかなり難しい問題であり、Aliceがかなり良いパスワードを使用している場合は非常に難しい問題です（セクション8を参照）。
Even if Eve finds Alice's P and SII, or constructs a massive dictionary of P and SII values, it does not help find any other SII values, because a new R is used for each PEPSI and SIM.
EveがAliceのPとSIIを見つけたり、PとSIIの値の大規模な辞書を構築したりしたとしても、各PEPSIとSIMに新しいRが使用されるため、他のSII値を見つけるのに役立ちません。
The user presents evidence that a particular SII has been assigned to him/her. The SIItype is an Object Identifier (OID) that defines the format and scope of the SII value. For example, in Korea, one SIItype is defined as follows:
ユーザーは、特定のSIIが彼/彼女に割り当てられたという証拠を提示します。SiityPEは、SII値の形式と範囲を定義するオブジェクト識別子（OID）です。たとえば、韓国では、1つのsiitypeが次のように定義されています。
-- KISA specific arc
id-KISA OBJECT IDENTIFIER ::=
{iso(1) member-body(2) korea(410) kisa(200004)}
-- KISA specific OIDs
id-npki OBJECT IDENTIFIER ::= {id-KISA 10}
id-attribute OBJECT IDENTIFIER ::= {id-npki 1}
id-kisa-identifyData OBJECT IDENTIFIER ::= {id-attribute 1}
id-VID OBJECT IDENTIFIER ::= {id-kisa-identifyData 10}
id-SII OBJECT IDENTIFIER ::= {id-VID 1}
For closed communities, the SIItype value may be assigned by the CA itself, but it is still recommended that the OID be registered.
閉鎖コミュニティの場合、SIITYPE値はCA自体によって割り当てられる場合がありますが、OIDを登録することをお勧めします。
The user selects a password as one of the input values for computing the SIM. The strength of the password is critical to protection of the user's SII, in the following sense. If an attacker has a candidate SII value, and wants to determine whether the SIM value in a specific subject certificate, P is the only protection for the SIM. The user should be encouraged to select passwords that will be difficult to be guessed, and long enough to protect against brute force attacks.
ユーザーは、SIMを計算するための入力値の1つとしてパスワードを選択します。次の意味で、ユーザーのSIIを保護するには、パスワードの強度が重要です。攻撃者が候補SII値を持っており、特定のサブジェクト証明書のSIM値がSIMの唯一の保護であるかどうかを判断したい場合。ユーザーは、推測するのが難しく、ブルートフォース攻撃から保護するのに十分な長さのパスワードを選択することをお勧めする必要があります。
Implementations of this specification MUST permit a user to select passwords of up to 28 characters. RAs SHOULD implement password filter rules to prevent user selection of trivial passwords. See [FIPS 112] and [FIPS 180-1] for security criteria for passwords and an automated password generator algorithm that randomly creates simple pronounceable syllables as passwords.
この仕様の実装では、ユーザーが最大28文字のパスワードを選択できるようにする必要があります。RASは、ユーザーが些細なパスワードの選択を防ぐために、パスワードフィルタールールを実装する必要があります。パスワードのセキュリティ基準と、パスワードとして単純な発音可能な音節をランダムに作成する自動パスワードジェネレーターアルゴリズムについては、[FIPS 112]および[FIPS 180-1]を参照してください。
The RA generates a random number, R. A new R MUST be generated for each SIM. The length of R MUST be the same as the length of the output of the hash algorithm H. For example, if H is SHA-1, the random number MUST be 160 bits.
RAは乱数を生成します。R。各SIMに対して新しいRを生成する必要があります。Rの長さは、ハッシュアルゴリズムHの出力の長さと同じでなければなりません。たとえば、HがSHA-1の場合、乱数は160ビットでなければなりません。
A Random Number Generator (RNG) that meets the requirements defined in [FIPS 140-2] and its use is strongly recommended.
[FIPS 140-2]で定義されている要件を満たし、その使用を強くお勧めします。
The SIM in the subjectAltName extension within a certificate identifies an entity, even if multiple subjectAltNames appear in a certificate. RAs MUST calculate the SIM value with the designated inputs according to the following algorithm:
証明書内のsumberaltaltname拡張機能のSIMは、証明書に複数のsubjectaltnamesが表示されたとしても、エンティティを識別します。RASは、次のアルゴリズムに従って、指定された入力でSIM値を計算する必要があります。
SIM = R || PEPSI
where PEPSI = H(H(P || R || SIItype || SII))
The SII is made known to an RA at user enrollment. Both SHA-1 and SHA-256 MUST be supported for generation and verification of PEPSI values. This specification does not preclude use of other one-way hash functions, but SHA-1 or SHA-256 SHOULD be used wherever interoperability is a concern.
SIIは、ユーザー登録時のRAに知られています。SHA-1とSHA-256の両方を、PEPSI値の生成と検証のためにサポートする必要があります。この仕様は、他の一方向ハッシュ関数の使用を排除するものではありませんが、相互運用性が懸念事項であればどこでもSHA-1またはSHA-256を使用する必要があります。
Note that a secure communication channel MUST be used to pass P and SII passing from the end entity to the RA, to protect them from disclosure or modification.
安全な通信チャネルを使用して、PおよびSIIが最終エンティティからRAへと通過し、開示や変更から保護するために使用する必要があることに注意してください。
The syntax and the associated OID for SIM are also provided in the ASN.1 modules in Section 5.1. Also, Section 5.2 describes the syntax for PEPSI in the ASN.1 modules.
SIMの構文と関連するOIDは、セクション5.1のASN.1モジュールにも提供されています。また、セクション5.2では、ASN.1モジュールのPEPSIの構文について説明します。
It may be required that the CA (not just the RA) verifies SII before issuing a certificate. To meet this requirement, RA SHOULD encrypt the SIItype, SII, and SIM and send the result to the CA by a secure channel. The user SHOULD also encrypt the same values and send the result to the CA in his or her certificate request message. Then the CA compares these two results for verifying the user's SII.
CA（RAだけでなく）が証明書を発行する前にSIIを検証する必要がある場合があります。この要件を満たすために、RAはSIITYPE、SII、およびSIMを暗号化し、安全なチャネルで結果をCAに送信する必要があります。また、ユーザーは同じ値を暗号化し、証明書リクエストメッセージで結果をCAに送信する必要があります。次に、CAは、ユーザーのSIIを検証するためにこれら2つの結果を比較します。
Where the results from RA and the user are the EPEPSI.
RAとユーザーの結果はEpepsiです。
EPEPSI = E(SIItype || SII || SIM)
epepsi = e（siitype || sii || sim）
When the EPEPSI is used in a user certificate request, it is in regInfo of [RFC4211] and [RFC2986].
Epepsiがユーザー証明書リクエストで使用される場合、それは[RFC4211]および[RFC2986]のReginfoにあります。
Note: Specific encryption/decryption methods are not defined in this document. For transmission of the PEPSI value from a user to a CA, the certificate request protocol employed defines how encryption is performed. For transmission of this data between an RA and a CA, the details of how encryption is performed is a local matter.
注：特定の暗号化/復号化方法は、このドキュメントでは定義されていません。ユーザーからCAへのPEPSI値を送信するために、採用された証明書要求プロトコルは、暗号化の実行方法を定義します。RAとCAの間にこのデータを送信するために、暗号化の実行方法の詳細は局所的な問題です。
The syntax and the associated OID for EPEPSI is provided in the ASN.1 modules in Section 5.3.
Epepsiの構文と関連するOIDは、セクション5.3のASN.1モジュールで提供されています。
As described above, a certificate request message MAY contain the SIM. [RFC2986] and [RFC4211] are widely used message syntaxes for certificate requests.
上記のように、証明書要求メッセージにはSIMが含まれる場合があります。[RFC2986]および[RFC4211]は、証明書リクエストに広く使用されているメッセージの構文です。
Basically, a PKCS#10 message consists of a distinguished name, a public key, and an optional set of attributes, collectively signed by the end entity. The SIM alternative name MUST be placed in the subjectAltName extension if this certificate request format is used. If a CA verifies SII before issuing the certificate, the value of SIM in the certification request MUST be conveyed in the EPEPSI form and provided by the subject.
基本的に、PKCS＃10メッセージは、著名な名前、公開鍵、および最終エンティティによって総合的に署名されたオプションの属性のセットで構成されています。この証明書リクエスト形式が使用されている場合、SIMの代替名はsubjectaltname拡張機能に配置する必要があります。CAが証明書を発行する前にSIIを検証する場合、認証要求のSIMの値はEpepsiフォームで伝えられ、被験者によって提供される必要があります。
A CA that issues certificates containing the SIM includes the SIM as a form of otherName from the GeneralName structure in the "subjectAltName" extension.
SIMを含む証明書を発行するCAには、simを「sumbesaltaltname」拡張子の一般名構造から他の名前の形式として含めます。
In an environment where a CA verifies SII before issuing the certificate, a CA decrypts the EPEPSI values it receives from both the user and the RA, and compares them. It then validates that the SII value is correctly bound to the subject.
CAが証明書を発行する前にSIIを検証する環境では、CAはユーザーとRAの両方から受け取るEpepsi値を復号化し、それらを比較します。次に、SII値が主題に正しく結合されていることを検証します。
SIItype, SII, SIM = D(EPEPSI)
SIIタイプ、SII、SIM = De Pepsi）
This section specifies the syntax for the SIM name form included in the subjectAltName extension. The SIM is composed of the three fields: the hash algorithm identifier, the authority-chosen random value, and the value of the PEPSI itself.
このセクションでは、sumberaltaltname拡張子に含まれるSIM名フォームの構文を指定します。SIMは、3つのフィールドで構成されています。ハッシュアルゴリズム識別子、権限を選択したランダム値、およびPEPSI自体の値です。
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 }
SIM ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
authorityRandom OCTET STRING, -- RA-chosen random number
-- used in computation of
-- pEPSI
pEPSI OCTET STRING -- hash of HashContent
-- with algorithm hashAlg
}
This section specifies the syntax for the PEPSI. The PEPSI is generated by performing the same hash function twice. The PEPSI is generated over the ASN.1 structure HashContent. HashContent has four values: the user-selected password, the authority-chosen random number, the identifier type, and the identifier itself.
このセクションでは、Pepsiの構文を指定します。ペプシは、同じハッシュ関数を2回実行することにより生成されます。ペプシは、asn.1構造のハッシュコンテンツで生成されます。HashContentには、ユーザーが選択したパスワード、機関が選択した乱数、識別子タイプ、識別子自体の4つの値があります。
HashContent ::= SEQUENCE {
userPassword UTF8String,
-- user-supplied password
authorityRandom OCTET STRING,
-- RA-chosen random number
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String -- SII
}
Before calculating a PEPSI, conforming implementations MUST process the userPassword with the six-step [LDAPBIS STRPREP] string preparation algorithm, with the following changes:
Pepsiを計算する前に、実装を適合させると、6段階の[ldapbis strprep]文字列準備アルゴリズムでユーザーパスワードを処理する必要があります。
* In step 2, Map, the mapping shall include processing of characters commonly mapped to nothing, as specified in Appendix B.1 of [RFC3454]. * Omit step 6, Insignificant Character Removal.
* ステップ2のMAPでは、マッピングには、[RFC3454]の付録B.1に指定されているように、一般的にマッピングされた文字の処理を含むものとします。*ステップ6、重要でない文字削除を省略します。
This section describes the syntax for the Encrypted PEPSI. The Encrypted PEPSI has three fields: identifierType, identifier, and SIM.
このセクションでは、暗号化されたペプシの構文について説明します。暗号化されたPepsiには、識別型、識別子、およびSIMの3つのフィールドがあります。
EncryptedPEPSI ::= SEQUENCE {
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String, -- SII
sIM SIM -- Value of the SIM
}
When it is used in a certificate request, the OID in 'regInfo' of [RFC4211] and [RFC2986] is as follows:
証明書リクエストで使用される場合、[RFC4211]と[RFC2986]の「Reginfo」のOIDは次のとおりです。
id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }
Depending on different security environments, there are three possible use cases with SIM.
さまざまなセキュリティ環境に応じて、SIMには3つのユースケースがあります。
1. When a relying party does not have any information about the certificate user. 2. When a relying party already knows the SII of the certificate user. 3. When the certificate user does not want to disclose his SII.
1. 頼っている当事者が証明書ユーザーに関する情報を持っていない場合。2.頼っている当事者がすでに証明書ユーザーのSIIを知っている場合。3.証明書ユーザーがSIIを開示したくない場合。
For the use case 1, the SII and a user-chosen password P (which only the user knows) must be sent to a relying party via a secure communication channel; the certificate including the SIM also must be transmitted. The relying party acquires R from the certificate. The relying party can verify that the SII was validated by the CA (or RA) and is associated with the entity that presented the password and certificate. In this case, the RP learns which SII is bound to the subject as a result of the procedure.
ユースケース1の場合、SIIとユーザーが選択したパスワードP（ユーザーのみが知っている）は、安全な通信チャネルを介して依存者に送信する必要があります。SIMを含む証明書も送信する必要があります。頼る当事者は、証明書からRを取得します。頼る当事者は、SIIがCA（またはRA）によって検証され、パスワードと証明書を提示したエンティティに関連付けられていることを確認できます。この場合、RPは、手順の結果としてどのSIIが主題に拘束されるかを学習します。
In case 2, a certificate user transmits only the password, P, and the certificate. The rest of the detailed procedure is the same as case 1, but here the relying party supplies the SII value, based on its external knowledge of that value. The purpose in this case is to enable the RP to verify that the subject is bound to the SII, presumably because the RP identifies the subject based on this SII.
ケース2では、証明書ユーザーはパスワードP、および証明書のみを送信します。詳細な手順の残りの部分はケース1と同じですが、ここでは、その価値の外部知識に基づいて、頼る当事者はSII値を提供します。この場合の目的は、おそらくRPがこのSIIに基づいて被験者を識別しているため、被験者がSIIに拘束されていることをRPが確認できるようにすることです。
In the last case, the certificate user does not want to disclose his or her SII because of privacy concerns. Here the only information sent by a certificate subject is the intermediate value of the PEPSI, H(R || P || SIItype || SII). This value MUST be transmitted via a secure channel, to preserve its confidentiality. Upon receiving this value, the relying party applies the hash function to the intermediate PEPSI value sent by the user, and matches it against the SIM value in the user's certificate. The relying party does not learn the user's SII value as a result of this processing, but the relying party can verify the fact that the user knows the right SII and password. This gives the relying party more confidence that the user is the certificate subject. Note that this form of user identity verification is NOT to be used in lieu of standard certificate validation procedures, but rather in addition to such procedures.
最後のケースでは、証明書ユーザーはプライバシーの懸念のためにSIIを開示したくありません。ここで、証明書の件名から送信される唯一の情報は、ペプシの中間値h（r || p || siitype || sii）です。この値は、機密性を維持するために、安全なチャネルを介して送信する必要があります。この値を受信すると、頼る当事者は、ハッシュ関数をユーザーが送信した中間ペプシ値に適用し、ユーザーの証明書のSIM値と一致させます。頼る当事者は、この処理の結果としてユーザーのSII値を学習しませんが、頼る当事者は、ユーザーが正しいSIIとパスワードを知っているという事実を確認できます。これにより、ユーザーが証明書の科目であるという自信が依存します。この形式のユーザーID検証は、標準的な証明書検証手順の代わりに使用されるのではなく、そのような手順に加えて使用する必要があることに注意してください。
The SIM value is stored as an otherName of a subject alternative name; however, there are no constraints that can be placed on this form of the name.
SIM値は、件名の代替名の別の名として保存されます。ただし、この形式の名前に配置できる制約はありません。
Confidentiality for a SIM value is created by the iterated hashing of the R, P, and SII values. A SIM value depends on two properties of a hash function: the fact that it cannot be inverted and the fact that collisions (especially with formatted data) are rare. The current attacks by [WANG] are not applicable to SIM values since the end entity supplying the SII and SIItype values does not supply all of the data being hashed; i.e., the RA provides the R value.
SIM値の機密性は、R、P、およびSII値の反復ハッシュによって作成されます。SIM値は、ハッシュ関数の2つの特性に依存します。反転できないという事実と、衝突（特にフォーマットされたデータを使用）はまれです。[Wang]による現在の攻撃は、SIIおよびSiityPE値を供給する最終エンティティがハッシュされているすべてのデータを提供しないため、SIM値には適用されません。つまり、RAはR値を提供します。
In addition, a fairly good password is needed to protect against guessing attacks on SIMs. Due to the short length of many SIIs, it is possible that an attacker may be able to guess it with partial information about gender, age, and date of birth. SIItype values are very limited. Therefore, it is important for users to select a fairly good password to prevent an attacker from determining whether a guessed SII is accurate.
さらに、SIMに対する推測攻撃から保護するために、かなり良いパスワードが必要です。多くのSIIの長さが短いため、攻撃者が性別、年齢、生年月日に関する部分的な情報でそれを推測できる可能性があります。siitype値は非常に限られています。したがって、ユーザーがかなり良いパスワードを選択して、攻撃者が推測されたSIIが正確であるかどうかを判断しないようにすることが重要です。
This protocol assumes that Bob is a trustworthy relying party who will not reuse the Alice's information. Otherwise, Bob could "impersonate" Alice if only knowledge of P and SII were used to verify a subject's claimed identity. Thus, this protocol MUST be used only with the protocols that make use of digital signatures generated using the subject's private key.
このプロトコルは、ボブがアリスの情報を再利用しない信頼できる頼りの当事者であると想定しています。それ以外の場合、PとSIIの知識だけが被験者の主張されたアイデンティティを検証するために使用された場合、ボブはアリスに「偽装」することができました。したがって、このプロトコルは、被験者の秘密鍵を使用して生成されたデジタル署名を使用するプロトコルでのみ使用する必要があります。
Digital signatures are used by a message sender to demonstrate knowledge of the private key corresponding to the public key in a certificate, and thus to authenticate and bind his or her identity to a signed message. However, managing a private key is vulnerable under certain circumstances. It is not fully guaranteed that the claimed private key is bound to the subject of a certificate. So, the SIM can enhance verification of user identity.
デジタル署名は、メッセージ送信者によって使用され、証明書の公開鍵に対応する秘密鍵の知識を示すために、したがって、彼または彼女の身元を認証して署名されたメッセージに結合します。ただし、秘密鍵の管理は特定の状況下で脆弱です。請求された秘密鍵が証明書の主題に拘束されることは完全には保証されていません。したがって、SIMはユーザーIDの検証を強化できます。
Whenever a certificate needs to be updated, a new R SHOULD be generated and the SIM SHOULD be recomputed. Repeating the value of the SIM from a previous certificate permits an attacker to identify certificates associated with the same individual, which may be undesirable for personal privacy purposes.
証明書を更新する必要があるときはいつでも、新しいRを生成し、SIMを再計算する必要があります。以前の証明書からSIMの値を繰り返すことで、攻撃者は同じ個人に関連する証明書を特定することができます。これは、個人のプライバシー目的では望ましくない可能性があります。
Jim Schaad (Soaring Hawk Consulting), Seungjoo Kim, Jaeho Yoon, Baehyo Park (KISA), Bill Burr, Morrie Dworkin (NIST), and the Internet Security Technology Forum (ISTF) have significantly contributed to work on the SIM and PEPSI concept and identified a potential security attack. Also their comments on the set of desirable properties for the PEPSI and enhancements to the PEPSI were most illumination. Also, thanks to Russell Housley, Stephen Kent, and Denis Pinkas for their contributions to this document.
ジム・シャード（ソアリング・ホーク・コンサルティング）、スンジュジ・キム、ジェホ・ユン、バエヒョ・パーク（KISA）、ビル・バー、モリー・ドワーク（NIST）、およびインターネットセキュリティテクノロジーフォーラム（ISTF）は、SIMとペプシのコンセプトとペプシのコンセプトとペプシのコンセプトの作業に大きく貢献しました。潜在的なセキュリティ攻撃を特定しました。また、ペプシの望ましい特性のセットとペプシの強化に関する彼らのコメントは、最も照明でした。また、この文書への貢献をしてくれたラッセル・ヒューズリー、スティーブン・ケント、デニス・ピンカスに感謝します。
In the future, IANA may be asked to establish a registry of object identifiers to promote interoperability in the specification of SII types.
将来、IANAは、SIIタイプの仕様における相互運用性を促進するために、オブジェクト識別子のレジストリを確立するよう求められる場合があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[RFC2986] Nystrom、M。およびB. Kaliski、「PKCS＃10：認定要求構文仕様バージョン1.7」、RFC 2986、2000年11月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454] Hoffman、P。およびM. Blanchet、「国際化された文字列の準備（「StringPrep」）」、RFC 3454、2002年12月。
[RFC4043] Pinkas, D. and T. Gindin, "Internet X.509 Public Key Infrastructure Permanent Identifier", RFC 4043, May 2005.
[RFC4043] Pinkas、D。およびT. Gindin、「Internet X.509公開キーインフラストラクチャパーマネント識別子」、RFC 4043、2005年5月。
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[RFC4211] Schaad、J。、「Internet X.509公開キーインフラストラクチャ証明書リクエストメッセージフォーマット（CRMF）」、RFC 4211、2005年9月。
[LDAPBIS STRPREP] Zeilenga, K., "LDAP: Internationalized String Preparation", Work in Progress.
[Ldapbis strprep] Zeilenga、K。、「LDAP：国際化された文字列準備」、進行中の作業。
[FIPS 112] Fedreal Information Processing Standards Publication (FIPS PUB) 112, "Password Usage", 30 May 1985.
[FIPS 112] Fedreal Information Processings Standards Publication（FIPS Pub）112、「パスワード使用」、1985年5月30日。
[FIPS 180-1] Federal Information Processing Standards Publication (FIPS PUB) 180-1, "Secure Hash Standard", 17 April 1995.
[FIPS 180-1]連邦情報処理標準出版（FIPS Pub）180-1、「Secure Hash Standard」、1995年4月17日。
[FIPS 140-2] Federal Information Processing Standards Publication (FIPS PUB) 140-2, "Security Requirements for Cryptographic Modules", 25 May 2001.
[FIPS 140-2]連邦情報処理標準出版（FIPS Pub）140-2、「暗号化モジュールのセキュリティ要件」、2001年5月25日。
[WANG] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu, "Finding Collisions in the Full SHA-1", Crypto'05. <http://www.infosec.sdu.edu.cn/paper/sha1-crypto-auth-new-2-yao.pdf>
[王] Xiaoyun Wang、Yiqun Lisa Yin、およびHongbo Yu、「Full Sha-1で衝突を見つける」、Crypto'05。<http://www.infosec.sdu.edu.cn/paper/sha1-crypto-auth-new-2-yao.pdf>
Authors' Addresses
著者のアドレス
Jongwook Park Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA
Jongwook Park Korea Information Security Agency 78、Garak-Dong、Songpa-gu、Seoul、138-803韓国共和国
Phone: 2-405-5432 EMail: khopri@kisa.or.kr
電話：2-405-5432メール：khopri@kisa.or.kr
Jaeil Lee 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA Korea Information Security Agency
Jaeil Lee 78、Garak-Dong、Songpa-gu、Seoul、138-803韓国韓国情報セキュリティ機関
Phone: 2-405-5300 EMail: jilee@kisa.or.kr
電話：2-405-5300メール：jilee@kisa.or.kr
Hongsub Lee Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA
Hongsub Lee Korea Information Security Agency 78、Garak-Dong、Songpa-Gu、Seoul、138-803韓国共和国
Phone: 2-405-5100 EMail: hslee@kisa.or.kr Sangjoon Park BCQRE Co.,Ltd Yuil Bldg. Dogok-dong 411-14, Kangnam-ku, Seoul, 135-270 REPUBLIC OF KOREA
電話：2-405-5100メール：hslee@kisa.or.kr Sangjoon Park Bcqre Co.、Ltd Yuil Bldg。Dogok-Dong 411-14、Kangnam-ku、ソウル、135-270韓国共和国
EMail: sjpark@bcqre.com
Tim Polk National Institute of Standards and Technology 100 Bureau Drive, MS 8930 Gaithersburg, MD 20899
Tim Polk National Institute of Standards and Technology 100 Bureau Drive、MS 8930 Gaithersburg、MD 20899
EMail: tim.polk@nist.gov
Appendix A. "Compilable" ASN.1 Module, 1988 Syntax
付録A.
PKIXSIM {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-sim2005(38) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
始める
-- EXPORTS ALL
- すべてエクスポートします
IMPORTS
輸入
AlgorithmIdentifier, AttributeTypeAndValue FROM PKIX1Explicit88
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)}
-- SIM
- シム
-- SIM certificate OID
-SIM証明書OID
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 }
-- Certificate Syntax
- 証明書構文
SIM ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
authorityRandom OCTET STRING, -- RA-chosen random number
-- used in computation of
-- pEPSI
pEPSI OCTET STRING -- hash of HashContent
-- with algorithm hashAlg
}
-- PEPSI
- ペプシ
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279
HashContent ::= SEQUENCE {
userPassword UTF8String,
-- user-supplied password
authorityRandom OCTET STRING,
-- RA-chosen random number identifierType OBJECT IDENTIFIER, -- SIItype identifier UTF8String -- SII }
-Ra-Cosen乱数識別型オブジェクト識別子、-SiityPe識別子UTF8STRING-SII}
-- Encrypted PEPSI
- 暗号化されたペプシ
-- OID for encapsulated content type
- カプセル化されたコンテンツタイプのOID
id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }
EncryptedPEPSI ::= SEQUENCE {
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String, -- SII
sIM SIM -- Value of the SIM
}
END
終わり
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。