Page 10

　
12.  RFC 4871, Section 3.9, Relationship between SDID and AUID

Original Text:  

(None.  New section.  Additional text.)

12.  RFC 4871、3.9節、SDIDとAUIDの関係

原文：

（なし。新しい節。追加文。）

Corrected Text:

DKIM’s primary task is to communicate from the Signer to a recipient-side Identity Assessor a single Signing Domain Identifier (SDID) that refers to a responsible identity.  DKIM MAY optionally provide a single responsible Agent or User Identifier (AUID).

修正：

DKIMの第一の任務は署名者から受信側のアイデンティティ評価者に対して責任を持つアイデンティティを参照する単一の署名ドメイン識別子(SDID)を伝えることである。DKIMはオプションとして単一のエージェントまたはユーザ識別子(AUID)を提供してもよい(MAY)。

Hence, DKIM’s mandatory output to a receive-side Identity Assessor is a single domain name.  Within the scope of its use as DKIM output, the name has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. That is, within its role as a DKIM identifier, additional semantics cannot be assumed by an Identity Assessor.

それゆえ、DKIMの受信側アイデンティティ評価者に対する必須出力は単一のドメイン名である。DKIM出力としての使用の範囲内では、ドメイン名は基本のドメイン名セマンティクスのみを有する。所有者特有のセマンティクスについてはDKIMの範囲外である。すなわち、DKIM識別子としての役割においては、アイデンティティ評価者は追加のセマンティクスを仮定することはできない。

A receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present.

受信側のDKIM検証者はアイデンティティ評価者モジュールに署名ドメイン識別子(d=)を伝えなければならず(MUST)、エージェントまたはユーザ識別子(i=)が存在する場合それを伝えてもよい(MAY)。

To the extent that a receiver attempts to intuit any structured semantics for either of the identifiers, this is a heuristic function that is outside the scope of DKIM’s specification and semantics.  Hence, it is relegated to a higher-level service, such as a delivery handling filter that integrates a variety of inputs and performs heuristic analysis of them.

受信者がどちらかの識別子について構造化されたセマンティクスを見つけようとする処理は発見的機能であり、DKIM仕様およびセマンティクスの範囲外である。それゆえ、様々な入力を統合して発見的分析を行う配送処理フィルタのようなより上位のサービスに委ねられている。

INFORMATIVE DISCUSSION: This document does not require the value of the SDID or AUID to match the identifier in any other message header field.  This requirement is, instead, an assessor policy issue.  The purpose of such a linkage would be to authenticate the value in that other header field.  This, in turn, is the basis for applying a trust assessment based on the identifier value.  Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks.  The real-world efficacy of any but the most basic bindings between the SDID or AUID and other identities is not well established, nor is its vulnerability to subversion by an attacker.  Hence, reliance on the use of such bindings should be strictly limited.  In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the SDID or AUID.

参考議論：本文書は、SDIDまたはAUIDがなんらかのメッセージヘッダフィールド内のアイデンティティと合致していることを要求していない。むしろ、この要求は検証者のポリシの問題である。このような結合の目的はその他のヘッダフィールド内の値を認証することである。よって、識別子の値に基づく信頼の評価を適用するための基盤ということになる。信頼は広く複雑な話題であり、信頼の機構は非常に独創性の高い攻撃の対象である。SDIDまたはAUIDと他のアイデンティティとの結合以外については、実際に使用する場合の有効性の高さや攻撃者による破壊されやすさが実証されていない。それゆえこのような結合の使用における信頼性は厳密に制限されるべきである。特に、SDIDまたはAUIDのをうまく使うことで生まれる可能性のあるなんらかの保証に典型的な受信エンドユーザがどの程度まで依存できるかについてはまったく明らかになっていない。

　
 [Page 10]