| ネットワーク WG Request for Comments： 2511 分類： スタンダードトラック |
M. Myers |
インターネットX.509証明書要求メッセージフォーマット
( Internet X.509 Certificate Request Message Format )
このメモの位置づけ
本書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものです。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」 (STD 1) の最新版を参照してください。このメモの配布に制限はありません。
著作権表記
Copyright (C) The Internet Society (1999). All Rights Reserved.
本書は、証明書要求メッセージ形式 （Certificate Request Message Format, CRMF) について規定します。この構文は X.509 証明書発行を目的に、認証局 （Certification Authority, CA) （登録局 （Registration Authority, RA) を経由することもあります）に証明書の申請 （request） を伝える役割を持っています。典型的に公開鍵と関連登録情報がリクエストに含まれています。
本書中のキーワード、"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は、RFC 2119 に記述されているように解釈されるべきものです。
証明書リクエストの構築は、以下の 2 つの段階を必要とします。：
a) CertRequest 値の生成においては、公開鍵、エンドエンティティ (EE) 名もしくはその一部、その他の要求された証明書フィールド、および登録プロセスに関係する追加制御情報がこの値に含まれます。
b) proof of possession （要求する証明書の公開鍵と対応している秘密鍵をもっている証拠）値は CertRequest の値に基づいて計算できます。
c) 追加登録情報、proof of possession 値、および CertRequest 構造の組み合わせで CertReqMessage を構成します。
d) CertReqMessage は、CAとの間で安全に通信を行います。安全な伝送手段を明確に規定することは、本仕様の規定範囲外です。
証明書要求メッセージ （certificate request message） は、証明書リクエスト、オプションの proof of possession フィールド、およびオプションの登録情報フィールドによって構成されます。
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop ProofOfPossession OPTIONAL,
-- 内容 （content） は鍵タイプに依存します。regInfo SEQUENCE SIZE (1..MAX) of AttributeTypeAndValue OPTIONAL }
proof of possession フィールドは、証明書と結び付いているエンティティが対応する秘密鍵を確実に所有していることを証明するために使われます。このフィールドは certReq フィールドの内容を意図し、公開鍵アルゴリズムの種別と運用方式 （operational mode） の違いによって構造的かつ内容的に異なります。
regInfo フィールドには証明書リクエストの要件を満たすために必要な証明書申請の状況に関連する補足情報のみを格納することとします。この情報には加入者 （subscriber） 連絡先情報、料金請求情報、または、ほかの証明書申請を実現するために役に立つ補助的な情報を含むことがあります。
証明書内容 （content） に直接に関係している情報は certReq content のなかに格納されることとします。しかしながら、RA による付加的な certReq content の包含は、一般的なフィールドを無効化してしまうことがあります。したがって、証明書内容を意図されたデータは regInfo に格納することができます。
regInfo 内容の実例は 第 8 章 と 付録 B をご参照ください。
4. Proof of Possession (POP) English
特定の攻撃から守り、エンドエンティティと鍵ペア間との連結の有効性について CA/RA が適切に検証できるようにするためには、ここでいう PKI 管理業務が、あるエンドエンティティが申請する証明書用の公開鍵と対応している秘密鍵を所持すること（すなわち、使用できること）を証明することを可能にしました。一定の CA/RA は証明書交換のなかでいかに POP （例えば、アウト・オブ・バウンド手続き型方法 対 CRMF イン・バウンドメッセージ）を実施するのかを自由に選択できます（つまり、これは1つのポリシー問題です）。しかし、現在使用されている多くの non-PKIX 運用プロトコル（様々な電子メールプロトコルはその一例です。）はエンドエンティティと秘密鍵間の連結を明示的に検証しないため、CA/RA は何らかの手段で POP を強制的に実施することとなっています。確実に結合性（署名、暗号化、および鍵合意の鍵ペアに関して）を検証する運用プロトコルが存在し、かつ遍在した状態になるまで、この結合は単純に CA/RA によって検証されたことしか想定できません。したがって、もしこの結合が CA/RA によって検証されていなければ、インターネット公開鍵インフラストラクチャにおける証明書の存在意義は結局それほど意味がありません。
申請される証明書用の鍵のタイプによって、POP は異なる方法で実現されます。複数目的対応の鍵（例えば、RSA 鍵）の場合は、任意の手段を使用することができます。
この仕様は POP が CA、RA、もしくはその両者によって有効性検証されることを考慮にいれています。ポリシーによっては、CA による認証の過程のなかで POP の検証実施を要求されることもあります。その際、RA はエンドエンティティの CertRequest と ProofOfPossession フィールドを何も変更を加えずに CA に先渡しをしなければなりませんが、オプションとして RA 自身が POP を検証することも可能です。もしポリシーが CA に POP 検証を要求していなければ、RA はエンドエンティティのリクエストおよび検証証拠に変更を加えずに上記と同様に CA に渡すこととします。これが不可能の場合（例えば、RA はアウト・オブ・バウンド方式で POP 検証する）、RA は CA に対して要求の証拠が既に検証済みであることを証明することができます。もし CA がアウト・オブ・バウンド方式で（例えば、CA が生成した秘密鍵を物理的に送付する方法） POP 検証を行うならば、ProofOfPossession フィールドは使用されません。
署名鍵を用いることで、エンドエンティティは、ある値に署名をすることで秘密鍵の所有を証明できます。
鍵暗号鍵を用いることで、エンドエンティティは秘密鍵を CA/RA に（安全に）提供することができます。また秘密鍵の所有を証明するための任意値の復号に使うこともできます。値の復号は直接または間接的におこなわれます。
直接方式とは、エンドエンティティが即時のレスポンスを要求した場合に、RA/CA が（単に暗号化のためだけの）ランダムなチャレンジを発行する方式です。
間接方式とは、エンドエンティティに対して暗号化された証明書を発行する方式です。（そしてエンドエンティティに確認メッセージを使って当該証明書を復号できる能力を示します）これによって、CA が意図した対象のエンドエンティティしか使用できない形式の証明書を発行することが可能になります。
鍵合意鍵を用いることで、エンドエンティティは 5.2 節で述べられた 3つの方法のいずれかで暗号鍵として使うことができます。直接方式と間接方式では、エンドエンティティと PKI 管理エンティティ（つまり、CA または RA）はエンドエンティティが秘密鍵（すなわち、暗号化された証明書の復号または発行済チャレンジへのレスポンスを構築するための）を所有することを立証するために1つの共有鍵を確立しなければなりません。これは鍵に対して必ず与えられた CA の認証を受けるという制約を課することを意味するものではないことに注意してください。とりわけ、Diffie-Hellman 鍵ではエンドエンティティが自由にそのアルゴリズムを選択できます。仮に CA は必要に応じて適切なパラメータをもった短期（もしくは一回限り）の鍵ペアを生成できます。
POP を証明するための 4番目の代替策として、エンドエンティティは証明書リクエストの MAC を取得する方法があります。（Diffie-Hellman 計算結果から得る共有秘密鍵を使用して）このオプションは CA が既にエンドエンティティを認知できる DH 証明書を持ち、そして EE （エンドエンティティ）が進んで CA の DH パラメータを使用することを前提にしています。
4.4 Proof of Possession 構文 English
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
-- RA が既にリクエスタが秘密鍵を所有することを確められた場合に使用。signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
--署名（「algorithmIdentifier」を使って）は poposkInput の DER エンコード化された値に付与されました。
-- 注意：CertReqMsg certReq CertTemplate が主体者と publicKey 値を含んでいれば、poposkInput は省略しなければなりません。署名も CertReqMsg certReq の DER エンコード化された値で計算しなければなりません。逆に CertReqMsg certReq CertTemplate が公開鍵と主体者値を含んでいない場合は、poposkInpu は必ず存在し、かつ署名されていなければなりません。この方策は、公開鍵が同時に poposkInput フィールドと CertReqMsg certReq CertTemplate フィールドに存在しないことを保証しました。
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,
-- アルゴリズム値は PasswordBasedMac { 1 2 840 113533 7 66 13 } です。
-- パラメータ値は PBMParameter です。value BIT STRING }
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- このメッセージ（自身の秘密鍵を含んでいる （CA のために暗号化されている））で所有が証明されました。
subsequentMessage [1] SubsequentMessage,
-- 後続のメッセージで所有を証明されることになります。dhMAC [2] BIT STRING }
-- keyAgreement （のみ）にとって、所有することはこのメッセージ（その中にエンドエンティティの秘密 DH 鍵と CA の公開 DH 鍵から生成された鍵をもとにした MAC （CertReqMsg の certReq パラメータの DER エンコード値を対象に、それには subject と publicKey が必ず含まれる）を格納しています。）で証明されています。
-- dhMAC 値は必ず付録 A で規定された指示に従い算出しなければなりません。SubsequentMessage ::= INTEGER {
encrCert (0),
-- エンドエンティティのために証明書の暗号化結果を要求します。
-- （その後、確認メッセージによって POP が証明されることになります。）challengeResp (1) }
-- 秘密鍵の所有を証明するために CA/RA がエンドエンティティとの間にチャレンジ―応答方式の交換に従事することを要求します。この仕様を組み入れる完全なプロトコルには、必要となる確認メッセージおよびチャレンジ―応答方式メッセージを包含することが期待されます。
4.4.1 パスワード・ベース MAC の使用 English
リクエストの信頼性を証明するため、publicKeyMAC が POPOSigningKeyInput の中で使われた場合、以下のアルゴリズムを使用することになります。
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- 一方向機能ための AlgId （SHA-1 推奨）iterationCount INTEGER,
-- OWF の回数が適用されますmac AlgorithmIdentifier
-- MAC AlgId （例えば、DES-MAC、Triple-DES-MAC [PKCS11]、PBMParameter を用いて publicKeyMAC を計算し、そして公開鍵証明書リクエストの原本性を検証するプロセスは 2つのステージで構成されます。第1ステージは共有秘密情報にて MAC 鍵を生成します。第 2ステージは、MAC 鍵で当該公開鍵を MAC し、証明済みの値を生成します。
アルゴリズムの第1ステージの初期化において、CA/RA とエンドエンティティ間に信頼性のある方式によって配布されている共有秘密が存在することを仮定しています。ソルト値 （salt value） が共有秘密に追加され、一方向機能 （owf） が iterationCount 回数適用されます。ソルトされた秘密は繰り返し（交わされる値）の一回目の入力（値）となり、前回の繰り返し（値）の出力は後続の繰り返し（値）の入力に設定され、鍵Kを生成します。
第2ステージでは、K と公開鍵は [HMAC] で定義された HMAC の入力（値）となり、以下の publicKeyMAC の値を生成します。
publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )
ipad と opad については [RFC2104] で規定されています。owf の AlgorithmIdentifier は SHA-1 { 1 3 14 3 2 26 } のこととなり、mac の AlgorithmIdentifier は HMAC-SHA1 { 1 3 6 1 5 5 8 1 2 } となります。
CertRequest 構文はリクエスト識別子、証明書内容の雛形、およびオプションとしての制御情報シーケンスで構成されます。
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- リクエストとリプライを一致させる ID
certTemplate CertTemplate, -- 発行対象 cert の選択フィールド
controls Controls OPTIONAL } -- 発行に影響を与える属性
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 } -- 最低1つが存在しますTime ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
CertRequest の生成には、リクエストの処理に関係する1つまたは1つ以上の制御値を含めることがあります。
Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue
下記の制御は定義されています（時間の推移によってこのリストの拡張が認められています）： regToken; authenticator; pkiPublicationInfo; pkiArchiveOptions; oldCertID; protocolEncrKey
regToken 制御には、証明書発行前に主体者の身元を確認するため CA が使用することを想定している一回限りの情報（秘密値またはナレッジのいずれかに基づいて）を含んでいます。regToken のための値を含んだ証明書リクエストを受信した場合、受信 CA はその情報を検証し、証明書リクエストに主張されている身元（完全性）を確認します。
RegToken のための値は CA によって生成され、アウト・オブ・バンド方式で署名者に提供することもできますし、また別の方法でも CA と署名者の両者で利用可能にすることもできます。任意のアウト・オブ・バンド方式交換の安全性は、意図した署名者以外の者から値を傍受される CA のリスクと同一基準となります。
regToken 制御の典型的な使い方は、PKI におけるエンドエンティティの初期化だけに利用されることに対して、一方 authenticator 制御の典型的な使い方は、最初の証明書リクエストおよびその後続に適用することです。
使用例のなかで、regToken の値は文字列であったり、乱数のような数値であったりします。後者の場合、値はバイナリの数字またはバイナリの数字を表す文字列となります。数量の性質に関係なく値のエンコード化の統一性を保つために、regToken のエンコードは UTF8 とします。
Authenticator 制御には CA と通信する際に、非暗号的な身元確認を確立する現在有効な基本情報を用いた情報を含んでいます。例えば、母親の旧姓、社会保障番号の最後 4桁、または署名者 CA と共有するその他のナレッジ・ベースの情報、その情報のハッシュ、またはこの目的のためのその他の情報など。Authenticator 制御のための値は署名者または CA によって生成されます。
使用例のなかで、regToken の値は文字列であったり、乱数のような数値であったりします。後者の場合、値はバイナリの数字またはバイナリの数字を表す文字列となります。数量の性質に関係なく値のエンコード化の統一性を保つために、regToken のエンコードは UTF8 とします。
pkiPublicationInfo 制御は被認証者による CA 証明書の公開を制御することを可能とします。以下の通りに定義されます。
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
-- もしアクションが 「dontPublish」 ならば、pubInfos は存在してはいけません。
-- （アクションが 「pleasePublish」 であり、pubInfos が省略されている場合は、「dontCare」 と仮定します。）SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },pubLocation GeneralName OPTIONAL }
オプションの dontPublish が選択された場合、そのリクエスタが証明書を公開するべきでない PKI であると示しています。（これはリクエスタ自身が証明書を公表するつもりであることを表します。）
dontCare メソッドが選択された場合、もしくは PKIPublicationInfo 制御がリクエストから省略された場合、リクエスタは PKI が選択した任意の証明書を公表することができます。
もしリクエスタが少なくとも、いくつかの場所で証明書の出現を望みながら、または CA にほかのディレクトリで提供可能にすることを考えているなら、pubInfos に SinglePubInfo の2つの値を設定してください：x500、web または ldap による一つの値；もう 1つは dontCare です。
pubLocation フィールドが存在する場合は、リクエスタがどこで証明書が見つかることを望んでいるのかを表します。（GeneralName の選択肢は URL と IP アドレスを含めることに注意してください）
pkiArchiveOptions 制御は、被認証者に証明書リクエストの公開鍵に対応する秘密鍵のアーカイブを構築する際に必要な情報を提供することを可能にします。これは以下の構文で定義されます。
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- 公開鍵の実の値keyGenParameters [1] KeyGenParameters,
-- 秘密鍵の再生成を許可するパラメータarchiveRemGenPrivKey [2] BOOLEAN }
--リクエストに応じて受信者が生成した鍵ペアの秘密鍵を送信者がアーカイブすることを望んでいれば、真に設定します。
-- アーカイブの希望がなければ、偽に設定します。
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue,
envelopedData [0] EnvelopedData }
-- 暗号化された秘密鍵は envelopedData encryptedContentInfo encryptedContent OCTET STRING の中に格納しなければなりません。
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- 当該値が適用対象のアルゴリズムsymmAlg [1] AlgorithmIdentifier OPTIONAL,
-- 当該値を暗号化するための対称型アルゴリズムencSymmKey [2] BIT STRING OPTIONAL,
-- 当該値を暗号化するための（暗号化済み）対称型鍵keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- 対称型鍵を暗号化するためのアルゴリズムvalueHint [4] OCTET STRING OPTIONAL,
-- encValue 内容の簡潔な説明もしくは識別子
-- （送信側エンティティにとってしか意味をなさない可能性があり、将来的に送信側エンティティによって EncryptedValue が再検証されるかもしれない場合に限り使用されます）encValue BIT STRING }
KeyGenParameters ::= OCTET STRING
鍵送付の代替策として、KeyGenParameters 選択肢を使用した鍵再生成に関する情報の送信があります。（例えば、多くの RSA 実装の場合において初期テストとして最初の乱数を送付します）このパラメータの実際の構文はこのドキュメントの後続バージョンもしくは別の標準のなかで規定されることになります。
もし OldCertID 制御が存在する場合、現在の証明書リクエストによって更新される証明書を指定します。その値の構文は下記の通りです：
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER}
protocolEncrKey 制御が存在する場合、CA が CertReqMessages に返すレスポンスを暗号化するための鍵を指定します。
この制御は CA が署名者に送付し暗号化する必要のある情報を所持する際に使用できます。このような情報のなかには CA 発行の署名者用の秘密鍵を含んでいます。
The encoding of protocolEncrKey SHALL be SubjectPublicKeyInfo.
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) }
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl (1) }
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
-- Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo (2) }
id-regInfo-asciiPairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
--with syntax OCTET STRING
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
--with syntax CertRequest
CRMF 伝送のセキュリティは CA との交信に使われたプロトコルとプロセスのセキュリティ機構に依存しています。このようなプロトコルとプロセスは完全性、データ原本信頼性、およびメッセージのプライバシーを保障する必要があります。CRMF に署名者の秘密情報を含んでおり、かつ CA がエンドエンティティ認知の暗号証明書を所有していれば、CRMF の暗号化は強く推奨されます。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti,
「HMAC： メッセージ認証のための鍵付ハッシング(HMAC: Keyed- Hashing for Message Authentication)」,
RFC 2104, 1997年 2月.
本書の著者より Barbara Fox 氏、Warwick Ford 氏、Russ Housley 氏、および John Pawling 氏の貢献に深く感謝の意を表します。彼らの論評および意見はこの仕様の有用性を著しく明確にし、かつ向上させました。
Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA 94019EMail： mmyers＠verisign.com
Carlisle Adams
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Canada, K1V 1A7EMail： cadams＠entrust.com
Dave Solo
Citicorp
666 Fifth Ave, 3rd Floor
New York, Ny 10103EMail： david.solo＠citicorp.com
David Kemp
National Security Agency
Suite 6734
9800 Savage Road
Fort Meade, MD 20755EMail： dpkemp＠missi.ncsc.mil
本付録は Diffie-Hellman 証明書リクエストに向けた proof-of-possession の POPOPrivKey 構造にある 「dhMAC」 のビット列の計算法について説明します。
1．エンティティ生成する DH 公開/秘密鍵のペア
公開鍵を計算する DH パラメータは CA の DH 証明書で指定されたものとします。
CA の DH 証明書による：
CApub = g^x mod p (where g and p are the established DH parameters and x is the CA's private DH component) entity E 用：
DH private value = y
Epub = DH public value = g^y mod p2. マッキングプロセスは以下のステップで構成されます。
a) certReq フィールドの値は DER エンコード化され、バイナリ列が生成されます。これは [HMAC] のなかで参照対象の「テキスト」となり、HMAC-SHA1 の適用対象データです。
b) 共有の DH 秘密が以下のように計算されます。
shared secret = Kec = g^xy mod p
[エンティティE では 「CApub^y」 として、CA では 「Epub^x」 として実行されます。 CApub は、CA の DH 証明書から派生され、Epub は実際の証明書リクエストから派生されます。]
c) 鍵K は CA の証明書にある共有秘密 Kec、主体者、および発行者名から派生されます。
K = SHA1 (DER-encoded-subjectName | Kec | DER-encoded-issuerName)
「｜」 のところは連結を意味します。CA 証明書の subjectName が空の SEQUENCE であるならば、DER-encoded-subjectAltName を代わりに使うべきです。同様に、issuerName が空の SEQUENCE なら、DER-encoded-issuerAltName に代えるべきです。
d) [RFC2104] により、以下のようにデータ「テキスト」に対して HMAC-SHA1 計算します。
SHA1 (K XOR opad, SHA1(K XOR ipad, text) )
where,
opad (outer pad) = the byte 0x36 repeated 64 times
and
ipad (inner pad) = the byte 0x5C repeated 64 times.
Namely,
(1) 64 バイトの列になるように、K の背後に 0 を付加します。（例えば、K が 16 バイト長であれば、その後ろに 48 バイト分の 0x00 を追加します）
(2) ipad でステップ (1) で算出された 64 バイト列に XOR （排他的論理和）を求めます。
(3) ステップ (2) の結果の 64 バイト列にデータストリームの「テキスト」を付け加えます
(4) ステップ (3) で生成されたストリームに SHA1 を適用します
(5) opad でステップ (1) での算出結果 64 バイト列の XOR （排他的論理和）を求めます
(6) ステップ (4) の SHA1 結果をステップ (5) の結果 64 バイト列に追加します。
(7) ステップ (6) で生成されたストリームに SHA1 を適用し、その結果を出力します。
e) (d) の結果が BIT STRING （「dhMAC」 値） にエンコードされます。
3. proof-of-possession プロセスにおいて、CA がステップ （a） からステップ （d） までを実行し、そしてステップ （d） の実行結果を受信した 「dhMAC」 値と比較します。もし両者が一致すれば、以下の結論が断定できます。
1) エンティティが証明書申請の中の公開鍵と対応する秘密鍵を所有しています。（共有した秘密を計算するには秘密鍵を必要とするからです）
2) 意図した CA のみがこのリクエストを検証することができます。（CA が同じ共有秘密を計算するには自分の秘密鍵を必要とするからです。）これによって、悪意の CA から保護することができます。
参考文献
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti,
"HMAC: Keyed Hashing for Message Authentication", RFC 2104, 1997年 2月.
[RFC2202] Cheng, P. and R. Glenn,
"Test Cases for HMAC-MD5 and HMAC- SHA-1", RFC 2202, 1997年 9月.
謝辞
本付録の詳細は Hemma Prafullchandra 氏が提供されたものです。
付録 B. Name-Value ペアのための RegInfo の使用 English
id-regInfo-utf 8 Pairs OCTET STRING （値が 12 である 「tag」 フィールドと適切な 「length」 フィールド）にある 「value」 フィールドには一連の UTF8 の name/value ペアが存在します。
本付録はこの仕様に依存しない実装との相互運用性を促進するために、このようなペアの共通例のいくつかを一覧にしています。この一覧は網羅的なものではなく、時間の推移および実装経験から発展することが考えられています。
B.1. Name/Value ペアの実例 English
regInfo が 1 つまたは 1 つ以上の name-value ペアを （id-regInfo-utf8Pairs 経由で）伝送する際に、一番最初のペアとその後続のペアは以下のように構成されます：
[name?value] [%name?value]*%
この列は次に OCTET STRING にエンコード化され、regInfo SEQUENCE のなかに格納されます。
予約語としての目的で使われる場合を除いて、予約語は [RFC1738] の 「%xx」 機構でエンコード化されます。
次の表は一組の推奨される指定エレメントについて定義します。「Name Value」 列にある値は regInfo に現れる実際の文字列そのものです。
Name Value
version -- （regInfo使用の差異のバージョン）
corp_company -- （被認証者仲間の連携）
org_unit -- （組織単位）
mail_firstName -- （個人氏名コンポーネント）
mail_middleName -- （個人氏名コンポーネント）
mail_lastName -- （個人氏名コンポーネント）
mail_email -- （被認証者の電子メールアドレス）
jobTitle -- j （被認証者の職位）
employeeID -- （従業員識別番号もしくは識別文字列）
mailStop -- （メール停止）
issuerName -- （CA名）
subjectName -- （主体者名）
validity -- validity interval （有効期間）
例：
version?1%corp_company?Acme, Inc.%org_unit?Engineering%
mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader%
mail_email?john@acme.com%
B.1.1. IssuerName、SubjectName と Validity の値エンコーディング English
IssuerName、SubjectName と Validity が指定エレメントとして id-regInfo-utf8Pairs 構文に現れたときに、それらの値のエンコーディングは以下の構文を使用することになります。「[]」 という符号はオプションフィールドであることを示し、「::=」 と 「｜」 は通常の BNF 意味に準拠し、非終端名称を除いたその他全ての符号（意味のないスペースを除外）は終端です。
issuerName ::= <names>
subjectName ::= <names>
<names> ::= <name> | <names>:<name>
<validity> ::= validity ? [<notbefore>]-[<notafter>]
<notbefore> ::= <time>
<notafter> ::= <time>UTC 時間の <time> は YYYYMMDD [HH[MM[SS]]] の形式をとっています。HH、MM、およびSS はデフォルト的に 00 値に設定され、そして 00 値の後ろにある場合は省略されます。
Validity エンコーディングの実例：
validity?-19991231%
には notBefore の値がなく、notAfter の値が1999年12月31日に設定された有効期間を表しています。
各々の名前は一文字の名前形式識別子と、後ろに一文字または UTF8 文字の名前の値 （name value） から構成されます。名前の値の中で、既に範囲外のレベルで重要性を形成していた 1 つの文字の曖昧さをなくす必要があるときに、エスケープ・シーケンス %xx が使用されることになります。xx は関係対象の 16 進数の値を表します。パーセンテージの符号は 「%%」 で表します。
<name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname>
名前の表現形式と値の型については、以下の通りです：
X.500 directory name form (identifier "X"):
<xname> ::= <rdns>
<rdns> ::= <rdn> | <rdns> , <rdn>
<rdn> ::= <avas>
<avas> ::= <ava> | <avas> + <ava>
<ava> ::= <attyp> = <avalue>
<attyp> ::= OID.<oid> | <stdat>標準属性タイプ <stdat> は下記のアルファベット属性タイプ識別子です：
C ( country )
L ( locality )
ST ( state or province )
O ( organization )
OU ( organizational unit )
CN ( common name )
STREET ( street address )
E ( E-mail address ).<avalue> は 1〜64 文字の UTF8 文字列の形式をとった名前のコンポーネントです。UTF8 の IA5 集合のなかで ASN.1 PrintableString の文字しか使用できないと制限されています。
そのほかの名前形式（識別子「0」）：
<oname> ::= <oid> , <utf8string>
電子メールアドレス （rfc822name） 名前形式（識別子 「E」）：
<ename> ::= <ia5string>
DNS名前形式（識別子 「D」）：
<dname> ::= <ia5string>
URI名前形式（識別子 「U」）：
<uname> ::= <ia5string>
IPアドレス（識別子 「I」）：
<iname> ::= <oid>
例：
issuerName?XOU=Our CA,O=Acme,C=US%
subjectName?XCN=John Smith, O=Acme, C=US, E=john@acme.com%
参考資料
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, 1994年12月.
PKIXCRMF { iso (1) identified-organization (3) dod (6) internet (1) security (5) mechanisms (5) pkix (7) id-mod (0) id-mod-crmf (5) }
CRMF DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- ディレクトリ認証フレームワーク （X.509 ）Version, AlgorithmIdentifier, Name, Time,
SubjectPublicKeyInfo, Extensions, UniqueIdentifier
FROM PKIX1Explicit88 { iso (1) identified-organization (3) dod (6)
internet (1) security (5) mechanisms (5) pkix (7) id-mod (0)
id-pkix1-explicit-88 (1) }
-- 証明書拡張 （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-88 (2) }
-- 暗号メッセージ構文EnvelopedData
FROM CryptographicMessageSyntax { iso (1) member-body (2)
us (840) rsadsi (113549) pkcs (1) pkcs-9 (9) smime (16)
modules (0) cms (1) };
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop ProofOfPossession OPTIONAL,
-- 内容は鍵タイプに依存しています。
regInfo SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
（要求と応答を一致させるためのID）
certTemplate CertTemplate, -- Selected fields of cert to be issued
（発行対象certの選択フィールド）
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
（最低限 1 つが存在しなければなりません）
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type OBJECT IDENTIFIER,
value ANY DEFINED BY type }
ProofOfPossession ::= CHOICE {
raVerified [0] NULL, -- RAが既にリクエスタが秘密鍵を所有する事を立証した場合に使用されます。
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
-- この署名 （「algorithmIdentifier」 使用）の対象は poposkInput の DER エンコードされた値です。
-- 注意事項：
-- CertReqMsg certReq CertTemplate が subject と publicKey の値を含んでいれば、poposkInput は省略されなければなりません。また署名も CertReqMsg certReq の DER エンコード化された値をもとに計算しなければなりません。
-- もし CertReqMsg certReq CertTemplate に公開鍵と主体者の値が含まれていなけれ
ば、poposkInput は必ず存在し、かつ署名されなければなりません。
-- この方策は公開鍵が同時に poposkInput と CertReqMsg certReq CertTemplate の 2 つのフィールドに現れないことを保証します。
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- 送信者に対する証明済みの身元を確立した場合のみ使用されます。（例えば、以前発行され、現在有効な証明書の DN ）publicKeyMAC PKMACValue },
-- 認証済みの送信者の GeneralName が現在存在しない場合にのみ使用されます； publicKeyMAC には publicKey の DER エンコード化された値に対するパスワード・ベースの MAC が含まれています。
publicKey SubjectPublicKeyInfo } -- from CertTemplate
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
-- アルゴリズムの値は PasswordBasedMac { 1 2 840 113533 7 66 13 } です。 パラメータの値は PBMParameter です。value BIT STRING }
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier, -- 一方向機能のAlgId （SHA-1 推奨）
iterationCount INTEGER, -- OWF の適用回数
mac AlgorithmIdentifier -- MAC AlgId （例えば、DES-MAC、 Triple-DES-MAC [PKCS11]、または HMAC [RFC2104, RFC2202]) }
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING,
-- このメッセージ（その中に自分の秘密鍵 （CAのために暗号化されている）を持っている）において所有することが証明されています。subsequentMessage [1] SubsequentMessage,
-- その所有は後続のメッセージで証明されることになります。dhMAC [2] BIT STRING }
-- keyAgreement （のみ）にとって、所有することはこのメッセージ（その中にエンドエンティティの秘密 DH 鍵と CA の公開 DH 鍵から生成された鍵をもとにした MAC （CertReqMsg の certReq パラメータの DER エンコード値を対象に、それには subject と publicKey が必ず含まれる）を格納しています。）で証明されています。
-- dhMAC 値は必ず付録 A で規定された指示に従い算出しなければなりません。
SubsequentMessage ::= INTEGER {
encrCert (0),
-- エンドエンティティのために証明書の暗号化結果を要求します。
-- （その後、確認メッセージによって POP が証明されることになります）
challengeResp (1) }
-- 秘密鍵の所有を証明するために CA がエンドエンティティとの間でチャレンジ―応答方式の交換に従事することを要求します。
-- オブジェクト識別子の割り当て
id-pkix OBJECT IDENTIFIER ::= { iso (1) identified-organization (3)
dod (6) internet (1) security (5) mechanisms (5) 7 }
-- インターネット X.509 プロトコルおよびそのコンポーネントのための arc
id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
-- CRMF における登録制御
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
-- 下記の定義は、UTF8String を理解できない ASN.1 コンパイラを使用するために
コメント されないかもしれません。
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
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
-- アクションが 「dontPublish」 のときに、pubInfos は存在してはいけません。（アクションが「pleasePublish」 であり、かつ pubInfos が省略された時に 「dontCare」 が想定されます）
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,
-- 公開鍵の実の値
keyGenParameters [1] KeyGenParameters,
-- 秘密鍵の再生成を許可するパラメータ
archiveRemGenPrivKey [2] BOOLEAN }
--リクエストに応じて受信者が生成した鍵ペアの秘密鍵を送信者がアーカイブすることを望んでいれば、真に設定します
-- アーカイブの希望がなければ、偽に設定します。
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue,
envelopedData [0] EnvelopedData }
-- 暗号化された秘密鍵は envelopedData encryptedContentInfo encryptedContent OCTET STRING の中に格納しなければなりません。
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- 当該値が適用対象のアルゴリズム
symmAlg [1] AlgorithmIdentifier OPTIONAL,
-- 当該値を暗号化するための対称型アルゴリズム
encSymmKey [2] BIT STRING OPTIONAL,
-- 当該値を暗号化するための（暗号化済み）対称型鍵
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- 対称型鍵を暗号化するためのアルゴリズム
valueHint [4] OCTET STRING OPTIONAL,
-- encValue 内容の簡潔な説明もしくは識別子
-- （送信側エンティティにとってしか意味をなさない可能性があり、将来的に送信側エンティティによって EncryptedValue が再検証されるかもしれない場合に限り使用されます）
encValue BIT STRING }
-- 暗号化された値そのもの
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
-- 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
END
著作権表記全文
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.