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)
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).
著作権（C）インターネット協会（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証明書生成の目的のために、おそらく登録機関（RA）を介して、証明機関（CA）に証明書の要求を伝えるためのプロトコル内で使用されています。要求は、一般的に、公開鍵と関連する登録情報が含まれます。
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).
証明書の要求は、別のCAからクロス証明書を要求するCAによって、または直接エンドエンティティ（EE）で、件名に代わって証明書を要求RAにより提出することができます。
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].
キーワード「MUST」、「REQUIRED」は、「推奨」、「SHOULD」、および「MAY」（図示のように、大文字で）この文書に記載されている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）追加登録情報はCertReqMessageを形成するために、プルーフ・オブ・所持値とcertrequestコマンド構造と組み合わせることができます。追加の登録情報は、件名と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によって指定されます。
4. Add information describing the contents of the EncryptedValue structure.
4. EncryptedValue構造体の内容を説明する情報を追加します。
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に置き換え。唯一の違いは、サブジェクト名が空だった場合、指定の古いテキストが主体名の代わりにサブジェクト代替名を使用することです。これは、PKIXを使用して発行したCA証明書のために可能ではありません。しかし、このフォールバックポジションを持っているRFC 2875を更新することは有用であろう。
7. Insert Appendix C describing why POP is necessary and what some of the different POP attacks are.
7.挿入付録Cは、POPが必要な理由について説明し、どのような異なるPOP攻撃の一部です。
8. pop field in the CertReqMsg structure has been renamed to popo to avoid confusion between POP and pop.
CertReqMsg構造8.ポップ・フィールドは、POPとポップの間で混乱を避けるために、ポポに改名されました。
9. The use of the EncryptedValue structure has been deprecated in favor of the EnvelopedData structure.
9. EncryptedValue構造の使用は、EnvelopedDataの構造を支持して廃止されました。
10. Add details on how private keys are to be structured when encrypted.
10.キーは暗号化されたときに構造化される方法民間の詳細を追加します。
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.
ポポは、証明書のサブジェクトとして識別されるエンティティが対応する秘密鍵の所有に実際にあることを実証するために使用される値が含まれています。このフィールドは、発行される証明書の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コンテンツに含まれるべきです。しかし、RAが追加CERTREQコンテンツを含めることは、（使用される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は、その認証交換中（CRMFインバンドメッセージに対して、例えば、アウト・オブ・バンド手続き手段）POPを適用する方法を自由に選択することができます。所与CRP内、CAおよびRAは（すなわち、これは、RA / CAにローカルポリシーの問題である）が提供POP方法の中から自由に選択できます。 CRPは、方法が必要とされるPOPのいずれかを定義する、またはサポートされている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運用プロトコルは、（様々な電子メールプロトコルは一例です）現在ありません。 （署名、暗号化、および鍵合意鍵ペアのための）結合を確認するん運用プロトコルが存在し、かつユビキタスになるまで、この結合は、CA / RAによって検証されていると想定することはできません。証明書の公開鍵とアイデンティティの結合が実際に正しいかどうそこで、一つは、真に知ることはできません。
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鍵）のために使用することができる場合には、方法のいずれを用いてもよいです。プロトコルの設計者は、秘密鍵は、ハードウェアトークンに維持されている場合の方法は、例えば、使用可能であるかもしれないものPOPにハードウェアの制限があることを認識する必要があります。
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、またはその両方によって検証されるケースを可能にします。いくつかのポリシーは、RAがCAに変更されていないエンドエンティティのcertrequestコマンドとProofOfPossessionフィールドを転送しなければならない場合には、証明書発行時のPOPを確認するために、CAが必要です（この場合、RAは、POPを検証し、むしろ、CAに転送するよりも失敗した証明書の要求を拒否できる）CAがPOPを検証するために、ポリシーによって必要とされていない場合には、RAはエンドエンティティの要求と証明を転送する必要があり、変更されていません、上記のようにCAへ。 （RAは、アウト・オブ・バンド方式によりPOPを検証するため、など）これが不可能な場合、RAは、必要な証明が検証されたCAを証明するraVerified素子を用いました。 CA / RAは、（例えば、CA / RA-生成された秘密鍵の物理的送達など）POPを確認するためにアウトオブバンド方式を使用する場合、ProofOfPossessionフィールドが省略されています。
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が独自のPOP検証を行うために必要とされず、2）RAはCERTREQフィールドの内容を変更する必要があるRAによって使用されます。 CRPはProofOfPossessionに署名するRAのための方法を提供しなければなりません。リクエスタは、このフィールドを設定してはいけませんし、RA / CAは、要求者がこのフィールドを設定しますProofOfPossessionを受け入れてはいけません。
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は、鍵合意型の暗号鍵（即ち、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は、証明書が望まれるアイデンティティを含むデータの部分に署名操作を実行することによって達成されます。
There are three cases that need to be looked at when doing a POP for a signature key:
署名鍵のためのPOPをやったときに見する必要が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の文字列を持っていません。この場合、POPOSigningKeyInput構造がAUTHINFOためpublicKeyMACの選択肢を使用して記入されるだろう、とパスワードとアイデンティティはpublicKeyMAC値を計算するために使用されるだろう。要求された証明書の公開鍵がPOPOSigningKeyInputと証明書テンプレートの構造の両方に配置されるだろう。署名フィールドは、DERエンコードPOPOSigningKeyInput構造にわたって計算されます。
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は、証明書のサブジェクトのために認証されたアイデンティティを確立しているが、リクエスタは、証明書要求にそれを置くことはありません。この場合、POPOSigningKeyInput構造がAUTHINFOの送信者の選択肢を使用して記入することでしょう。要求された証明書の公開鍵がPOPOSigningKeyInputと証明書テンプレートの構造の両方に配置されるだろう。署名フィールドは、DERエンコードPOPOSigningKeyInput構造にわたって計算されます。
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.証明書のサブジェクトは、公開鍵と一緒に証明書テンプレートの構造でその名前を配置します。この場合、同時にpoposkInputフィールドはPOPOSigningKey構造から省略されています。署名フィールドは、DER符号化された証明書テンプレート構造上に計算されます。
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
The fields of POPOSigningKey have the following meaning:
POPOSigningKeyのフィールドは以下の意味があります。
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は、署名アルゴリズムと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.
署名は、POP値農産物を含有します。同時に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:
POPOSigningKeyInputのフィールドは以下の意味があります。
sender contains an authenticated identity that has been previously established for the subject.
送信者は、以前に対象のために確立された認証されたIDが含まれています。
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.
公開鍵は、証明書テンプレートからの公開鍵のコピーが含まれています。これは、証明書テンプレートに含まれているとまったく同じ値でなければなりません。
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にそれを提供することで証明されました。仕様が最初に書かれていた場合、このフィールドは間違って入力されました。このフィールドを使用する正しい方法は、暗号化されたコンテンツは、EncryptedValue構造は、ビット列型でラップされた秘密鍵であるEncryptedValue構造を作成することです。このフィールドは、EncryptedKeyにするために廃止されました。
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.
subsequentMessageはPOPがCA / RAからのメッセージを解読し、応答を返すことによって完了されることを示すために使用されます。復号化されるメッセージのタイプは、使用される値によって示されます。
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.
チャレンジ - レスポンスはチャレンジメッセージは、要求側に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は、ディフィー・ヘルマン鍵合意鍵のために使用されています。これは、要求者の秘密鍵とCA / RAの公開鍵を用いて得られる計算されたMACが含まれています。このフィールドの使用はagreeMACフィールドの賛成で廃止されました。詳細は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.
agreeMACは鍵合意鍵のために使用されています。これは、要求者の秘密鍵と一致する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.
EncryptedKeyには証明書が発行されるべき公開鍵に一致する暗号化された秘密鍵が含まれています。それはまた、それが証明書の要求者によって構築されたことを示す識別値を含みます。エンベロープコンテンツタイプは、ID-CT-encKeyWithIDなければなりません。
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.
このコンテンツタイプは、秘密鍵とセクション6.4でアーカイブオプションのコントロールを使用して、秘密鍵の2）エスクロー（）の所有を証明する）1のために使用されています。この構造は、[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の値によって定義されているオクテット文字列です。
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-プライベート番号に設定しなければなりません。 ID-DH-プライベート数のパラメータは、DomainParameters（[PKIXALG]からインポート）です。
DH-PrivateKey ::= INTEGER
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]からインポート）です。
DSA-PrivateKey ::= INTEGER
When creating a PrivateKeyInfo for an RSA key, the following rules apply:
RSAキーのPrivateKeyInfoでを作成する場合は、次の規則が適用されます。
2. The ASN structure for privateKey MUST be RSAPrivateKey (defined in [PKCS1])
2.秘密鍵のASN構造は、RSA秘密鍵（[PKCS1]で定義されている）でなければなりません
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.
以下は、間接的な実証の所持が動作するように期待されているかについて、もう1つは、この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.
前記第2の要求メッセージを復号値のハッシュを含みます。 1は完全にランダムな値を「署名しない」んとこのメッセージは、暗号化された値の単なるハッシュにすることはできません。明示的に行うことができるようにハッシュ過程で、このようなアイデンティティ文字列などの情報を含むことが望ましいです。この戻り値は身元の第二の証明に含まれなければなりません。
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を実行するときに、これは一緒過程で異なるメッセージを抱き合わせ）1を可能にしてトランザクション識別子とナンス値は、要求されることが示唆された2）各エンティティはアイデンティティの証明を行うためのプロセスにランダムなデータのいくつかの量を注入させます。
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つの方法の1つによって達成されます。最初の3つはキー暗号化キーのために上記のものと同一です。第四の方法は、共有シークレットが生成されると値が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.
エンドエンティティは、MACもPOPを実証するための第4の代替として（計算から導出さ共有秘密鍵を使用して）証明書要求をしてもよいです。このオプションは、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 - ユーザーのパスワードデータを含むオクテット文字列 - MAC-EDイーターする値を含むオクテット文字列 - 反復回数
Output: MAC - an octet string containing the resultant MAC value
出力：MAC - 結果のMAC値を含むオクテット文字列
MAC = HASH( K XOR opad, HASH( K XOR ipad, data) )
MAC = HASH（K XORのOPAD、HASH（K XOR計算され、データ））
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:
certrequestコマンドのフィールドは以下の意味があります。
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.その他の文書に記載されています。 CRPは、コントロールが必要とされている指定する責任があります。
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.
signingAlgは省略しなければなりません。このフィールドは、証明書の作成中に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の発行されたときに、このフィールドは、一般的に使用されるケースがあります新しい証明書は、既存の証明書と同じ有効期間を持つことになりように、この場合には、既存の証明書の有効性は、このフィールドに配置されるだろう。有効性が省略されていない場合は、サブフィールドの少なくとも一つを指定する必要があります。次のようにサブフィールドは、次のとおりです。
notBefore contains the requested start time of the certificate. The time follows the same rules as the notBefore time in [PROFILE].
notBeforeのは、証明書の要求された開始時刻が含まれています。時間は、[PROFILE]でnotBeforeの時間と同じ規則に従います。
notAfter contains the requested expiration time of the certificate. The time follows the same rules as the notAfter time in [PROFILE].
notAfterのは、証明書の要求された有効期限が含まれています。時間は、[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.
公開鍵証明書が作成されている公開鍵が含まれています。このフィールドは、要求者は、独自のキーを生成した場合に記入する必要があります。キーはRA / CAによって生成された場合、このフィールドは省略されています。
issuerUID MUST be omitted. This field has been deprecated in [PROFILE].
issuerUIDは省略しなければなりません。このフィールドは、[PROFILE]で廃止されました。
subjectUID MUST be omitted. This field has been deprecated in [PROFILE].
subjectUIDは省略しなければなりません。このフィールドは、[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.
公開フィールドを除き、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-regCtrl-regToken以下のような）別の場所に配置されている場合は、証明書の要求者によって指定される必要がないフィールドが存在しません。
The generator of a CertRequest may include one or more control values pertaining to the processing of the request.
certrequestコマンドの発生器は、要求の処理に関連する一つまたは複数の制御値を含むことができます。
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.
次のコントロールは、このドキュメントによって定義される：regToken（セクション6.1）。オーセンティケータ（セクション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制御前の証明書を発行する被験者の身元を確認するためにCAによって使用されることを意図し（いずれか秘密値または他の共有情報に基づいて）ワンタイム情報を含みます。 regTokenための値を含む認証要求を受信すると、受信したCAは、証明書要求に記載のアイデンティティを確認するための情報を確認します。
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.
オーセンティケータ制御（セクション7.2を参照）初期ならびにその後の認証要求に使用することができる一方regToken制御は、PKIにのみエンドエンティティの初期化のために使用されます。
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.
オーセンティケータコントロールは、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.
使用のいくつかの例では、オーセンティケータの値は、乱数などのテキスト文字列または数値の量とすることができます。後者の値は二進数の文字列表現として符号化されます。オーセンティケータのエンコーディングは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.
オーセンティケータまたは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は、他の場所に公開することを可能にしたい場合は、それはDONTCAREだろう一つはSinglePubInfo構造の複数の値を、指定します。
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は、特定の場所に証明書を発行するためのリクエスタが望むことを示します。場所はpubLocationの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は、特定の場所に証明書を発行するためのリクエスタが望むことを示します。場所はpubLocationの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.
ウェブは、CA / RAは、特定の場所に証明書を発行するために要求者が望んでいることを示しています。場所はpubLocationの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制御は、認証要求の公開鍵に対応する秘密鍵のアーカイブを確立するために必要な情報を提供するために、加入者を可能にします。それは、次の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.
- 対称鍵valueHint [4を暗号化するために使用されるアルゴリズム - 値keyAlg [3]のAlgorithmIdentifier OPTIONALを暗号化するために使用される（暗号化された）対称鍵、 - 対称アルゴリズムは、値[2]ビット列OPTIONAL encSymmKeyを暗号化するために使用します] OCTET STRINGのOPTIONAL、 - 簡単な説明又はencValueコンテンツの識別子は、 - （将来的にのみ送信エンティティに有意義であってもよい、とのみ使用 - - EncryptedValueは送信エンティティによって再検討されるかもしれない場合） encValueビット列} - EncryptedValueフィールドの使用は賛成で廃止されました - EnvelopedDataの構造と。 - - EncryptedValueは（とは対照的に - 証明書）の秘密鍵を運ぶために使用される場合 - [PKCS11]で定義されるように暗号化されたPrivateKeyInfoで含有、 - 、実装がencValueフィールドをサポートしなければならないセクション12.11。 encValueは、いくつかの他のフォーマット/エンコーディングが含まれている場合 - フォーマット/エンコーディングを示すために、（ - このオクテットのこの時に指定されていませんが、可能な値があることに注意してください - ）秘密鍵のを、valueHintの最初のオクテットは使用されるかもしれません。すべての場合において、 - この情報がない限り、秘密鍵の意図されたアルゴリズム - - intendedAlgフィールドは、少なくともOIDを示すために使用されなければならないいくつかの他の手段によって送信側と受信側の両方に事前に知られています。
KeyGenParameters ::= OCTET STRING
The fields of PKIArchiveOptions have the following meaning:
PKIArchiveOptionsのフィールドは以下の意味があります。
encryptedPrivKey contains an encrypted version of the private key.
encryptedPrivKeyは、秘密鍵の暗号化されたバージョンが含まれています。
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の実装のために一方が素数について試験第1の乱数（複数可）を送ることができます。ここに行くための構造は、この文書で定義されていません。この構造体の内容を定義するのCRPは、ここに行くことであるコンテンツだけでなく定義しなければならないが、また、そのデータを不正アクセスから包まれていますか。
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:
EncryptedKeyにのフィールドは以下の意味があります。
encryptedValue is longer used. This field has been deprecated along with the EncryptedValue structure.
encryptedValueが長く使用されています。このフィールドはEncryptedValue構造とともに廃止されました。
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のは、秘密鍵の暗号化された値が含まれています。この構造は、データを暗号化する人のためのエンティティを定義しなければならない使用CPRSは、どのようにそのキーまたはキーのセットを決定すべきである（EEは、エージェント、CAがエスクロー）。 EnvelopedDataの構造を構築の詳細については、[CMS]で発見されています。暗号化されたコンテンツは、ID-CT-encKeyWithIDでなければなりません。この構造はまた、プルーフ・オブ・所持を行うために使用されない限り、識別子を省略することができます。
If present, the OldCertID control specifies the certificate to be updated by the current certification request. The OID and syntax is:
存在する場合、OldCertID制御は、現在の認証要求によって更新する証明書を指定します。 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です。このフィールドのパラメータ構造がSubjectPublicKeyInfoです。 （この構造は[PROFILE]で定義されます。）
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.
この制御は、証明書を発行するCAにRAの対象からテキストベースの情報を伝えるために使用されます。この構造体の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%]*
名前？値％[名前？値％] *
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は、件名によって提案された証明書テンプレートを変更する必要があるが、件名がそのPOP計算の一部として、証明書テンプレートを使用する問題に対処するように設計されています。この場合、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) }
- インターネットX.509 PKIプロトコルの円弧とそのコンポーネントID-pkipオブジェクト識別子:: {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）の値を実装する必要があります。 1）キーは、特定のユーザーに関連付けされていること、および2）利用者は、問題のキーの使用を持っていること：良いPOPアルゴリズムは、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）塩、およびパディングを生成しなければなりません。暗号鍵を生成するために不十分な疑似乱数発生器（のPRNG）の使用は、ほとんどまたは全くセキュリティをもたらすことができます。攻撃者はそれをはるかに簡単に全体のキースペースを検索結果として起こる小さい可能性はなく、ブルートフォースを探し、キーを生成PRNG環境を再現するかもしれません。品質の乱数の生成が困難です。 RFC 4086 [RANDOM]はこの領域で重要な指導を提供し、FIPSパブ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.
証明書のメッセージ要求構文の一つの特徴は、証明書要求の作成からリモートで実行されるキー生成のためです。この機能は、署名鍵の生成に使用すべきではありません。署名鍵は、ユーザーのために生成されている場合は、否認の要素が場に出ます。ユーザは、アイテムがキーならびにジェネレータから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が同じエンティティであり、したがって、同じ名前を持つと仮定することはできません。第二に、エスクローエージェントへの輸送中に、秘密鍵または他の鍵生成情報をマスクするために使用されるアルゴリズムは、キーによって保護されているデータの値に相応する必要があります。第三に、エスクローエージェントは、エスクロー鍵が唯一の秘密鍵を取得することができるはずエンティティに返され、十分な保護手段を提供する必要があります。一般的に、これはデータを預託するエンティティに制限する必要があります。第四に、エスクローデータベースは、安全な方法で保存する必要があります。これを行うための1つの一般的な方法は、唯一のエスクローエージェントがアクセス権を持っているキーにデータを再暗号化することです。この場合、1は、同様にエスクローエージェントキーをエスクローする必要があるかもしれません。エスクローエージェントまたはアーカイブキーのいずれかへのアクセスは、そのエージェントに預託されているすべての秘密鍵へのアクセスに達するだろう。
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[PKCS1]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（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.、ベラー、M.、およびR.カネッティ、 "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社、公開鍵暗号規格 - "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.
[PROFILE] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネット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]、RFC 3279 Bassham、L.、ポーク、W.、およびR. Housley氏、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールのためのアルゴリズムと識別子"、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、 "ディフィー - ヘルマンプルーフ・オブ・所有アルゴリズム"、RFC 2875、2000年7月。
[DSS] National Institute of Standards and Technology, FIPS Pub 186: Digital Signature Standard, May 1994.
[DSS]米国国立標準技術研究所、FIPSパブ186：デジタル署名標準、1994年5月。
[PKCS8] RSA Laboratories, "PKCS #8: Private-Key Information Syntax Standard", PKCS #8 v1.2, November 1993.
[PKCS8] RSA Laboratories社、 "PKCS＃8：プライベート・キー情報の構文標準"、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.
[ランダム]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、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]チェン、P.およびR.グレン、 "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]バーナーズ=リー、T.、Masinter、L.、およびM. McCahill、 "ユニフォームリソースロケータ（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.
ワーキンググループはまた感謝レビューやコメントかなり明確にし、この仕様の有用性を改善バーバラ・フォックス、ワーウィック・フォード、ラスHousley、ジョンPawlingの貢献を認めています。 CA-トークメーリングリストのメンバーはまた、相互運用性テストに関して重要なインプットを提供します。
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ロードマップ文書の一部でした。
Appendix A. Use of RegInfo for Name-Value Pairs
名前と値のペアのためのREGINFOの付録A.を使用
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.
（12に等しい「タグ」フィールドと、適切な「長さ」フィールドを持つ）ID-REGINFO-utf8Pairs文字列の「値」フィールドは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.
この付録では、この仕様の独立した実装間での相互運用性を促進する目的のために、このようなペアのいくつかの一般的な例を示しています。このリストは網羅的なものではなく、時間と実装経験と成長することが認識されています。
A.1. Defined Names
A.1。定義名
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？例、株式会社％のORG_UNIT？エンジニアリング％のmail_firstName？ジョン％のmail_lastName？スミス％jobTitle？チームリーダーの％のmail_email?john@example.com%
A.2. IssuerName, SubjectName, and Validity Value Encoding
A.2。 IssuerName、サブジェクト名、および有効性の値のエンコーディング
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.
ここで、<時間>フォーム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.
notBeforeのための無価値、およびnotAfterのため1999年12月31日の値を持つ有効期間です。
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 %%.
それぞれの名前は、一つ以上のUTF-8文字の名前の値が続く単一文字の名前のフォームの識別子を含みます。名前値、それが外側のレベルで有意性をフォーマットしている文字を明確にする必要がある場合、xxは、当該符号化のためのHEX値を表し、エスケープシーケンス％の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（一般名）STREET（ストリートアドレス）E（E-mailアドレス）。
<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は>は、UTF-8のIA5サブセットにのみASN.1はPrintableStringの文字を使用することができる制限で、1〜64文字のUTF-8文字列の形式で名前のコンポーネントです。
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%
issuerName？XOU私たちのCAを=、O =例、C = US％のSubjectName？XCN =ジョン・スミス、O =例、C = US、E=john@example.com%
Appendix B. ASN.1 Structures and OIDs
付録B. ASN.1構造とのOID
PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36)}
PKIXCRMF-2005 {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（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]
輸入 - ディレクトリ認証フレームワーク（X.509）バージョン、のAlgorithmIdentifier、名前、時間、SubjectPublicKeyInfoで、拡張機能、のUniqueIdentifier、属性PKIX1Explicit88 FROM {ISO（1）識別組織（3）DOD（6）インターネット（1）セキュリティ（5 ）機構（5）PKIX（7）ID-MOD（0）ID-pkix1-明示（18）} - [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]
- 証明書の拡張（X.509）のGeneralName PKIX1Implicit88 FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID -pkix1-暗黙（19）} - [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]
- CryptographicMessageSyntax2004 {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（0）CMS-2004（24から暗号メッセージ構文EnvelopedDataの）}。 - [CMS]で見つかりました
-- The following definition may be uncommented for use with -- ASN.1 compilers that do not understand UTF8String.
- UTF8Stringを理解していないASN.1コンパイラ - 以下の定義は、で使用するためのコメントを解除することがあります。
-- 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.
- 同時にpoposkInputのDER符号化された値 - （「のAlgorithmIdentifier」を使用して）署名が上にあります。注：CertReqMsg場合 - CERTREQ CertTemplateのは、対象と公開鍵値が含まれ、 - 次いで同時にpoposkInputを省略しなければならなくて、署名がなければなりません - CertReqMsg CERTREQのDER符号化された値にわたって計算します。 CertReqMsg CERTREQ CertTemplateのが両方含まれていない - - 場合は公開鍵と被験者の値を（それが一つだけ含まれている場合、すなわち、 - これらの、またはどちらも）を、次いで、同時にpoposkInputが存在しなければならないと - 署名しなければなりません。
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);
- （MACが含まれている（のDER符号化された値を超える - - に基づいて公開鍵） - サブジェクトの両方を含まなければなりませんCertReqMsgでCERTREQパラメータ、するKeyAgreement（のみ）のために、所持は、このメッセージで証明されていますエンドエンティティの由来キー - プライベートDHキーとCAの公開DHキー）。
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は、CMSのオブジェクトのために使用される新しいコンテンツタイプです。 - 回復要求元に対してチェックするための薬剤 - それは秘密鍵とキーエスクローのための識別子の両方が含まれています。
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
END
終わり
Appendix C. Why do Proof-of-Possession (POP)
付録C.なぜ実証の所持（POP）
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.
所持プルーフ、または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:
それは全体としてPKIの正しい動作を保証する適切なレベルを提供するので、POPが重要です。その最低のレベルでは、POPは、「サービスの自ら招い拒否を」カウンタ;それは、企業が自主的に情報を署名または暗号化/復号化に使用することができない証明書を取得しています。次の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.アリスはチャーリー、CAから証明書を持っていると仮定し、Y.アリスはPOPがなければ、トランザクション・T.に署名するXを使用して含む、マルもチャーリーから証明書を得ることができます同じ公開鍵を含む、Y.は今、2つの可能性のある脅威があります。マルはTの真の署名者であったと主張することができ、またはアリスは虚偽ではなくマルだったと主張し、Tに署名拒否することができます。誰もが確実にマルがやったことを証明することはできませんか、これまでXを所有していなかったので、これらの主張のどちらが反論することができるので、サービスはによって提供され、PKIの信頼が敗北されています。 （マルが本当にX、アリスの秘密鍵を持っていた場合はもちろん、その後、世界にはPOPメカニズムは助けないでしょうが、それは別の問題です。）
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.
保護のレベルは、（トランザクションの真の署名者として）アリスを有することによって得ることができることに留意されたい署名付き情報、彼女の証明書または彼女の証明書の識別子（例えば、彼女の証明書のハッシュ）が含まれます。これは、より困難マルは、原作者を主張するために作るかもしれません。彼は彼が間違ってではなく、彼自身よりもアリスの証明書を、含まれていることを主張しなければならないでしょう。しかし、それは誤って彼女の行動を否認からアリスを停止しないでしょう。証明書自体は公共アイテムですので、マルは確かに署名したトランザクションに、アリスの証明書または識別子を挿入することができたので、その存在は、アリスは今、否認トランザクションに参加した一人だったことを示すものではありません。この攻撃を停止する唯一の確実な方法は、自分の証明書が発行される前に、マルは、彼が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.
キー管理キーのPOP：同様に、鍵管理キー（つまり、キー契約または鍵交換のどちらかのために使用される鍵である）のためのPOPは、PKIの信頼を損なう防止するのに役立つことができます。 Alは地元の大学のコンピュータサイエンス学部の新しいインストラクターであると仮定します。アルは、彼が教えているネットワークコースの紹介のためのドラフト最終試験を作成しました。彼は前に試験を与えることに彼女の検討のため、ドロシー、部長にドラフト最終のコピーを送信したいです。いくつかの学生がコンピュータシステムへのアクセス権を持っているとして、この試験では、もちろん、暗号化されます。しかし、証明書リポジトリのクイック検索は、（例えば、のsubjectPublicKey = Dorothy's値を持つすべてのレコードのリポジトリを検索する）いくつかの学生がドロシーと同じ公開鍵管理鍵を含む証明書を持っているという事実をアップになります。この時点では、何のPOPがCAによって行われていない場合は、Alが学生のすべては、単に対応する秘密鍵を知らなくても、これらの証明書を作成している（したがって、ドロシーに暗号化された試験を送信するために安全である）かどうかを知る方法はありません、または（試験を送信するので、それは確かに安全ではありません）学生は何とかドロシーの秘密鍵を取得しているかどうか。このように、ユーザーが通信している人では自信を持って、相互に通信できるようにするPKIによって提供されるサービスは、完全に敗北されています。 CAは、POPを提供している場合は、どちらかの一切の学生は、このような証明書を持っていないだろう、あるいはAlは、学生が実際にドロシーの秘密鍵を知っていますかという確信を持って知って、それに応じて行動することができます。
Author's Address
著者のアドレス
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251
ジムSchaad高騰ホークコンサルティング私書箱675ゴールドバー、WA 98251
EMail: jimsch@exmsft.com
メールアドレス：jimsch@exmsft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。