メインコンテンツまでスキップ

3.7 Computing the Message Hashes (メッセージハッシュの計算)

3.7. Computing the Message Hashes (メッセージハッシュの計算)​

署名と検証の両方は、メッセージに対する2つの暗号ハッシュの計算から始まります。Signerは"Signer Actions"(Section 5)で説明されている署名パラメータを選択し、Verifierは検証中のDKIM-Signatureヘッダーフィールドで指定されたパラメータを使用します。以下の説明では、存在する(検証時)または作成される(署名時)DKIM-Signatureヘッダーフィールド内のタグ名が使用されます。正規化(Section 3.4)は署名または検証用の電子メールを準備するためにのみ使用され、送信される電子メールには影響しないことに注意してください。

Signer/Verifierは2つのハッシュを計算する必要があります:メッセージ本文に対する1つと、メッセージの選択されたヘッダーフィールドに対する1つ。

Signerは示された順序で計算する必要があります。Verifierは、結果がこの順序で計算された場合のセマンティクスと意味的に同一である限り、Verifierに都合の良い任意の順序で計算できます。

ハッシュステップ1では、Signer/Verifierは"c="タグで指定された本文正規化アルゴリズムを使用して正規化され、"l="タグで指定された長さに切り詰められたメッセージ本文をハッシュする必要があります。そのハッシュ値はbase64形式に変換され、DKIM-Signatureヘッダーフィールドの"bh="タグに挿入(Signer)または比較(Verifier)されます。

ハッシュステップ2では、Signer/Verifierは示された順序で以下をハッシュアルゴリズムに渡す必要があります。

  1. "h="タグで指定されたヘッダーフィールドを、そのタグで指定された順序で、"c="タグで指定されたヘッダー正規化アルゴリズムを使用して正規化します。各ヘッダーフィールドは単一のCRLFで終了する必要があります。

  2. メッセージに存在する(検証)または挿入される(署名)DKIM-Signatureヘッダーフィールド。"b="タグの値(周囲のすべての空白を含む)は削除(つまり、空文字列として扱われ)、"c="タグで指定されたヘッダー正規化アルゴリズムを使用して正規化され、末尾のCRLFはありません。

DKIM-Signatureヘッダーフィールド内のすべてのタグとその値は、暗号ハッシュに含まれます。唯一の例外は"b="(署名)タグの値部分で、これはnull文字列として扱う必要があります。Verifierが理解できない可能性がある場合でも、すべてのタグを含める必要があります。ヘッダーフィールドは、残りのヘッダーフィールドではなくメッセージ本文の後にハッシュアルゴリズムに提示する必要があり、"c="(正規化)タグで指定されたように正規化する必要があります。DKIM-Signatureヘッダーフィールドは独自の"h="タグに含めてはなりませんが、他のDKIM-Signatureヘッダーフィールドに署名できます(Section 4を参照)。

base64またはquoted-printableエンコーディングを使用して送信されるメッセージのハッシュを計算する場合、Signerはエンコード後にハッシュを計算する必要があります。同様に、Verifierはbase64またはquoted-printableテキストをデコードする前に値をハッシュに組み込む必要があります。ただし、ハッシュは、SMTPの"dot-stuffing"(SMTPメッセージ終了マーカーとの混同を避けるために"."で始まる行を変更すること、[RFC5321]で指定)などのトランスポートレベルエンコーディングの前に計算する必要があります。

Section 3.4で説明されている正規化手順を除いて、DKIM署名プロセスはメッセージの本文を単なるオクテット文字列として扱います。DKIMメッセージはプレーンテキストまたはMIME形式のいずれかです; MIMEコンテンツに特別な処理は提供されません。MIME形式のメッセージ添付ファイルは署名されたコンテンツに含める必要があります。

より正式には、署名アルゴリズムの疑似コードは次のとおりです:

body-hash    =  hash-alg (canon-body, l-param)
data-hash    =  hash-alg (h-headers, D-SIG, body-hash)
signature    =  sig-alg (d-domain, selector, data-hash)

ここで:

  • body-hash: hash-algを使用して本文をハッシュした出力。
  • hash-alg: "a"パラメータで指定されたハッシュアルゴリズム。
  • canon-body: "c"パラメータで指定された本文アルゴリズムを使用して生成された本文の正規化表現で、Section 3.4で定義され、DKIM-Signatureフィールドを除外します。
  • l-param: "l"パラメータの本文長の値。
  • data-hash: hash-algアルゴリズムを使用して、DKIM-Signatureヘッダーを含むヘッダーと本文ハッシュをハッシュした出力。
  • h-headers: "h"パラメータで指定された署名するヘッダーのリスト。
  • D-SIG: 正規化されたDKIM-Signatureフィールド自体で、パラメータの署名値部分なし、つまり空のパラメータ値。
  • signature: 署名アルゴリズムによって生成された署名値。
  • sig-alg: "a"パラメータで指定された署名アルゴリズム。
  • d-domain: "d"パラメータで指定されたドメイン名。
  • selector: "s"パラメータで指定されたセレクタ値。

注: 多くのデジタル署名APIは、単一の"sign()"プリミティブを使用してハッシュとRSA秘密鍵の適用の両方を提供します。このようなAPIを使用する場合、アルゴリズムの最後の2つのステップは、"a-hash-alg"と"sig-alg"の両方を実行する単一の呼び出しに結合される可能性があります。

に最終更新