RFC4683 日本語訳
4683 Internet X.509 Public Key Infrastructure Subject IdentificationMethod (SIM). J. Park, J. Lee, H.. Lee, S. Park, T. Polk. October 2006. (Format: TXT=41285 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループJ.公園要求をネットワークでつないでください: 4683年のJ.リーカテゴリ: 標準化過程H.リー吉舎S.公園BCQRE T.ポークNIST2006年10月
Internet X.509 Public Key Infrastructure
Subject Identification Method (SIM)
インターネットX.509公開鍵暗号基盤対象同定法(シム)
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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拡張子でプライバシー機密の識別子を含むようにSubject Identification Method(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はまた、特定の証明書の対象が特定の機密の識別子に対応する人であるかどうか決定するのに当てにしているパーティーによって使用されるかもしれないオプション機能です。
Park, et al. Standards Track [Page 1] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[1ページ]。
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
1. 序論…2 1.1. キーワード…5 2. シンボル…6 3. 要件…6 3.1. セキュリティ要件…6 3.2. ユーザビリティ要件…7 3.3. ソリューション…7 4. 手順…8 4.1. SIIとSIItype…8 4.2. ユーザの選ばれたパスワード…9 4.3. 乱数発生…9 4.4. SIMの世代…9 4.5. ペプシの暗号化…10 4.6. 証明要求…10 4.7. 証明…11 5. 定義…11 5.1. SIM構文…11 5.2. ペプシ…12 5.3. ペプシを暗号化します…12 6. SIMの例の使用法…13 7. 規制を命名してください…13 8. セキュリティ問題…14 9. 承認…15 10. IANA問題…15 11. 参照…15 11.1. 標準の参照…15 11.2. 有益な参照…15 付録A."Compilable"ASN.1モジュール、1988年の構文…18
1. Introduction
1. 序論
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.
認証局(カリフォルニア)は、対象に公開鍵を縛るために公開鍵証明書を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.
それぞれの特定のカリフォルニアに関しては、対象の名前はユニークな人、デバイス、グループ、または役割に文通されます。 カリフォルニアは故意に同じ対象の名前の下で複数の実体に証明書を発行しないでしょう。 すなわち、特定の証明書発行人では、同じ対象の名前が(s)であると断言するすべての現在有効な証明書が同じ実体に向かっています。
Park, et al. Standards Track [Page 2] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[2ページ]。
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].
いくつかの場合、事実上、証明書の対象が異なったCAsで支給したアプリケーションか確実にするパーティーが、必要がある信用が同じ実体です。 この必要条件は、複数のCAsの向こう側にユニークなのと同じ対象に発行されたすべての証明書に「永久的な識別子」を含んでいることによって、満たされるかもしれません。 「永久的な識別子」を比較することによって、信用パーティーは制限された異なったCAsから同じ対象まで証明書を特定するかもしれません。 このソリューションは[RFC4043]で定義されます。
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.
多くの場合、人か会社の識別子(例えば、社会保障Number)は敏感であると見なされます、個人的であるか、個人的なデータ。 公開が誤用につながるかもしれないので、対象の分野の一部としてそのような識別子を絶対に含むことができません。 したがって、平文フォームに証明書にこの種類のプライバシーの機密の識別子を含むべきではありません。
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.
他方では、そのような識別子は実際に秘密ではありません。 人々は、あるクラスのトランザクションのためのこれらの識別子を明らかにするのを選びます。 例えば、人は、銀行口座を開くか、または借金するために社会保障Numberを明らかにするかもしれません。 これは、人の名前かアドレスを確認する物理的な資格証明書(例えば、運転免許証)を提示することによって、通常確証されます。
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
これらの要求を実現させるために、この仕様は証明書にプライバシーの機密の識別子を含むようにSubject Identification Method(SIM)とPrivacyによって高められたProtected Subject情報(ペプシ)書式を定義します。 証明書への拘束力があるプライバシー機密の識別子のための他の解決策を見いだすことができましたが、本書では指定されたメソッドは特に魅力的な特性を持っています。 そしてこの仕様が一般的なPKI習慣を表する。
Park, et al. Standards Track [Page 3] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[3ページ]。
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メカニズムは、対象が機密の識別子の暴露を制御するのを可能にします。 対象が、機密の識別子を暴露するのを選ぶと、信用パーティーは結合について確かめることができます。 明確に:
(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つ以上のアイデンティティを縛るために信頼できる第三者機関(カリフォルニア)に頼っています。 伝統的なPKI実装はX.501分類名を公開鍵に縛りますが、また、アイデンティティはRFC822アドレスかDNS名で指定されるかもしれません。 SIM仕様で、公開鍵に名前を縛るのと同じ信頼できる第三者機関(カリフォルニア)はまた、証明書でプライバシー機密の識別子を入れることができます。 当てにしているパーティー(RP)が既に問題証明書にカリフォルニアを任せるので、また、機密の識別子の検証と結合を含むのは、簡単な拡大です。 別の信頼できる第三者機関は別々にこの結合を確立できましたが、これはインフラストラクチャを複雑にするでしょう。
(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) 明らかに識別子に公開鍵を縛ることによって、この仕様は主張者の識別子を確認して、主張者がその識別子の対象であると確認するために信用にパーティーを許容します。 すなわち、秘密鍵の所有物の証拠は、主張者がアイデンティティがPKI(アーキテクチャによるカリフォルニアか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.
別々のメッセージ(例えば、署名していて暗号化されたSecure MIME(S/MIME)オブジェクト)で同じ目標を達成するために、メッセージは、証明書(例えば、X.501分類名)の証明書かアイデンティティに縛られる必要があるでしょう。 証明書が期限が切れるので、前のソリューションは問題が多いです。 名前が今までにインフラストラクチャで再利用されるなら、後者のソリューションは問題を起こすかもしれません。 証明書における明白な結合は、信頼できるより簡単なソリューションと、その他です。
Park, et al. Standards Track [Page 4] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[4ページ]。
(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.
さらに、このドキュメントは、証明書発行プロセスの間、立ち聞きする者に識別子を明らかにしないで機密の識別子情報を交換できるように、Encryptedペプシ(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は例の使用にケースを供給します。
1.1. Key Words
1.1. キーワード
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Park, et al. Standards Track [Page 5] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[5ページ]。
2. Symbols
2. シンボル
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[FIPS180-1]か、より安全なハッシュ関数が必要です。
SII Sensitive Identification Information
(e.g., Social Security Number).
SIIの機密の識別情報(例えば、社会保険番号)。
SIItype Object Identifier that identifies the type of SII.
SIIのタイプを特定するSIItype Object Identifier。
P A user-chosen password.
P Aユーザによって選ばれたパスワード。
R The random number value generated by a Registration
Authority (RA).
乱数値がRegistration Authority(RA)で生成したR。
PEPSI Privacy-Enhanced Protected Subject Information.
Calculated from the input value P, R, SIItype, SII
using two iteration of H().
ペプシは保護された対象の情報をプライバシーで高めました。 入力値P、R、SIItype、H()のSII使用two繰り返しから、計算されています。
E() The encryption algorithm to encrypt the PEPSI value.
E、() ペプシ値を暗号化する暗号化アルゴリズム。
EPEPSI Encrypted PEPSI.
EPEPSIはペプシを暗号化しました。
D() The decryption algorithm to decrypt the EPEPSI.
D()、EPEPSIを解読する復号化アルゴリズム。
3. Requirements
3. 要件
3.1. Security Requirements
3.1. セキュリティ要件
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(彼女の社会保障Numberなどの)--ボブ、アリスのSIIaに関する知識を必要とする信用パーティー--イブ、機密の識別子によるアリスの証明書--アリスが彼女のSIIaを明かさなければならないRA--アリスの証明書を発行するカリフォルニアを取得する攻撃者
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であるとボブに立証できます。
Park, et al. Standards Track [Page 6] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[6ページ]。
- 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値も等しく見つけにくい問題があります。 すなわち、何も彼女があらかじめ計算できるそれが他の証明書の彼女の攻撃PEPSIs、および彼女が助けるうまくいっている攻撃から学ばないことを助けるいかなる他のも攻撃することがありません。 - カリフォルニアがRAによって通過されたSIIを有効にする必要があるケースの中、カリフォルニアはアリスのSIIaを学びません。 - カリフォルニアは特別な処理なしで"subjectAltName"拡大で追加名前フォームとしてSIMを扱うことができます。 - アリスは、別のSII(SIIx)、およびパスワードが(P)であることを見つけることができないで、それは、彼女が偽のSIIについて断言するのに証明書を使用するのを許容するでしょう。
3.2. Usability Requirements
3.2. ユーザビリティ要件
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値を含む証明書に関連して変更なしで商用既製品ソフトウェア(例えば、標準のブラウザ)を使用できます。
3.3. Solution
3.3. ソリューション
We define SIM as: R || PEPSI
where PEPSI = H(H( P || R || SIItype || SII))
私たちはSIMを以下と定義します。 R|| ペプシが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は正しいです。 3. RAは、無作為の値がR.4であると生成します。 RAは、SIMがペプシがH(H(P| | R| | SIItype| | SII))と等しい=(R| | ペプシ)であると生成します。 5. RAはいくつかのバンドで出ている手段でSIMをアリスに送って、また、カリフォルニアにそれを向かわせます。 6. アリスはcertRequestをカリフォルニアに送ります。 カリフォルニアはGeneralName構造からsubjectAltName拡張子でotherNameのフォームとしてSIMを含むアリスの証明書を作ります。 7. アリスは彼女のCert、P、SIItype、およびSIIをボブに送ります。 それらの秘密性を保存するために安全な通信チャネルで後者の値を伝えなければなりません。
Park, et al. Standards Track [Page 7] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[7ページ]。
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と等しいです。|| その結果SIIについて確かめるアリスの証明書のSIM値への'ペプシ'。
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値がボブによって必要とされないなら(ボブは、既にアリスの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. アリスは彼女のCertをボブに送ります、そして、秘密性を保存するために安全な通信チャネルでP.Pを送らなければなりません。 8. 'ボブは、ペプシ'=H(H(P| | R| | SIItype| | SII))を計算して、SIMを比較できること'はRと等しいです。|| その結果SIIについて確かめるSIMの値への'ペプシ'。
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. ボブは、SIMで証明書でSIMからRを得て、次に、H(中間的値)を計算して、それを値と比較できます、その結果、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).
イブは、アリスの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に値を見つけても、いかなる他のSII値も見つけるのを助けません、新しいRが各ペプシとSIMに使用されるので。
4. Procedures
4. 手順
4.1. SII and SIItype
4.1. SIIとSIItype
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価値の形式と範囲を定義するObject Identifier(OID)です。 例えば、韓国では、1SIItypeが以下の通り定義されます:
-- KISA specific arc
id-KISA OBJECT IDENTIFIER ::=
{iso(1) member-body(2) korea(410) kisa(200004)}
-- 吉舎の特定のアークイド-KISA OBJECT IDENTIFIER:、:= iso(1)メンバーボディー(2)korea(410) kisa(200004)
Park, et al. Standards Track [Page 8] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[8ページ]。
-- 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}
-- 吉舎の特定のOIDsイド-npki OBJECT IDENTIFIER:、:= イド吉舎10イド属性OBJECT IDENTIFIER:、:= イド-npki1イド-kisa-identifyDataオブジェクト識別子:、:= イド属性1イド-VIDオブジェクト識別子:、:= イド-kisa-identifyData10イドSIIオブジェクト識別子:、:= イド-VID1
For closed communities, the SIItype value may be assigned by the CA itself, but it is still recommended that the OID be registered.
閉じている共同体に関しては、SIItype値はカリフォルニア自体によって割り当てられるかもしれませんが、OIDが登録されるのは、まだお勧めです。
4.2. User Chosen Password
4.2. ユーザの選ばれたパスワード
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のキャラクタに関するパスワードを選択することを許可しなければなりません。 RAs SHOULDは、些細なパスワードのユーザ品揃えを防ぐためにパスワードフィルタ規則を実装します。 パスワードのセキュリティ評価基準とパスワードとして手当たりしだいに簡単な発音可能な音節を作成する自動化されたパスワードジェネレータアルゴリズムに関して[FIPS112]と[FIPS180-1]を見てください。
4.3. Random Number Generation
4.3. 乱数発生
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は乱数を生成して、各SIMのためにR.のA新しいRを生成しなければなりません。 Rの長さはハッシュアルゴリズムH.Forの例の出力の長さと同じであるに違いありません、HがSHA-1であるなら、乱数が160ビットでなければなりません。
A Random Number Generator (RNG) that meets the requirements defined in [FIPS 140-2] and its use is strongly recommended.
[FIPS140-2]とその使用で定義された必要条件を満たすRandom Number Generator(RNG)は強く推薦されます。
4.4. Generation of SIM
4.4. SIMの世代
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:
複数のsubjectAltNamesが証明書に現れても、証明書の中のsubjectAltName拡張子におけるSIMは実体を特定します。 以下のアルゴリズムによると、RAsは指定された入力があるSIM値について計算しなければなりません:
SIM = R || PEPSI
where PEPSI = H(H(P || R || SIItype || SII))
シムはRと等しいです。|| ペプシがHと等しいペプシ(H(P| | R| | SIItype| | SII))
Park, et al. Standards Track [Page 9] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[9ページ]。
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 MUSTの両方、ペプシ値の世代と検証には、サポートされてください。 この仕様は他の一方向ハッシュ関数の使用ではなく、SHA-1かSHA-256 SHOULDを排除します。どこでも、相互運用性が関心であるところで使用されます。
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.
また、セクション5.1のASN.1モジュールにSIMのための構文と関連OIDを提供します。 また、セクション5.2はペプシのためにASN.1モジュールで構文について説明します。
4.5. Encryption of PEPSI
4.5. ペプシの暗号化
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.
カリフォルニア(RAであるだけではない)が証明書を下付する前にSIIについて確かめるのが必要であるかもしれません。 RA SHOULDは、この必要条件を満たすために、SIItype、SII、およびSIMを暗号化して、安全なチャンネルで結果をカリフォルニアに送ります。 ユーザSHOULDはその人の証明書要求メッセージのカリフォルニアにまた、同じ値を暗号化して、結果を送ります。 そして、カリフォルニアは、ユーザの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.
以下に注意してください。 特定の暗号化/復号化メソッドは本書では定義されません。 ペプシ価値のユーザからカリフォルニアまでの送信のために、使われた証明書要求プロトコルは暗号化がどう実行されるかを定義します。 RAとカリフォルニアの間のこのデータの伝達のために、暗号化がどう実行されるかに関する詳細は地域にかかわる事柄です。
The syntax and the associated OID for EPEPSI is provided in the ASN.1 modules in Section 5.3.
セクション5.3のASN.1モジュールにEPEPSIのための構文と関連OIDを提供します。
4.6. Certification Request
4.6. 証明要求
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
基本的に、PKCS#10メッセージはまとめて署名される分類名、公開鍵、および任意のセットの属性から成ります。
Park, et al. Standards Track [Page 10] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[10ページ]。
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.
終わりの実体。 この証明書要求形式が使用されているなら、SIM代替名をsubjectAltName拡張子に置かなければなりません。 証明書を発行する前にカリフォルニアがSIIについて確かめるなら、証明要求における、SIMの値をEPEPSIフォームで伝えて、対象は提供しなければなりません。
4.7. Certification
4.7. 証明
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を含む証明書を発行するカリフォルニアはGeneralName構造からのotherNameのフォームとして"subjectAltName"拡大で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.
証明書を発行する前にカリフォルニアがSIIについて確かめる環境で、カリフォルニアは、それがユーザとRAの両方から受けるEPEPSI値を解読して、それらを比較します。 次に、それはそれを有効にします。SII値は正しく対象に制限されています。
SIItype, SII, SIM = D(EPEPSI)
SIItype、SII、SIM=D(EPEPSI)
5. Definition
5. 定義
5.1. SIM Syntax
5.1. SIM構文
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名のための構文を含んでいて、このセクションは指定します。 SIMは3つの分野で構成されます: ハッシュアルゴリズム識別子、権威に選ばれた無作為の値、およびペプシ自体の値。
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 }
イドオンなOBJECT IDENTIFIER:、:= SIM OBJECT IDENTIFIERの上のイド-pkix8イド:、:= イドオンな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
}
SIM:、:= 系列hashAlg AlgorithmIdentifier(authorityRandom OCTET STRING(RAによって選ばれた乱数))はアルゴリズムがあるHashContentの--pEPSI pEPSI OCTET STRING--ハッシュの計算にhashAlgを使用しました。
Park, et al. Standards Track [Page 11] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[11ページ]。
5.2. PEPSI
5.2. ペプシ
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.
このセクションはペプシに構文を指定します。 ペプシは、二度同じハッシュ関数を実行することによって、生成されます。 ペプシはASN.1構造HashContentの上で生成されます。 HashContentには、4つの値があります: ユーザによって選択されたパスワード、権威に選ばれた乱数、識別子タイプ、および識別子自体。
HashContent ::= SEQUENCE {
userPassword UTF8String,
-- user-supplied password
authorityRandom OCTET STRING,
-- RA-chosen random number
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String -- SII
}
HashContent:、:= 系列userPassword UTF8String--ユーザによって与えられたパスワードauthorityRandom OCTET STRING--RAによって選ばれた乱数identifierType OBJECT IDENTIFIER--SIItype識別子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:
ペプシについて計算する前に、実装を従わせると、userPasswordは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]のAppendix B.1で指定されるように。 * InsignificantキャラクターRemoval、ステップ6を省略してください。
5.3. Encrypted PEPSI
5.3. 暗号化されたペプシ
This section describes the syntax for the Encrypted PEPSI. The Encrypted PEPSI has three fields: identifierType, identifier, and SIM.
このセクションはEncryptedペプシのために構文について説明します。 Encryptedペプシには、3つの分野があります: identifierType、識別子、およびSIM。
EncryptedPEPSI ::= SEQUENCE {
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String, -- SII
sIM SIM -- Value of the SIM
}
EncryptedPEPSI:、:= 系列identifierType OBJECT IDENTIFIER--、SIItype識別子UTF8String--SII sIM SIM--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 }
イド-regEPEPSIオブジェクト識別子:、:= イド-pkip3
Park, et al. Standards Track [Page 12] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[12ページ]。
6. Example Usage of SIM
6. SIMの例の使用法
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がカリフォルニア(または、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に縛られることを確かめるのを可能にすることです、RPがおそらくこのSIIに基づく対象を特定するので。
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とパスワードを知っているという事実について確かめることができます。 これはユーザが証明書対象であるというより多くの信用を信用パーティーに与えます。 この形式のユーザアイデンティティ検証がそうでないことに注意して、標準の証明書合法化手順の代わりに使用されますが、むしろそのような手順に加えて使用されてください。
7. Name Constraints
7. 名前規制
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として保存されます。 しかしながら、名前のこのフォームに置くことができる規制が全くありません。
Park, et al. Standards Track [Page 13] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[13ページ]。
8. Security Considerations
8. セキュリティ問題
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つの所有地に依存します: それを逆にすることができないという事実と衝突(特にフォーマット済みデータがある)がまれであるという事実。 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はユーザのアイデンティティの検証を機能アップできます。
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.
証明書が、アップデートされて、a新しいR SHOULDである必要があるときはいつも、発生していてSIM SHOULDになってください。再計算されます。 前の証明書からSIMの値を繰り返すのは、攻撃者が同じ個人のプライバシー目的のために望ましくないかもしれない個人に関連している証明書を特定することを許可します。
Park, et al. Standards Track [Page 14] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[14ページ]。
9. Acknowledgements
9. 承認
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(高く昇るHawk Consulting)、Seungjooキム、Jaehoチョ、Baehyo Park(吉舎)、ビルBurr、モーリー・ドーキン(NIST)、およびインターネットSecurity Technology Forum(ISTF)はSIMとペプシ概念に取り組むためにかなり貢献して、潜在的セキュリティー攻撃を特定しました。 また、ペプシに、望ましい特性とペプシへの増進のセットの彼らのコメントはほとんどのイルミネーションでした。 また、このドキュメントへの彼らの貢献のためにラッセルHousley、スティーブン・ケントとデニス・ピンカスをありがとうございます。
10. IANA Considerations
10. IANA問題
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タイプの仕様で相互運用性を促進するためにオブジェクト識別子の登録を確立するように頼まれるかもしれません。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10:
Certification Request Syntax Specification Version
1.7", RFC 2986, November 2000.
[RFC2986] ニストロム、M.、およびB.Kaliski、「PKCS#10:」 証明は2000年11月に構文仕様バージョン1.7インチ、RFC2986を要求します。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC
3454, December 2002.
[RFC3454] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、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の公開鍵暗号基盤の永久的な識別子」、RFC4043)は2005がそうするかもしれません。
[RFC4211] Schaad, J., "Internet X.509 Public Key
Infrastructure Certificate Request Message Format
(CRMF)", RFC 4211, September 2005.
J.、「インターネットX.509公開鍵暗号基盤証明書要求メッセージ形式(CRMF)」、RFC4211 2005年9月の[RFC4211]Schaad。
11.2. Informative References
11.2. 有益な参照
[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.
[FIPS112] Fedreal情報処理規格公表(FIPSパブ)112、「パスワード用法」、1985年5月30日。
Park, et al. Standards Track [Page 15] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[15ページ]。
[FIPS 180-1] Federal Information Processing Standards
Publication (FIPS PUB) 180-1, "Secure Hash
Standard", 17 April 1995.
[FIPS180-1] 連邦政府の情報処理規格公表(FIPSパブ)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.
[FIPS140-2] 連邦政府の情報処理規格公表(FIPSパブ)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>
「完全なSHA-1インチでの衝突、暗号'05'を見つける」[ワング]Xiaoyunワング、Yiqunリサ殷、およびホンボー・ユー。 <http://www.infosec.sdu.edu.cn/紙/sha1暗号-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、Garak-ドング、Songpa-Gu、ソウル、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リー78、Garak-ドング、Songpa-Gu、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リー韓国情報警備機関78、Garak-ドング、Songpa-Gu、ソウル、138-803大韓民国
Phone: 2-405-5100 EMail: hslee@kisa.or.kr
以下に電話をしてください。 2-405-5100 メールしてください: hslee@kisa.or.kr
Park, et al. Standards Track [Page 16] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[16ページ]。
Sangjoon Park BCQRE Co.,Ltd Yuil Bldg. Dogok-dong 411-14, Kangnam-ku, Seoul, 135-270 REPUBLIC OF KOREA
Sangjoon公園BCQRE社、Ltd Yuilビルディング Dogok-ドング411-14、Kangnam区、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
ゲイザースバーグ、MS8930MD ティムポーク米国商務省標準技術局100の事務局ドライブ、20899
EMail: tim.polk@nist.gov
メール: tim.polk@nist.gov
Park, et al. Standards Track [Page 17] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[17ページ]。
Appendix A. "Compilable" ASN.1 Module, 1988 Syntax
付録A."Compilable"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) }
PKIXSIMiso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズ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)}
PKIX1Explicit88からのAlgorithmIdentifier、AttributeTypeAndValueiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-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) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-SIM OBJECT IDENTIFIER ::= { id-on 6 }
イドオンなOBJECT IDENTIFIER:、:= SIM OBJECT IDENTIFIERの上のイド-pkix8イド:、:= イドオンな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
}
SIM:、:= 系列hashAlg AlgorithmIdentifier(authorityRandom OCTET STRING(RAによって選ばれた乱数))はアルゴリズムがあるHashContentの--pEPSI pEPSI OCTET STRING--ハッシュの計算にhashAlgを使用しました。
-- PEPSI
-- ペプシ
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279
UTF8String:、:= [UNIVERSAL12]IMPLICIT OCTET STRING--このタイプの内容はRFC2279に従います。
HashContent ::= SEQUENCE {
userPassword UTF8String,
-- user-supplied password
authorityRandom OCTET STRING,
HashContent:、:= SEQUENCE、userPassword UTF8String--ユーザによって与えられたパスワードauthorityRandom OCTET STRING
Park, et al. Standards Track [Page 18] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[18ページ]。
-- RA-chosen random number
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String -- SII
}
-- RAによって選ばれた乱数identifierType OBJECT IDENTIFIER--SIItype識別子UTF8String--SII
-- Encrypted PEPSI
-- 暗号化されたペプシ
-- OID for encapsulated content type
-- カプセル化されたcontent typeのためのOID
id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }
イド-regEPEPSIオブジェクト識別子:、:= イド-pkip3
EncryptedPEPSI ::= SEQUENCE {
identifierType OBJECT IDENTIFIER, -- SIItype
identifier UTF8String, -- SII
sIM SIM -- Value of the SIM
}
EncryptedPEPSI:、:= 系列identifierType OBJECT IDENTIFIER--、SIItype識別子UTF8String--SII sIM SIM--SIMの値
END
終わり
Park, et al. Standards Track [Page 19] RFC 4683 Subject Identification Method October 2006
公園、他 規格は同定法2006年10月にRFC4683対象の跡をつけます[19ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Park, et al. Standards Track [Page 20]
公園、他 標準化過程[20ページ]
一覧
スポンサーリンク
