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)
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).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate.
この文書は、証明書のsubjectAltName拡張にプライバシーに敏感な識別子を含むための対象識別法（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.
公開鍵に一つ以上のアイデンティティをバインドする - CA - （1）公開鍵基盤（PKI）は、信頼できる第三者機関に依存します。従来のPKIの実装では、公開鍵にX.501識別名を結合するが、同一性は、RFC 822アドレスまたはDNS名で指定することがあります。 CA - - だけでなく、証明書には、プライバシーに敏感な識別子を含めるために、公開鍵に名前をバインドSIM仕様は同じ信頼できるサードパーティを可能にします。証明書利用者（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フィールドに敏感な識別子を符号化します。 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）明示的識別子に公開鍵を結合することにより、この仕様は、依拠当事者が原告の識別子を確認し、原告はその識別子の対象であることを確認することができます。それは秘密鍵の所有の証明は、請求者がそのアイデンティティ（アーキテクチャによっては、CAまたはRA）PKIによって確認されたのと同じ人物であることを確認、です。
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）オブジェクト）は、メッセージは、証明書で証明書またはアイデンティティ（例えば、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.
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
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プライバシー・強化は、Subjectの情報を保護しました。 SIIは、H（二反復を使用して、入力値P、R、SIItypeから計算します）。
E() The encryption algorithm to encrypt the PEPSI value.
E（）PEPSI値を暗号化する暗号化アルゴリズム。
EPEPSI Encrypted PEPSI.
PEPSI暗号化PEPSI。
D() The decryption algorithm to decrypt the EPEPSI.
D（）EPEPSIを復号化する復号アルゴリズム。
We make the following assumptions about the context in which SIM and PEPSI are to be employed:
私たちは、SIMとペプシが採用されるべき状況について次のように仮定します
- 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の知識が必要になります依存者 - - アリスを誰にRAを漏らすしなければならない - イブ、アリスの証明書を取得し、攻撃者を - 敏感な識別子（例えば、彼女の社会保障番号など）SIIAとアリス、証明書の所有者、彼女のSIIA - アリスの証明書を発行するCA
We wish to design SIM and PEPSI, using a password that Alice chooses, that has the following properties:
私たちは、次のプロパティがあり、アリスが選択したパスワードを使用して、SIMとペプシを設計したいです：
- 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を決定することができたとしても、彼女は他のどのPEPSIから他のSII値を見つけるために均等に難しい問題を抱えています。それは彼女が彼女が他の証明書にPEPSIsを攻撃することができますし、何も彼女が他の攻撃に役立ちます成功した攻撃から学習していない、計算を事前できるものは何もありません、です。 - CAは、CAは、RAから渡されたSIIを検証する必要がある場合を除いて、アリスのSIIAを学ぶことはありません。 - CAは、特別な処理と「のsubjectAltName」拡張子で追加の名前フォームとしてSIMを扱うことができます。 - アリスは、彼女が偽SIIを主張するために彼女の証明書を使用できるようになります別のSII（シークス）、およびパスワード（P）を、見つけることができません。
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とペプシが使用される場合、任意のカスタム処理は、依拠当事者で起こります。アリスはSIM値を含む証明書に関連して変更することなく、商用オフザシェルフのソフトウェア（例えば、標準的なブラウザ）を使用することができます。
We define SIM as: R || PEPSI where PEPSI = H(H( P || R || SIItype || SII))
私たちは、としてSIMを定義する：R || PEPSI 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.アリスは、RA（セキュアチャネルを介して）パスワードPを選び、そしてPを与え、SIItype、およびSII。 2. RAはSIItypeとSIIを検証します。すなわち、それはSII値が正しく主題と関連していると判断しSIItypeが正しいです。前記RAは、RAがSIM =（R || PEPSI）PEPSI = H（H（P || R || || SIItype SII））を生成するランダム値R 4を生成します。 5. RAは、いくつかのアウトオブバンドによってアリスにSIMを送信しても、CAに渡し6.アリスはCAにcertrequestコマンドを送信しますCAはsubjectAltName拡張内のGeneralName構造からotherNameの形態としてSIMを含むアリスの証明書を生成します。 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.ボブは '= H（H（P || R || || SIItype SII））と比較SIM' = R || PEPSIを計算することができますアリスの証明書で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:
アリスのSII値はボブ（Bobがすでにアリスの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.ボブは '= H（H（P || R || || SIItype SII））と比較SIM' = R || PEPSIを計算することができますこれにより、SIIの検証SIMの値にPEPSI」、。
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-検証識別子の対象であることを証明したい場合は、ボブに彼女の識別子を開示せず、その後、次のように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.ボブはH（中間値）を計算し、それによってPとSIIのアリスの知識を確認する、SIMの値と比較し、次に、証明書にSIMからRを得ることができます。
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).
イブは徹底的アリスのSIIを見つけるために、H（P || R || || SIItype SII）のスペースを検索しています。これは、R（後に指定されている）の大きさの、アリスが悪いパスワードを使用している場合でも、かなり難しい問題であり、本当に難しい問題アリスはかなり良いパスワードを使用している場合（セクション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.
イブは、アリスのPとSIIを見つけ、またはPとSIIの値の大規模な辞書を構築したとしても、それは新しいRはそれぞれPEPSIとSIMのために使用されるため、他の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を計算するための入力値の一つとして、パスワードを選択します。パスワードの強度は、次の意味では、ユーザーのSIIの保護に重要です。攻撃者は候補SII値を持ち、特定の対象証明書内のSIM値かどうかを確認したい場合は、Pは、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文字のパスワードをユーザが選択することを許可する必要があります。 RAは些細なパスワードのユーザ選択を防ぐために、パスワードフィルタルールを実装する必要があります。パスワードやランダムなパスワードのような単純な発音可能な音節を作成し、自動化されたパスワード生成アルゴリズムのためのセキュリティ基準について[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. A新たなRは、各SIMのために生成しなければなりません生成します。 Rの長さHは、SHA-1である場合、乱数は160ビットでなければなりません、例えば、ハッシュアルゴリズムHの出力の長さと同じでなければなりません。
A Random Number Generator (RNG) that meets the requirements defined in [FIPS 140-2] and its use is strongly recommended.
[FIPS 140-2]とその使用に定義された要件を満たしている乱数発生器（RNG）が強く推奨されます。
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:
証明書内のsubjectAltName拡張におけるSIMは、複数subjectAltNamesを証明書に表示されていても、エンティティを識別する。 RAは次のアルゴリズムに従って指定された入力でSIM値を計算する必要があります：
SIM = R || PEPSI where PEPSI = H(H(P || R || SIItype || SII))
SIM = R || PEPSI 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の両方がペプシ値の生成および検証のためにサポートしなければなりません。この仕様は、他の一方向ハッシュ関数の使用を排除するものではありませんが、相互運用性が懸念されるところはどこでも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.
安全な通信チャネルは、開示または改変から保護するために、RAにエンドエンティティから通過PとSIIを渡すために使用しなければならないことに留意されたいです。
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を検証するために、これら二つの結果を比較します。
Where the results from RA and the user are the EPEPSI.
RAとユーザーからの結果は、EPEPSIどこにいます。
EPEPSI = E(SIItype || SII || SIM)
EPEPSI = E（SII SIItype || || 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は、「のsubjectAltName」拡張子でのGeneralName構造からotherNameの形態としてSIMを含みます。
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はEPEPSIが、それはユーザとRAの両方から受け取る値復号化し、それらを比較します。その後、SII値が正しく対象にバインドされていることを検証します。
SIItype, SII, SIM = D(EPEPSI)
SIItype、SII、SIM = D（EPEPSI）
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.
このセクションでは、subjectAltName拡張に含まSIM名形式の構文を指定します。ハッシュアルゴリズム識別子、権限、選択されたランダム値、およびPEPSI自体の値：SIMは、三つのフィールドで構成されています。
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の構文を指定します。 PEPSIは二度同じハッシュ関数を実行することによって生成されます。 PEPSIは、ASN.1構造HashContentの上に生成されます。ユーザーが選択したパスワード、権限に選択された乱数、識別子タイプ、および識別子自体：HashContentは四つの値を持っています。
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]ストリング準備アルゴリズムとのuserPasswordを処理しなければなりません。
* 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では、地図は、マッピングは、[RFC3454]の付録B.1に指定されているように、一般的に何にマッピングされた文字の処理を含むものとします。 *省略ステップ6、無意味な文字の削除。
This section describes the syntax for the Encrypted PEPSI. The Encrypted PEPSI has three fields: identifierType, identifier, and SIM.
このセクションでは、暗号化されたペプシの構文について説明します。 identifierType、識別子、およびSIM：暗号化されたPEPSIは、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:
それは、証明書要求で使用される場合、以下のように、「のREGINFO」[RFC4211]及び[RFC2986]でのOIDです。
id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }
Depending on different security environments, there are three possible use cases with SIM.
異なるセキュリティ環境によっては、SIMとの三つの可能なユースケースがあります。
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.証明書利用者は、証明書の利用者に関する情報を持っていないとき。依存者がすでに証明書ユーザのSIIを知っている2。 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を開示したくありません。ここで、証明書のサブジェクトによって送信された情報のみがPEPSI、H（R || P || || SIItype SII）の中間値です。この値は、その機密性を保持するために、安全なチャネルを介して送信されなければなりません。この値を受信すると、証明書利用者は、利用者が送信された中間PEPSI値にハッシュ関数を適用し、ユーザーの証明書で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の値は、対象代替名のotherNameとして記憶されます。しかし、名前のこのフォーム上に配置することができ制約がありません。
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の値は、ハッシュ関数の二つの特性に依存します。 【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.
また、かなり良いパスワードは、SIMSの推測攻撃から保護するために必要とされます。多くのSIISの短い長さのために、攻撃者は、性別、年齢、生年月日に関する部分的な情報とそれを推測することができる可能性があります。 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.
ジムSchaad（ソアリングホークコンサルティング）、Seungjooキム、Jaehoユン、Baehyoパーク（KISA）、ビル・バー、モリー先生Dworkin（NIST）、およびインターネットセキュリティ技術フォーラム（ISTF）が大幅にSIMとペプシ概念上で動作するように貢献したと潜在的なセキュリティ攻撃を同定しました。また、PEPSIのPEPSIと機能強化のための望ましい特性のセットで彼らのコメントは、ほとんどの照明でした。また、このドキュメントへの貢献のためのラッセルHousley氏、スティーブン・ケント、そしてデニスピンカスのおかげ。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[RFC4043] Pinkas, D. and T. Gindin, "Internet X.509 Public Key Infrastructure Permanent Identifier", RFC 4043, May 2005.
[RFC4043]ピンカス、D.とT. Gindin、 "インターネット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.、 "インターネットX.509公開鍵暗号基盤証明書要求メッセージ・フォーマット（CRMF）"、RFC 4211、2005年9月。
[LDAPBIS STRPREP] Zeilenga, K., "LDAP: Internationalized String Preparation", Work in Progress.
【LDAPBIS STRPREP] Zeilenga、K.、 "LDAP：国際文字列調製"、ProgressのWork。
[FIPS 112] Fedreal Information Processing Standards Publication (FIPS PUB) 112, "Password Usage", 30 May 1985.
[FIPS 112] Fedreal情報処理規格出版（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、 "セキュアハッシュ標準"、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>
【WANG] Xiaoyunワング、Yiqunリサ陰、及びHongbo優、 "フルSHA-1での検索衝突"、Crypto'05。<Http://www.infosec.sdu.edu.cn/paper/sha1-crypto- auth-新しい-2-yao.pdf>
Authors' Addresses
著者のアドレス
Jongwook Park Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA
Jongwookパーク韓国情報保護振興機構78、カラク洞、市松坡区ソウル、韓国138から803 REPUBLIC
Phone: 2-405-5432 EMail: khopri@kisa.or.kr
電話：2-405-5432 Eメール：khopri@kisa.or.kr
Jaeil Lee 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA Korea Information Security Agency
Jaeilリー78、カラク洞、市松坡区ソウル、韓国韓国情報保護振興機構の138から803 REPUBLIC
Phone: 2-405-5300 EMail: jilee@kisa.or.kr
電話：2-405-5300 Eメール：jilee@kisa.or.kr
Hongsub Lee Korea Information Security Agency 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 REPUBLIC OF KOREA
Hongsubリー韓国情報保護振興機構78、カラク洞、市松坡区ソウル、韓国138から803 REPUBLIC
Phone: 2-405-5100 EMail: hslee@kisa.or.kr
電話：2-405-5100 Eメール：hslee@kisa.or.kr
Sangjoon Park BCQRE Co.,Ltd Yuil Bldg. Dogok-dong 411-14, Kangnam-ku, Seoul, 135-270 REPUBLIC OF KOREA
SangjoonパークBCQRE株式会社Yuilビル。 Dogok洞411から14、江南区、ソウル、135から270大韓民国
EMail: sjpark@bcqre.com
メールアドレス：sjpark@bcqre.com
Tim Polk National Institute of Standards and Technology 100 Bureau Drive, MS 8930 Gaithersburg, MD 20899
ティムポーク国立標準技術研究所100局ドライブ、MS 8930ゲイサーズバーグ、MD 20899
EMail: tim.polk@nist.gov
メールアドレス：tim.polk@nist.gov
Appendix A. "Compilable" ASN.1 Module, 1988 Syntax
付録A.「コンパイル可能」ASN.1モジュール、1988構文
PKIXSIM {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-sim2005(38) }
PKIXSIM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（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)}
AlgorithmIdentifier、AttributeTypeAndValue PKIX1Explicit88 FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-明示（18） }
-- SIM
- 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
- 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-選択された乱数identifierTypeオブジェクト識別子、 - SIItype識別子UTF8Stringを - SII}
-- Encrypted PEPSI
- 暗号化された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).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。