ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Consensus call on d=/i= clarification

2009-02-22 13:08:47
At 00:58 22-02-2009, Murray S. Kucherawy wrote:
(d) included a "with the following changes" provision.  What changes 
are you suggesting (or supporting)?

I'm reusing text from Eliot's and Jim's proposal.  From Section 5 of RFC 4871:

OLD

    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

NEW

     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.  Absent additional external information
         outside of the context of the "g=" tag, verifiers MUST treat the
         Local-part contents as an opaque string.  The Local-part and any
         "subdomain" of the "d=" value that appears in the "i=" tag are
         significant only to the signer.

OLD


  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 any but the most basic
            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.

NEW

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.
            Although its syntax might suggest otherwise, the "i="
            value need not be in the namespace that contains the mailbox
            of the user or agent.  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 any but
            the most basic 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.

Regards,
-sm 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html