Page 7

　
10.  RFC 4871, Section 3.5, The DKIM-Signature Header Field

Original Text:

i=  Identity of the user or agent (e.g., a mailing list manager) on behalf of which this message is signed (dkim-quoted-printable; OPTIONAL, default is an empty Local-part followed by an “@” followed by the domain from the “d=” tag).  The syntax is a standard email address where the Local-part MAY be omitted.  The domain part of the address MUST be the same as or a subdomain of the value of the “d=” tag.

10.  RFC 4871、3.5節、DKIM-Signatureヘッダフィールド

原文：

i= 署名者が本メッセージに署名を代行するエージェントまたはユーザ(メーリングリスト管理者など)(dkim-quoted-printable文字列、オプション、特に指定しない場合はlocal-partは空で@の後に”d=”タグで指定したドメイン)。文法は標準の電子メールアドレスであり、local-partは省略してもよい(MAY)。アドレスのドメイン部分は”d=”タグ値と同一またはそのサブドメインでなければならない(MUST)。

Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC3490] using the “ToASCII” function.

ABNF:

sig-i-tag =  %x69 [FWS] "=" [FWS]
             [ Local-part ] "@" domain-name

国際化ドメイン名は[RFC3490]の4章に挙げられた手順を用いて”ToASCII”機能を使って変換されなければならない(MUST)。

ABNF:

sig-i-tag =  %x69 [FWS] "=" [FWS]
           [ Local-part ] "@" domain-name

INFORMATIVE NOTE: The Local-part of the “i=” tag is optional because in some cases a signer may not be able to establish a verified individual identity.  In such cases, the signer may wish to assert that although it is willing to go as far as signing for the domain, it is unable or unwilling to commit to an individual user name within their domain.  It can do so by including the domain part but not the Local-part of the identity.

参考：署名者が個別のアイデンティティが検証されたかを実証できない場合があるため”i=”タグのlocal-partはオプションである。たとえば、署名者は自分がそのドメインに対して署名を行うつもりはあるがそのドメイン内の個別のユーザ名にかかわることができない、もしくはかかわるつもりがないことを主張したい場合がある。”i=”タグにアイデンティティのドメイン部分のみを含みlocal-partを入れなければ、上記の主張が可能である。

INFORMATIVE DISCUSSION: This document does not require the value of the “i=” tag to match the identity in any message header fields.  This is considered to be a verifier policy issue. Constraints between the value of the “i=” tag and other identities in other header fields seek to apply basic authentication into the semantics of trust associated with a role such as content author.  Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks.  The real-world efficacy of bindings between the “i=” value and other identities is not well established, nor is its vulnerability to subversion by an attacker.  Hence reliance on the use of these options 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 “i=” options.

参考議論：本文書は”i=”タグ値がなんらかのメッセージヘッダフィールド内のアイデンティティと合致していることを要求していない。これは検証者のポリシの問題だと考えられる。”i=”タグ値と他のヘッダフィールドの他のアイデンティティを結び付けることは、コンテンツの著者のような役割に関する信頼のセマンティクスに対して基本的な認証を適用しようとすることになる。信頼は広く複雑な話題であり、信頼の機構は非常に独創性の高い攻撃の対象である。”i=”値と他のアイデンティティの結合については、実際に使用する場合の有効性の高さや攻撃者による破壊されやすさが実証されていない。それゆえこれらのオプションの使用における信頼性は厳密に制限されるべきである。特に、”i=”オプションをうまく使うことで生まれる可能性のあるなんらかの保証に典型的な受信エンドユーザがどの程度まで依存できるかについてはまったく明らかになっていない。

　
[Page 7]