Subject: [ietf-dkim] SSP-02 the problem with Author Signature

From: Douglas Otis <[email-masked]>
Date: Mon, 18 Feb 2008 15:33:54 -0800

Per RFC 4871:

The signature's i= parameter is "expected" to contain on-behalf-of  
information:

----
i=  Identity of the user or agent (e.g., a mailing list manager) on  
behalf of which this message is signed...
...
INFORMATIVE DISCUSSION: This document does not require the value of  
the "i=" tag to match the identity in any message header fields.

This definition is fairly useful since it allows signing domains to  
provide a reporting token within the i= parameter for verifiers to use  
to identify the agent creating a problem.  This token can be obscured  
and be a transient hash of the account used to access their outbound  
servers, for example.

SSP-02:

2.8. Author Signature

  An "Author Signature" is any Valid Signature where the identity of
  the user or agent on behalf of which the message is signed (listed in
  the "i=" tag or its default value from the "d=" tag) matches an
  Author Address (From header email-address) in the message.

3.3. SSP Record Syntax

"all" All mail from the domain is signed with an Author Signature.

Translation:

Only signatures on-behalf-of the From header email-address are  
considered compliant with an "all" SSP policy.  This is in conflict  
with RFC 4871.  Not all signatures are on-behalf-of the entity  
represented by the From header, of course.  Essentially, this  
necessitates the i= parameter not be used when the identity might  
conflict with the identity contained within the From header.  The i=  
parameter, as the only parameter defined as providing a higher  
granularity of the message sources, will no longer be useful in these  
cases.  How does this help verifiers cope with abuse?  It doesn't.

Per RFC 4871, a signature is valid when the signed on-behalf-of  
identity, the i= parameter, does not relate to the From header email- 
address.   However, the SSP-02 definition prevents the i= parameters  
from being useful in this role.  As a result, in many cases, this  
parameter is now unable to identify the actual agent or user who  
introduced the message when using an obscured hash of the identity the  
agent when it is related to the Resent-From or Sender header.

-Doug

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 19 Feb 2008 03:04:08 -0800

Expanding upon the effect of the SSP-02 Author Signature definition  
based upon a conversation with Jim...

Jim suggested that to comply with SSP-02, signatures will not make use  
of the i= parameter, since the i= parameter is needed only for g=  
restricted keys.

Instead of a practice that offers an explicit token (even one that is  
opaque) identifying the user/agent that introduced the message, once  
again examining the header stack and guessing which header might apply  
again becomes necessary.  It is also unknown whether the entire header  
stack will have been captured within the signatures hash, so this  
guessing may also be prone to the introduction of spoofed headers  
while attempting to resolve top most identifiers.

Secondly, this also means that MUAs attempting to highlight who the  
signature indicates as having introduced the message is also prone to  
getting this wrong, because the signature's identity (i=) MUST BE  
absent whenever the entity introducing the message is _not_  
represented by the email-addresses within the From header. : (

Although unlikely, some domains may feel compelled to sign the message  
twice.  One signature to comply with the SSP-02 Author Signature  
definition, and another to clarify who actually introduced the  
message. : (

As a result, instead of DKIM offering a "reportable" or "displayable"  
identifier clarifying who introduced the message, this identifier must  
again be guessed. : (

Jim's example as to why this definition is needed offers yet another  
problem with this scheme.

In Jim's example, there are users and a mail-list in example.com.   
Example.com SSP asserts they sign "all" messages.

Messages signed by the mailing-list contain the identifier of "mailing- 
list" that is not found within the From/Sender/Resent-* headers,  
whereas all the "user" messages will be signed with the i= parameter  
either containing the identity within the From header, or left blank,  
especially when the user is represented by a header further up the  
header stack. It is unknown whether the entire stack is included  
within the signature hash, so again guessing is needed when selecting  
a specific top most identifier and might be prone to spoofing.  When  
the i= parameter is blank, the identity of who introduced the message  
is in doubt.  In addition, messages signed by the mailing-list are  
also non-compliant with the "all" signed assertion, so they are likely  
to be rejected.

The goal of this scheme was to "protect" the From line in a message  
for all legacy MUAs.  This does not work.

Protecting the From line MUST BE the role of the signer, and not that  
of the verifier.  The signer should not offer keys to untrustworthy  
entities.  When i= points to the Sender header, and this key is g=  
restricted, and the From header contains a user within the domain,  
message filtering will be able to identify this type of message as  
being fairly odd, and modern MUAs will be able to highlight the  
identity, making this message also appear odd to the recipient.  IMHO,  
RFC 4871 should have declared such non-From header signatures with g=  
restricted keys as being invalid.

The g= restricted key used for non-From headers represents the corner  
case of all corner cases.  This extremely odd use is the primary  
reason for the extremely convoluted Author Signature definition.

Recommendation:

1) Change "Author Signature" to "Author Domain Signature".

2) Change "Author Signing Policy" to "Author Domain Signing Policy".

3) Accept the premise that when the "Author Domain" signs the message,  
the message is complaint with the "Author Domain's Signing Policy" _by  
definition_.

4) Only when the message is not signed by the "Author Domain", is the  
"Author Domain Signing Policy" in need of checking.

-Doug

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 20 Feb 2008 18:30:37 -0500

>of the i= parameter, since the i= parameter is needed only for g=  

Is that really true? I thought one could use i= in cases like so:

d=bar.org
i=@foo.bar.org

I didn't think g= was needed in that case.

>definition, and another to clarify who actually introduced the  

I think being able to use multiple signatures offers flexibility.

>identifier clarifying who introduced the message, this identifier must  

I don't think it really matters who introduced the message. What really
matters is if any of the DKIM identities are recognizable.

>problem with this scheme.

<snip>

>"Author Domain Signing Policy" in need of checking.

These seem reasonable to me, but I don't know if we need to be that
fine grained.

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421
:: v: 781-372-1922 | f: 781-863-8118
:: www.e-dialog.com

---

From: Jim Fenton <[email-masked]>
Date: Wed, 20 Feb 2008 21:55:09 -0800

> I didn't think g= was needed in that case.

I was misunderstood here.  A local part on i= is REQUIRED if the signing 
key is "restricted" through use of a g= parameter other than *.  i= can 
be used at other times and for other things as well, as you point out.  
In the example you gave, i=@foo.bar.org would result in an Author 
Signature when the Author Address on the message is something like 
[email-masked].
>> represented by the email-addresses within the From header. : (

Huh??  ASP does not prohibit other signatures, it just provides no 
additional information about them.
> I think being able to use multiple signatures offers flexibility.

Sure, and doesn't signing the Sender header field clarify who actually 
introduced the message, if that's important?
> matters is if any of the DKIM identities are recognizable.

Yes, that's the point.
> These seem reasonable to me, but I don't know if we need to be that

Just because the signing policy is expressed only at the domain level 
doesn't mean that the definition of Author Signature must also be at 
exactly the same level of granularity.  So an Author Domain Signing 
Policy can still deal with Author Signatures.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Feb 2008 12:19:59 -0800

On Feb 20, 2008, at 9:55 PM, Jim Fenton wrote:

>>> Expanding upon the effect of the SSP-02 Author Signature  
>>> definition  based upon a conversation with Jim...
>>>
>>> Jim suggested that to comply with SSP-02, signatures will not make  
>>> use  of the i= parameter, since the i= parameter is needed only  
>>> for g=  restricted keys.
>>>
>>

Including the local-part is only required for g= restricted keys,  
where often the default of "i=@<d=domain>" is likely to be used.  A  
signature is not valid when the key is domain restricted, and the  
domain of the identity is within a sub-domain, which should make this  
case moot.

> I was misunderstood here.  A local part on i= is REQUIRED if the  
> signing key is "restricted" through use of a g= parameter other than  
> *.  i= can be used at other times and for other things as well, as  
> you point out.  In the example you gave, i=@foo.bar.org would result  
> in an Author Signature when the Author Address on the message is  
> something like [email-masked].

Although excluding the local-part from the i= parameter is possible,  
the identify of who introduced the message becomes ambiguous.  For  
example:

Sender: [email-masked]
From: [email-masked]
Dkim-signature: d=bar.org i=foo.bar.org (SSP-02 compliant with "all")

A perfectly valid signature identifying [email-masked] as  
introducing the message (per RFC 4871 definition where i= indicates on  
who's behalf the signature was added) would not be compliant with an  
SSP-02 assertion of "all"!

Sender: [email-masked]
From: [email-masked]
Dkim-signature: d=bar.org i=[email-masked] (SSP-02 non-compliant  
with "all")

The SSP-02 Author-Signature definition _requires_ use of an  
"ambiguous" signature in these rather common cases.  So when the  
signing domain wishes to ensure clarity in who introduced the message,  
it must add an additional signature for the same message.  To defend  
against signature removal, the explicit signature needs to be included  
within the ambiguous signature, or, to ensure walking up the header  
stack does not lead to confusion when lacking the explicit signature,  
empty Sender, Resent-* headers must be listed to preclude their use.

The preclusion of headers when using a single signature will prevent  
practices that might have been able to preserve the original  
signature.  A potential for confusion results in the SSP-02  
requirement that the "Author Signature" MUST specifically identify the  
 From header address, or MUST BE ambiguous about the local-part.  This  
SSP-02 definition is attempting to ensure those using g= restricted  
keys are unable to sign compliant messages where the identity is not  
included within the From header.

SSP-02 would be a better specification and would create fewer problems  
by adding a non-normative statement that messages signed with local- 
part restricted keys where the identity is not within the From header  
should cause great caution, regardless of the SSP-02 policy  
assertions.  Would anyone disagree with such advice?

To allow the properly evaluation of results returned by a signature  
validation process, the following should be enumerated:

2 bits Signed By: no-one			0
                  first-party			1		
                  third-party			2
                  authorized third-party        3 (future)

1 bit local-part restricted, 			0 not /1 is

1 bit domain restricted, 		        0 not/ 1 is

2 bits policy: no policy			0
               "all" 				1
               "repudiate-able"			2
               "SMTP disavowed"			3

1 bit TPA policy"				0 not used, 1 used (future)			

>>> Instead of a practice that offers an explicit token (even one that  
>>> is  opaque) identifying the user/agent that introduced the  
>>> message, once  again examining the header stack and guessing which  
>>> header might apply  again becomes necessary.  It is also unknown  
>>> whether the entire header  stack will have been captured within  
>>> the signatures hash, so this  guessing may also be prone to the  
>>> introduction of spoofed headers  while attempting to resolve top  
>>> most identifiers.
>>>
>>> Secondly, this also means that MUAs attempting to highlight who  
>>> the  signature indicates as having introduced the message is also  
>>> prone to  getting this wrong, because the signature's identity  
>>> (i=) MUST BE  absent whenever the entity introducing the message  
>>> is _not_ represented by the email-addresses within the From  
>>> header. : (
>

When the entity is not represented by the From header, to be specific  
about on-who's-behalf the signature had been added SSP-02 essentially  
requires two signatures be added.  Needing two signatures as part of a  
normal process adds overhead and complexity, and increases the  
difficulty of defending the verification process.  There is no  
justification for _requiring_ the use of multiple signatures.  No  
additional information is being added by the SSP-02 compliant  
signature.  This signature is purely wasted overhead that increases  
complexity and risk.

>>> Although unlikely, some domains may feel compelled to sign the  
>>> message  twice.  One signature to comply with the SSP-02 Author  
>>> Signature  definition, and another to clarify who actually  
>>> introduced the  message. : (
>>>
>>
> Sure, and doesn't signing the Sender header field clarify who  
> actually introduced the message, if that's important?

RFC 4871 allows multiple signatures, but these multiple signatures of  
the same domain are needed _only_ because SSP-02 requires _less_  
information be contained within the policy compliant signature!

>>> As a result, instead of DKIM offering a "reportable" or  
>>> "displayable"  identifier clarifying who introduced the message,  
>>> this identifier must  again be guessed. : (
>>
>> I don't think it really matters who introduced the message. What  
>> really matters is if any of the DKIM identities are recognizable.
>
> Yes, that's the point.

A DKIM signature from the Author Signature's Domain provides a  
recognizable identity, the _domain_.  Why stipulate the local-part  
MUST NOT be included within a signature in order to be SSP-02 Author  
Signature compliant when added on-behalf-of the entity represented by  
the Sender header?  The definition of Author Domain Signature should  
allow this type of signature to be compliant.

>>> Jim's example as to why this definition is needed offers yet  
>>> another  problem with this scheme.

Don't overlook the situation created by Jim's example, that when there  
is a desire to ensure the identity on who's behalf the signature is  
being added, ambiguous signatures only add to possible confusion when  
required these signatures are required to achieve compliance with an  
"all" assertion.  Wandering up the header stack when only one  
signature is used increases the likelihood of this identification  
process becoming prone to spoofing.

>>> 3) Accept the premise that when the "Author Domain" signs the  
>>> message,  the message is complaint with the "Author Domain's  
>>> Signing Policy" _by  definition_.
>>>
>>> 4) Only when the message is not signed by the "Author Domain", is  
>>> the  "Author Domain Signing Policy" in need of checking.
>>
> Just because the signing policy is expressed only at the domain  
> level doesn't mean that the definition of Author Signature must also  
> be at exactly the same level of granularity.  So an Author Domain  
> Signing Policy can still deal with Author Signatures.

Compliance with your definition of Author Signature, when signing on  
behalf of an entity not within the From header, requires the  
signature's identity be falsified, or to remain ambiguous.  Forcing  
use of falsified or ambiguous signatures potentially enables  
exploitations, as the verifier/MUAs may attempt to guess the most  
likely identity.  These identities that may not have been included  
within the signature's hash as well, as this is not required.

Requiring two signatures be added in a specific order to retrain a  
secure indication of the i= parameter makes no sense.  This  
requirement only exposes the process to additional risks.  Verifiers  
will not have any trouble assessing the level of risk associated with  
a local-part restricted key where this identity is not found within  
the From header.  Policy is not needed to identify this type of  
signature as being risky.  The Author Signature is being overly  
restrictive as it precludes a signature from containing essential  
information.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 22 Feb 2008 17:31:19 -0800

Jim

As the cut-off approaches, this is an appeal for you to reconsider  
where agreement might be found.

Risks associated with the use of g= restricted keys signing messages  
where i= identities are not found within the From header exists  
whether policy is asserted or not.  A g= restricted key signifies the  
signing is restricted due to limited trust.  In other words, the  
message signed by such keys may not be controlled by the domain's  
signing practices, whether any policy records are published or not.

Being aware of the risk associated with local-part restricted keys  
REQUIRES the presence of this restriction be indicated the DKIM  
validation process, or this risk can not be accurately assessed.  The  
risk related to the use of g= restricted keys does not change  
substantially when the domain also asserts they sign "all" messages.   
Domains asserting such policy are also likely more cautious about the  
distribution of these local-party restricted keys.   Why limit  
weighing this risk with local-part restricted keys to just rare  
situations where domains assert a DKIM policy?  Otherwise, use of  
restricted local-parts not within the From header is likely indicative  
of messages attempting to phish or spam using keys purloined from  
someone's laptop.

You seem fairly determined to keep your version of the "Author  
Signature" definition you feel designed to address this concern, but  
only in fairly limited situations.  This definition, in many cases,  
prohibits use of user/agent specific information regarding a token  
directly associated with signatures without also implementing multiple  
signatures, or expecting verifiers to guess identities by picking the  
higher header within the message header stack.  This is most  
unfortunate, as the value DKIM may have had in curbing abuse depends,  
to a substantial degree, upon the definition expressed within RFC 4871  
for the i= parameter.  This definition permits the i= parameter to  
serve as a token for the entity introducing the message (on whose  
behalf the signature was added).  This token enables simpler feedback  
reports, and defensive measures that can be used by receiving  
domains.  "They can use multiple signatures when they wish to be  
specific" sounds too much like "let them eat cake."  This statement  
represents an excuse for an awkward and erroneous definition that  
overlooks the intent of RFC 4871, and the increased overhead,  
complexity, and risk.

A defence afforded by meaningful tokens of the user/agent is not  
affected by a value being opaque and matches nothing within the  
message.  Such an opaque value would be compliant with RFC 4871.  The  
i= identity's real value is found as a token that can track sources  
within a domain of compromised systems.  Whether the token represents  
an obscured machine or person does not matter.  Even an i= identity  
changing every day still provides useful information when dealing with  
large domains where blocking at the domain is truly onerous.

In addition, the Author Signature restatement of the definition for  
the i= parameter is plain wrong.  One can not say the i= parameter  
represents on whose behalf the signature was added, and then say this  
identity must also represent the email-addresses found within the From  
header.  Such a definition must be wrong in many cases.  DKIM is not  
about ensuring that the identity of an individual matches that of an  
email-address contained with the message.  Such matching is completely  
optional, since DKIM is _not_ attempting to replace S/MIME or  
OpenPGP.  As such, there is no reason for DKIM policies to then  
stipulate what identities are permitted to represent the on-behalf-of  
entity.  The recognizable identity offered by DKIM is the _DOMAIN_.

Your Author Signature definition forces recipients into guessing which  
header might contain the identity on whose behalf the signature was  
added.  This may happen when, to be compliant with the Author  
Signature definition, the signature remains ambiguous as a path of  
least resistance.  Guessing identities then opens the door for  
spoofing, especially when multiple signatures are added, but perhaps  
in the wrong order.  It is ironic most DKIM messages are not processed  
during the SMTP transaction, where a policy definition expecting use  
of multiple signatures only makes this goal less obtainable.  This  
definition causes the signature processing overhead to be more  
complex, and more error prone, and less safe.  Anyone using DKIM  
naively thinking that, because they sign all their messages using RFC  
4871, they can then make a DKIM policy assertion they sign "all" their  
messages, will be in for a rude awakening due to your definition of  
Author Signature.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 25 Feb 2008 15:35:49 -0800

Doug,

Much as I appreciate your personal appeal, it's really the rough 
consensus of the working group, and not my opinion, that matters.

If I understand correctly, the difference between the approach you favor 
and the one that I favor is as follows:

Approach A (favored by Doug): Check the g= tag on the key referenced by 
a valid signature, if present, compare it to the local-part of a From 
address to determine if the signature is an Author Signature.

Approach B (favored by Jim):  Compare the i= value on a valid signature 
(or its default value) against a From address; if the i= value has a 
local-part, then it must match the local-part of that From address.

If there is a g= tag in the key, then there must be a matching 
local-part in the i= of the signature in order for the signature to be 
valid, so the approaches are approximately equivalent in this case.

If there is not a g= tag (or if its value is *), and if there is no 
local-part in the i= of the signature, then the approaches are also 
equivalent.

The difference appears when there is not a g= tag (or if its value is *) 
and the i= contains a local-part.  Approach A would consider this to be 
an Author Signature regardless of the local-part, and approach B would 
only consider this to be an Author Signature if the local-parts match.

My rationale for B is that it allows a domain to apply a signature not 
representing an author sharing the domain.  While we haven't gone 
through the details of how mailing list signing might work, there might 
be times when such an agent might want to sign a message, but explicitly 
not as the author.  It also does not require the retention (or 
re-retrieval) of the key information in evaluating whether something is 
an Author Signature.

As I understand it, your rationale for A is that it allows the 
local-part of i= to be used for an opaque tag representing but not 
revealing the identity of the user or agent for which the signature is 
being applied.  My response to this is that there are lots of other 
places an opaque tag could be put, since it is local to the use of a 
particular domain, and can be done without interfering with the ability 
of a domain to sign as other than an author.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 25 Feb 2008 17:45:23 -0800

> consensus of the working group, and not my opinion, that matters.

Jim,

Thank you for your feedback.

Of course consensus matters, but so does compatibility with RFC 4871.   
The SSP-03 draft will cause valid DKIM signatures applied by the From  
domain to be non-compliant with SSP "all" assertions.  This happens  
when the i= parameter is used to indicate the on-behalf-of user/agent,  
but this identity does not represent the From email-address.  Domains  
attempting to clarify which identities have been authenticated by  
setting the i= parameter are prevented from doing so without applying  
multiple signatures, or leaving user/agent identities ambiguous.  Use  
of multiple or ambiguous signatures creates new risks.

> If I understand correctly, the difference between the approach you  
> favor and the one that I favor is as follows:
>
> Approach A (favored by Doug): Check the g= tag on the key referenced  
> by a valid signature, if present, compare it to the local-part of a  
> From address to determine if the signature is an Author Signature.

No, the g= tag is to be used by untrustworthy systems.  When the key  
g= tag restricts the identity, and the i= identity is not found within  
the From header, even a valid signature MUST BE considered to have  
UNKNOWN DOMAIN SIGNING COMPLIANCE.  It does not matter whether the  
domain makes policy assertions with respect to this specific and  
unusual case.  This type of signature MUST BE excluded from being  
considered compliant with any domain policy, and SHOULD NOT cause  
trust for the domain to be applied.

After excluding restricted key signatures containing a non-From header  
identity from being considered DOMAIN COMPLIANT, then only the domain  
of the signature, and the domain of the From header email-address  
require evaluation.  This approach permits the i= parameter to  
_always_ represent the user/agent without the identity even being  
contained within the message itself.  The A Approach is thus far more  
compatible with RFC 4871.

> Approach B (favored by Jim):  Compare the i= value on a valid  
> signature (or its default value) against a From address; if the i=  
> value has a local-part, then it must match the local-part of that  
> From address.

This is directly in conflict with RFC 4871's definition for the i=  
parameter.

> If there is a g= tag in the key, then there must be a matching local- 
> part in the i= of the signature in order for the signature to be  
> The difference appears when there is not a g= tag (or if its value  
> is *) and the i= contains a local-part.  Approach A would consider  
> this to be an Author Signature regardless of the local-part, and  
> approach B would only consider this to be an Author Signature if the  
> local-parts match.

This overlooks the exclusion that any evaluation process should make.   
In the Approach B, the UNKNOWN DOMAIN SIGNING COMPLIANCE when the key  
g= tag restricts the identity, and the i= identity is not found within  
the From header is never notices unless policy is being evaluated.   
This makes Approach B less safe, and less compatible with RFC 4871.

> My rationale for B is that it allows a domain to apply a signature  
> not representing an author sharing the domain.

Approach B may require an ambiguous signature or two overlapping  
signatures.  In the case of just a single ambiguous signature, the  
identity of the user/agent on whose behalf the signature was added  
must be guessed by looking for headers that might exist above the From  
header.  Requiring two signatures may tend to prevent in session  
evaluations from being practical.  In essence, Approach B requires  
possible removal of information permitted by RFC 4871 from the  
signature, where restoration of this information may necessitate a  
second signature.

> While we haven't gone through the details of how mailing list  
> signing might work, there might be times when such an agent might  
> want to sign a message, but explicitly not as the author.  It also  
> does not require the retention (or re-retrieval) of the key  
> information in evaluating whether something is an Author Signature.

Approach A requires restricted keys for non-From identities to be  
noted, but this notation SHOULD BE done regardless of any policy  
assertion.  For Approach A, beyond that specific notation step, only  
the domains of the signature and the From email address then play a  
role in signature compliance.

> As I understand it, your rationale for A is that it allows the local- 
> part of i= to be used for an opaque tag representing but not  
> revealing the identity of the user or agent for which the signature  
> is being applied.

Exactly.  This parameter is the _ONLY_ identity currently defined upon  
which a verifier may employ to defend against abuse related to  
compromised systems or malicious users having the freedom to use any  
 From header address they wish.  A user's freedom to use any From  
email-address is independent of the signing domain's policy assertions.

> My response to this is that there are lots of other places an opaque  
> tag could be put, since it is local to the use of a particular  
> domain, and can be done without interfering with the ability of a  
> domain to sign as other than an author.

Only Approach B interferes with an ability to identity the agent/ 
user.  No other tags have been defined for this purpose.  Defining yet  
another tag for the same purpose is not needed when compatibility with  
RFC 4871 is retained.

-Doug

>> Risks associated with the use of g= restricted keys signing  
>> messages where i= identities are not found within the From header  
>> exists whether policy is asserted or not.  A g= restricted key  
>> signifies the signing is restricted due to limited trust.  In other  
>> words, the message signed by such keys may not be controlled by the  
>> domain's signing practices, whether any policy records are  
>> published or not.
>>
>> validation process, or this risk can not be accurately assessed.   
>> The risk related to the use of g= restricted keys does not change  
>> substantially when the domain also asserts they sign "all"  
>> messages.  Domains asserting such policy are also likely more  
>> cautious about the distribution of these local-party restricted  
>> keys.   Why limit weighing this risk with local-part restricted  
>> keys to just rare situations where domains assert a DKIM policy?   
>> Otherwise, use of restricted local-parts not within the From header  
>> is likely indicative of messages attempting to phish or spam using  
>> keys purloined from someone's laptop.
>>
>> Signature" definition you feel designed to address this concern,  
>> but only in fairly limited situations.  This definition, in many  
>> cases, prohibits use of user/agent specific information regarding a  
>> token directly associated with signatures without also implementing  
>> multiple signatures, or expecting verifiers to guess identities by  
>> picking the higher header within the message header stack.  This is  
>> most unfortunate, as the value DKIM may have had in curbing abuse  
>> depends, to a substantial degree, upon the definition expressed  
>> within RFC 4871 for the i= parameter.  This definition permits the  
>> i= parameter to serve as a token for the entity introducing the  
>> message (on whose behalf the signature was added).  This token  
>> enables simpler feedback reports, and defensive measures that can  
>> be used by receiving domains.  "They can use multiple signatures  
>> when they wish to be specific" sounds too much like "let them eat  
>> cake."  This statement represents an excuse for an awkward and  
>> erroneous definition that overlooks the intent of RFC 4871, and the  
>> increased overhead, complexity, and risk.
>>
>> message.  Such an opaque value would be compliant with RFC 4871.   
>> The i= identity's real value is found as a token that can track  
>> sources within a domain of compromised systems.  Whether the token  
>> represents an obscured machine or person does not matter.  Even an  
>> i= identity changing every day still provides useful information  
>> when dealing with large domains where blocking at the domain is  
>> truly onerous.
>>
>> represents on whose behalf the signature was added, and then say  
>> this identity must also represent the email-addresses found within  
>> the From header.  Such a definition must be wrong in many cases.   
>> DKIM is not about ensuring that the identity of an individual  
>> matches that of an email-address contained with the message.  Such  
>> matching is completely optional, since DKIM is _not_ attempting to  
>> replace S/MIME or OpenPGP.  As such, there is no reason for DKIM  
>> policies to then stipulate what identities are permitted to  
>> represent the on-behalf-of entity.  The recognizable identity  
>> offered by DKIM is the _DOMAIN_.
>>
>> Your Author Signature definition forces recipients into guessing  
>> which header might contain the identity on whose behalf the  
>> signature was added.  This may happen when, to be compliant with  
>> the Author Signature definition, the signature remains ambiguous as  
>> a path of least resistance.  Guessing identities then opens the  
>> door for spoofing, especially when multiple signatures are added,  
>> but perhaps in the wrong order.  It is ironic most DKIM messages  
>> are not processed during the SMTP transaction, where a policy  
>> definition expecting use of multiple signatures only makes this  
>> goal less obtainable.  This definition causes the signature  
>> processing overhead to be more complex, and more error prone, and  
>> less safe.  Anyone using DKIM naively thinking that, because they  
>> sign all their messages using RFC 4871, they can then make a DKIM  
>> policy assertion they sign "all" their messages, will be in for a  
>> rude awakening due to your definition of Author Signature.
>>
>> -Doug
>>
>>
>>
>>