[要約] RFC 4211は、Internet X.509 Public Key Infrastructure (PKI) Certificate Request Message Format (CRMF)に関する文書です。このRFCは、公開鍵証明書のリクエストを生成し、送信するためのフォーマットを定義しています。CRMFは、証明書の発行や更新の際に、利用者の公開鍵やその他の属性を認証局(CA)に提出するために使用されます。このフォーマットは、PKIシステムの効率的な運用を支援し、セキュリティを強化する目的があります。関連するRFCには、RFC 5280 (X.509証明書とCRLのプロファイル)やRFC 4210 (Certificate Management Protocol, CMP)などがあります。
Network Working Group J. Schaad
Request for Comments: 4211 Soaring Hawk Consulting
Obsoletes: 2511 September 2005
Category: Standards Track
Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
インターネットX.509公開キーインフラストラクチャ証明書リクエストメッセージフォーマット（CRMF）
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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol.
このドキュメントでは、証明書要求メッセージ形式（CRMF）の構文とセマンティクスについて説明します。この構文は、X.509証明書の生産を目的として、おそらく登録機関（RA）を介して認証機関（CA）に証明書の要求を伝えるために使用されます。リクエストには通常、公開キーと関連する登録情報が含まれます。このドキュメントは、証明書要求プロトコルを定義しません。
Table Of Contents
目次
1. Introduction and Terminology ....................................3
2. Overview ........................................................3
2.1. Changes since RFC 2511 .....................................4
3. CertReqMessage Syntax ...........................................4
4. Proof-of-Possession (POP) .......................................5
4.1. Signature Key POP ..........................................7
4.2. Key Encipherment Keys ......................................9
4.2.1. Private Key Info Content Type ......................11
4.2.2. Private Key Structures .............................12
4.2.3. Challenge-Response Guidelines ......................13
4.3. Key Agreement Keys ........................................14
4.4. Use of Password-Based MAC .................................14
5. CertRequest syntax .............................................16
6. Controls Syntax ................................................18
6.1. Registration Token Control ................................18
6.2. Authenticator Control .....................................19
6.3. Publication Information Control ...........................19
6.4. Archive Options Control ...................................21
6.5. OldCert ID Control ........................................23
6.6. Protocol Encryption Key Control ...........................23
7. RegInfo Controls ...............................................23
7.1. utf8Pairs .................................................23
7.2. certReq ...................................................24
8. Object Identifiers .............................................24
9. Security Considerations ........................................25
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
11. Acknowledgements ..............................................28
Appendix A. Use of RegInfo for Name-Value Pairs ..................29
A.1. Defined Names ............................................29
A.2. IssuerName, SubjectName, and Validity Value Encoding .....29
Appendix B. ASN.1 Structures and OIDs ............................32
Appendix C. Why do Proof-of-Possession (POP) .....................38
This document describes the Certificate Request Message Format (CRMF). A Certificate Request Message object is used within a protocol to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information.
このドキュメントでは、証明書リクエストメッセージ形式（CRMF）について説明します。証明書リクエストメッセージオブジェクトは、プロトコル内で使用され、X.509証明書の生産の目的で、証明書のリクエストを認証機関（CA）に伝えます（おそらく登録機関（RA）を介して伝えられます。リクエストには通常、公開キーと関連する登録情報が含まれます。
The certificate request object defined in this document is not a stand-alone protocol. The information defined in this document is designed to be used by an externally defined Certificate Request Protocol (CRP). The referencing protocol is expected to define what algorithms are used, and what registration information and control structures are defined. Many of the requirements in this document refer to the referencing Certificate Request Protocol (CRP).
このドキュメントで定義されている証明書要求オブジェクトは、スタンドアロンのプロトコルではありません。このドキュメントで定義されている情報は、外部から定義された証明書要求プロトコル（CRP）によって使用されるように設計されています。参照プロトコルは、どのアルゴリズムが使用されているか、どの登録情報と制御構造が定義されているかを定義することが期待されます。このドキュメントの要件の多くは、参照証明書要求プロトコル（CRP）を指します。
Certificate requests may be submitted by an RA requesting a certificate on behalf of a Subject, by a CA requesting a cross-certificate from another CA, or directly by an End Entity (EE).
証明書リクエストは、被験者に代わって証明書を要求するRAによって、別のCAからの相互承認を要求するCAによって、または最終エンティティ（EE）によって提出される場合があります。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document (in uppercase, as shown) are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントの「必須」、「必要」、「必要」、「必要」、「推奨」、および「5月」は（上記のように）RFC 2119 [RFC2119]で説明されているように解釈されます。
Construction of a certification request involves the following steps:
認定リクエストの構築には、次の手順が含まれます。
a) A CertRequest object is constructed. This object may include the public key, all or a portion of the Subject name, other requested certificate fields, and additional control information related to the registration process. Depending on the CRP, this information can be specified by the Subject and potentially modified by an RA, or specified by the RA based on knowledge of the Subject or documentation presented by the Subject.
a) certrequestオブジェクトが構築されています。このオブジェクトには、公開キー、件名名のすべてまたは一部、その他の要求された証明書フィールド、および登録プロセスに関連する追加の制御情報が含まれます。CRPに応じて、この情報は被験者によって指定され、RAによって潜在的に変更される可能性があるか、被験者が提示した主題または文書の知識に基づいてRAによって指定されます。
b) If required, a proof-of-possession (of the private key corresponding to the public key for which a certificate is being requested) value is calculated.
b) 必要に応じて、証明の証明（証明書が要求されている公開鍵に対応する秘密鍵の）値が計算されます。
c) Additional registration information can be combined with the proof-of-possession value and the CertRequest structure to form a CertReqMessage. Additional registration information can be added by both the Subject and an RA.
c) 追加の登録情報は、入金の証明値とcertrequest構造と組み合わせて、certreqmessageを形成できます。追加の登録情報は、被験者とRAの両方によって追加できます。
d) The CertReqMessage is securely communicated to a CA. Specific means of secure transport are to be specified by each CRP that refers to this document.
d) certreqmessageは、CAに安全に通信されます。安全な輸送の特定の手段は、このドキュメントを参照する各CRPによって指定されます。
1. Addition of an introduction section.
1. 紹介セクションの追加。
2. Addition of the concept of a CRP and language relating to CRPs.
2. CRPに関連するCRPと言語の概念の追加。
3. In section 6.2, changed regToken to authenticator.
3. セクション6.2では、RegTokenを認証器に変更しました。
4. Add information describing the contents of the EncryptedValue structure.
4. 暗号化された値構造の内容を説明する情報を追加します。
5. Changed name and contents of OID {id-regInfo 1}.
5. oid {id-reginfo 1}の名前と内容を変更しました。
6. Added text detailing what goes into the fields of the different structures defined in the document.
6. ドキュメントで定義されているさまざまな構造のフィールドに入るものを詳述するテキストが追加されました。
7. Replaced Appendix A with a reference to [RFC2875]. The only difference is that the old text specified to use subject alt name instead of subject name if subject name was empty. This is not possible for a CA certificate issued using PKIX. It would however be useful to update RFC 2875 to have this fallback position.
7. [RFC2875]を参照して、付録Aを置き換えました。唯一の違いは、件名名が空の場合、サブジェクト名の代わりにサブジェクトALT名を使用するように指定された古いテキストです。これは、PKIXを使用して発行されたCA証明書では不可能です。ただし、RFC 2875を更新して、このフォールバック位置を確保することは便利です。
7. Insert Appendix C describing why POP is necessary and what some of the different POP attacks are.
7. POPが必要な理由と、さまざまなポップ攻撃のいくつかが何であるかを説明する付録Cを挿入します。
8. pop field in the CertReqMsg structure has been renamed to popo to avoid confusion between POP and pop.
8. CertreQMSG構造のPOPフィールドは、POPOとPOPの混乱を避けるためにPopoに改名されました。
9. The use of the EncryptedValue structure has been deprecated in favor of the EnvelopedData structure.
9. 暗号化されたバリュー構造の使用は、封筒構造を支持して非推奨されています。
10. Add details on how private keys are to be structured when encrypted.
10. 暗号化されたときにプライベートキーを構成する方法の詳細を追加します。
11. Allow for POP on key agreement algorithms other than DH.
11. DH以外のキー契約アルゴリズムにPOPを許可します。
A certificate request message is composed of the certificate request, an optional proof-of-possession field, and an optional registration information field.
証明書リクエストメッセージは、証明書要求、オプションのプルーフオブポッセッションフィールド、およびオプションの登録情報フィールドで構成されています。
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL
}
The fields of CertReqMsg have the following meaning:
certreqmsgのフィールドには次の意味があります。
certReq contains the template of the certificate being requested. The template is filled in by (or on behalf of) the Subject. Not all fields within the template need to be specified. Details on this field are found in section 5.
Certreqには、要求されている証明書のテンプレートが含まれています。テンプレートは、被験者によって（または代わって）入力されます。テンプレート内のすべてのフィールドを指定する必要はありません。このフィールドの詳細は、セクション5にあります。
popo contains the value used to demonstrate that the entity that will be identified as the Subject of the certificate is actually in possession of the corresponding private key. This field varies in structure and content based on the public key algorithm and the mode (encryption vs. signature) in which the algorithm is used, as specified in the KeyUsage field of the certificate to be issued. Details on this field are found in section 4.
POPOには、証明書の主題として特定されるエンティティが実際に対応する秘密鍵を所有していることを実証するために使用される値が含まれています。このフィールドの構造とコンテンツは、公開キーアルゴリズムと、発行される証明書のkeyusageフィールドで指定されているように、アルゴリズムが使用されるモード（暗号化と署名）に基づいて異なります。このフィールドの詳細は、セクション4にあります。
regInfo field SHOULD contain only supplementary information relating to the context of the certificate request, where such information is required to fulfill the request. This information might include subscriber contact information, billing information, or other ancillary information useful to fulfillment of the request.
RegINFOフィールドには、リクエストを満たすためにそのような情報が必要な証明書要求のコンテキストに関連する補足情報のみを含める必要があります。この情報には、サブスクライバーの連絡先情報、請求情報、またはリクエストの履行に役立つその他の補助情報が含まれる場合があります。
Information directly related to certificate content SHOULD be included in the certReq content. However, inclusion of additional certReq content by RAs can invalidate the popo field (depending on the details of the POP method used). Therefore, data intended for certificate content MAY be provided in regInfo.
証明書コンテンツに直接関連する情報は、Certreqコンテンツに含める必要があります。ただし、RASによる追加のCertreqコンテンツを含めると、POPOフィールドを無効にする可能性があります（使用するPOPメソッドの詳細に応じて）。したがって、証明書のコンテンツを対象としたデータは、reginfoで提供される場合があります。
It is the responsibility of a referencing CRP to define the details of what can be specified in the regInfo field. This document describes one method of encoding the information found in this field. Details on this encoding are found in Appendix A.
RegINFOフィールドで指定できるものの詳細を定義することは、参照CRPの責任です。このドキュメントでは、このフィールドで見つかった情報をエンコードする1つの方法について説明します。このエンコードの詳細は、付録Aにあります。
In order to prevent certain attacks (see Appendix C) and to allow a CA/RA to properly check the validity of the binding between a subject and a key pair, the PKI management structures specified here make it possible for a subject to prove that it has possession of (i.e., is able to use) the private key corresponding to the public key for which a certificate is requested. A given CRP is free to choose how to enforce POP (e.g., out-of-band procedural means versus the CRMF in-band message) in its certification exchanges. Within a given CRP, CAs and RAs are free to choose from among the POP methods provided (i.e., this is a policy issue local to an RA/CA). A CRP SHOULD define either which POP methods are required, or specify a mechanism for clients to discover the POP methods supported.
特定の攻撃を防止し（付録Cを参照）、CA/RAが被験者とキーペア間の結合の妥当性を適切に確認できるようにするために、ここで指定されたPKI管理構造により、被験者がそれを証明できることを証明することができます。証明書が要求されている公開鍵に対応する秘密鍵を所有している（つまり、使用できる）。指定されたCRPは、認証交換でPOP（たとえば、CRMFインバンドメッセージとより帯域外の手続き手段）を強制する方法を自由に選択できます。特定のCRP内で、CASとRASは、提供されているPOPメソッドから自由に選択できます（つまり、これはRA/CAにローカルな政策問題です）。CRPは、どのポップメソッドが必要かを定義するか、クライアントがサポートされているPOPメソッドを発見するメカニズムを指定する必要があります。
Any CRP referencing this document MUST enforce POP by some means. There are currently many non-PKIX operational protocols in use (various electronic mail protocols are one example) that do not explicitly check the binding between the end entity and the private key. Until operational protocols that do verify the binding (for signature, encryption, and key agreement key pairs) exist, and are ubiquitous, this binding cannot be assumed to have been verified by the CA/RA. Therefore, one cannot truly know if the binding of the public key and the identity in the certificate is actually correct.
このドキュメントを参照するCRPは、何らかの方法でPOPを実施する必要があります。現在、使用中の多くの非PKIX運用プロトコル（さまざまな電子メールプロトコルが1つの例です）があり、最終エンティティと秘密鍵の間のバインディングを明示的にチェックしません。バインディング（署名、暗号化、および主要な一致キーペアの場合）を検証する運用プロトコルが存在し、ユビキタスであるまで、この結合はCA/RAによって検証されたと想定できません。したがって、公開鍵の拘束力と証明書のIDが実際に正しいかどうかを真に知ることはできません。
POP is accomplished in different ways depending on the type of key for which a certificate is requested. If a key can be used for multiple purposes (e.g., a signing and decryption RSA key), then any of the methods MAY be used. Protocol designers need to be aware that there can be hardware limitations on what POP methods may be usable, e.g., if the private key is maintained in a hardware token.
POPは、証明書が要求されるキーのタイプに応じて、さまざまな方法で達成されます。キーを複数の目的に使用できる場合（たとえば、署名および復号化RSAキーなど）、いずれかの方法を使用できます。プロトコル設計者は、ハードウェアトークンで秘密鍵が維持されている場合、ポップメソッドが使用可能になる可能性のあるハードウェアの制限がある可能性があることに注意する必要があります。
This specification allows for cases where POP is validated by the CA, the RA, or both. Some policies require the CA to verify POP during certificate issuance, in which case the RA MUST forward the end entity's CertRequest and ProofOfPossession fields unaltered to the CA. (In this case, the RA could verify the POP and reject failing certificate requests rather than forwarding them to the CA.) If the CA is not required by policy to verify POP, then the RA SHOULD forward the end entity's request and proof, unaltered, to the CA as above. If this is not possible (for example because the RA verifies POP by an out-of-band method), then the RA uses the raVerified element to attest to the CA that the required proof has been validated. If the CA/RA uses an out-of-band method to verify POP (such as physical delivery of CA/RA-generated private keys), then the ProofOfPossession field is omitted.
この仕様により、POPがCA、RA、またはその両方によって検証される場合があります。一部のポリシーでは、CAが証明書の発行中にPOPを検証することを要求しています。この場合、RAは、CAに変更されていないエンティティのエンティティのCERTESTと証明フィールドを転送する必要があります。（この場合、RAはPOPを検証し、CAに転送するのではなく、失敗した証明書要求を拒否することができます。）CAがポリシーでPOPを検証する必要がない場合、RAはエンティティの要求と証明を転送する必要があります。、上記のようにCAに。これが不可能な場合（たとえば、RAが帯域外の方法でPOPを検証するため）、RAは、必要な証明が検証されていることをCAを証明するためにラベリファイされた要素を使用します。CA/RAが帯域外の方法を使用してPOP（CA/RA生成されたプライベートキーの物理的配信など）を検証する場合、ProofPossessionフィールドは省略されています。
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
The fields of ProofOfPossession have the following meaning:
ProofofPossessionのフィールドには次の意味があります。
raVerified indicates that the RA has performed the POP required on the certificate request. This field is used by an RA when 1) the CA is not required to do its own POP verification and 2) the RA needs to change the contents of the certReq field. CRPs MUST provide a method for the RA to sign the ProofOfPossession. A requestor MUST NOT set this field and an RA/CA MUST NOT accept a ProofOfPossession where the requestor sets this field.
Raverifiedは、RAが証明書リクエストで必要なPOPを実行したことを示しています。このフィールドは、1）CAが独自のポップ検証を行う必要がなく、2）RAはCertreqフィールドの内容を変更する必要がある場合、RAによって使用されます。CRPSは、RAがProofofPossessionに署名する方法を提供する必要があります。要求者はこのフィールドを設定してはなりません。RA/CAは、リクエスターがこのフィールドを設定する場合の証明の存在を受け入れてはなりません。
signature is used for performing POP with signature keys. The details of this field are covered in section 4.1.
署名は、署名キーを使用してPOPを実行するために使用されます。このフィールドの詳細については、セクション4.1で説明しています。
keyEncipherment is used for performing POP with key encipherment encryption based keys (i.e., RSA). The details of this field are covered in section 4.2.
KeyEnciphermentは、キーエンカップ暗号化ベースのキー（つまり、RSA）を使用してPOPを実行するために使用されます。このフィールドの詳細については、セクション4.2で説明しています。
keyAgreement is used for performing POP with key agreement type encryption keys (i.e., DH). The details of this field are covered in section 4.3.
KeyAgreementは、Key Asmartionタイプの暗号化キー（つまり、DH）でPOPを実行するために使用されます。このフィールドの詳細については、セクション4.3で説明しています。
POP for a signature key is accomplished by performing a signature operation on a piece of data containing the identity for which the certificate is desired.
署名キーのPOPは、証明書が望まれているIDを含むデータに署名操作を実行することにより実現されます。
There are three cases that need to be looked at when doing a POP for a signature key:
署名キーのためにポップを行うときに検討する必要がある3つのケースがあります。
1. The certificate subject has not yet established an authenticated identity with a CA/RA, but has a password and identity string from the CA/RA. In this case, the POPOSigningKeyInput structure would be filled out using the publicKeyMAC choice for authInfo, and the password and identity would be used to compute the publicKeyMAC value. The public key for the certificate being requested would be placed in both the POPOSigningKeyInput and the Certificate Template structures. The signature field is computed over the DER-encoded POPOSigningKeyInput structure.
1. 証明書の科目は、CA/RAを使用した認証されたアイデンティティをまだ確立していませんが、CA/RAからのパスワードとIDの文字列を持っています。この場合、PoposigingKeyInput構造は、authinfoのpublickeymac選択を使用して記入され、パスワードとIDはpublickeymac値を計算するために使用されます。要求されている証明書の公開鍵は、PopoSigingKeyInputと証明書テンプレート構造の両方に配置されます。署名フィールドは、der-Encoded PopoSigingKeyInput構造を介して計算されます。
2. The CA/RA has established an authenticated identity for the certificate subject, but the requestor is not placing it into the certificate request. In this case, the POPOSigningKeyInput structure would be filled out using the sender choice for authInfo. The public key for the certificate being requested would be placed in both the POPOSigningKeyInput and the Certificate Template structures. The signature field is computed over the DER-encoded POPOSigningKeyInput structure.
2. CA/RAは、証明書の科目の認証されたIDを確立していますが、リクエスターはそれを証明書要求に入れていません。この場合、authinfoの送信者の選択を使用して、ポポジンキーインプット構造が記入されます。要求されている証明書の公開鍵は、PopoSigingKeyInputと証明書テンプレート構造の両方に配置されます。署名フィールドは、der-Encoded PopoSigingKeyInput構造を介して計算されます。
3. The certificate subject places its name in the Certificate Template structure along with the public key. In this case the poposkInput field is omitted from the POPOSigningKey structure. The signature field is computed over the DER-encoded certificate template structure.
3. 証明書の対象は、公開キーとともに証明書テンプレート構造にその名前を配置します。この場合、PopoSingputフィールドはPopoSigingKey構造から省略されています。署名フィールドは、derエンコードされた証明書テンプレート構造で計算されます。
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
The fields of POPOSigningKey have the following meaning:
PoposigingKeyのフィールドには、次の意味があります。
poposkInput contains the data to be signed, when present. This field MUST be present when the certificate template does not contain both the public key value and a subject name value.
Poposkinputには、署名するデータが含まれています。このフィールドは、証明書テンプレートに公開キー値と件名名値の両方が含まれていない場合に存在する必要があります。
algorithmIdentifier identifiers the signature algorithm and an associated parameters used to produce the POP value.
AlgorithMidentifier IDは、署名アルゴリズムと、POP値を生成するために使用される関連パラメーターを識別します。
signature contains the POP value produce. If poposkInput is present, the signature is computed over the DER-encoded value of poposkInput. If poposkInput is absent, the signature is computed over the DER-encoded value of certReq.
署名には、ポップ値プロデュースが含まれています。Poposkinputが存在する場合、署名はPopoSkinputのderエンコード値で計算されます。Poposkinputが存在しない場合、署名はcertreqのderエンコード値で計算されます。
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- used only if an authenticated identity has been
-- established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate)
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- on the DER-encoded value of publicKey
publicKey SubjectPublicKeyInfo } -- from CertTemplate
The fields of POPOSigningKeyInput have the following meaning:
PoposigingKeyInputのフィールドには、次の意味があります。
sender contains an authenticated identity that has been previously established for the subject.
送信者には、主題のために以前に確立された認証されたアイデンティティが含まれています。
publicKeyMAC contains a computed value that uses a shared secret between the CA/RA and the certificate requestor.
PublicKeymacには、CA/RAと証明書要求者の間に共有された秘密を使用する計算値が含まれています。
publicKey contains a copy of the public key from the certificate template. This MUST be exactly the same value as is contained in the certificate template.
PublicKeyには、証明書テンプレートからの公開キーのコピーが含まれています。これは、証明書テンプレートに含まれる値とまったく同じ値である必要があります。
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
value BIT STRING }
The fields of PKMACValue have the following meaning:
pkmacvalueのフィールドには次の意味があります。
algId identifies the algorithm used to compute the MAC value. All implementations MUST support id-PasswordBasedMAC. The details on this algorithm are presented in section 4.4.
ALGIDは、MAC値の計算に使用されるアルゴリズムを識別します。すべての実装は、id-passwordbasedmacをサポートする必要があります。このアルゴリズムの詳細は、セクション4.4に示されています。
value contains the computed MAC value. The MAC value is computed over the DER-encoded public key of the certificate subject.
値には、計算されたMac値が含まれています。MAC値は、証明書科目のderエンコードされた公開キーで計算されます。
The CA/RA identifies the shared secret to be used by looking at 1) the general name field in the certificate request or 2) either the regToken (see section 6.1) or authToken (see section 6.2) controls.
CA/RAは、1）証明書リクエストの一般名フィールドまたは2）RegToken（セクション6.1を参照）またはAuthToken（セクション6.2を参照）コントロールを調べて使用する共有秘密を特定します。
POP for key encipherment keys is accomplished by one of three different methods. The private key can be provided to the CA/RA, an encrypted challenge from the CA/RA can be decrypted (direct method), or the created certificate can be returned encrypted and used as the challenge response (indirect method).
キーエンシファメントキー用のPOPは、3つの異なる方法のいずれかによって達成されます。秘密鍵はCA/RAに提供できます。CA/RAからの暗号化されたチャレンジを復号化することができます（直接的な方法）、または作成された証明書を暗号化して、チャレンジ応答として使用することができます（間接的な方法）。
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING, -- deprecated
subsequentMessage [1] SubsequentMessage,
dhMAC [2] BIT STRING, -- deprecated
agreeMAC [3] PKMACValue,
encryptedKey [4] EnvelopedData }
-- for keyAgreement (only), possession is proven in this message
-- (which contains a MAC (over the DER-encoded value of the
-- certReq parameter in CertReqMsg, which must include both subject
-- and publicKey) based on a key derived from the end entity's
-- private DH key and the CA's public DH key);
-- the dhMAC value MUST be calculated as per the directions given
-- in RFC 2875 for static DH proof-of-possession.
SubsequentMessage ::= INTEGER {
encrCert (0),
challengeResp (1) }
The fields of POPOPrivKey have the following meaning:
Popoprivkeyのフィールドには次の意味があります。
thisMessage contains the encrypted private key for which a certificate is to be issued. The possession of the private key is proved by providing it to the CA/RA. This field was incorrectly typed when the specification was first written. The correct way to use this field is to create an EncryptedValue structure where the encrypted content is the private key, the EncryptedValue structure is then wrapped in the BIT STRING type. This field has been deprecated in favor of encryptedKey.
Thismessageには、証明書が発行される暗号化された秘密鍵が含まれています。秘密鍵の所有は、それをCA/RAに提供することによって証明されます。このフィールドは、仕様が最初に書かれたときに誤って入力されました。このフィールドを使用する正しい方法は、暗号化されたコンテンツが秘密鍵である暗号化されたバリュー構造を作成することです。暗号化されたバリュー構造はビット文字列タイプに包まれます。このフィールドは、暗号化されたKeyを支持して廃止されました。
subsequentMessage is used to indicate that the POP will be completed by decrypting a message from the CA/RA and returning a response. The type of message to be decrypted is indicated by the value used.
後続の問題は、CA/RAからのメッセージを復号化して応答を返すことにより、POPが完了することを示すために使用されます。復号化されるメッセージのタイプは、使用される値によって示されます。
encrCert indicates that the certificate issued is to be returned in an encrypted form. The requestor is required to decrypt the certificate and prove success to the CA/RA. The details of this are provided by the CRP.
Encrcertは、発行された証明書が暗号化された形式で返品されることを示しています。要求者は、証明書を復号化し、CA/RAに成功を証明する必要があります。この詳細はCRPによって提供されます。
challengeResponse indicates that a challenge message is to be sent from the CA/RA to the requestor. The details of the challenge message and the response are to be provided by the CRP.
Challengeresponseは、CA/RAからRequestorにCA/RAから送信されることを示しています。チャレンジメッセージと応答の詳細は、CRPによって提供されます。
dhMAC is used for Diffie-Hellman key agreement keys. It contains a computed MAC that is obtained by using the requestor's private key and the CA/RA public key. The use of this field is deprecated in favor of the agreeMAC field. Details are covered in section 4.3.
DHMACは、diffie-hellmanキー契約キーに使用されます。要求者の秘密鍵とCA/RA公開キーを使用して取得される計算されたMacが含まれています。このフィールドの使用は、合意フィールドを支持して廃止されます。詳細については、セクション4.3で説明します。
agreeMAC is used for key agreement keys. It contains a computed MAC that is obtained by using the requestor's private key and a matching CA/RA public key. Details are covered in section 4.3.
契約は、キー契約キーに使用されます。これには、要求者の秘密鍵と一致するCA/RA公開キーを使用して取得される計算されたMacが含まれています。詳細については、セクション4.3で説明します。
macAlg contains the algorithm identifying the method used to compute the MAC value.
Macalgには、Mac値の計算に使用される方法を識別するアルゴリズムが含まれています。
macValue contains the computed MAC value.
MacValueには、計算されたMac値が含まれています。
encryptedKey contains the encrypted private key matching the public key for which the certificate is to be issued. It also contains an identification value to indicate it was constructed by the requestor of the certificate. The enveloped content type MUST be id-ct-encKeyWithID.
暗号化されたKeyには、証明書が発行される公開鍵と一致する暗号化された秘密鍵が含まれています。また、証明書の要求者によって構築されたことを示すための識別値も含まれています。包括的なコンテンツタイプは、id-ct-eckeywithidでなければなりません。
It is expected that protocols that incorporate this specification will include the confirmation and challenge-response messages necessary for a complete protocol.
この仕様を組み込んだプロトコルには、完全なプロトコルに必要な確認と課題の応答メッセージが含まれることが予想されます。
This content type is used for 1) proving possession of private keys and 2) escrow of private keys (using the archive options control in section 6.4). This structure is based on the private key info structure from [PKCS8] but has one deliberate difference. There is a potential attack on escrow agents if they decrypt the private key but don't know to whom the encrypted key is supposed to belong. An attacker could intercept the encrypted private key, build a certificate request around it and then ask for a recovery operation on the private key.
このコンテンツタイプは、1）プライベートキーの所有と2）プライベートキーのエスクローを証明するために使用されます（セクション6.4のアーカイブオプションコントロールを使用）。この構造は、[PKCS8]の秘密のキー情報構造に基づいていますが、意図的な違いが1つあります。エスクローエージェントが秘密鍵を復号化するが、暗号化されたキーが誰に属しているかわからない場合、エスクローエージェントに潜在的な攻撃があります。攻撃者は、暗号化された秘密鍵をインターセプトし、その周りに証明書リクエストを作成し、秘密鍵で回復操作を求めることができます。
This content type and its structure are:
このコンテンツタイプとその構造は次のとおりです。
id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}
EncKeyWithID ::= SEQUENCE {
privateKey PrivateKeyInfo,
identifier CHOICE {
string UTF8String,
generalName GeneralName
} OPTIONAL
}
PrivateKeyInfo ::= SEQUENCE {
version INTEGER,
privateKeyAlgorithm AlgorithmIdentifier,
privateKey OCTET STRING,
attributes [0] IMPLICIT Attributes OPTIONAL
}
Attributes ::= SET OF Attribute
The fields of EncKeyWithID are defined as:
EnckeyWithidのフィールドは、次のように定義されています。
privateKey contains the encoded private key. Definitions for three private key formats are included in this document. Specifications for asymmetric algorithms need to include both the public and private key definitions for consistency.
privateKeyには、エンコードされた秘密鍵が含まれています。このドキュメントには、3つの秘密キー形式の定義が含まれています。非対称アルゴリズムの仕様では、一貫性のためのパブリックキー定義と秘密キー定義の両方を含める必要があります。
identifier contains a name that the CA/RA can associate with the requestor. This will generally be either the DN of a certificate or a text token passed and known to both the requestor and the CA/RA. This field MUST be present if the purpose is to prove possession of the private key. The field SHOULD be present if archiving a key and the archive agent is expected to decrypt the key.
識別子には、CA/RAが要求者に関連付けることができる名前が含まれています。これは通常、証明書のDNまたは渡され、リクエスターとCA/RAの両方に知られているテキストトークンのいずれかです。目的が秘密鍵の所有を証明することである場合、このフィールドが存在する必要があります。キーをアーカイブし、アーカイブエージェントがキーを解読することが期待される場合は、フィールドが存在する必要があります。
The fields of PrivatekeyInfo are define as:
privateKeyInfoのフィールドは次のように定義されています。
version MUST be the value 0
バージョンは値0でなければなりません
privateKeyAlgorithm contains the identifier for the private key object
privateKeyAlgorithmには、秘密キーオブジェクトの識別子が含まれています
privateKey is an octet string whose contents is the private key and whose format is defined by the value of privateKeyAlgorithm.
PrivateKeyは、内容がプライベートキーであり、その形式がprivateKeyAlgorithmの値によって定義されるOctet Stringです。
attributes is a set of attributes. They are extended information that is part of the private key information.
属性は一連の属性です。それらは、秘密のキー情報の一部である拡張情報です。
We are defining the structures here to be used for three algorithms.
ここでは、3つのアルゴリズムに使用される構造を定義しています。
When creating a PrivateKeyInfo for a D-H key, the following rules apply:
D-HキーのPrivateKeyInfoを作成する場合、次のルールが適用されます。
1. The privateKeyAlgorithm MUST be set to id-dh-private-number. The parameter for id-dh-private-number is DomainParameters (imported from [PKIXALG]).
1. privateKeyAlgorithmは、ID-DH-Private-Numberに設定する必要があります。ID-DH-Private-NumberのパラメーターはdomainParameters（[pkixalg]からインポート）です。
2. The ASN structure for privateKey MUST be
2. privateKeyのASN構造はそうでなければなりません
DH-PrivateKey ::= INTEGER
3. The attributes field MUST be omitted.
3. 属性フィールドを省略する必要があります。
When creating a PrivateKeyInfo for a DSA key, the following rules apply:
DSAキー用にprivatekeyinfoを作成する場合、次のルールが適用されます。
1. The privateKeyAlgorithm MUST be set to id-dsa. The parameters for id-dsa is Dss-Parms (imported from [PKIXALG]).
1. privateKeyAlgorithmはID-DSAに設定する必要があります。ID-DSAのパラメーターはDSS-Parms（[pkixalg]からインポート）です。
2. The ASN structure for privateKey MUST be
2. privateKeyのASN構造はそうでなければなりません
DSA-PrivateKey ::= INTEGER
3. The attributes field MUST be omitted.
3. 属性フィールドを省略する必要があります。
When creating a PrivateKeyInfo for an RSA key, the following rules apply:
RSAキー用のprivatekeyinfoを作成する場合、次のルールが適用されます。
1. The privateKeyAlgorithm MUST be set to rsaEncryption.
1. privatekeyalgorithmは、rsaencryptionに設定する必要があります。
2. The ASN structure for privateKey MUST be RSAPrivateKey (defined in [PKCS1])
2. privateKeyのASN構造はrsaprivateKeyでなければなりません（[PKCS1]で定義）
3. The attributes field MUST be omitted.
3. 属性フィールドを省略する必要があります。
The following provides guidelines to enrollment protocol authors about how an indirect proof-of-possession is expected to work and about some of the areas where one needs to be careful in crafting the messages to implement this POP method.
以下は、間接的な証明の実証がどのように機能するかについての登録プロトコル著者へのガイドラインと、このPOPメソッドを実装するためにメッセージを作成する際に注意する必要がある領域のいくつかについてのガイドラインを提供します。
1. The original enrollment request includes a proof of identity of some type and the public portion of the encryption key. Note that the proof of identity needs to cover the public portion of the encryption key to prevent substitution attacks (where the attacker changes your public key for his public key).
1. 元の登録リクエストには、暗号化キーのあるタイプと公開部分のアイデンティティの証明が含まれています。アイデンティティの証明は、交代攻撃を防ぐために暗号化キーの公共部分をカバーする必要があることに注意してください（攻撃者が公開鍵のために公開鍵を変更する場合）。
2. The response message from the server includes an encrypted data value of some type. That value needs to be authenticated in some fashion as having come from the server. The specification needs to include the specifics of how this value is returned for the different key types. For RSA keys, the value can be specified as being directly encrypted by the RSA public key; this will not work for a D-H key where you need to specify an indirect mechanism to encrypt the value.
2. サーバーからの応答メッセージには、何らかのタイプの暗号化されたデータ値が含まれています。その値は、サーバーから来たように、何らかの形で認証される必要があります。仕様には、さまざまなキータイプのこの値がどのように返されるかの詳細を含める必要があります。RSAキーの場合、値はRSAの公開キーによって直接暗号化されるように指定できます。これは、値を暗号化するための間接メカニズムを指定する必要があるD-Hキーでは機能しません。
3. The second request message includes a hash of the decrypted value. This message MUST NOT be just the hash of the encrypted value, as one should never "sign" a completely random value. It is desirable to include information such as the identity string in the hashing process so that this can be made explicitly. This returned value MUST be included in a second proof of identity.
3. 2番目の要求メッセージには、復号化された値のハッシュが含まれます。このメッセージは、完全にランダムな値に「署名」してはならないため、暗号化された値のハッシュだけではありません。これを明示的に行うことができるように、ハッシュプロセスにIdentity文字列などの情報を含めることが望ましいです。この返された価値は、アイデンティティの2番目の証明に含める必要があります。
It is strongly suggested that transaction identifiers and nonce values be required when performing indirect POP, as this allows for 1) tying the different messages in the process together and 2) letting each entity inject some amount of random data into the process of doing identity proofs.
間接POPを実行するときにトランザクション識別子とNonCE値が必要であることが強くお勧めします。。
POP for key agreement keys is accomplished by one of four different methods. The first three are identical to those presented above for key encryption keys. The fourth method takes advantage of the fact that a shared secret is produced and that the value can be used to MAC information.
キー契約キーのPOPは、4つの異なる方法のいずれかによって達成されます。最初の3つは、キー暗号化キーについて上記のものと同じです。4番目の方法は、共有された秘密が生成され、値をMAC情報に使用できるという事実を利用します。
When the direct or indirect encryption methods presented above are used, the CA/RA will need to create an ephemeral key for those cases where the encryption algorithm parameters do not match between the CA/RA and the requestor.
上記の直接または間接的な暗号化方法を使用する場合、CA/RAは、暗号化アルゴリズムのパラメーターがCA/RAとリクエスターの間で一致しない場合には、短命キーを作成する必要があります。
The end entity may also MAC the certificate request (using a shared secret key derived from computation) as a fourth alternative for demonstrating POP. This option may be used only if the CA/RA already has a certificate that is known to the end entity and if the Subject is able to use the CA/RA's parameters.
End Entityは、POPを実証するための4番目の代替手段として、証明書要求（計算から派生した共有シークレットキーを使用）をMACすることもできます。このオプションは、CA/RAが既に最終エンティティに知られている証明書を持っている場合、および被験者がCA/RAのパラメーターを使用できる場合にのみ使用できます。
For the DH key agreement algorithm, all implementations MUST support the static DH Proof-of-Possession. Details on this algorithm can be found in section 3 of [RFC2875]. NOTE: If either the subject or issuer name in the CA certificate is empty, then the alternative name should be used in its place.
DHキー契約アルゴリズムの場合、すべての実装は静的DHプルーフオブポッセッションをサポートする必要があります。このアルゴリズムの詳細は、[RFC2875]のセクション3に記載されています。注：CA証明書の件名または発行者名のいずれかが空の場合、代替名をその場所で使用する必要があります。
This MAC algorithm was designed to take a shared secret (a password) and use it to compute a check value over a piece of information. The assumption is that, without the password, the correct check value cannot be computed. The algorithm computes the one-way function multiple times in order to slow down any dictionary attacks against the password value.
このMacアルゴリズムは、共有秘密（パスワード）を使用し、それを使用して情報を使用してチェック値を計算するように設計されています。仮定は、パスワードがなければ、正しいチェック値を計算できないということです。アルゴリズムは、パスワード値に対する辞書攻撃を遅くするために、一方向関数を複数回計算します。
The algorithm identifier and parameter structure used for Password-Based MAC is:
パスワードベースのMacに使用されるアルゴリズム識別子とパラメーター構造は次のとおりです。
id-PasswordBasedMAC OBJECT IDENTIFIER ::=
{ 1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
)
The fields of PEMParameter have the following meaning:
Pemparameterのフィールドには、次の意味があります。
salt contains a randomly generated value used in computing the key of the MAC process. The salt SHOULD be at least 8 octets (64 bits) long.
塩には、MACプロセスのキーの計算に使用されるランダムに生成された値が含まれています。塩は少なくとも8オクテット（64ビット）の長さでなければなりません。
owf identifies the algorithm and associated parameters used to compute the key used in the MAC process. All implementations MUST support SHA-1.
OWFは、MACプロセスで使用されるキーを計算するために使用されるアルゴリズムと関連するパラメーターを識別します。すべての実装は、SHA-1をサポートする必要があります。
iterationCount identifies the number of times the hash is applied during the key computation process. The iterationCount MUST be a minimum of 100. Many people suggest using values as high as 1000 iterations as the minimum value. The trade off here is between protection of the password from attacks and the time spent by the server processing all of the different iterations in deriving passwords. Hashing is generally considered a cheap operation but this may not be true with all hash functions in the future.
IterationCountは、主要な計算プロセス中にハッシュが適用される回数を識別します。IterationCountは最低100でなければなりません。多くの人は、最小値として1000の反復値を高い値を使用することを提案しています。ここでのトレードオフは、攻撃からのパスワードの保護と、サーバーが使用する時間の時間の間にあります。ハッシュは一般に安価な操作と見なされますが、これは将来のすべてのハッシュ機能では当てはまらない場合があります。
mac identifies the algorithm and associated parameters of the MAC function to be used. All implementations MUST support HMAC-SHA1 [HMAC]. All implementations SHOULD support DES-MAC and Triple-DES-MAC [PKCS11].
MACは、使用するMAC関数のアルゴリズムと関連するパラメーターを識別します。すべての実装は、HMAC-SHA1 [HMAC]をサポートする必要があります。すべての実装は、DES-MACおよびTRIPLE-DES-MAC [PKCS11]をサポートする必要があります。
The following is pseudo-code for the algorithm:
以下は、アルゴリズムの擬似コードです。
Inputs: pw - an octet string containing the user's password data - an octet string containing the value to be MAC-ed Iter - iteration count
入力：PW-ユーザーのパスワードデータを含むオクテット文字
Output: MAC - an octet string containing the resultant MAC value
出力：Mac-結果のMac値を含むOctet文字列
1. Generate a random salt value S
1. ランダム塩値を生成します
2. Append the salt to the pw. K = pw || salt.
2. 塩をPWに追加します。K = PW ||塩。
3. Hash the value of K. K = HASH(K)
3. ハッシュkの値。k=ハッシュ（k）
4. If Iter is greater than zero. Iter = Iter - 1. Goto step 3.
4. iterがゼロより大きい場合。iter = iter -1。gotoステップ3。
5. Compute an HMAC as documented in [HMAC].
5. [HMAC]で文書化されているようにHMACを計算します。
MAC = HASH( K XOR opad, HASH( K XOR ipad, data) )
Where opad and ipad are defined in [HMAC].
ここで、OpadとiPadは[HMAC]で定義されています。
The CertRequest syntax consists of a request identifier, a template of certificate content, and an optional sequence of control information.
Certrequest構文は、リクエスト識別子、証明書コンテンツのテンプレート、およびオプションの制御情報シーケンスで構成されています。
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, --Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL } --at least one must be present
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
The fields of CertRequest have the following meaning:
Certre -Equestのフィールドには、次の意味があります。
certReqId contains an integer value that is used by the certificate requestor to associate a specific certificate request with a certificate response.
CertreQidには、特定の証明書要求を証明書の応答に関連付けるために証明書要求者が使用する整数値が含まれています。
certTemplate contains a template of an X.509 certificate. The requestor fills in those fields for which specific values are desired. Details on the fields are given below.
certTemplateには、x.509証明書のテンプレートが含まれています。要求者は、特定の値が望まれるフィールドに記入します。フィールドの詳細を以下に示します。
controls contains attributes that are not part of the certificate, but control the context in which the certificate is to be issued. Details on the controls defined in this document can be found in section 6. Other documents may define other controls. CRPs are responsible for specifying which controls are required.
コントロールには、証明書の一部ではなく、証明書が発行されるコンテキストを制御する属性が含まれています。このドキュメントで定義されているコントロールの詳細は、セクション6にあります。他のドキュメントでは、他のコントロールを定義できます。CRPSは、どのコントロールが必要かを指定する責任があります。
The fields of CertTemplate have the following meaning:
certTemplateのフィールドには次の意味があります。
version MUST be 2 if supplied. It SHOULD be omitted.
バージョンが提供されている場合は2でなければなりません。省略する必要があります。
serialNumber MUST be omitted. This field is assigned by the CA during certificate creation.
SerialNumberを省略する必要があります。このフィールドは、証明書作成中にCAによって割り当てられます。
signingAlg MUST be omitted. This field is assigned by the CA during certificate creation.
singingalgは省略する必要があります。このフィールドは、証明書作成中にCAによって割り当てられます。
issuer is normally omitted. It would be filled in with the CA that the requestor desires to issue the certificate in situations where an RA is servicing more than one CA.
通常、発行者は省略されています。RAが複数のCAを使用している状況で、要求者が証明書を発行したいと望んでいるCAで満たされます。
validity is normally omitted. It can be used to request that certificates either start at some point in the future or expire at some specific time. A case where this field would commonly be used is when a cross certificate is issued for a CA. In this case the validity of an existing certificate would be placed in this field so that the new certificate would have the same validity period as the existing certificate. If validity is not omitted, then at least one of the sub-fields MUST be specified. The sub-fields are as follows:
通常、妥当性は省略されています。証明書は、将来のある時点で開始するか、特定の時間に期限切れになることを要求するために使用できます。このフィールドが一般的に使用される場合は、CAのクロス証明書が発行される場合です。この場合、既存の証明書の有効性はこのフィールドに配置され、新しい証明書が既存の証明書と同じ有効期間を持つようにします。妥当性が省略されていない場合、少なくとも1つのサブフィールドを指定する必要があります。サブフィールドは次のとおりです。
notBefore contains the requested start time of the certificate. The time follows the same rules as the notBefore time in [PROFILE].
証明書の要求された開始時間が含まれる前に。時間は、[プロファイル]の時間前と同じルールに従います。
notAfter contains the requested expiration time of the certificate. The time follows the same rules as the notAfter time in [PROFILE].
Notafterには、証明書の要求された有効期限が含まれています。時間は、[プロファイル]の時間と同じルールに従います。
subject is filled in with the suggested name for the requestor. This would normally be filled in by a name that has been previously issued to the requestor by the CA.
被験者には、リクエスターの提案された名前が記入されています。これは通常、CAによって以前にリクエスターに発行された名前によって記入されます。
publicKey contains the public key for which the certificate is being created. This field MUST be filled in if the requestor generates its own key. The field is omitted if the key is generated by the RA/CA.
PublicKeyには、証明書が作成されている公開鍵が含まれています。要求者が独自のキーを生成する場合、このフィールドに記入する必要があります。キーがRA/CAによって生成される場合、フィールドは省略されます。
issuerUID MUST be omitted. This field has been deprecated in [PROFILE].
Issueruidは省略する必要があります。このフィールドは[プロファイル]で非推奨されています。
subjectUID MUST be omitted. This field has been deprecated in [PROFILE].
件名は省略する必要があります。このフィールドは[プロファイル]で非推奨されています。
extensions contains extensions that the requestor wants to have placed in the certificate. These extensions would generally deal with things such as setting the key usage to keyEncipherment.
拡張機能には、要求者が証明書に入れたい拡張機能が含まれています。これらの拡張機能は、一般に、キー使用量をkeyenciphermentに設定するなどのことを扱います。
With the exception of the publicKey field, the CA/RA is permitted to alter any requested field. The returned certificate needs to be checked by the requestor to see if the fields have been set in an acceptable manner. CA/RA SHOULD use the template fields if possible.
PublicKeyフィールドを除き、CA/RAは要求されたフィールドを変更することが許可されています。返品された証明書は、リクエスターがチェックして、フィールドが許容可能な方法で設定されているかどうかを確認する必要があります。CA/RAは、可能であればテンプレートフィールドを使用する必要があります。
There are cases where all fields of the template can be omitted. If the key generation is being done at the CA/RA and the identity proof is placed in a different location (such as the id-regCtrl-regToken below), then there are no fields that need to be specified by the certificate requestor.
テンプレートのすべてのフィールドを省略できる場合があります。キー生成がCA/RAで行われ、IDの証明が別の場所（以下のID-Regctrl-Regtokenなど）に配置されている場合、証明書要求者が指定する必要があるフィールドはありません。
The generator of a CertRequest may include one or more control values pertaining to the processing of the request.
Certre -Equestのジェネレーターには、リクエストの処理に関する1つ以上の制御値が含まれる場合があります。
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
The following controls are defined by this document: regToken (section 6.1); authenticator (section 6.2); pkiPublicationInfo (section 6.3); pkiArchiveOptions (section 6.4); oldCertID (section 6.5); protocolEncrKey (section 6.6). Each CRP MUST define the set of controls supported by that protocol. Additional controls may be defined by additional RFCs or by the CRP protocol itself.
次のコントロールは、このドキュメントで定義されています。認証機（セクション6.2）;pkipublicationInfo（セクション6.3）;pkiarchiveoptions（セクション6.4）;OldCertid（セクション6.5）;Protocolencrkey（セクション6.6）。各CRPは、そのプロトコルによってサポートされているコントロールのセットを定義する必要があります。追加のコントロールは、追加のRFCまたはCRPプロトコル自体によって定義される場合があります。
A regToken control contains one-time information (either based on a secret value or other shared information) intended to be used by the CA to verify the identity of the subject prior to issuing a certificate. Upon receipt of a certification request containing a value for regToken, the receiving CA verifies the information in order to confirm the identity claimed in the certification request.
Regtoken Controlには、証明書を発行する前に被験者のIDを検証するためにCAが使用することを目的とした1回限りの情報（秘密の値またはその他の共有情報に基づく）が含まれています。Regtokenの値を含む認定要求を受け取ると、受信CAは認証要求で請求されているIDを確認するために情報を検証します。
The value for regToken may be generated by the CA and provided out of band to the subscriber, or may otherwise be available to both the CA and the subscriber. The security of any out-of-band exchange should be commensurate with the risk that the CA will tolerate with regard to accepting an intercepted value from someone other than the intended subscriber. The regToken value is not encrypted on return, if the data is considered to be sensitive, it needs to be shrouded by the requestor.
RegTokenの値はCAによって生成され、サブスクライバーにバンドから提供される場合や、CAとサブスクライバーの両方が利用できる場合があります。バンド外交換のセキュリティは、CAが意図したサブスクライバー以外の誰かから傍受された価値を受け入れることに関して容認するリスクに見合っている必要があります。Regtoken値は返品時に暗号化されません。データが感度が高いと見なされる場合は、リクエスターが覆す必要があります。
The regToken control is used only for initialization of an end entity into the PKI, whereas the authenticator control (see section 7.2) can be used for the initial as well as subsequent certification requests.
Regtoken Controlは、PKIへの終了エンティティの初期化にのみ使用されますが、認証因子制御（セクション7.2を参照）は、初期およびその後の認証要求に使用できます。
In some instances of use the value for regToken could be a text string or a numeric quantity such as a random number. In the latter case, the value is encoded as a text string representation of the binary quantity. The encoding of regToken SHALL be UTF8String.
使用の場合には、RegTokenの値は、テキスト文字列または乱数などの数値です。後者の場合、値はバイナリ量のテキスト文字列表現としてエンコードされます。RegTokenのエンコードはUTF8STRINGでなければなりません。
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
Without prior agreement between the subscriber and CA agents, this value would be a textual shared secret of some type. If a computed value based on that shared secret is to be used instead, it is suggested that the CRP define a new registration control for that specific computation.
サブスクライバーとCAのエージェント間の事前の合意がなければ、この値は何らかのタイプのテキスト共有秘密になります。その共有秘密に基づいた計算値が代わりに使用される場合、CRPはその特定の計算の新しい登録制御を定義することが示唆されています。
An authenticator control contains information used on an ongoing basis to establish a non-cryptographic check of identity in communication with the CA. Examples include: mother's maiden name, last four digits of social security number, or other knowledge-based information shared with the subscriber's CA; a hash of such information; or other information produced for this purpose. The value for an authenticator control may be generated by the subscriber or by the CA.
Authenticator Controlには、CA。例には、以下が含まれます。母親の乙女名、社会保障番号の最後の4桁、または加入者のCAと共有されるその他の知識ベースの情報。そのような情報のハッシュ。またはこの目的のために作成されたその他の情報。認証装置コントロールの値は、サブスクライバーまたはCAによって生成される場合があります。
In some instances of use, the value for authenticator could be a text string or a numeric quantity such as a random number. The value in the latter case is encoded as a text string representation of the binary quantity. The encoding of authenticator SHALL be UTF8String.
使用の場合には、認証因子の値は、テキスト文字列または乱数などの数値である可能性があります。後者の場合の値は、バイナリ量のテキスト文字列表現としてエンコードされます。AuthenticatorのエンコーディングはUTF8STRINGでなければなりません。
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
When deciding whether to use an authenticator or a regToken, use the following guidelines. If the value is a one-time usage value, then regToken would be used. If the value has a long-term usage, then the authenticator control would be used.
AuthenticatorとRegtokenを使用するかどうかを決定するときは、次のガイドラインを使用してください。値が1回限りの使用値である場合、RegTokenが使用されます。値に長期的な使用法がある場合、認証器制御が使用されます。
The pkiPublicationInfo control enables subscribers to influence the
CA/RA's publication of the certificate. This control is considered
advisory and can be ignored by CAs/RAs. It is defined by the
following OID and syntax:
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
The fields of PKIPublicationInfo have the following meaning:
PkipublicationInfoのフィールドには、次の意味があります。
action indicates whether or not the requestor wishes the CA/RA to publish the certificate. The values and their means are:
アクションは、要求者がCA/RAに証明書を公開することを望んでいるかどうかを示します。価値とその手段は次のとおりです。
dontPublish indicates that the requester wishes the CA/RA not to publish the certificate (this may indicate that the requester intends to publish the certificate him/herself). If dontPublish is used, the pubInfos field MUST be omitted.
DontPublishは、要求者がCA/RAに証明書を公開しないように望んでいることを示します（これは、リクエスターが証明書を自分で公開するつもりであることを示している可能性があります）。dontpublishを使用する場合、pubinfosフィールドを省略する必要があります。
pleasePublish indicates that the requestor wishes the CA/RA to publish the certificate.
PleasePublishは、要求者がCA/RAに証明書を公開することを望んでいることを示します。
pubInfos holds the locations where the requestor desires the CA/RA to publish the certificate. This field is omitted if the dontPublish choice is selected. If the requestor wants to specify some locations for the certificate to be published, and to allow the CA/RA to publish in other locations, it would specify multiple values of the SinglePubInfo structure, one of which would be dontCare.
PubInfosは、リクエスターが証明書を公開するためにCA/RAを望む場所を保持しています。DontPublishの選択が選択されている場合、このフィールドは省略されています。要求者が、証明書のいくつかの場所を公開し、CA/RAが他の場所で公開できるようにする場合、シングルパビンフ構造の複数の値を指定します。
The fields of SinglePubInfo have the following meaning:
singlepubinfoのフィールドには次の意味があります。
pubMethod indicates the address type for the location at which the requestor desires the certificate to be placed by the CA/RA.
PubMethodは、要求者がCA/RAによって配置される証明書を望む場所のアドレスタイプを示します。
dontCare indicates that the CA/RA can publish the certificate in whatever locations it chooses. If dontCare is used, the pubInfos field MUST be omitted.
DontCareは、CA/RAが選択した場所で証明書を公開できることを示しています。dontcareを使用している場合は、pubinfosフィールドを省略する必要があります。
x500 indicates that the requestor wishes for the CA/RA to publish the certificate in a specific location. The location is indicated in the x500 field of pubLocation.
X500は、要求者がCA/RAが特定の場所で証明書を公開することを望んでいることを示しています。場所は、X500公開フィールドに示されています。
ldap indicates that the requestor wishes for the CA/RA to publish the certificate in a specific location. The location is indicated in the ldap field of pubLocation.
LDAPは、要求者がCA/RAが特定の場所に証明書を公開することを望んでいることを示します。場所は、公開のLDAPフィールドに示されています。
web indicates that the requestor wishes for the CA/RA to publish the certificate in a specific location. The location is indicated in the http field of pubLocation.
Webは、要求者がCA/RAに特定の場所で証明書を公開することを望んでいることを示しています。場所は、公開のHTTPフィールドに示されています。
pubLocation contains the address at which the certificate is to be placed. The choice in the general name field is dictated by the pubMethod selection in this structure.
公開には、証明書を配置するアドレスが含まれています。一般名のフィールドでの選択は、この構造のPubMethod選択によって決定されます。
Publication locations can be supplied in any order. All locations are to be processed by the CA for purposes of publication.
出版場所は任意の順序で提供できます。すべての場所は、公開の目的でCAによって処理されます。
The pkiArchiveOptions control enables subscribers to supply information needed to establish an archive of the private key corresponding to the public key of the certification request. It is defined by the following OID and syntax:
PKIARCHIVEOPTIONS CONTROLにより、購読者は、認証要求の公開鍵に対応する秘密鍵のアーカイブを確立するために必要な情報を提供できます。これは、次のOIDと構文によって定義されています。
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- the actual value of the private key
keyGenParameters [1] KeyGenParameters,
-- parameters which allow the private key to be re-generated
archiveRemGenPrivKey [2] BOOLEAN }
-- set to TRUE if sender wishes receiver to archive the private
-- key of a key pair that the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue, -- deprecated
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
-- the symmetric algorithm used to encrypt the value
encSymmKey [2] BIT STRING OPTIONAL,
-- the (encrypted) symmetric key used to encrypt the value
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the symmetric key
valueHint [4] OCTET STRING OPTIONAL,
-- a brief description or identifier of the encValue content
-- (may be meaningful only to the sending entity, and used only
-- if EncryptedValue might be re-examined by the sending entity
-- in the future)
encValue BIT STRING }
-- The use of the EncryptedValue field has been deprecated in favor
-- of the EnvelopedData structure.
--
-- When EncryptedValue is used to carry a private key (as opposed to
-- a certificate), implementations MUST support the encValue field
-- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
-- section 12.11. If encValue contains some other format/encoding
-- for the private key, the first octet of valueHint MAY be used
-- to indicate the format/encoding (but note that the possible values
-- of this octet are not specified at this time). In all cases, the
-- intendedAlg field MUST be used to indicate at least the OID of
-- the intended algorithm of the private key, unless this information
-- is known a priori to both sender and receiver by some other means.
KeyGenParameters ::= OCTET STRING
The fields of PKIArchiveOptions have the following meaning:
pkiarchiveoptionsのフィールドには、次の意味があります。
encryptedPrivKey contains an encrypted version of the private key.
暗号化されたPrivkeyには、暗号化されたバージョンの秘密鍵が含まれています。
keyGenParameters contains the information needed by the requestor to regenerate the private key. As an example, for many RSA implementations one could send the first random number(s) tested for primality. The structure to go here is not defined by this document. CRPs that define content for this structure MUST define not only the content that is to go here, but also how that data is shrouded from unauthorized access.
keygenparametersには、秘密鍵を再生するために要求者が必要とする情報が含まれています。例として、多くのRSA実装については、原始性についてテストされた最初の乱数を送信できます。ここに行く構造は、このドキュメントで定義されていません。この構造のコンテンツを定義するCRPSは、ここに行くコンテンツだけでなく、そのデータが不正アクセスからどのように覆われているかを定義する必要があります。
archiveRemGenPrivKey indicates that the requestor desires that the key generated by the CA/RA on the requestor's behalf be archived.
ArchiveRemgenPrivkeyは、リクエスターがリクエスターに代わってCA/RAによって生成されたキーがアーカイブされることを望んでいることを示しています。
The fields of EncryptedKey have the following meaning:
暗号化されたKeyのフィールドには、次の意味があります。
encryptedValue is longer used. This field has been deprecated along with the EncryptedValue structure.
暗号化されたValueはより長く使用されます。このフィールドは、暗号化された値構造とともに非推奨されています。
envelopedData contains the encrypted value of the private key. CPRs that use this structure MUST define the entity or entities for whom the data is to be encrypted (the EE, escrow agents, CAs) and how that key or set of keys is to be determined. Details on constructing an EnvelopedData structure are found in [CMS]. The encrypted content MUST be an id-ct-encKeyWithID. The identifier can be omitted unless this structure is also being used to do proof-of-possession.
EnvelopedDataには、秘密鍵の暗号化された値が含まれています。この構造を使用するCPRは、データを暗号化するエンティティまたはエンティティ（EE、エスクローエージェント、CAS）を定義する必要があり、そのキーまたはキーのセットを決定する方法を定義する必要があります。封筒構造の構築に関する詳細は、[CMS]にあります。暗号化されたコンテンツは、ID-ct-eckeywithidでなければなりません。識別子は、この構造が所有の証明を行うためにも使用されない限り省略できます。
If present, the OldCertID control specifies the certificate to be updated by the current certification request. The OID and syntax is:
存在する場合、OldCertid Controlは、現在の認定リクエストによって更新される証明書を指定します。OIDと構文は次のとおりです。
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER
}
If present, the protocolEncrKey control specifies a key that the CA is to use in encrypting a response to CertReqMessages. The OID for this control is id-regCtrl-protocolEncrKey. The parameter structure for this field is SubjectPublicKeyInfo. (This structure is defined in [PROFILE].)
存在する場合、protocolencrkeyコントロールは、CAがCertreqMessagesへの応答を暗号化する際に使用するキーを指定します。このコントロールのOIDは、ID-regctrl-protocolencrkeyです。このフィールドのパラメーター構造は、件名PublicKeyInfoです。（この構造は[プロファイル]で定義されています。）
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
This control is used when a CA has information to send to the subscriber that needs to be encrypted. Such information includes a private key generated by the CA for use by the subscriber.
このコントロールは、CAに暗号化する必要があるサブスクライバーに送信する情報がある場合に使用されます。このような情報には、サブスクライバーが使用するためにCAによって生成された秘密鍵が含まれます。
This section documents the controls that are to be placed in the regInfo field of the CertReqMsg structure.
このセクションでは、CertreQMSG構造のRegINFOフィールドに配置されるコントロールを文書化します。
This control is used to convey text-based information from the Subject to an RA to a CA issuing a certificate. The OID for this structure is id-regInfo-utf8Paris and has a type of UTF8String.
このコントロールは、テキストベースの情報を被験者からRAに、証明書を発行するCAに伝えるために使用されます。この構造のOIDはID-Reginfo-UTF8Parisであり、UTF8STRINGの種類があります。
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
The name is terminated by the question mark character ('?'). The value is terminated by the percent character '%'. Name value pairs can be repeated. Thus the syntax is:
名前は疑問符の文字（ '？'）によって終了します。値は、パーセント文字「％」によって終了します。名前のペアを繰り返すことができます。したがって、構文は次のとおりです。
Name?Value%[Name?Value%]*
name？value％[name？value％]*
The %xx mechanism of [RFC1738] is used to encode '?' (%3f) and '%' (%25) if they are not being used for their reserved purpose. Names MUST NOT start with a numeric character.
[RFC1738]の％XXメカニズムは、「？」をエンコードするために使用されます。（％3F）および「％」（％25）が予約された目的に使用されていない場合。名前は数値文字から始めてはなりません。
This control can appear multiple times in the regInfo structure. Resolution of conflicts of information is a matter of local policy on the RA/CA.
このコントロールは、RegINFO構造に複数回表示される可能性があります。情報の対立の解決は、RA/CAに関するローカルポリシーの問題です。
Appendix A contains a set of common names and data formats corresponding to fields that commonly appear in certificates and directories.
付録Aには、証明書とディレクトリに一般的に表示されるフィールドに対応する一連の共通名とデータ形式が含まれています。
This control is designed to deal with the problem where an RA needs to modify the certificate template proposed by a Subject, but the Subject used the certificate template as part of its POP calculation. In this case, the RA can place a new certificate template in the regInfo sequence.
このコントロールは、RAが被験者によって提案された証明書テンプレートを変更する必要がある問題に対処するように設計されていますが、被験者はポップ計算の一部として証明書テンプレートを使用しました。この場合、RAはRegINFOシーケンスに新しい証明書テンプレートを配置できます。
This control has the OID id-regInfo-certReq and the structure CertRequest. There can only be one instance of this attribute in the regInfo sequence. If this control exists in the regInfo structure, then the certificate template in the request is ignored. The RA MUST copy all data from the core template to this attribute.
このコントロールには、OID ID-Reginfo-Certreqと構造がcertrequestがあります。RegINFOシーケンスには、この属性のインスタンスが1つしかありません。このコントロールがRegINFO構造に存在する場合、リクエストの証明書テンプレートは無視されます。RAは、すべてのデータをコアテンプレートからこの属性にコピーする必要があります。
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
The OID id-pkix has the value
OID ID-PKIXには値があります
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
-- arc for Internet X.509 PKI protocols and their components
id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) }
-- arc for Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
-- arc for Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
Enrollment protocols, by their very nature, involve large amounts of private information. This can include private keys, identity numbers, credit card numbers, and the like. The security of any CRP is based on the security mechanisms of the protocol and/or process used to communicate between CAs, RAs and EEs. All protocols must provide for masking, either via encryption or off-line processing, of all subscriber-sensitive information.
登録プロトコルは、その性質上、大量の個人情報を伴います。これには、プライベートキー、身元番号、クレジットカード番号などが含まれます。CRPのセキュリティは、CAS、RAS、およびEEの間で通信するために使用されるプロトコルおよび/またはプロセスのセキュリティメカニズムに基づいています。すべてのプロトコルは、すべてのサブスクライバーに敏感な情報の暗号化またはオフライン処理を介してマスキングを提供する必要があります。
Many enrollment protocols provide for the initial establishment of identity between the CA/RA and the EE by the use of a token. Generally this token is delivered using an out-of-band delivery method (such as the governmental mail system). The security of any out-of-band exchange needs to be commensurate with the risk that the CA/RA will tolerate with regard to interception of the token by a third party.
多くの登録プロトコルは、トークンを使用することにより、CA/RAとEEの間のアイデンティティの初期確立を提供します。通常、このトークンは、帯域外配達方法（政府の郵便システムなど）を使用して配信されます。バンド外の交換のセキュリティは、第三者によるトークンの傍受に関してCA/RAが許容するリスクに見合っている必要があります。
Implementation must implement Proof-of-Possession (POP) values during certificate enrollment processes. A good POP algorithm needs to provide proof of two things: 1) that the key is tied to a specific user and 2) that the user has use of the key in question. Failure to implement POP allows people to create certificates where the public key and the name values do not correctly bind. This allows for impersonation on signature keys and interception of encrypted messages.
実装は、証明書登録プロセス中に、プルーフオブポッセッション（POP）値を実装する必要があります。優れたポップアルゴリズムは、2つのことの証明を提供する必要があります。1）キーが特定のユーザーに結び付けられていること、2）ユーザーが問題のキーを使用していること。POPの実装に失敗すると、人々は公開キーと名前の値が正しく拘束されない証明書を作成できます。これにより、署名キーになりすまし、暗号化されたメッセージの傍受が可能になります。
Implementations must use high entropy random number generators in producing private keys. Implementations must randomly generate content-encryption keys, message-authentication keys, initialization vectors (IVs), salt, and padding. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 4086 [RANDOM] offers important guidance in this area and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
実装は、プライベートキーの生産において、高いエントロピー乱数ジェネレーターを使用する必要があります。実装では、コンテンツ暗号化キー、メッセージ認証キー、初期化ベクトル（IV）、塩、およびパディングをランダムに生成する必要があります。不十分な擬似ランダム数ジェネレーター（PRNGS）を使用して暗号化キーを生成すると、セキュリティがほとんどまたはまったくなりません。攻撃者は、キーを生成するキーを生成するPRNG環境を再現する方がはるかに簡単になる場合があります。品質の乱数の生成は困難です。RFC 4086 [ランダム]はこの領域で重要なガイダンスを提供し、FIPS Pub 186の付録3 [DSS]は1つの品質のPRNG手法を提供します。
Implementations must protect private keys. The compromise of a signer's private key permits third parties to masquerade as the signer. The compromise of a decryption private key allows for interception of messages by a third party.
実装は、プライベートキーを保護する必要があります。署名者の秘密鍵の妥協により、サードパーティは署名者を装っています。復号化の秘密鍵の妥協により、サードパーティによるメッセージの傍受が可能になります。
One feature of the certificate message request syntax is for the key generation to be performed remotely from the creation of the certificate request. This feature should never be used for generation of signing keys. If signing keys are generated for the user, then an element of repudiation comes into play. The user can claim that an item was signed by the entity that generated the key as well as any entity that might have seen the key value during transfer from the generator the to EE. Care must be taken to protect encryption keys by the remote key generator to protect against interception of the keys by a third party. This means that the encryption algorithms used need to be secure, and a content encryption key or a key encryption key must be used to mask the private key during transport back to the user. CRP protocols must never assume that a signature key generated by the user can be used to decrypt the package in which an encryption private key is transported.
証明書メッセージ要求の構文の1つの機能は、証明書リクエストの作成からリモートでキー生成を実行することです。この機能は、署名キーの生成に使用しないでください。ユーザー用の署名キーが生成されると、拒否の要素が作用します。ユーザーは、キーを生成したエンティティと、発電機からEEからの転送中にキー値を見た可能性のあるエンティティによって署名されたと主張できます。サードパーティによるキーの傍受から保護するために、リモートキージェネレーターによる暗号化キーを保護するように注意する必要があります。つまり、使用される暗号化アルゴリズムは安全である必要があり、コンテンツ暗号化キーまたはキー暗号化キーを使用して、ユーザーへの輸送中に秘密キーをマスクする必要があります。CRPプロトコルは、ユーザーが生成する署名キーを使用して、暗号化の秘密キーが輸送されるパッケージを復号化できるとは決して想定してはなりません。
This document describes a method by which key escrow may be done. There are several issues that need to be taken into account when doing key escrow. First, the client must be able to correctly identify the entity to which a key is to be escrowed or the CRP must provide a method by which the client can discover this information. A CRP cannot assume that the key escrow agent and the CA are the same entity and thus have the same names. Second, the algorithms used to mask the private key or other key generation information during transport to the escrow agent need to be commensurate with the value of the data being protected by the key. Third, the escrow agent needs to provide sufficient safeguards that an escrowed key is returned only to entities that should be able to obtain the private key. Generally, this should be restricted to the entity that escrowed the data. Fourth, the escrow data base needs to be stored in a secure manner. One common method for doing this is to re-encrypt the data to keys that only the escrow agent has access to. In this case, one may need to escrow the escrow agent key as well. Access to either the escrow agent or the archived key would amount to access to all private keys that have been escrowed with that agent.
このドキュメントは、キーエスクローを実行する方法について説明しています。キーエスクローを実行する際に考慮する必要があるいくつかの問題があります。まず、クライアントは、キーがエスクローされることであるエンティティを正しく識別できる必要があります。または、CRPがクライアントがこの情報を発見できる方法を提供する必要があります。CRPは、キーエスクローエージェントとCAが同じエンティティであるため、同じ名前を持っていると仮定することはできません。第二に、エスクローエージェントへの輸送中に秘密鍵またはその他のキー生成情報をマスクするために使用されるアルゴリズムは、キーによって保護されているデータの価値と見なされる必要があります。第三に、エスクローエージェントは、エスクローされたキーが秘密鍵を取得できるエンティティにのみ返されるほど十分な保護手段を提供する必要があります。一般に、これはデータをエスクローしたエンティティに制限される必要があります。第4に、エスクローデータベースは安全な方法で保存する必要があります。これを行うための一般的な方法の1つは、エスクローエージェントのみがアクセスできるキーにデータを再暗号化することです。この場合、エスクローエージェントキーもエスクローする必要がある場合があります。エスクローエージェントまたはアーカイブされたキーへのアクセスは、そのエージェントとともにエスクロウになったすべてのプライベートキーへのアクセスに相当します。
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[PKCS1] Jonsson、J。and B. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA暗号仕様バージョン2.1 "、RFC 3447、2003年2月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[PKCS11] RSA Laboratories, The Public-Key Cryptography Standards - "PKCS #11 v2.11: Cryptographic Token Interface Standard", RSA Security Inc., June 2001.
[PKCS11] RSA Laboratories、Public -Key Cryptography Standards-「PKCS＃11 V2.11：暗号化トークンインターフェイス標準」、RSA Security Inc.、2001年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[プロファイル] Housley、R.、Polk、W.、Ford、W.、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[Pkixalg] Bassham、L.、Polk、W。、およびR. Housley、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイルのアルゴリズムと識別子」、RFC 3279、2002年4月。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[CMS] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[RFC2875] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", RFC 2875, July 2000.
[RFC2875] Prafullchandra、H。およびJ. Schaad、「Diffie-Hellman Proof-of-Possession Algorithms」、RFC 2875、2000年7月。
[DSS] National Institute of Standards and Technology, FIPS Pub 186: Digital Signature Standard, May 1994.
[DSS]国立標準技術研究所、FIPS Pub 186：Digital Signature Standard、1994年5月。
[PKCS8] RSA Laboratories, "PKCS #8: Private-Key Information Syntax Standard", PKCS #8 v1.2, November 1993.
[PKCS8] RSA Laboratories、「PKCS＃8：Private-Key Information Syntax Standard」、PKCS＃8 V1.2、1993年11月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC 2202, September 1997.
[RFC2202] Cheng、P。およびR. Glenn、「HMAC-MD5およびHMAC-SHA-1のテストケース」、RFC 2202、1997年9月。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
The working group would like to thank Michael Myers, Carlisle Adams, Dave Solo, and David Kemp, who authored the original version of this document.
ワーキンググループは、このドキュメントのオリジナルバージョンを執筆したマイケルマイヤーズ、カーライルアダムス、デイブソロ、デビッドケンプに感謝したいと思います。
The working group also gratefully acknowledges the contributions of Barbara Fox, Warwick Ford, Russ Housley, and John Pawling, whose review and comments significantly clarified and improved the utility of this specification. The members of the ca-talk mailing list also provided significant input with respect to interoperability testing.
ワーキンググループはまた、バーバラ・フォックス、ワーウィック・フォード、ラス・ヒューズリー、ジョン・ポーリングの貢献に感謝しています。CA-Talkメーリングリストのメンバーは、相互運用性テストに関して重要なインプットも提供しました。
The text of Appendix C (Why do POP) was taken from an e-mail message by Al Arsenault and was originally part of the PKIX Roadmap document.
付録C（なぜPOP）のテキストは、Al Arsenaultによる電子メールメッセージから撮影され、もともとPKIXロードマップドキュメントの一部でした。
The "value" field of the id-regInfo-utf8Pairs string (with "tag" field equal to 12 and appropriate "length" field) will contain a series of UTF-8 name/value pairs.
id-reginfo-utf8pairs文字列の「値」フィールド（「タグ」フィールドが12に等しく、適切な「長さ」フィールド）には、一連のUTF-8名/値ペアが含まれます。
This Appendix lists some common examples of such pairs for the purpose of promoting interoperability among independent implementations of this specification. It is recognized that this list is not exhaustive and will grow with time and implementation experience.
この付録には、この仕様の独立した実装間の相互運用性を促進する目的で、このようなペアの一般的な例をいくつか示しています。このリストは網羅的ではなく、時間と実装の経験とともに成長することが認識されています。
The following table defines a recommended set of named elements. The value in the column "Name Value" is the exact text string that will appear in the regInfo.
次の表は、推奨される名前付き要素のセットを定義しています。列「名前値」の値は、reginfoに表示される正確なテキスト文字列です。
Name Value
----------
version -- version of this variation of regInfo use
corp_company -- company affiliation of subscriber
org_unit -- organizational unit
mail_firstName -- personal name component
mail_middleName -- personal name component
mail_lastName -- personal name component
mail_email -- subscriber's email address
jobTitle -- job title of subscriber
employeeID -- employee identification number or string
mailStop -- mail stop
issuerName -- name of CA
subjectName -- name of Subject
validity -- validity interval
For example:
例えば：
version?1%corp_company?Example, Inc.%org_unit?Engineering% mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader% mail_email?john@example.com%
バージョン？1％corp_company？example、inc.％org_unit？eingineering％mail_firstname？john％mail_lastname？smith％jobtitle？チームリーダー％mail_email?john@example.com%
When they appear in id-regInfo-utf8Pairs syntax as named elements,
the encoding of values for issuerName, subjectName, and validity
SHALL use the following syntax. The characters [] indicate an
optional field, ::= and | have their usual BNF meanings, and all
other symbols (except spaces, which are insignificant) outside non-
terminal names are terminals. Alphabetics are case-sensitive.
issuerName ::= <names>
subjectName ::= <names>
<names> ::= <name> | <names>:<name>
<validity> ::= validity ? [<notbefore>]-[<notafter>]
<notbefore> ::= <time>
<notafter> ::= <time>
Where <time> is UTC time in the form YYYYMMDD[HH[MM[SS]]]. HH, MM, and SS default to 00 and are omitted if at the and of value 00.
ここで、<time>はyyyymmdd [hh [mm [ss]]]の形のutc時間です。HH、MM、およびSSはデフォルト00にデフォルトで、値00の場合は省略されています。
Example validity encoding:
妥当性エンコーディングの例：
validity?-19991231%
有効性？-19991231％
is a validity interval with no value for notBefore, and a value of December 31, 1999 for notAfter.
以前には価値のない有効性間隔であり、1999年12月31日の値はNotafterです。
Each name comprises a single character name form identifier, followed by a name value of one or more UTF-8 characters. Within a name value, when it is necessary to disambiguate a character that has formatting significance at an outer level, the escape sequence %xx SHALL be used, where xx represents the hex value for the encoding concerned. The percent symbol is represented by %%.
各名前は、単一の文字名フォーム識別子で構成され、その後に1つ以上のUTF-8文字の名前値が続きます。名前値内で、外側レベルでフォーマットの有意性を持つ文字を乱用する必要がある場合、xxは関係するエンコーディングの六角値を表します。パーセントシンボルは%%で表されます。
<name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname>
Name forms and value formats are as follows:
名前フォームと値形式は次のとおりです。
X.500 directory name form (identifier "X"):
x.500ディレクトリ名フォーム（識別子 "x"）：
<xname> ::= <rdns>
<rdns> ::= <rdn> | <rdns> , <rdn>
<rdn> ::= <avas>
<avas> ::= <ava> | <avas> + <ava>
<ava> ::= <attyp> = <avalue>
<attyp> ::= OID.<oid> | <stdat>
Standard attribute type <stdat> is an alphabetic attribute type identifier from the following set:
標準属性タイプ<STDAT>は、次のセットからのアルファベット属性型識別子です。
C (country) L (locality) ST (state or province) O (organization) OU (organizational unit) CN (common name) STREET (street address) E (E-mail address).
C（国）L（地域）ST（州または州）O（組織）OU（組織単位）CN（共通名）通り（通りの住所）E（電子メールアドレス）。
<avalue> is a name component in the form of a UTF-8 character string of 1 to 64 characters, with the restriction that in the IA5 subset of UTF-8 only the characters of ASN.1 PrintableString may be used.
<Avalue>は、1〜64文字のUTF-8文字文字列の形の名前コンポーネントであり、UTF-8のIA5サブセットではASN.1 PrintableStringの文字のみが使用できるという制限があります。
Other name form (identifier "O"):
<oname> ::= <oid> , <utf8string>
E-mail address (rfc822name) name form (identifier "E"):
<ename> ::= <ia5string>
DNS name form (identifier "D"):
<dname> ::= <ia5string>
URI name form (identifier "U"):
<uname> ::= <ia5string>
IP address (identifier "I"):
<iname> ::= <oid>
For example:
例えば：
issuerName?XOU=Our CA,O=Example,C=US% subjectName?XCN=John Smith,
O=Example, C=US, E=john@example.com%
PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Directory Authentication Framework (X.509)
Version, AlgorithmIdentifier, Name, Time,
SubjectPublicKeyInfo, Extensions, UniqueIdentifier, Attribute
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)} -- found in [PROFILE]
-- Certificate Extensions (X.509)
GeneralName
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19)} -- found in [PROFILE]
-- Cryptographic Message Syntax
EnvelopedData
FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms-2004(24) }; -- found in [CMS]
-- The following definition may be uncommented for use with
-- ASN.1 compilers that do not understand UTF8String.
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents of this type correspond to RFC 2279.
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 7 }
-- arc for Internet X.509 PKI protocols and their components
- インターネットX.509 PKIプロトコルとそのコンポーネントのアーク
id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 } -- content types
-- Core definitions for this module
- このモジュールのコア定義
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, -- Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL } -- at least one MUST be present
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type OBJECT IDENTIFIER,
value ANY DEFINED BY type }
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
-- used if the RA has already verified that the requester is in
-- possession of the private key
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
-- The signature (using "algorithmIdentifier") is on the
-- DER-encoded value of poposkInput. NOTE: If the CertReqMsg
-- certReq CertTemplate contains the subject and publicKey values,
-- then poposkInput MUST be omitted and the signature MUST be
-- computed over the DER-encoded value of CertReqMsg certReq. If
-- the CertReqMsg certReq CertTemplate does not contain both the
-- public key and subject values (i.e., if it contains only one
-- of these, or neither), then poposkInput MUST be present and
-- MUST be signed.
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- used only if an authenticated identity has been
-- established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate)
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- on the DER-encoded value of publicKey
publicKey SubjectPublicKeyInfo } -- from CertTemplate
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
-- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}
-- parameter value is PBMParameter
value BIT STRING }
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [HMAC, RFC2202])
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING, -- Deprecated
-- possession is proven in this message (which contains the private
-- key itself (encrypted for the CA))
subsequentMessage [1] SubsequentMessage,
-- possession will be proven in a subsequent message
dhMAC [2] BIT STRING, -- Deprecated
agreeMAC [3] PKMACValue,
encryptedKey [4] EnvelopedData }
-- for keyAgreement (only), possession is proven in this message
-- (which contains a MAC (over the DER-encoded value of the
-- certReq parameter in CertReqMsg, which MUST include both subject
-- and publicKey) based on a key derived from the end entity's
-- private DH key and the CA's public DH key);
SubsequentMessage ::= INTEGER {
encrCert (0),
-- requests that resulting certificate be encrypted for the
-- end entity (following which, POP will be proven in a
-- confirmation message)
challengeResp (1) }
-- requests that CA engage in challenge-response exchange with
-- end entity in order to prove private key possession
-- Object identifier assignments --
- オブジェクト識別子の割り当て -
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
--with syntax:
RegToken ::= UTF8String
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
--with syntax:
Authenticator ::= UTF8String
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
--with syntax:
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
--with syntax:
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- the actual value of the private key
keyGenParameters [1] KeyGenParameters,
-- parameters that allow the private key to be re-generated
archiveRemGenPrivKey [2] BOOLEAN }
-- set to TRUE if sender wishes receiver to archive the private
-- key of a key pair that the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue, -- Deprecated
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
-- the symmetric algorithm used to encrypt the value
encSymmKey [2] BIT STRING OPTIONAL,
-- the (encrypted) symmetric key used to encrypt the value
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the symmetric key
valueHint [4] OCTET STRING OPTIONAL,
-- a brief description or identifier of the encValue content
-- (may be meaningful only to the sending entity, and used only
-- if EncryptedValue might be re-examined by the sending entity
-- in the future)
encValue BIT STRING }
-- the encrypted value itself
-- When EncryptedValue is used to carry a private key (as opposed to
-- a certificate), implementations MUST support the encValue field
-- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
-- section 12.11. If encValue contains some other format/encoding
-- for the private key, the first octet of valueHint MAY be used
-- to indicate the format/encoding (but note that the possible values
-- of this octet are not specified at this time). In all cases, the
-- intendedAlg field MUST be used to indicate at least the OID of
-- the intended algorithm of the private key, unless this information
-- is known a priori to both sender and receiver by some other means.
KeyGenParameters ::= OCTET STRING
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
--with syntax:
OldCertId ::= CertId
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
--with syntax:
ProtocolEncrKey ::= SubjectPublicKeyInfo
-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 }
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax
UTF8Pairs ::= UTF8String
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax
CertReq ::= CertRequest
-- id-ct-encKeyWithID is a new content type used for CMS objects.
-- it contains both a private key and an identifier for key escrow
-- agents to check against recovery requestors.
id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}
EncKeyWithID ::= SEQUENCE {
privateKey PrivateKeyInfo,
identifier CHOICE {
string UTF8String,
generalName GeneralName
} OPTIONAL
}
PrivateKeyInfo ::= SEQUENCE {
version INTEGER,
privateKeyAlgorithm AlgorithmIdentifier,
privateKey OCTET STRING,
attributes [0] IMPLICIT Attributes OPTIONAL
}
Attributes ::= SET OF Attribute
ENDAppendix C. Why do Proof-of-Possession (POP)
終了付録C.
Proof-of-Possession, or POP, means that the CA is adequately convinced that the entity requesting a certificate for the public key Y, has access to the corresponding private key X.
Proof-of-Possession、またはPOPは、CAが公開鍵Yの証明書を要求するエンティティが対応する秘密鍵Xにアクセスできることを適切に確信していることを意味します。
POP is important because it provides an appropriate level of assurance of the correct operation of the PKI as a whole. At its lowest level, POP counters the "self-inflicted denial of service"; that is, an entity voluntarily gets a certificate that cannot be used to sign or encrypt/decrypt information. However, as the following two examples demonstrate, POP also counters less direct, but more severe, threats:
POPは、PKI全体の正しい動作の適切なレベルの保証を提供するため、重要です。最も低いレベルでは、ポップは「自傷行為の拒否」に反論します。つまり、エンティティは、情報に署名または暗号化/復号化するために使用できない証明書を自発的に取得します。ただし、次の2つの例が示しているように、POPは直接的ではないが、より深刻な脅威もカウンターします。
POP for signing keys: it is important to provide POP for keys used to sign material, in order to provide non-repudiation of transactions. For example, suppose Alice legitimately has private key X and its corresponding public key Y. Alice has a certificate from Charlie, a CA, containing Y. Alice uses X to sign a transaction T. Without POP, Mal could also get a certificate from Charlie containing the same public key, Y. Now, there are two possible threats: Mal could claim to have been the real signer of T; or Alice can falsely deny signing T, claiming that it was instead Mal. Since no one can reliably prove that Mal did or did not ever possess X, neither of these claims can be refuted, and thus the service provided by and the confidence in the PKI has been defeated. (Of course, if Mal really did possess X, Alice's private key, then no POP mechanism in the world will help, but that is a different problem.)
キーに署名するためのPOP：トランザクションの非和解を提供するために、材料に署名するために使用されるキーにPOPを提供することが重要です。たとえば、アリスが合法的に秘密キーXとそれに対応する公開キーYを持っていると仮定します。アリスはカリフォルニア州チャーリーからの証明書を持っています。Yを含むアリスはXを使用してトランザクションTに署名します。同じ公開鍵を含むY.今、2つの脅威があります。MALはTの本当の署名者であったと主張する可能性があります。または、アリスは署名を誤って否定し、代わりにマルであると主張することができます。MalがXを所有していないか、Xを所有していないことを確実に証明できないため、これらの主張のどちらも反論することはできません。したがって、PKIが提供するサービスと信頼は敗北しました。（もちろん、マルが本当にアリスの秘密鍵であるXを持っていた場合、世界のポップメカニズムは役立ちませんが、それは別の問題です。）
Note that one level of protection can be gained by having Alice (as the true signer of the transaction) include in the signed information, her certificate or an identifier of her certificate (e.g., a hash of her certificate). This might make it more difficult for Mal to claim authorship; he would have to assert that he incorrectly included Alice's certificate, rather than his own. However, it would not stop Alice from falsely repudiating her actions. Since the certificate itself is a public item, Mal indeed could have inserted Alice's certificate or identifier into the signed transaction, and thus its presence does not indicate that Alice was the one who participated in the now-repudiated transaction. The only reliable way to stop this attack is to require that Mal prove he possesses X before his certificate is issued.
アリスに（取引の真の署名者として）アリスに署名情報、証明書、または証明書の識別子（例えば、彼女の証明書のハッシュ）に含めることで、1つのレベルの保護を得ることができることに注意してください。これにより、MALが著者を主張することがより困難になる可能性があります。彼は、自分の証明書ではなく、アリスの証明書を誤って含めたと主張しなければなりません。しかし、それはアリスが彼女の行動を誤って否定するのを止めることはないでしょう。証明書自体は公開アイテムであるため、MALは実際にアリスの証明書または識別子を署名されたトランザクションに挿入できた可能性があるため、その存在は、アリスが現在繰り返されたトランザクションに参加した人であることを示していません。この攻撃を停止する唯一の信頼できる方法は、証明書が発行される前にMALが彼がXを所有していることを証明することを要求することです。
For signing keys used only for authentication, and not for non-repudiation, the threat is lower because users may not care about Alice's after-the-fact repudiation, and thus POP becomes less important. However, POP SHOULD still be done wherever feasible in this environment, by either off-line or on-line means.
認証にのみ使用されるキーに署名する場合、非繰り返しではなく、ユーザーがアリスの事後の拒否を気にしないため、POPがそれほど重要ではないため、脅威は低くなります。ただし、オフラインまたはオンライン手段のいずれかによって、この環境で実行可能な場合はどこでもPOPを実行する必要があります。
POP for key management keys: Similarly, POP for key management keys (that is, keys used for either key agreement or key exchange) can help to prevent undermining confidence in the PKI. Suppose that Al is a new instructor in the Computer Science Department of a local university. Al has created a draft final exam for the Introduction to Networking course he is teaching. He wants to send a copy of the draft final to Dorothy, the Department Head, for her review prior to giving the exam. This exam will of course be encrypted, as several students have access to the computer system. However, a quick search of the certificate repository (e.g., search the repository for all records with subjectPublicKey=Dorothy's-value) turns up the fact that several students have certificates containing the same public key management key as Dorothy. At this point, if no POP has been done by the CA, Al has no way of knowing whether all of the students have simply created these certificates without knowing the corresponding private key (and thus it is safe to send the encrypted exam to Dorothy), or whether the students have somehow acquired Dorothy's private key (and thus it is certainly not safe to send the exam). Thus, the service to be provided by the PKI allowing users to communicate with one another, with confidence in who they are communicating with, has been totally defeated. If the CA is providing POP, then either no students will have such certificates, or Al can know with certainty that the students do indeed know Dorothy's private key, and act accordingly.
キーマネジメントキーのポップ：同様に、キー管理キー（つまり、キー契約またはキーエクスチェンジのいずれかに使用されるキー）のポップは、PKIに対する信頼を損なうのを防ぐのに役立ちます。Alが地元の大学のコンピューターサイエンス部門の新しいインストラクターであると仮定します。アルは、彼が教えているネットワーキングコースの紹介のために最終試験のドラフトを作成しました。彼は、試験を行う前に、彼女のレビューのために、部門長のドロシーに決勝ドラフトのコピーを送りたいと考えています。数人の学生がコンピューターシステムにアクセスできるため、この試験はもちろん暗号化されます。ただし、証明書リポジトリをすばやく検索すると（たとえば、subjectpublickey = dorothy's-valueですべてのレコードのリポジトリを検索）、数人の学生がドロシーと同じ公開キー管理キーを含む証明書を持っているという事実が明らかになります。この時点で、CAによってポップが行われていない場合、ALは、すべての学生が対応する秘密鍵を知らずにこれらの証明書を単に作成したかどうかを知る方法がありません（したがって、暗号化された試験をドロシーに送ることは安全です）、または、学生が何らかの形でドロシーの秘密鍵を取得したかどうか（したがって、試験を送ることは確かに安全ではありません）。したがって、PKIによって提供されるサービスにより、ユーザーが誰とコミュニケーションをとっているかに自信を持って、ユーザーが互いに通信できるようにするサービスは完全に敗北しました。CAがPOPを提供している場合、学生はそのような証明書を持っている人はいません。また、ALは、学生が実際にドロシーの秘密鍵を知っていることを確実に知ることができ、それに応じて行動します。
Author's Address
著者の連絡先
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
Jim Schaad Soaring Hawk Consulting Po Box 675 Gold Bar、WA 98251
EMail: jimsch@exmsft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。