3. データ構造 English
この章で、PKI 管理メッセージに関わるデータ構造について説明します。第 4 章で、それぞれ異なる PKI 管理操作ごとに、データ構造の値とイベントの結果に対する制約を規定します。第 5 章では、いかにこれらをカプセル化し、様々な伝送機構に組み入れるのかについて述べます。
本仕様の中で使用され、PKI 管理目的としたすべてのメッセージは以下の構造を使用します。
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL}
PKIHeader は PKIメッセージに共通する情報を格納します。
PKIBody はメッセージ固有の情報を格納します。
PKIProtectionが使用される場合は、PKI メッセージを保護するためのビットを格納されています。
extraCertsフィールドは受取者にとって有用な証明書を格納することができます。例えば、CA か RA がこのフィールドを利用して自分の新しい証明書を検証するために必要な証明書を EE に付与することができます。（もし、例えば、 EE の証明書を発行した CA は 、当該 EE のルート CA ではない場合）このフィールドには特に認証パスを格納する必要性がないことに注意してください。受取者はそれらの格別な証明書を使用するためには、ソート（sort）、検索（select from）、あるいはその逆順で処理しなければならないことがあります。
宛先の特定やトランザクションの識別を行うために、すべての PKI メ ッセージが何らかのヘッダー情報を必要とします。これらの情報は伝送に特化したエンベロップ（envelope）に格納されることもありますが、もし PKI メッセージが保護されていればこの情報も同様に保護されることになります。（すなわち、安全な伝送については何も前提を設けない）
この情報を格納するデータ構造について、以下に示します。:
PKIHeader ::= SEQUENCE {
pvno INTEGER { ietf-version2 (1) },
sender GeneralName,
-- 送信者を識別する
recipient GeneralName,
-- 対象の受信者を識別する
messageTime [0] GeneralizedTime OPTIONAL,
-- このメッセージの生成時刻（送信者がこの伝送が「適切だ」と思うときに使用される。すなわち、受信者にとって意味あること）
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
-- 保護ビットを計算するためのアルゴリズム
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- 保護目的の特定の鍵を識別するため
transactionID [4] OCTET STRING OPTIONAL,
-- トランザクションの識別；すなわち、対応している要求、応答および確認メッセージの同一フィールド値は同一である）
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- リプレイ対策としてのノンス。senderNonceはこのメッセージの生成者によって挿入されます。recipNonce はこのメッセージの意図した受信者が以前に関連のメッセージに挿入したノンスです。
freeText [7] PKIFreeText OPTIONAL,
-- これを使ってコンテキスト固有命令（context-specific instructions）を識別します。（このフィールドは人間による操作を想定している）
generalInfo [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue OPTIONAL
-- これを使って、コンテキスト固有命令を伝送します。（このフィールドは基本的に人間による操作を想定されていない）}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- UTF-8 Stringにエンコード化されたテキスト（注意事項：UTF8String 中のテキスト言語を判別するために、UTF8String ごとに RFC1766 言語のタグを含めることとします。）このバージョンの本仕様において、pvno フィールドが固定（同一に）されています。
sender フィールドは PKIMessage の送信者の名称を格納します。その名称（senderKID が提供された場合は、それと結合して）はこのメッセージにかかる保護（protection）の検証に役に立ちます。送信エンティティが送信者について何も知らなければ（例えば、初期要求メッセージにおいて、 EE が自分の識別名（DN）、電子メール名、IP アドレスなどを知らないこともある）、sender フィールドには必ず「NULL」という値を設定しなければなりませんx。； つまり、関連識別名のSEQUENCE OFの長さは「0」であることです。このような場合は、senderKID フィールドにはこのメッセージを検証するための適切な共有秘密情報を受信者に指し示すための識別子（つまり、参照番号）を持たなければなりません。
Recipient フィールドは PKIMessage の受信者の名称を格納しています。この名称（recipKID が提供されて入れば、それと結合して）はこのメッセージにかかる保護の検証に役に立ちます。
protectionAlg フィールドはメッセージを保護するためのアルゴリズムを指定します。もし保護ビットが提供されていなければ（PKIProtection がオプションであることに注意）、このフィールドを省略しなければなりません 。； 保護ビットが提供された場合は、このフィールドも必ず提供しなければなりません。
senderKID とr ecipKID はメッセージの保護にどの鍵が使われていたのかを識別するために使用されます。（通常、メッセージの保護にディフェ・ヘルマン（DH）鍵が使われた場合にのみ、recipKIDが必要）メッセージヘッダーにある transactionID フィールドを使えば、レスポンス・メッセージの受信者がレスポンス・メッセージを以前に発行したリクエストと関連づけることを可能にします。例えば、RAの場合はある指定の時刻にいくつものリクエストが「目立っている」可能性があります。
senderNonce と recipNonce フィールドはリプレイ攻撃から PKIMessage を守ります。
messageTime フィールドには送信者がそのメッセージを作成した時刻を格納します。これは、 EE のローカル時間をセントラル・システム時間と一致するように修正することに役に立ちます。
freeText フィールドを用いて、受信者に人間が読み取り可能なメッセージ（いくつの言語で書かれても）を送付することができます。このシーケンスに書かれている最初の言語は応答のなかで使用してほしい言語を表しています。
generalInfo フィールドを使って、受信者に機械処理可能な付加的なデータを送信することができます。
PKIBody ::= CHOICE { -- message-specific body elements メッセージ固有の本文の構成部分
ir [0] CertReqMessages, --Initialization Request初期化要求
ip [1] CertRepMessage, --Initialization Response初期化応答
cr [2] CertReqMessages, --Certification Request認証要求
cp [3] CertRepMessage, --Certification Response認証応答
p10cr [4] CertificationRequest, --PKCS #10 Cert. Req. PKCS #10認証要求 PKCS #10認証要求（[PKCS10]を参照）
popdecc [5] POPODecKeyChallContent, --pop Challenge （popチャレンジ）
popdecr [6] POPODecKeyRespContent, --pop Response（pop応答）
kur [7] CertReqMessages, --Key Update Request（鍵更新要求）
kup [8] CertRepMessage, --Key Update Response（鍵更新応答）
krr [9] CertReqMessages, --Key Recovery Request（鍵回復要求）
krp [10] KeyRecRepContent, --Key Recovery Response（鍵回復応答）
rr [11] RevReqContent, --Revocation Request（失効要求）
rp [12] RevRepContent, --Revocation Response（失効応答）
ccr [13] CertReqMessages, --Cross-Cert. Request（相互認証要求）
ccp [14] CertRepMessage, --Cross-Cert. Response（相互認証応答）
ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann.（CA 鍵更新通知）
cann [16] CertAnnContent, --Certificate Ann.（証明書通知）
rann [17] RevAnnContent, --Revocation Ann.（失効通知）
crlann [18] CRLAnnContent, --CRL Announcement（CRL通知）
conf [19] PKIConfirmContent, --Confirmation（確認）
nested [20] NestedMessageContent, --Nested Message（ネスト化メッセージ）
genm [21] GenMsgContent, --General Message（一般メッセージ）
genp [22] GenRepContent, --General Response（一般応答）
error [23] ErrorMsgContent --Error Message（エラーメッセージ）}
種類別の詳細については、以下の 3.3 節にて説明します。
一部の PKI メッセージはその完全性が保護されています。（もしメッセージの保護に非対称型アルゴリズムが使われ、関連の公開コンポネントが既に認証された場合、メッセージの原本性も証明されることに注意してください。他方では、もし公開コンポーネントが未認証である場合に、メッセージの原本性は自動的に認証されることはないが、アウト・オブ・バンド方式経由で認証されることができます。）
保護の適用を実施する際に、下記の構造を使用します。
PKIProtection ::= BIT STRING
PKIProtection計算に対する入力は以下のデータ構造をDERエンコード化したものです。 ：
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody}
場合によって、メッセージ保護以外の目的に PKIProtection BIT STRING を故意に使用することがあります。（すなわち、この OPTIONAL フィールドが省略されます）その原因は PKIX 外部のほかの保護が代わりに適用されることがあるからです。このような選択の余地は本仕様のなかで明示的に認められています。このような外部保護の実例として、 PKCS#7[PKCS7] や PKIMessage（関連PKIHeader情報が外部機構によって安全に伝送が行われていれば、PKIBody のみで（CHOICE タグを省いて））のセキュリティ・マルチパーツ [RFC1847] によるカプセル化などが挙げられます。PKCS #7 を使用した外部保護の仕様については、別のドキュメントのなかで提供されます。よく知られているように、このような外部機構の多くは EE が既に公開鍵証明書と（または）識別名、およびそのほかのインフラストラクチャ関連情報を所有していることを要求します。したがって、初期登録、鍵回復、またはそのほかの「boot-strapping」特徴をもつ処理には適切ではないかもしれません。このような場合は、PKIProtection パラメータの使用が必要かもしれないです。将来的に「boot-strapping」シナリオに適合するように外部機構が変更されたら（された場合）、PKIProtection の使用は珍しくなるか存在しなくなることと考えられます。
環境によって、PKIProtection ビットにはメッセージ認証コード（MAC）または署名を格納することができます。以下の場合のみが発生可能です。：
- 共有秘密情報
この場合、送信者と受信者の間に秘密情報を共有します。（アウト・オブ・バンド方式経由か以前の PKI 管理操作によって確立される）PKIProtection には MAC 値が格納され、protectionAlg は以下の通りです：
PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {salt OCTET STRING,
owf AlgorithmIdentifier,
-- 一方向関数のAlgId（SHA-1推奨）
iterationCount INTEGER,
-- OWFの適用回数
mac AlgorithmIdentifier
-- AlgId（例えば、DES-MAC、Triple-DES-MAC [PKCS11]、上記の protectionAlg の中にソルト値（salt value）が共有秘密入力の後ろに付加されています。OWF が iterationCount 回に適用されて、ソルティット秘密（salted secret）は最初 1回目の繰り返しへの入力値となり、後続の繰り返しへの入力は前回の繰り返しの出力となっています。繰り返しの最後の出力（参照しやすくするために「基本鍵（BASEKEY）」と呼び、そのサイズは "H" である）は対称鍵の生成に使われます。もし MAC アルゴリズムがKビットの鍵を要求し、そして（K<= H）の場合に、基本鍵の最も重要なKビットが使用されます。もし K > H ならば、基本鍵の全体が鍵の最も重要な H ビットのために使い、OWF （"2" || BASEKEY）は鍵の次になる重要なHビットに使い、以降も同様、最後にすべてのK ビットを出し切るまでです。（ここの "N" は数字 N のアスキー・バイト（ASCII byte）・エンコーディングであり、そして「||」は連結を意味します）
- DH鍵ペア
送信者と受信者が互換性のある DH パラメータ付きのディフィ・ヘルマン証明書を所有するときに、メッセージ保護のために EE はその秘密 DH 鍵値とPKI メッセージの受信者の DH 公開鍵を基に、対称型鍵を生成しなければなりません。PKIProtection はこの生成された対称型鍵をもとにできた MAC 値を格納し、そして protectionAlg は以下の通りになります。
DHBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
-- 一方向関数のAlgId（SHA-1推奨）
-- AlgId（例えば、DES-MAC、Triple-DES-MAC [PKCS11]、上記の protectionAlg のなかで、OWF がディフィ・ヘルマンの計算結果に適用されます。 OWF 出力（参照しやすいように「基本鍵（BASEKEY）」と呼び、そのサイズを"H"とする）を用いて対称鍵が生成されます。もし MAC アルゴリズムがKビットの鍵を要求し、そしてK <= Hならば、基本鍵の最も重要なKビットが使用されます。K > H の場合に、基本鍵の全体を鍵の最も重要な H ビットに使い、OWF（"1" || BASEKEY）は次に最も重要な鍵の H ビットに使用し、OWF（"2" || BASEKEY）またその次に最も重要な鍵のHビットに使用し、以降同様、すべての K ビットが出し切るまで（これをくりかえします）。（ここの "N" は数字Nのアスキー・バイト（ASCII byte）・エンコーディングであり、そして「||」は連結を意味します）
- 署名
送信者が署名鍵ペアを持っていれば、簡単に PKI メッセージに署名をすることができます。PKIProtection は署名値を含み、protectionAlg はディジタル署名（例えば、 md5WithRSAEncryption または dsaWithSha-1）の AlgorithmIdentifier となります。
- 多重保護
EE が保護済みの PKI メッセージを RA に送信するときに、RA はそのメッセージに自分の保護（MAC か署名の可能性があり、RA と CA 間に共有する情報と証明書に依存）をくっつけ、その後 CA に先渡しをすることはあります。これは EE が送付したメッセージの全体をネスト化し、新しい PKI メッセージの中に入れることで実現します。その構造は下記に示します。
NestedMessageContent ::= PKIMessage
PKIBody の詳細種別を明示する前に、ここに様々なケースで使われるデータ構造について定義します。
多くの PKI 管理メッセージは証明書の必要フィールドを明示するよう、メッセージの作成者に要求します。CertTemplate 構造は EE か RA に必要なだけの証明書フィールドの指定を認めています。CertTemplate は一枚の証明書と同じですが、すべてのフィールドはオプションフィールドです。
たとえメッセージの作成者が申請の証明書の内容を指定したとしても、CA が実際発行する証明書のフィールドに対して自由に変更を加えることができることに注意してください。もし、その修正された証明書が要求者にとって受領できないものであれば、確認メッセージが保留されるかエラーメッセージ（PKIStatus が「拒否（rejection）」に設定されている）が送られることになります。
CertTemplate 構文については、[CRMF] を参照してください。
PKI メッセージで暗号化された値を送信する場合は、EncryptedValue データ構造を使用します。
EncryptedValue 構文については、[CRMF] を参照してください。
このデータ構造を使用するには、生成者と意図した受信者がそれぞれ暗号化と復号ができることを要求します。一般的に、それは送信者と受信者が共有の機密鍵を所有し、または生成できることを意味します。
もし PKIMessage の受信者が既に復号用の秘密鍵を所有していれば、encSymmKey フィールドに受信者の公開鍵で暗号化したセッション鍵を格納することができます。
3.2.3 PKI メッセージのステータス・コードと故障情報 English
すべての応答メッセージには何らかのステータス情報が含まれています。その値の定義は以下の通りです。
PKIStatus ::= INTEGER {
granted (0),
-- 要求したものがその通りに受け取った
grantedWithMods (1),
-- 要求したものと同様なものを受け取った。要求者はその差異を確認する責任がある。
rejection (2),
-- 受け取らなかった。未到着メッセージの中にまだ他の情報がある。
waiting (3),
-- リクエストの本文の部分はまだ未処理状態にあり、後でより多い情報の入手を予期する。
revocationWarning (4),
-- 失効が間近に迫っているとの警告がこのメッセージに含まれている。
revocationNotification (5),
-- 失効の発生を通知する。
keyUpdateWarning (6)
-- 鍵更新要求メッセージで指定されたoldCertIdが更新完了。}
失敗の場合について、応答者は以下の構文を用いてより多くの情報を提供することができます。
PKIFailureInfo ::= BIT STRING {
-- 故障の仕方が一通りではないゆえに、将来的に／必要に応じて、ほかのコードを追加することが可能です。badAlg (0),
-- 未認識または非対応のアルゴリズム識別子
badMessageCheck (1),
-- 完全性確認失敗（例えば、証明書が検証不可など）
badRequest (2),
-- 許可されていないまたは非対応のトランザクション
badTime (3),
-- messageTime とシステムタイムとの時間差はローカル・ポリシーの要件定義に満たさなかった。
badCertId (4),
-- 与えられた基準に合致する証明書はなかった。
badDataFormat (5),
-- 提示されたデータのフォーマットが誤っている
wrongAuthority (6),
-- リクエストに示された機関はレスポンス・トークンを生成する機関と相違する
incorrectData (7),
-- リクエスタのデータが間違っている（公証サービス向けに）。
missingTimeStamp (8),
-- ポリシーに従い、存在するはずのタイムスタンプが見つからない。
badPOP (9)
-- proof-of-possession失敗}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL}
特定の証明書を識別するには CertId データ構造を使用します。
CertId構文については [CRMF] を参照します。
3.2.5 「アウト・オブ・バンド」ルート CA 公開鍵 English
個々のルート CA は何らかの「アウト・オブ・バンド」方式で最新の公開鍵の公開を可能にしなければなりません。このような機構は本ドキュメントの規定範囲外ですが、それをサポートするデータ構造について定義します。
通常2通りの利用可能な方法があります。： CA が直接に自己署名の証明書を公開する方法； あるいはその証明書情報をディレクトリ（それに相当するもの）を通して利用可能にし、さらに CA がそのハッシュ値を公開し、利用する前にその完全性を検証可能にする方法。
OOBCert ::= Certificate
この証明書のフィールドについて、下記のように制約されています：
- 証明書は自己署名したものでなければなりません。（すなわち、その署名は SubjectPublicKeyInfo フィールドで検証可能でなければなりません）
- 主体者（subject）フィールドと発行者（ issuer）フィールドは同じでなければなりません。
- 主体者フィールドが NULL であれば、subjectAltNames と issuerAltNames 拡張は必ず存在し、かつ値が等しくなければなりません
- 他のすべての拡張領域の値は自己署名証明書に適合しなければなりません。（例えば、主体者と発行者の鍵識別子は同じでなければなりません。）
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
-- hashValは自己署名証明書を基に、識別子の certID で計算されたものです。}
ハッシュ値の目的はハッシュ値を安全に（アウト・オブ・バンド方式で）受け取った誰しも当該 CA の自己署名証明書を検証できるようにすることです。
リクエスタは秘密鍵の値を PKIArchiveOptions 構造でアーカイブするよう PKI に要望することができます。
PKIArchiveOptions 構文については、[CRMF] を参照してください。
リクエスタはPKIPublicationInfo構造体による証明書の公開を PKI に要望することを示すことができます。
PKIPublicationInfo 構文については、[CRMF] を参照してください。
3.2.8 Proof-of-Possession 構造体 English
もし証明書の要求は署名用鍵ペアを対象とするならば（すなわち、検証証明書の申請）、秘密署名鍵の「所有の証明（proof of possession）」は POPOSigningKey 構造体の使用によって実証されます。
POPOSigningKey 構文については、[CRMF] を参照してください。本仕様において POPOSigningKeyInput に以下の意味的な条件があることに注意してください。
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- PKIHeader から（送信者が既に信頼における身元が確立された場合に限り、使用されます（例えば、以前発行かつ現在有効な証明書にある識別名（DN）））publicKeyMAC [1] PKMACValue
-- 送信者の認証済みのGeneralNameが存在しない場合にのみ、使用されます。publicKey の DER エンコード化された値に対する（PKIHeader の protectionAlg AlgId を用いて）パスワード・ベースの MAC が publicKeyMAC に格納されます。},
publicKey SubjectPublicKeyInfo -- from CertTemplate
}
もう一方、暗号鍵ペアに対する認証要求（すなわち、暗号証明書に対する要求）の場合は、秘密復号鍵の「所有の証明（proof of possession）」は以下の三つの方法のいずれかで実証することができます。
1) （PKIArchiveOptions 制御構造の）CertRequest に（暗号化された状態の）秘密鍵を含める方法
2〉証明書ではなく、暗号化された証明書を CA から返してもらう方法（すなわち、ランダム生成の対称型鍵で暗号化される証明書、そしてその対称型鍵は認証リクエストの生成時に使用した公開鍵で暗号化されている）――これは前の 2.3.2 節で言及した「間接的」な方法です。 EE はこの対称型鍵から派生された鍵を用いて、MACing メッセージと PKIConfirm メッセージを通して秘密復号鍵についての認識を CA に証明します。（PKIMessage に 1つ以上の CertReqMsg が含まれている場合は、CA は CertReqMsg ごとに異なる対称鍵を使用し、そして MAC がこれらすべての鍵の連結から派生された鍵を使用します。）MACing 手順において、3.1 節で定義された PasswordBasedMac AlgId が使用されます。
3) CertReqMessages と CertRepMessage 間の「チャレンジ―レスポンス」プロトコルを EE に取り入れさせる方法――これは前の 2.3.2節で言及した「直接」な方法です。（RA が POP を認証し、そして EE に代わって CA に対して認証要求を行う環境での使用がこの方法の典型的なケースです。）プロトコルの全体は以下のように示します（req' が req をネスト化メッセージにカプセル化する必要がないことに注意してください 。）
EE RA CA ---- req ----> <--- chall resp> ---- req' ---> <--- rep conf> <--- rep conf>このプロトコルは明らかに上記の選択肢（2）で提示した 3つのやり取りよりも長いですが、ローカルの登録局の使用を許可し、そして「proof of possession」が完了するまで証明書自身が生成されない特性をもっています。
もし証明書要求が鍵合意鍵（KAK）ペアを対象した場合に、POP は暗号化鍵ペアを対象とした上記の 3つ方法のいずれかを使用することができます。以下の変更点があります：（1）項目2)の説明文は"（すなわち、CA の秘密 KAK と認証リクエストの対象である公開鍵から派生された対称型鍵によって暗号化される証明書）"に取り替えられる；（2）「チャレンジ」のchallengeフィールドの一番目の説明文は、以下のように取り替えられる 。：「PreferredSymmAlg (付録 B6 を参照)および CA の秘密KAKと認証リクエストの対象である公開鍵から派生された対称型鍵を使用する」。あるいは、もし CA が既に EE の認知を受けた D-H 証明書を所有していれば、POP 実証の4つ目の代替策として、POP は [CRMF]（中の alg フィールドに DHBasedMAC を、signatureフ ィールドに MAC を格納されています） にある POPOSigningKey 構造体を使用することができます。
秘密復号鍵の「所有の証明（proof of possession）」用の「チャレンジ―レスポンス」メッセージは以下のように明記します。（詳細は[MvOV97, p.404]を参照）「チャレンジ―レスポンス」交信は PKIHeader にあるノンス（nonce）および PKIMessage に対する保護（MACing または署名）によって、先行する証明書リクエスト・メッセージ（そして後続する証明書レスポンスと確認メッセージ）とに結び付けられます。
POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- 暗号鍵認証リクエストごとにチャレンジが1つあります（CertReqMessages に表示されているリクエストと同じ順番に）
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
-- 最初のチャレンジに必ず存在します。； POPODecKeyChallContent にある後続の任意のチャンレジにおいては省略可能です（省略された場合は、直前のチャレンジで使われた owf を使うことになっています。）witness OCTET STRING,
-- ランダム生成の整数Aに一方向関数（owf）を適用した結果（個々のチャレンジには必ず異なる整数を使用しなければなりません）challenge OCTET STRING
-- Randの暗号化（証明書リクエストの対象である公開鍵による）。Rand は以下に示す通りです。：-- Rand ::= SEQUENCE {
-- int INTEGER,
-- - ランダム生成の整数A（上記）-- sender GeneralName
-- 送信者の名前（PKIHeader に含まれているものと同様）}
}
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
-- 暗号化鍵認証リクエストごとに整数が 1つ存在します（CertReqMessages に表示されているリクエストと同じ順番）。戻り値の整数 A（上記）は当該チャレンジの送信者に返されます。
3.3.1 初期化リクエスト English
初期化リクエストメッセージには要求の証明書を明記するための PKIBody と CertReqMessages データ構造を含んでいます。典型的な場合は、ubjectPublicKeyInfo、 KeyId、および Validity は要求された個々の証明書に提供できる雛形フィールドです。（詳細の情報は付録 B のプロファイルを参照）このメッセージはエンティティが最初に PKI に参加（加入）するために初期化する際に使うことを意図しています。
CertReqMessages 構文については、[CRMF] を参照してください。
3.3.2 初期化レスポンス English
初期化レスポンスメッセージには PKIBody が格納されています。PKIBody は個々の証明書別に、PKIStatusInfo フィールド、主体者証明書（subject certificate）、そして大抵の場合に秘密鍵（通常セッション鍵によって暗号化され,セッション鍵自身も protocolEncKey で暗号化されている)をもつ CertRepMessage データ構造となっています。
CertRepMessage 構文については 3.3.4 節を参照してください。PKI メッセージ保護が「共有秘密情報」（ 3.1.3 節を参照）の場合に、caPubs フィールドに示されている任意の証明書はルート CA 証明書として直接にイニシエータによって信頼されることができることに注意してください。
3.3.3 登録／認証リクエスト English
登録／認証リクエストメッセージには要求の証明書を明示するための CertReqMessages データ構造が PKIBody として格納されています。このメッセージは既存のPKIエンティティがほかの証明書を取得しようとする際に、使用することとなっています。
CertReqMessages 構文については、[CRMF] を参照してください。
また、PKIBody は CertificationRequest である場合もあります。（[PKCS10] の ASN.1 構造にある CertificationRequest がこの構造の完全な定義をしています）この構造はレガシーシステムとの相互接続性が要求されたときに、署名鍵ペアの証明書リクエストに必要とされますが、絶対に必須の場合を除き、その使用は極力避けるべきです。
登録レスポンスメッセージは CertRepMessage デ ータ構造を PKIBody として格納しています。その構造は要求の証明書ごとにステータス値をもっており、そしてオプションとしてCAの公開鍵、故障情報、主体者証明書、暗号化された秘密鍵も格納できます。
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
response SEQUENCE OF CertResponse}
CertResponse ::= SEQUENCE {
certReqId INTEGER,
-- このレスポンスを対応のリクエストに照合させる（対応のリクエストに certReqId が明示されていなければ、値-1 が使われます。）status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- CertReqMsg [CRMF]のregInfoのために定義したid-regInfo-asciiPairs OCTET STRING に類似します。}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
publicationInfo [1] PKIPublicationInfo OPTIONAL}
CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue}
個々の CertResponse（ステータスに依存する）には(PKIStatusInfo の中の)failInfo と (CertifiedKeyPair の中の)証明書が 1つずつしか格納することができません。一部のステータス値（たとえば、waitingの場合）の際に、このオプションフィールドのいずれも表示されません。
EncryptedCert と適切な復号鍵があれば、証明書を取得することができます。CA から証明書の値を返しますが、意図した受取者しかその実際の証明書を取得することができない制約にすることを目的としています。このアプローチの利点というのは、たとえリクエスタが関連秘密鍵を使用できる EE の証明が存在しなくても、CA が証明書で応答することができるからです。（CA が PKIConfirm メッセージを受領するまではその証明を受け取れないことに注意してください）。そうして proof of possession に何らかの支障が起きたとしても、CA がその証明書を失効させる必要はありません。
3.3.5 鍵更新リクエストの内容 English
鍵更新リクエストに CertReqMessages 構文が使用されています。典型的な場合、更新対象の鍵ごとにSubjectPublicKeyInfo、KeyId、および Validity が雛形フィールドとして提供されています。このメッセージは現存する（失効されてない、かつ期限切れてない）証明書の更新を要求するために使用されます。
CertReqMessages構文については [CRMF] を参照してください。
3.3.6 鍵更新レスポンスの内容 English
鍵更新レスポンスに CertRepMessage 構文が使用されます。このレスポンスは初期化レスポンスと同一のものです。
CertRepMessage 構文に 3.3.4 節を参照してください。
3.3.7 鍵回復リクエストの内容 English
鍵回復リクエストには初期化リクエスト CertReqMessages と同じ構文が使われます。典型的な場合、SubjectPublicKeyInfo と KeyId は証明書の要求対象である署名公開鍵を提供するための雛形フィールドとされます。
CertReqMessages 構文については、[CRMF] を参照してください。もし鍵履歴が要求された場合に、リクエストメッセージの中でリクエスタがプロトコル暗号化鍵制御（Protocol Encryption Key control）を提供できなければならないことに注意してください。
3.3.8 鍵回復レスポンスの内容 English
以下の構文が鍵回復レスポンスに使用されます。一部のステータス値（例えば、waiting）の場合に、オプションのフィールドが一切存在しません。
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF CertifiedKeyPair OPTIONAL}
3.3.9 失効リクエストの内容 English
ある証明書（またはいくつの証明書）の失効を要求する際に、以下のデータ構造が使用されます。リクエスタの名前は PKIHeader 構造体の部分に表示されます。
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
--失効要求に必要なだけの量の証明書情報をリクエスタがここに明記することが可能。
--（例えば、serialNumber が利用不可能な場合に）revocationReason ReasonFlags OPTIONAL,
-- 失効を要求する理由badSinceDate GeneralizedTime OPTIONAL,
-- 送信者について最新情報の明記crlEntryDetails Extensions OPTIONAL
-- 要求されたcrlEntryExtensions}
3.3.10 失効レスポンスの内容 English
上記メッセージに対する応答です。生成された場合、失効を要求したリクエスタに送られます。（失効通知メッセージは失効を要求された証明書の主体者に別途送付されることもあります。）
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, -- RevReqContentの中で送る順番と同じ
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, -- 失効を要求されたID（ステータスと同じ順番）
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL -- 結果としてのCRL（1つ以上の可能性があります）}
3.3.11 相互認証リクエストの内容 English
相互認証リクエストは通常の認証リクエストと同じ構文（CertReqMessages）を使用しますが、鍵ペアは必ず要求側 CA によって生成され、そして応答側 CA に秘密鍵を送付してはいけない制約を持っています。
CertReqMessages 構文は[CRMF] を参照してください。
3.3.12 相互認証レスポンスの内容 English
相互認証レスポンスは通常の証明書レスポンスと同じ構文(CertRepMessage) を使用しますが、暗号化された秘密鍵の送付を禁止する制約があります。
CertRepMessage 構文については、3.3.4 節を参照してください。
3.3.13 CA鍵更新通知の内容 English
CA が自分の鍵ペアを更新する際に、このイベントを発表するために以下のデータ構造体が使用されることがあります。
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate, -- 新しい秘密鍵で署名した古い公開鍵
newWithOld Certificate, -- 古い秘密鍵で署名した新しい公開鍵
newWithNew Certificate -- 新しい秘密鍵で署名した新しい公開鍵}
3.3.14 証明書通知 English
この構造体は証明書の存在を通知するために使うことができます。
このメッセージは、証明書の公開に既存の方法が存在しない場合に使われることを想定していることに注意してください。； 例えば、X.500 を証明書公開の手段としているところでの使用は想定されていません。
CertAnnContent ::= Certificate
3.3.15 失効通知 English
CA がある特定の証明書を失効させた、あるいは失効させようとする場合に、この（やがて発生する）イベントの通知を行うことができます。
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL -- 追加 CRL の詳細（例えば、crl 番号、理由、ローケションなど）}
CA はこのような通知を用いて証明書が失効されることになる（あるいは既に失効されたこと）について主体者に警告あるいは通知を行うことができます。失効リクエストが主体者自身によるものではない場合に、典型的に使われます。
willBeRevokedAt フィールドには新しいエントリーが関連 CRL に追加された時刻を格納しています。
3.3.16 CRL通知 English
新しい CRL（CRLの集合）を発行する際に、CA は以下のデータ構造体を使って、イベントの通知を行うことができます。
CRLAnnContent ::= SEQUENCE OF CertificateList
3.3.17 PKI確認の内容 English
このデータ構造体は最後の PKIMessage として、3方向（three-way）プロトコルの中で使用されます。すべてのケースにおいて、同じ内容となっています。−実際には、PKIHeader がすべての必要な情報を持っているため、内容は存在しません。
PKIConfirmContent ::= NULL
3.3.18 PKI一般メッセージの内容 English
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL}
-- 例として、InfoTypeAndValue の内容は以下の項目を含み、ただしそれらに限るものではありません。：
-- { CAProtEncCert = {id-it 1}, Certificate }
-- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier }
-- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier }
-- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier }
-- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent }
-- { CurrentCRL = {id-it 6}, CertificateList }
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
--この構成は新しい PKIX 証明書管理プロトコルのリクエスト／レスポンス・メッセージ、または将来のニーズ／特定の環境向けの一般目的（例えば、通知）メッセージの定義にも使用することができます。GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
-- EE、RA または CA からの送信になることはあります（メッセージの内容に依存）。上記のいくつかの例の中で、InfoTypeAndValue のオプションとしての infoValueパラメータが省略されるのは典型的です。受信者は含まれている認識不能な OBJ. IDs を無条件に無視することができます。EE から CA に送付され、集合が空の場合に、CA が送信したい任意の／すべての情報を送ることができることを表します。
3.3.19 PKI一般レスポンスの内容 English
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
-- 受信者が含まれている認識不能な OBJ. IDs を無条件に無視することができます。
3.3.20 エラーメッセージの内容 English
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
-- 実装専用のエラーコード
errorDetails PKIFreeText OPTIONAL
-- 実装専用のエラー詳細}