CRMF

RFC 2511 Internet X.509 Public Key Infrastructure Certificate Request Message Format (旧)

インターネット X.509 公開鍵暗号基盤 証明書要求メッセージ形式 (CRMF)

RFC 4211

インターネット X.509 公開鍵基盤 証明書要求メッセージフォーマット (CRMF)

本文書のステータス

本文書は、インターネットコミュニティのためのインターネット標準化過程プロトコルを規定し、改善のための議論と提案を求めるものです。本プロトコルの標準化状況については、「インターネット公式プロトコル標準」(STD 1) の最新版を参照してください。本文書の配布は無制限です。

著作権表示

Copyright (C) The Internet Society (2005).

概要

本文書は、証明書要求メッセージフォーマット (CRMF) の構文とセマンティクスについて説明します。この構文は、X.509 証明書発行を目的として、認証局 (CA) （場合によっては登録局 (RA) 経由）に証明書の要求を伝えるために使用されます。要求には通常、公開鍵と関連する登録情報が含まれます。本文書は、証明書要求プロトコルを定義するものではありません。

1. 概要と用語

この文書では、証明書要求メッセージフォーマット（CRMF）について説明します。証明書要求メッセージオブジェクトは、X.509証明書発行を目的として、認証局（CA）（場合によっては登録局（RA）経由）への証明書要求を伝達するためのプロトコル内で使用されます。要求には通常、公開鍵と関連する登録情報が含まれます。

この文書で定義される証明書要求オブジェクトは、スタンドアロンプ​​ロトコルではありません。この文書で定義される情報は、外部で定義された証明書要求プロトコル（CRP）で使用されるように設計されています。参照プロトコルは、使用されるアルゴリズム、および定義される登録情報と制御構造を定義することが期待されます。この文書の多くの要件は、参照元の証明書要求プロトコル（CRP）を参照しています。

証明書要求は、サブジェクトに代わって証明書を要求するRA、別のCAに相互証明書を要求するCA、またはエンドエンティティ（EE）によって直接提出される場合があります。

2. 概要

証明書要求の作成は、以下の手順で行われます。

a) CertRequest オブジェクトが構築されます。このオブジェクトには、公開鍵、サブジェクト名の全部または一部、その他の要求された証明書フィールド、および登録プロセスに関連する追加の制御情報が含まれる場合があります。CRP によっては、これらの情報はサブジェクトによって指定され、RA によって変更される場合もあります。また、RA がサブジェクトに関する知識またはサブジェクトが提示した文書に基づいて指定する場合もあります。

b) 必要に応じて、証明書の要求対象となる公開鍵に対応する秘密鍵の所有証明値が計算されます。

c) 追加の登録情報は、所有証明値と CertRequest 構造体と組み合わせて CertReqMessage を作成できます。追加の登録情報は、サブジェクトと RA の両方によって追加できます。

d) CertReqMessage は CA に安全に送信されます。安全な転送の具体的な手段は、この文書を参照する各 CRP によって指定されます。

2.1. RFC 2511 以降の変更点

1. 導入セクションの追加。

2. CRP の概念と CRP に関する用語の追加。

3. セクション 6.2 で、regToken を authenticator に変更。

4. EncryptedValue 構造体の内容を説明する情報を追加。

5. OID {id-regInfo 1} の名称と内容を変更。

6. 本文書で定義されている様々な構造体のフィールドに格納される内容を詳述するテキストを追加。

7. POPが必要な理由と、様々なPOP攻撃について説明した付録Cを挿入します。

8. CertReqMsg構造体のpopフィールドは、POPとpopの混同を避けるため、popoに名前が変更されました。

9. EncryptedValue構造体の使用は非推奨となり、EnvelopedData構造体が推奨されます。

10. 暗号化時の秘密鍵の構造化方法に関する詳細を追加します。

11. DH以外の鍵共有アルゴリズムでPOPを使用できるようにします。

3. CertReqMessage の構文

証明書要求メッセージは、証明書要求、オプションの所有証明フィールド、およびオプションの登録情報フィールドで構成されます。

code:CertReqMessages

CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {

certReq CertRequest,

popo ProofOfPossession OPTIONAL,

-- コンテンツは鍵の種類によって異なります

regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL

}

CertReqMsg の各フィールドの意味は以下のとおりです。

certReq には、要求されている証明書のテンプレートが含まれます。このテンプレートは、Subject によって（または Subject に代わって）入力されます。テンプレート内のすべてのフィールドを指定する必要はありません。このフィールドの詳細については、セクション 5 を参照してください。

popo には、証明書の Subject として識別されるエンティティが、対応する秘密鍵を実際に所有していることを示すために使用される値が含まれます。このフィールドの構造と内容は、発行される証明書の KeyUsage フィールドで指定される公開鍵アルゴリズムと、そのアルゴリズムが使用されるモード（暗号化または署名）によって異なります。このフィールドの詳細については、セクション 4 を参照してください。

regInfo フィールドには、証明書要求のコンテキストに関連する補足情報のみを含める必要があります。ただし、そのような情報は要求を満たすために必要です。この情報には、加入者の連絡先情報、請求情報、または要求を満たすのに役立つその他の補助情報が含まれる場合があります。

証明書の内容に直接関連する情報は、certReq の内容に含める必要があります。ただし、RAがcertReqに追加のコンテンツを含めると、popoフィールドが無効になる可能性があります（使用されるPOP方式の詳細によって異なります）。したがって、証明書コンテンツ用のデータはregInfoで提供できます。

regInfoフィールドに指定できる内容の詳細を定義するのは、参照側のCRPの責任です。本文書では、このフィールドに含まれる情報をエンコードする1つの方法について説明します。エンコードの詳細については、付録Aを参照してください。

4. 所有証明 Proof-of-Possession (POP)

特定の攻撃（付録C参照）を防止し、CA/RAがサブジェクトと鍵ペア間のバインディングの有効性を適切に確認できるようにするため、ここで規定するPKI管理構造は、サブジェクトが証明書の要求対象となる公開鍵に対応する秘密鍵を所有している（つまり、使用できる）ことを証明することを可能にします。特定のCRPは、証明書交換においてPOPをどのように適用するか（例えば、帯域外手続き型かCRMF帯域内メッセージか）を自由に選択できます。特定のCRP内では、CAとRAは提供されているPOP方式から自由に選択できます（つまり、これはRA/CA固有のポリシー事項です）。CRPは、どのPOP方式が必須であるかを定義するか、クライアントがサポートされているPOP方式を検出するためのメカニズムを規定する必要があります（SHOULD）。

本文書を参照するすべてのCRPは、何らかの方法でPOPを適用しなければなりません（MUST）。現在、エンドエンティティと秘密鍵の結合を明示的に検証しないPKIX以外の運用プロトコルが数多く使用されています（様々な電子メールプロトコルがその一例です）。署名、暗号化、鍵共有のための鍵ペアの結合を検証する運用プロトコルが存在し、広く普及するまでは、この結合がCA/RAによって検証されているとは想定できません。したがって、公開鍵と証明書内のIDの結合が実際に正しいかどうかを真に知ることはできません。

POPは、証明書の要求対象となる鍵の種類に応じて、さまざまな方法で実行されます。鍵が複数の目的に使用できる場合（例：署名と復号にRSA鍵を使用）、いずれかの方法を使用できます（MAY）。プロトコル設計者は、使用可能なPOP方法にハードウェア上の制限がある場合があることに注意する必要があります（例：秘密鍵がハードウェアトークンに保持されている場合）。

本仕様では、POPがCA、RA、またはその両方によって検証される場合を想定しています。一部のポリシーでは、証明書発行時に CA が POP を検証することが求められます。この場合、RA はエンド エンティティの CertRequest フィールドと ProofOfPossession フィールドを、変更せずに CA に転送する必要があります (MUST)。(この場合、RA は POP を検証し、失敗した証明書要求を CA に転送するのではなく拒否することができます。) ポリシーによって CA が POP を検証することが求められていない場合、RA はエンド エンティティの要求と証明を、変更せずに上記のように CA に転送する必要があります (SHOULD)。これが不可能な場合 (たとえば、RA がアウトオブバンド方式で POP を検証する場合)、RA は raVerified 要素を使用して、必要な証明が検証されたことを CA に証明します。CA/RA がアウトオブバンド方式を使用して POP を検証する場合 (CA/RA が生成した秘密鍵の物理的な配送など)、ProofOfPossession フィールドは省略されます。

code:ProofOfPossession

ProofOfPossession ::= CHOICE {

ProofOfPossession の各フィールドの意味は以下のとおりです。

raVerified は、RA が証明書要求で要求された POP を実行したことを示します。このフィールドは、1) CA が独自の POP 検証を行う必要がない場合、かつ 2) RA が certReq フィールドの内容を変更する必要がある場合に、RA によって使用されます。CRP は、RA が ProofOfPossession に署名する方法を提供しなければなりません (MUST)。要求者はこのフィールドを設定してはならず (MUST)、また、RA/CA は要求者がこのフィールドを設定した ProofOfPossession を受け入れてはなりません (MUST)。

signature は、署名鍵を用いた POP を実行するために使用されます。このフィールドの詳細については、セクション 4.1 を参照してください。

keyEncipherment は、鍵暗号化ベースの鍵 (RSA など) を用いた POP を実行するために使用されます。このフィールドの詳細については、セクション 4.2 を参照してください。

keyAgreement は、鍵合意型暗号鍵 (DH など) を用いた POP を実行するために使用されます。このフィールドの詳細については、セクション 4.3 で説明します。

4.1. 署名鍵のPOP

署名鍵のPOPは、証明書の対象となるIDを含むデータに対して署名操作を実行することで実現されます。

署名鍵のPOPを実行する際には、以下の3つのケースを検討する必要があります。

1. 証明書の主体がCA/RAとの間で認証済みのIDをまだ確立していないが、CA/RAからパスワードとID文字列を取得している場合。この場合、POPOSigningKeyInput構造体はauthInfoにpublicKeyMACを選択して入力され、パスワードとIDを用いてpublicKeyMAC値が計算されます。要求されている証明書の公開鍵は、POPOSigningKeyInput構造体と証明書テンプレート構造体の両方に格納されます。署名フィールドは、DERエンコードされたPOPOSigningKeyInput構造体に基づいて計算されます。

2. CA/RAは証明書の主体の認証済みのIDを確立しているが、要求者はそれを証明書要求に含めていません。この場合、POPOSigningKeyInput構造体は、送信者が選択したauthInfoに基づいて入力されます。要求されている証明書の公開鍵は、POPOSigningKeyInput構造体と証明書テンプレート構造体の両方に格納されます。署名フィールドは、DERエンコードされたPOPOSigningKeyInput構造体に基づいて計算されます。

3. 証明書の主体は、公開鍵とともに自身の名前を証明書テンプレート構造体に格納します。この場合、POPOSigningKey構造体からpoposkInputフィールドは省略されます。署名フィールドは、DERエンコードされた証明書テンプレート構造体に基づいて計算されます。

code:POPOSigningKey

POPOSigningKey ::= SEQUENCE {

algorithmIdentifier AlgorithmIdentifier,

signature BIT STRING }

POPOSigningKey の各フィールドの意味は以下のとおりです。

poposkInput は、存在する場合、署名するデータを含みます。証明書テンプレートに公開鍵値とサブジェクト名値の両方が含まれていない場合は、このフィールドが必須です。

algorithmIdentifier は、POP 値を生成するために使用される署名アルゴリズムと関連パラメータを識別します。

signature は、生成された POP 値を含みます。 poposkInput が存在する場合、署名は poposkInput の DER エンコード値に基づいて計算されます。 poposkInput が存在しない場合、署名は certReq の DER エンコード値に基づいて計算されます。

code:POPOSigningKeyInput

POPOSigningKeyInput ::= SEQUENCE {

authInfo CHOICE {

-- used only if an authenticated identity has been

-- established for the sender (e.g., a DN from a

-- previously-issued and currently-valid certificate)

-- 送信者の認証済み ID が確立されている場合にのみ使用されます

-- (例: 以前に発行され、現在有効な証明書の DN)

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

-- 送信者に認証されたGeneralNameが現在存在しない場合に使用されます。

-- publicKeyMACには、publicKeyのDERエンコードされた値に基づく

-- パスワードベースのMACが含まれます。

publicKey SubjectPublicKeyInfo } -- from CertTemplate

POPOSigningKeyInput の各フィールドの意味は以下のとおりです。

sender には、サブジェクトに対して事前に確立された認証済み ID が含まれます。

publicKeyMAC には、CA/RA と証明書要求者間の共有秘密鍵を使用して計算された値が含まれます。

publicKey には、証明書テンプレートの公開鍵のコピーが含まれます。この値は、証明書テンプレートに含まれるものと完全に一致する必要があります。

code:PKMACValue

PKMACValue ::= SEQUENCE {

algId AlgorithmIdentifier,

value BIT STRING }

PKMACValue の各フィールドの意味は以下のとおりです。

algId は、MAC 値の計算に使用されるアルゴリズムを識別します。すべての実装は id-PasswordBasedMAC をサポートしなければなりません。このアルゴリズムの詳細はセクション 4.4 に記載されています。

value には、計算された MAC 値が含まれます。MAC 値は、証明書のサブジェクトの DER エンコードされた公開鍵に基づいて計算されます。

CA/RA は、1) 証明書要求の一般名フィールド、または 2) regToken (セクション 6.1 参照) または authToken (セクション 6.2 参照) のいずれかを参照することにより、使用する共有秘密鍵を特定します。

4.2. 鍵暗号化鍵

鍵暗号化鍵のPOPは、3つの異なる方法のいずれかで実行されます。秘密鍵をCA/RAに提供するか、CA/RAからの暗号化されたチャレンジを復号するか（直接方式）、作成された証明書を暗号化して返送し、チャレンジレスポンスとして使用するか（間接方式）のいずれかです。

code:POPOPrivKey

POPOPrivKey ::= CHOICE {

-- 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.

-- keyAgreement（のみ）の場合、このメッセージ（エンドエンティティの

-- 秘密DH鍵とCAの公開DH鍵から導出された鍵に基づくMAC

-- （CertReqMsgのcertReqパラメータのDERエンコードされた値、

-- subjectとpublicKeyの両方を含む必要がある）を含む）

-- で所有権が証明されます。

-- dhMAC値は、RFC 2875の静的DH所有権証明に示されている指示に従って

-- 計算されなければなりません。

SubsequentMessage ::= INTEGER {

encrCert (0),

challengeResp (1) }

POPOPrivKey の各フィールドの意味は以下のとおりです。

thisMessage には、証明書発行の対象となる暗号化された秘密鍵が含まれます。秘密鍵の所持は、CA/RA に秘密鍵を提供することで証明されます。このフィールドは、仕様が最初に作成された際に誤った型で記述されていました。このフィールドを正しく使用するには、暗号化されたコンテンツが秘密鍵である EncryptedValue 構造体を作成し、その EncryptedValue 構造体を BIT STRING 型でラップします。このフィールドは非推奨となり、encryptedKey が推奨されます。

subsequentMessage は、CA/RA からのメッセージを復号して応答を返すことで POP が完了することを示すために使用されます。復号されるメッセージの種類は、ここで指定された値によって示されます。

encrCert は、発行された証明書が暗号化された形式で返されることを示します。要求者は証明書を復号し、CA/RA に成功を証明する必要があります。詳細は CRP によって提供されます。

challengeResponse は、CA/RA から要求者にチャレンジメッセージを送信することを示します。チャレンジメッセージとレスポンスの詳細は、CRP によって提供されます。

dhMAC は、Diffie-Hellman 鍵共有鍵に使用されます。この鍵には、要求者の秘密鍵と CA/RA 公開鍵を使用して計算された MAC が含まれます。このフィールドの使用は非推奨であり、agreeMAC フィールドが推奨されます。詳細はセクション 4.3 で説明されています。

agreeMAC は、鍵共有鍵に使用されます。この鍵には、要求者の秘密鍵と対応する CA/RA 公開鍵を使用して計算された MAC が含まれます。詳細はセクション 4.3 で説明されています。

macAlg には、MAC 値の計算に使用される方法を識別するアルゴリズムが含まれます。

macValue には、計算された MAC 値が含まれます。

encryptedKey には、証明書の発行対象となる公開鍵と一致する暗号化された秘密鍵が含まれます。また、証明書の要求者によって作成されたことを示す識別値も含まれます。エンベロープコンテンツタイプは、id-ct-encKeyWithID でなければなりません。

この仕様を組み込んだプロトコルには、完全なプロトコルに必要な確認メッセージとチャレンジ レスポンス メッセージが含まれることが予想されます。

4.2.1. 秘密鍵情報コンテンツタイプ Private Key Info Content Type

このコンテンツ タイプとその構造は次のとおりです。

code:encKeyWithID

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 ::= SET OF Attribute

EncKeyWithID のフィールドは次のように定義されます。

privateKey には、エンコードされた秘密鍵が含まれます。このドキュメントには、3 つの秘密鍵形式の定義が含まれています。非対称アルゴリズムの仕様では、一貫性を保つために、公開鍵と秘密鍵の両方の定義を含める必要があります。

identifier には、CA/RA が要求元に関連付けることができる名前が含まれます。これは通常、証明書の DN か、要求元と CA/RA の両方に渡され、両者に知られているテキストトークンのいずれかになります。秘密鍵の所有を証明することが目的の場合は、このフィールドが必須です。鍵をアーカイブし、アーカイブエージェントが鍵を復号することが想定される場合は、このフィールドが必須です。

PrivatekeyInfo のフィールドは次のように定義されます。

version は値 0 でなければなりません。

privateKeyAlgorithm には、秘密鍵オブジェクトの識別子が含まれます。

privateKey は、内容が秘密鍵であるオクテット文字列で、その形式は privateKeyAlgorithm の値によって定義されます。

attribute は属性のセットです。秘密鍵情報の一部となる拡張情報です。

4.2.2. 秘密鍵の構造

ここでは、3つのアルゴリズムで使用するための構造を定義します。

4.2.2.1. D-H秘密鍵

D-H鍵のPrivateKeyInfoを作成する場合、以下のルールが適用されます。

2. privateKeyのASN構造は、

DH-PrivateKey ::= INTEGER

である必要があります。

3. 属性フィールドは省略する必要があります。

4.2.2.2. DSA秘密鍵

DSA鍵のPrivateKeyInfoを作成する場合、以下のルールが適用されます。

2. privateKey の ASN 構造は、

DSA-PrivateKey ::= INTEGER

でなければなりません。

3. 属性フィールドは省略しなければなりません。

4.2.2.3. RSA秘密鍵

RSA鍵のPrivateKeyInfoを作成する際は、以下のルールが適用されます。

1. privateKeyAlgorithmはrsaEncryptionに設定する必要があります。

3. 属性フィールドは省略する必要があります。

4.2.3. チャレンジ・レスポンス方式のガイドライン

以下は、登録プロトコル作成者向けに、間接所有証明がどのように機能するか、およびこのPOP方式を実装するためにメッセージを作成する際に注意が必要な点に関するガイドラインです。

1. 元の登録要求には、何らかの種類の本人確認情報と暗号鍵の公開鍵部分が含まれています。ただし、すり替え攻撃（攻撃者がユーザーの公開鍵を自分の公開鍵にすり替える攻撃）を防ぐため、本人確認情報は暗号鍵の公開鍵部分をカバーする必要があります。

2. サーバーからの応答メッセージには、何らかの暗号化されたデータ値が含まれます。この値は、サーバーから送信された値であることを何らかの方法で認証する必要があります。仕様には、異なる鍵の種類に対して、この値がどのように返されるかを具体的に規定する必要があります。RSA鍵の場合、値はRSA公開鍵によって直接暗号化されたものとして指定できます。しかし、値を暗号化するために間接的なメカニズムを指定する必要があるD-H鍵では、この方法は機能しません。

3. 2番目のリクエストメッセージには、復号化された値のハッシュが含まれます。このメッセージは、暗号化された値のハッシュのみであってはなりません。完全にランダムな値に「署名」するべきではないからです。ハッシュ化処理には、ID文字列などの情報を含めることで、明示的に署名を行うことが望ましいです。この返された値は、2番目のID証明に含める必要があります。

間接 POP を実行する場合は、トランザクション識別子と nonce 値を要求することを強くお勧めします。これにより、1) プロセス内のさまざまなメッセージを結び付け、2) 各エンティティが ID 証明を行うプロセスに一定量のランダム データを挿入できるようになります。

4.3. 鍵共有鍵 Key Agreement Keys

鍵共有鍵のPOPは、4つの異なる方法のいずれかで実行されます。最初の3つは、鍵暗号化鍵の場合で前述した方法と同じです。4つ目の方法は、共有秘密鍵が生成され、その値がMAC情報に使用できるという点を利用します。

上記の直接暗号化または間接暗号化を使用する場合、CA/RAは、CA/RAと要求者の間で暗号化アルゴリズムのパラメータが一致しない場合に備えて、一時的な鍵を作成する必要があります。

エンドエンティティは、POPを証明するための4つ目の方法として、証明書要求をMAC（計算によって生成された共有秘密鍵を使用）で送信することもできます。このオプションは、CA/RAがエンドエンティティに既知の証明書を既に保有しており、かつサブジェクトがCA/RAのパラメータを使用できる場合にのみ使用できます。

4.4. パスワードベースMACの使用

このMACアルゴリズムは、共有秘密（パスワード）を用いて、ある情報に対するチェック値を計算するように設計されています。パスワードがなければ正しいチェック値を計算できないという前提に基づいています。このアルゴリズムは、パスワード値に対する辞書攻撃を遅くするために、一方向性関数を複数回計算します。

パスワードベースMACに使用されるアルゴリズム識別子とパラメータ構造は次のとおりです。

code:PasswordBasedMAC

id-PasswordBasedMAC OBJECT IDENTIFIER ::=

{ 1 2 840 113533 7 66 13}

PBMParameter ::= SEQUENCE {

salt OCTET STRING,

owf AlgorithmIdentifier,

iterationCount INTEGER,

mac AlgorithmIdentifier

)

PEMParameter の各フィールドの意味は以下のとおりです。

salt には、MAC プロセスの鍵の計算に使用されるランダム生成値が含まれます。salt の長さは 8 オクテット (64 ビット) 以上である必要があります。

owf には、MAC プロセスで使用される鍵の計算に使用されるアルゴリズムと関連パラメータを指定します。すべての実装は SHA-1 をサポートする必要があります。

iterationCount には、鍵計算プロセス中にハッシュが適用される回数を指定します。iterationCount は最低 100 である必要があります。多くの人は、最小値として 1000 回程度の反復回数を使用することを提案しています。ここでのトレードオフは、パスワードを攻撃から保護することと、サーバーがパスワード導出における様々な反復処理をすべて処理するのにかかる時間との間のトレードオフです。ハッシュ化は一般的に低コストな処理と考えられていますが、将来的にはすべてのハッシュ関数でそうであるとは限らない可能性があります。

以下は、このアルゴリズムの擬似コードです。

入力:

pw - ユーザのパスワードを含むオクテット文字列

data - MAC する値を含むオクテット文字列

Iter - 反復回数

出力:

MAC - 結果の MAC 値を含むオクテット文字列

1. ランダムなソルト値 S を生成する

2. ソルトを pw に追加する。K = pw || salt

3. K の値をハッシュする。K = HASH(K)

4. Iter が 0 より大きい場合。Iter = Iter - 1。手順 3 に進む。

MAC = HASH( K XOR opad, HASH( K XOR ipad, data) )

5. CertRequest 構文

CertRequest 構文は、リクエスト識別子、証明書コンテンツのテンプレート、およびオプションの制御情報シーケンスで構成されます。

code: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 {

OptionalValidity ::= SEQUENCE {

Time ::= CHOICE {

utcTime UTCTime,

generalTime GeneralizedTime }

CertRequest の各フィールドの意味は以下のとおりです。

certReqId には、証明書要求者が特定の証明書要求と証明書応答を関連付けるために使用する整数値が含まれます。

certTemplate には、X.509 証明書のテンプレートが含まれます。要求者は、特定の値が必要なフィールドに値を入力します。各フィールドの詳細は後述します。

controls には、証明書の一部ではないものの、証明書が発行されるコンテキストを制御する属性が含まれます。このドキュメントで定義されているコントロールの詳細は、セクション 6 に記載されています。他のドキュメントでは、他のコントロールが定義されている場合があります。CRP は、どのコントロールが必要かを指定する責任を負います。

CertTemplate の各フィールドの意味は以下のとおりです。

version は指定されている場合は必ず 2 を指定してください。省略可能です。

serialNumber は必ず省略してください。このフィールドは、証明書作成時に CA によって割り当てられます。

signingAlg は必ず省略してください。このフィールドは、証明書作成時に CA によって割り当てられます。

issuer は通常省略されます。RA が複数の CA にサービスを提供している場合、要求者が証明書の発行を希望する CA を指定します。

validity は通常省略されます。これは、証明書の有効期間を将来のある時点で開始するか、特定の日付で終了するかを要求するために使用できます。このフィールドがよく使用されるのは、CA に対して相互証明書が発行される場合です。この場合、既存の証明書の有効期間がこのフィールドに格納され、新しい証明書の有効期間が既存の証明書と同じになります。validity が省略されていない場合は、少なくとも 1 つのサブフィールドを指定する必要があります。サブフィールドは以下のとおりです。

subject には、要求者の提案名が入ります。通常は、CA が要求者に以前に発行した名前が入ります。

publicKey には、証明書を作成するための公開鍵が含まれます。要求者が独自の鍵を生成する場合は、このフィールドは必ず入力する必要があります。鍵が RA/CA によって生成される場合は、このフィールドは省略されます。

extensions には、要求者が証明書に追加することを希望する拡張機能が含まれます。これらの拡張機能は、一般的に、鍵の用途をkeyEnciphermentに設定するといった処理を行います。

publicKeyフィールドを除き、CA/RAは要求されたあらゆるフィールドを変更することが許可されています。返された証明書は、要求者が各フィールドが適切に設定されているかどうかを確認する必要があります。CA/RAは、可能な限りテンプレートのフィールドを使用するべきです。

テンプレートのすべてのフィールドを省略できる場合もあります。鍵生成がCA/RAで行われ、身元証明が別の場所（下記のid-regCtrl-regTokenなど）に保存されている場合、証明書要求者が指定する必要のあるフィールドはありません。

6. 制御構文 Controls Syntax

CertRequest のジェネレータには、リクエストの処理に関連する1つ以上の制御値を含めることができます。

Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue

このドキュメントでは、以下の制御を定義します。regToken (セクション 6.1)、authenticationator (セクション 6.2)、pkiPublicationInfo (セクション 6.3)、pkiArchiveOptions (セクション 6.4)、oldCertID (セクション 6.5)、protocolEncrKey (セクション 6.6)。各 CRP は、そのプロトコルでサポートされる制御セットを定義する必要があります。追加の制御は、追加の RFC または CRP プロトコル自体で定義される場合があります。

6.1. 登録トークン制御 Registration Token Control

regToken制御には、CAが証明書発行前にサブジェクトの身元確認を行うために使用する、（秘密値またはその他の共有情報に基づく）ワンタイム情報が含まれます。regTokenの値を含む証明書要求を受信すると、受信側のCAは、証明書要求で主張された身元を確認するために、その情報を検証します。

regTokenの値は、CAによって生成され、加入者に帯域外で提供される場合もあれば、CAと加入者の両方が利用できる場合もあります。帯域外交換のセキュリティは、意図された加入者以外の第三者から傍受された値を受け入れることに関してCAが許容するリスクに見合ったものでなければなりません。regToken値は返される際に暗号化されません。データが機密情報とみなされる場合は、要求者によって暗号化される必要があります。

regToken制御は、エンドエンティティをPKIに初期化する場合にのみ使用されます。一方、認証子制御（セクション7.2参照）は、最初の認証要求だけでなく、それ以降の認証要求にも使用できます。

regTokenの値は、場合によってはテキスト文字列、または乱数などの数値となることがあります。後者の場合、値はバイナリ値のテキスト文字列表現としてエンコードされます。regTokenのエンコードはUTF8Stringでなければなりません（SHALL）。

id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }

加入者とCAエージェントの間で事前の合意がない場合、この値は何らかのテキスト形式の共有秘密となります。代わりに、その共有秘密に基づいて計算された値を使用する場合は、CRPにおいて当該計算のための新たな登録制御を定義することが推奨されます。

6.2. 認証子制御 Authenticator Control

認証子制御には、CAとの通信において、暗号を用いない本人確認を継続的に行うために用いられる情報が含まれます。例としては、母親の旧姓、社会保障番号の下4桁、または加入者のCAと共有されるその他の知識ベース情報、これらの情報のハッシュ値、あるいはこの目的で生成されるその他の情報などが挙げられます。認証子制御の値は、加入者またはCAによって生成される場合があります。

場合によっては、認証子の値はテキスト文字列、または乱数などの数値となることがあります。後者の場合、値はバイナリ量のテキスト文字列表現としてエンコードされます。認証子のエンコードはUTF8Stringとします（SHALL）。

id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }

認証子とregTokenのどちらを使用するかを決定する際には、以下のガイドラインに従ってください。値が1回限り使用される場合はregTokenを使用します。値が長期間使用される場合は、認証子制御を使用します。

6.3. 公開情報制御 Publication Information Control

pkiPublicationInfo制御により、加入者はCA/RAによる証明書の公開に影響を与えることができます。この制御は勧告的なものであり、CA/RAは無視することができます。この制御は、以下のOIDと構文で定義されます。

code:PKIPublicationInfo

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 }

PKIPublicationInfo の各フィールドの意味は以下のとおりです。

action は、要求者が CA/RA に証明書の公開を希望するかどうかを示します。値とその意味は以下のとおりです。

dontPublish は、要求者が CA/RA に証明書の公開を希望しないことを示します（これは、要求者が自ら証明書を公開する意図を示している可能性があります）。dontPublish を使用する場合は、pubInfos フィールドを省略する必要があります。

pleasePublish は、要求者が CA/RA に証明書の公開を希望することを示します。

pubInfos には、要求者が CA/RA に証明書の公開を希望する場所が保持されます。dontPublish を選択した場合、このフィールドは省略されます。要求者が証明書の公開場所をいくつか指定し、CA/RA が他の場所での公開を許可する場合は、SinglePubInfo 構造体の複数の値を指定します。そのうちの 1 つが dontCare です。

SinglePubInfo の各フィールドの意味は以下のとおりです。

pubMethod は、要求者が CA/RA に証明書の発行を希望する場所のアドレスタイプを示します。

dontCare は、CA/RA が任意の場所に証明書を発行できることを示します。dontCare を使用する場合は、pubInfos フィールドを省略する必要があります。

x500 は、要求者が CA/RA に証明書を特定の場所に発行することを希望していることを示します。発行場所は pubLocation の x500 フィールドに示されます。

ldap は、要求者が CA/RA に証明書を特定の場所に発行することを希望していることを示します。発行場所は pubLocation の ldap フィールドに示されます。

web は、要求者が CA/RA に証明書を特定の場所に発行することを希望していることを示します。発行場所は pubLocation の http フィールドに示されます。

pubLocation には、証明書が配置されるアドレスが含まれます。一般名フィールドの選択は、この構造体のpubMethodの選択によって決定されます。

公開場所は任意の順序で指定できます。すべての場所は、公開のためにCAによって処理されます。