ネットワーク WG
Request for Comments： 2511
分類：スタンダードトラック

M. Myers
VeriSign
C. Adams
Entrust Technologies
D. Solo
Citicorp
D. Kemp
DoD
1999年3月

インターネットX.509証明書要求メッセージフォーマット
(Internet X.509 Certificate Request Message Format)

このメモの位置づけ

本書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものです。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1)の最新版を参照してください。このメモの配布に制限はありません。

著作権表記

1. 要旨 English

本書は、証明書要求メッセージ形式(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. 概要 English

証明書リクエストの構築は、以下の 2 つの段階を必要とします。：

CertRequest値の生成においては、公開鍵、エンドエンティティ(EE)名もしくはその一部、その他の要求された証明書フィールド、および登録プロセスに関係する追加制御情報がこの値に含まれます。
proof of possession(要求する証明書の公開鍵と対応している秘密鍵をもっている証拠)値はCertRequestの値に基づいて計算できます。
追加登録情報、proof of possession値、およびCertRequest構造の組み合わせでCertReqMessageを構成します。
CertReqMessageは、CAとの間で安全に通信を行います。安全な伝送手段を明確に規定することは、本仕様の規定範囲外です。

3. CertReqMessage構文 English

証明書要求メッセージ(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フィールドは使用されません。

4.1 署名鍵 English

署名鍵を用いることで、エンドエンティティは、ある値に署名をすることで秘密鍵の所有を証明できます。

4.2 鍵暗号鍵 English

鍵暗号鍵を用いることで、エンドエンティティは秘密鍵をCA/RAに(安全に)提供することができます。また秘密鍵の所有を証明するための任意値の復号に使うこともできます。値の復号は直接または間接的におこなわれます。

直接方式とは、エンドエンティティが即時のレスポンスを要求した場合に、 RA/CAが(単に暗号化のためだけの)ランダムなチャレンジを発行する方式です。

間接方式とは、エンドエンティティに対して暗号化された証明書を発行する方式です。 (そしてエンドエンティティに確認メッセージを使って当該証明書を復号できる能力を示します) これによって、CAが意図した対象のエンドエンティティしか使用できない形式の証明書を発行することが可能になります。

4.3 鍵合意鍵 English

鍵合意鍵を用いることで、エンドエンティティは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]、
    -- またはHMAC [RFC2104, RFC2202])
}

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 }となります。

5. CertRequest構文 English

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 }

6．制御構文 English

CertRequestの生成には、リクエストの処理に関係する1つまたは1つ以上の制御値を含めることがあります。

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

下記の制御は定義されています(時間の推移によってこのリストの拡張が認められています)： regToken; authenticator; pkiPublicationInfo; pkiArchiveOptions; oldCertID; protocolEncrKey

6.1 登録トークン制御 English

regToken制御には、証明書発行前に主体者の身元を確認するためCAが使用することを想定している1回限りの情報(秘密値またはナレッジのいずれかに基づいて)を含んでいます。 regTokenのための値を含んだ証明書リクエストを受信した場合、受信CAはその情報を検証し、証明書リクエストに主張されている身元(完全性)を確認します。

RegTokenのための値はCAによって生成され、アウト・オブ・バンド方式で署名者に提供することもできますし、また別の方法でもCAと署名者の両者で利用可能にすることもできます。任意のアウト・オブ・バンド方式交換の安全性は、意図した署名者以外の者から値を傍受されるCAのリスクと同一基準となります。

regToken制御の典型的な使い方は、 PKIにおけるエンドエンティティの初期化だけに利用されることに対して、一方authenticator制御の典型的な使い方は、最初の証明書リクエストおよびその後続に適用することです。

使用例のなかで、regTokenの値は文字列であったり、乱数のような数値であったりします。後者の場合、値はバイナリの数字またはバイナリの数字を表す文字列となります。数量の性質に関係なく値のエンコード化の統一性を保つために、 regTokenのエンコードはUTF8とします。

6.2 Authenticator制御 English

Authenticator制御にはCAと通信する際に、非暗号的な身元確認を確立する現在有効な基本情報を用いた情報を含んでいます。例えば、母親の旧姓、社会保障番号の最後4桁、または署名者CAと共有するその他のナレッジ・ベースの情報、その情報のハッシュ、またはこの目的のためのその他の情報など。 Authenticator制御のための値は署名者またはCAによって生成されます。

6.3 公表情報制御 English

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アドレスを含めることに注意してください)

6.4 記録オプション制御 English

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実装の場合において初期テストとして最初の乱数を送付します) このパラメータの実際の構文はこのドキュメントの後続バージョンもしくは別の標準のなかで規定されることになります。

6.5 OldCert ID制御 English

もしOldCertID制御が存在する場合、現在の証明書リクエストによって更新される証明書を指定します。その値の構文は下記の通りです：

CertId ::= SEQUENCE {
    issuer GeneralName,
    serialNumber INTEGER
}

6.6 プロトコル暗号鍵制御 English

protocolEncrKey制御が存在する場合、 CAがCertReqMessagesに返すレスポンスを暗号化するための鍵を指定します。

この制御はCAが署名者に送付し暗号化する必要のある情報を所持する際に使用できます。このような情報のなかにはCA発行の署名者用の秘密鍵を含んでいます。

The encoding of protocolEncrKey SHALL be SubjectPublicKeyInfo.

7. オブジェクト識別子

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

8. セキュリティについての考慮事項 English

CRMF伝送のセキュリティはCAとの交信に使われたプロトコルとプロセスのセキュリティ機構に依存しています。このようなプロトコルとプロセスは完全性、データ原本信頼性、およびメッセージのプライバシーを保障する必要があります。 CRMFに署名者の秘密情報を含んでおり、かつCAがエンドエンティティ認知の暗号証明書を所有していれば、 CRMFの暗号化は強く推奨されます。

9. 参考文献 English

[HMAC]

Krawczyk, H., Bellare, M. and R. Canetti,
「HMAC：メッセージ認証のための鍵付ハッシング(HMAC:Keyed-Hashing for Message Authentication)」,
RFC 2104, 1997年2月.

10. 謝辞 English

本書の著者よりBarbara Fox氏、Warwick Ford氏、Russ Housley氏、およびJohn Pawling氏の貢献に深く感謝の意を表します。彼らの論評および意見はこの仕様の有用性を著しく明確にし、かつ向上させました。

11. 著者のアドレス

Michael Myers
VeriSign, Inc.
1390 Shorebird Way
Mountain View, CA 94019

EMail： mmyers＠verisign.com

Carlisle Adams
Entrust Technologies
750 Heron Road, Suite E08
Ottawa, Canada, K1V 1A7

EMail： cadams＠entrust.com

Dave Solo
Citicorp
666 Fifth Ave, 3rd Floor
New York, Ny 10103

EMail： david.solo＠citicorp.com

David Kemp
National Security Agency
Suite 6734
9800 Savage Road
Fort Meade, MD 20755

EMail： dpkemp＠missi.ncsc.mil

付録 A.「dhMAC」生成 English

本付録は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 p

2. マッキングプロセスは以下のステップで構成されます。

certReqフィールドの値はDERエンコード化され、バイナリ列が生成されます。これは [HMAC] のなかで参照対象の「テキスト」となり、 HMAC-SHA1の適用対象データです。
共有のDH秘密が以下のように計算されます。
　　shared secret = Kec = g^xy mod p
[エンティティEでは「CApub^y」として、 CAでは「Epub^x」として実行されます。 CApubは、CAのDH証明書から派生され、 Epubは実際の証明書リクエストから派生されます。]
鍵KはCAの証明書にある共有秘密Kec、主体者、および発行者名から派生されます。
　　K = SHA1 (DER-encoded-subjectName | Kec | DER-encoded-issuerName)
「｜」のところは連結を意味します。 CA証明書のsubjectNameが空のSEQUENCEであるならば、 DER-encoded-subjectAltNameを代わりに使うべきです。同様に、issuerNameが空のSEQUENCEなら、 DER-encoded-issuerAltNameに代えるべきです。
[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を適用し、その結果を出力します。
サンプル・コードは [RFC2104, RFC2202] にて参照できます。
d. の結果がBIT STRING (「dhMAC」値)にエンコードされます。

3. proof-of-possessionプロセスにおいて、 CAがステップa. からステップd. までを実行し、そしてステップd. の実行結果を受信した「dhMAC」値と比較します。もし両者が一致すれば、以下の結論が断定できます。

エンティティが証明書申請の中の公開鍵と対応する秘密鍵を所有しています。 (共有した秘密を計算するには秘密鍵を必要とするからです)
意図した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に現れる実際の文字列そのものです。

Nave value
version --	(regInfo使用の差異のバージョン)
corp_company --	(被認証者仲間の連携)
org_unit --	(組織単位)
mail_firstName --	(個人氏名コンポーネント)
mail_middleName --	(個人氏名コンポーネント)
mail_lastName --	(個人氏名コンポーネント)
mail_email --	(被認証者の電子メールアドレス)
jobTitle --	(被認証者の職位)
employeeID --	(従業員識別番号もしくは識別文字列)
mailStop --	(メール停止)
issuerName --	(CA名)
subjectName --	(主体者名)
validity --	(有効期間)

例：

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

付録 C. ASN.1構造とOID English

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

著作権表記全文

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.

インターネットX.509証明書要求メッセージフォーマット (Internet X.509 Certificate Request Message Format)

このメモの位置づけ

著作権表記

1. 要旨 English

2. 概要 English

3. CertReqMessage構文 English

4. Proof of Possession (POP) English

4.1 署名鍵 English

4.2 鍵暗号鍵 English

4.3 鍵合意鍵 English

4.4 Proof of Possession構文 English

4.4.1 パスワード・ベースMACの使用 English

5. CertRequest構文 English

6．制御構文 English

6.1 登録トークン制御 English

6.2 Authenticator制御 English

6.3 公表情報制御 English

6.4 記録オプション制御 English

6.5 OldCert ID制御 English

6.6 プロトコル暗号鍵制御 English

7. オブジェクト識別子

8. セキュリティについての考慮事項 English

9. 参考文献 English

10. 謝辞 English

11. 著者のアドレス

付録 A.「dhMAC」生成 English

参考文献

謝辞

付録 B. Name-ValueペアのためのRegInfoの使用 English

B.1. Name/Value ペアの実例 English

B.1.1. IssuerName、SubjectNameとValidityの値エンコーディング English

参考資料

付録 C. ASN.1構造とOID English

著作権表記全文

インターネットX.509証明書要求メッセージフォーマット
(Internet X.509 Certificate Request Message Format)