Subject: [ietf-dkim] ADSP Informative Note on parent domain signing

From: Jim Fenton <[email-masked]>
Date: Mon, 06 Apr 2009 16:36:49 -0700

There remains some disagreement on whether the "informative note"
contained in the last paragraph of the text I proposed on March 27
should appear in the ADSP draft.  The note said:

> Informative Note:  ADSP is incompatible with DKIM signing by parent
> domains described in section 3.8 of [RFC4871] in which a signer uses 
> "i=" to assert that a parent domain is signing for a subdomain.
>   
This would replace the Note in draft-ietf-dkim-ssp-09, section 2.7.

Thus far, I feel it should be included and John Levine and Dave Crocker
feel it shouldn't.  May we have guidance from others in the Working
Group, please?

-Jim

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

---

From: Hector Santos <[email-masked]>
Date: Mon, 06 Apr 2009 20:39:09 -0400

> feel it shouldn't.  May we have guidance from others in the Working

My input:

Maybe I don't quite see the issues, but I've been doing more testing 
later to see how this is all going to fit, and there seems to be a 
need to deal with issues for the high potential cases:

1) same primary domain name spaces

     From: user @ subdomain.primary-domain.com
     DKIM-Signature:  d=primary-domain.com

     or

     From: user @ primary-domain.com
     DKIM-Signature:  d=subdomain.primary-domain.com

2) "3rd party" or non-author domain name space

     From: user @ primary-domain.com
     DKIM-Signature:  d=some-other-domain.com

As far as the i= is concern, as long as the h= binds the From: header 
(as it must per 4871) the i= appears to me as an "extra" bit of 
information that is not required for DKIM 4871 verification.

Lacking applications for usage, I don't see how i= "helps".  I think I 
understand some people want to use it as feed to some future or 
current trust service in the works.  But I see that as gravy information.

If the "issue" relates to non-author domain signatures, then of 
course, I will always continue to believe we have neglected to resolve 
the 3rd party design issue from a "Fraud Protection" standpoint. Not 
the whitelisting part of that design, the blacklisting.  No one wants 
to hear that (at least here) and thats unfortunate because in all my 
engineering experience and logic tells me, that is will continue to be 
a thorn on (DKIM) side and in my view, the #1 threat to DKIM wide 
acceptance and adoption. I would think that would mean something to 
the marketing of DKIM. But thats me.

If the i= is suppose to address that Jim, then I will love to hear and 
understand it because currently I don't see how that helps.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: Doug Otis <[email-masked]>
Date: Tue, 7 Apr 2009 09:10:59 -0700

On Apr 6, 2009, at 4:36 PM, Jim Fenton wrote:

>> domains described in section 3.8 of [RFC4871] in which a signer  
>> uses "i=" to assert that a parent domain is signing for a subdomain.
>

### This note is not correct.  The incompatibility is not dependent  
upon the i= value, which might be omitted.

Informative Note:  ADSP is incompatible with DKIM signing by parent  
domains described in section 3.8 of [RFC4871] when a parent domain  
signs for a sub-domain within an email-address.  ADSP requires the  
 From email-address domain (Author Domain) and the signing domain  
(SDID) to be the same.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 07 Apr 2009 11:53:37 -0700

> current trust service in the works.  But I see that as gravy information.

Since there is indeed no defined application for the i= value, "gravy
information" is not a bad description.  Nevertheless, Section 3.8 of RFC
4871 says that it's possible to sign messages where the domain part of
the i= value is a subdomain of the d= value, which of course it is.  But
since such a signature won't serve as an Author Domain Signature in ADSP
(when the From address is in the subdomain), I think it's important that
the ADSP specification point that out.

-Jim

---

From: "Siegel, Ellen" <[email-masked]>
Date: Tue, 7 Apr 2009 16:58:38 -0400

> feel it shouldn't.  May we have guidance from others in the Working

[> ] 

I think it may be the "incompatible" that's causing the disagreement. ADSP is not incompatible with that signing configuration, it would just require that a second signature be added. 

Maybe something more like the following?

"ADSP should not be used for domains that use "i=" values to enable a parent domain to sign for a subdomain (as described in section 3.8 of [RFC4871]) unless an additional signature where the "d=" domain matches the "i=" domain is added."

Ellen

---

From: Doug Otis <[email-masked]>
Date: Tue, 7 Apr 2009 14:37:53 -0700

On Apr 7, 2009, at 1:58 PM, Siegel, Ellen wrote:
> "ADSP should not be used for domains that use "i=" values to enable  
> a parent domain to sign for a subdomain (as described in section 3.8  
> of [RFC4871]) unless an additional signature where the "d=" domain  
> matches the "i=" domain is added."

Disagree.  The proposed change in the ADSP Author Domain Signature  
definition is to allow the i= value to represent any sub-domain and/or  
any local-part within the domain.  Unless further revised, the Author  
Signature definition still requires a valid DKIM signature applied by  
the Author Domain.  In other words, the From email-address domain  
(Author Domain) and the SDID must be the the same.

The current ADSP Author Signature definition in Section 2.7 states the  
following:
,---
An "author signature" is a Valid Signature that has the _same_ domain  
name in the DKIM signing identity as the domain name in the Author  
Address.
'---
Dropping the i= value as a constraining issue was the goal.  This can  
be done by striking the following in
Section 2.7:
,---
If the DKIM signing identity has a Local-part, it is be identical to  
the Local-part in the Author Address.  Following [RFC5321], Local-part  
comparisons are case sensitive, but domain comparisons are case  
insensitive.

For example, if a message has a Valid Signature, with the DKIM- 
Signature field containing "i=[email-masked]", then domain.example  
is asserting that it takes responsibility for the message.  If the  
message's From: field contains the address "[email-masked]", that  
would mean that the message does not have a valid Author Signature.  
Even though the message is signed by the same domain, it will not  
satisfy ADSP that specifies "dkim=all" or "dkim=discardable".

Note:   ADSP is incompatible with valid DKIM usage in which a signer  
uses "i=" with values that are not the same as addresses in mail  
headers.  In that case, a possible workaround could be to add a second  
DKIM signature a "d=" value that matches the Author  Address, but no  
"i=".
'---

The following could be an appropriate note:

Informative Note:  A DKIM signing by parent domains as described in  
section 3.8 of [RFC4871] where a parent domain signs for a sub-domain  
within the From email-address will not represent an Author Domain  
Signature.  ADSP requires the From email-address domain (Author  
Domain) and the signing domain (SDID) to be the same.

-Doug

---

From: "Siegel, Ellen" <[email-masked]>
Date: Tue, 7 Apr 2009 17:44:30 -0400

On Apr 7, 2009, at 17:28, "Jim Fenton" <[email-masked]> wrote:

> Siegel, Ellen wrote
>>>>
>>>>
>>>
>>
>> [> ]
>>
>> I think it may be the "incompatible" that's causing the  
>> disagreement. ADSP is not incompatible with that signing  
>> configuration, it would just require that a second signature be  
>> added.
>>
>> a parent domain to sign for a subdomain (as described in section  
>> 3.8 of [RFC4871]) unless an additional signature where the "d="  
>> domain matches the "i=" domain is added."
>>
>
> Good thought, but since parent domain signing is largely to simplify  
> key
> management (so that the public keys don't need to be published in each
> subdomain), it's not necessary to apply a parent domain signature if a
> signature where the d= value matches the actual From domain is also  
> applied.
>
> But you're right, "incompatible" may be a little harsh; I just  
> followed
> John Levine's wording in -09.  How about:
>
> Informative Note:  DKIM signatures by parent domains as described in  
> section 3.8 of [RFC4871] (in which a signer uses "i=" to assert that  
> it is signing for a subdomain) do not satisfy the requirements for  
> an Author Domain Signature as defined above.
>
> -Jim
>

Works for me.

Ellen

---

From: Doug Otis <[email-masked]>
Date: Tue, 7 Apr 2009 14:53:05 -0700

>> an Author Domain Signature as defined above.

Unfortunately, this is still wrong.  This issue does not depend upon  
the i= value.  A signature can be non-compliant with ADSP and not  
express an i= value.  The issue is solely whether the From email- 
address domain and the Signing Domain (SDID) are the same.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 07 Apr 2009 14:28:10 -0700

> "ADSP should not be used for domains that use "i=" values to enable a parent domain to sign for a subdomain (as described in section 3.8 of [RFC4871]) unless an additional signature where the "d="…

Good thought, but since parent domain signing is largely to simplify key
management (so that the public keys don't need to be published in each
subdomain), it's not necessary to apply a parent domain signature if a
signature where the d= value matches the actual From domain is also applied.

But you're right, "incompatible" may be a little harsh; I just followed
John Levine's wording in -09.  How about:

Informative Note:  DKIM signatures by parent domains as described in section 3.8 of [RFC4871] (in which a signer uses "i=" to assert that it is signing for a subdomain) do not satisfy the requirements for an Author Domain Signature as defined above.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Tue, 07 Apr 2009 14:36:08 -0700

> From email-address domain (Author Domain) and the signing domain
But what section 2.7 talks about has to do with the use of the i=
value.  Without the i= value, Parent Domain Signing (as defined there)
doesn't exist.

Have a look at the alternate wording I proposed in response to Ellen's
message and let me know what you think of that.

-Jim

---

From: John Levine <[email-masked]>
Date: 7 Apr 2009 22:22:23 -0000

>> section 3.8 of [RFC4871] (in which a signer uses "i=" to assert
>> that it is signing for a subdomain) do not satisfy the requirements
>> for an Author Domain Signature as defined above.

Since there is no other reference to i= in the ADSP document, the
reason to put in a note like this is to warn people who have a
mistaken impression of the way that ADSP works.  If we're going to do
that, there's quite a lot of other warnings that are at least as
important to add, such as:

 A signature whose d= matches the domain of a Sender: address does not
 satisfy ADSP unless the Sender: and From: addresses are in the same
 domain.

 A signature whose d= matches the domain of a Resent-From: or
 Resent-Sender: address does not satisfy ADSP unless that address and
 the From: addresses are in the same domain.

 A signature whose d= matches the RFC 2821 envelope MAIL FROM address does
 not satisfy ADSP unless the MAIL FROM and From: addresses are in the
 same domain.

 A signature whose d= matches the RFC 2821 HELO domain does not
 satisfy ADSP unless the EHLO domain is the same as the one in the
 From: address.

 etc.

If you think these are silly, I wouldn't disagree, but I don't see any
reason that some of them are sillier than others.

R's,
John

---

From: John Levine <[email-masked]>
Date: 7 Apr 2009 22:24:00 -0000

>value.  

Huh?  In our current draft, there's no mention of i= other than your
proposed warning.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 07 Apr 2009 15:36:08 -0700

> Huh?  In our current draft, there's no mention of i= other than your

Then it doesn't meet the requirement in RFC 5016, section 5.3, item 2.

		Mike

---

From: Jim Fenton <[email-masked]>
Date: Tue, 07 Apr 2009 15:38:53 -0700

> reason that some of them are sillier than others.

Because none of those examples are specifically called out in RFC 4871,
while the one for which I am proposing the informative note is.

Why was the informative note that you added in -09, which also described
a signing practice not described in RFC 4871, not (to use your term) silly?

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Tue, 07 Apr 2009 15:32:53 -0700

> Huh?  In our current draft, there's no mention of i= other than your
Sorry; typo (shifted left on the keyboard).  I meant to say section 3.8
(of RFC 4871).

-Jim

---

From: "John R. Levine" <[email-masked]>
Date: Wed, 8 Apr 2009 00:14:56 +0100 (BST)

> a signing practice not described in RFC 4871, not (to use your term) silly?

Because it pointed out a way that version of ADSP was badly broken, of 
course.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 07 Apr 2009 16:19:02 -0700

I think that John meant to send this to the list.

John R. Levine wrote:
> So what?
> Regards,
> John Levine, [email-masked], Primary Perpetrator of "The Internet for 
> Dummies",
> Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
> "More Wiener schnitzel, please", said Tom, revealingly.

---

From: "John R. Levine" <[email-masked]>
Date: Wed, 8 Apr 2009 00:22:05 +0100 (BST)

Please refrain from publishing private correspondence without permission.

I would think that all members of this WG would be familiar with the 
basics of e-mail etiquette, but you learn something new every day.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 07 Apr 2009 16:24:31 -0700

> basics of e-mail etiquette, but you learn something new every day.

No. Don't send me mail you don't want published, especially when you
are being a putz.

		Mike

---

From: Doug Otis <[email-masked]>
Date: Tue, 7 Apr 2009 17:20:28 -0700

On Apr 7, 2009, at 3:32 PM, Jim Fenton wrote:

>> Huh?  In our current draft, there's no mention of i= other than  
>> your proposed warning.
>>
>>

Jim,

You are right.  The term "Signing Identity" in ADSP Section 2.7 was  
seen as representing the SDID.

The ADSP Author Domain Signature definition in Section 2.7 need to  
change to the following:

A valid first party signature "Author Domain Signature" is a Valid  
Signature where the domain name in the DKIM signing domain (SDID) is  
the same domain name in the Author
Address .

Strike the following in Section 2.7:
,---
If the DKIM signing identity has a Local-part, it is be identical to
the Local-part in the Author Address.  Following [RFC5321], Local-part
comparisons are case sensitive, but domain comparisons are case
insensitive.

The following note could be added:

Informative Note:  Signing by parent domains as described in section  
3.8 of [RFC4871] where a parent domain signs for a sub-domain within  
the From email-address does not represent a valid first party  
signature or "Author Domain Signature".  A valid first party signature  
requires the From email-address domain (Author Domain) and the signing  
domain (SDID) to be the same.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 09 Apr 2009 11:11:09 -0600

>> an Author Domain Signature as defined above.
  [ . . . ]
> Works for me.

+1

(I'd use commas instead of parentheses, but that's minor.)

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Doug Otis <[email-masked]>
Date: Thu, 9 Apr 2009 16:43:15 -0700

On Apr 9, 2009, at 10:11 AM, J.D. Falk wrote:

> Siegel, Ellen wrote:
>
>>> Informative Note:  DKIM signatures by parent domains as described  
>>> in section 3.8 of [RFC4871] (in which a signer uses "i=" to assert  
>>> that it is signing for a subdomain) do not satisfy the  
>>> requirements for an Author Domain Signature as defined above.
>  [ . . . ]
>> Works for me.
>
> +1
>

IMHO, this is still wrong.  The i= value should be _ignored_ when  
determining ADSP compliance.  I'll try some examples.

,----
DKIM-Signature: ... d=foo.example.com;
From: [email-masked]
'----
#### This would be a first-party or Author Domain Signature.  Note the  
lack of the i= value.

,----
DKIM-Signature: ... d=example.com;
From: [email-masked]
'----
#### This would not be a first-part or Author Domain Signature.  Again  
note the lack of an i= value.

,----
DKIM-Signature: ... d=example.com; i=@foo.example.com
From: [email-masked]
'----
#### This would be a first-part or Author Domain Signature.  Although  
in conflict with the prior definition, use of a sub-domain in the i=  
value helps ensure against accidental collisions with a real email- 
addresses, when the i= value represents a token for the on-behalf-of  
identity.

There is no reason for ADSP to facilitate parent domain signing.    
Parent domain ADSP assertions are impossible after all.

Since each ADSP assertion MUST be made at the "_adsp._domainkey.email- 
address-domain TXT", creating a DNS entry at  
"<s=value>._domainkey.email-address-domain TXT" (which could point to  
a parent domain key using CNAME) represents only a minor effort.    
When it is too difficult to reference a key from the email-address  
domain, then don't make ADSP assertions at sub-domains intended to  
send and receive email.

Here is one more attempt at redefining section 2.7.
,----
A valid first party signature or "Author Domain Signature" is a Valid  
Signature where the domain name in the DKIM signing domain (SDID) is  
the same as the Author Domain.

Any sub-domain included within the i= value (AUID) will not affect  
ADSP compliance.  Only email-address domains that reference the DKIM  
key can comply with ADSP assertions.
'----

-Doug

---

From: Mark Delany <[email-masked]>
Date: Thu, 9 Apr 2009 19:30:58 -0700

> key can comply with ADSP assertions.

Right. The point is that i= is irrelevant at this stage to ADSP, just  
as other tags in the signature may be. The question is whether we want  
to be explicit about this tag not being relevant (and hence all the  
others that aren't relevant need to be stated too).

Maybe the right thing to say is that a future extension to ADSP may  
address how to interpret other signature tags, such as i=, but for now  
they are explicitly *not* part of the ADSP evaluation.

Mark.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 09 Apr 2009 21:43:19 -0700

> determining ADSP compliance.  I'll try some examples.

Yes, the i= value _is_ ignored when determining ADSP compliance.  The
text that refers to the i= value is in RFC 4871, not the ADSP spec, and
the point of the note is to point out that the comments about the use of
i= there don't apply to ADSP because ADSP doesn't use i=.

-Jim

---

From: Hector Santos <[email-masked]>
Date: Fri, 10 Apr 2009 06:19:30 -0400

> they are explicitly *not* part of the ADSP evaluation.

It would be nice to use this "life time" to get this resolve now. Fr 
some reason, I don't see a "future extension" coming, maybe something 
completely different. Nevertheless, the key issue as I see it that we 
lack protocol consistency and because of that we will be forced to 
invent new and better policies.

Per 4871, i=, if any, must comply to d= formatting.

   From: user @ domain.com
   DKIM-Signature: d=domain.com
          i=[email-masked]            <=  DKIM key tag t == s
          i=[email-masked]  <=  DKIM key tag t != s

This would satisfy ADSP "1st party only" requirement, but 4871 does 
have semantics that suggest possible "3rd party" using numerous 
reference to terminology such as "on behalf of" using the i= tag.

The problem overall is that that 4871 requires the d=/i= to match (per 
section 3.8).

Personally the big "invention" here is to not enforce that i= must be 
the same domain name space.  Since it is suppose to be "opaque", and 
only useful for accessors, and its a concept beyond the verification 
process, maybe we can afford this.

Here's why:

   1) WITHOUT ADSP

   Per 4871, right now with DKIM verifiers, if the d.domain and
   i.domain are not compliant, the signature is considered invalid.
   From.domain doesn't need to be considered in this test.

   Like wise per 4871, if the From.domain and the d.domain are not
   compliant, the signature is considered invalid.  The i.domain
   doesn't need to be considered in this test.

   2) WITH ADSP

   As far as ADSP is concern, the only thing that is important is the
   From.domain and the d.domain matching.  The validity of the
   signature only includes the binding of i= regardless of its value.

So from a protocol consistency standpoint, i= really is open to be any 
value and if that was allowed to be the case, the benefits are:

  1) ADSP and 4871 are protocol consistency

  2) 3rd party designs are now more possible using i= as part of
     algorithm

  3) MUA can benefit to possible gain "On Behalf" display ergonomics.

I see verifiers in the long run doing fast lookup for the From: domain 
before invoking heavy overhead DKIM hashing.  The signature, if it 
exist, must first pass syntax and formatting checking. i.e., check the 
that domains match, before really anything else.  So if i= is tied to 
d= as it is now, then it create issues for policies like it does not 
and limits 3rd party designs.

-- 
Sincerely

Hector Santos

---

From: Hector Santos <[email-masked]>
Date: Fri, 10 Apr 2009 06:48:58 -0400

> i= there don't apply to ADSP because ADSP doesn't use i=.

I don't think we should have a note in a protocol that suggest, imply 
anything NEGATIVE about not being compliant with DKIM-BASE.  It is 
works, it is compliant or its not.   If we keep that statement that 
people will undoubtedly think the protocol is now worth its effort, 
especially when they do want to use i=.

The technical problem as I see it is the tight requirement between d= 
and i=.

If i= is suppose to be an "On Behalf of" idea, then it probably needs 
to be open ended.

This will allow for ADSP to be protocol consistency for 1st party 
signing domain considerations and still allow for a 3rd party signer 
identity.

Isn't i= part of the DKIM hashing?

If so, I don't see why it was restricted to be equal or part of the d= 
domain.

Probably too late or too big of a change to do in 4871, but it is 
certainly something to keep in mind.

The final part of DKIM is to resolve the 3rd party authorization 
issues and I don't think we should only rely on "reputation" to 
resolve first level fraud.

-- 
Sincerely

Hector Santos

---

From: Hector Santos <[email-masked]>
Date: Fri, 10 Apr 2009 07:03:19 -0400

> especially when they do want to use i=.

Typo  Rewrite and small follow up example:

Either it works and compliant or does not. If we keep that statement
then people will undoubtedly think the protocol is not worth its
effort, especially when they do want to use i=.

> The technical problem as I see it is the tight requirement 
> between d= and i=. If i= is suppose to be an "On Behalf of"
> idea, then it probably needs to be open ended.

For example, using my gmail account.

    From: [email-masked]
    Dkim-Signature: d=gmail.com
                    i=@winserver.com

Why is this not desirable/possible?

Technically, I thinik gmail, probably should of done:

    From: [email-masked]
    Dkim-Signature: d=gmail.com
                    i=[email-masked]

because [email-masked] is my real gmail.com account, the from: is 
an authorized account I added to my gmail.com profile which gmail.com 
performed an email verification.

But from a POLICY standpoint, if ADSP was a standard, GMAIL.COM would 
do a ADSP check to see if WINSERVER.COM allows this.

So if ADSP is not supposed, I think gmail should be allow to add an i= 
that is reflective of the real account holder. I don't think it has to 
be a gmail.com domain as it would be in a mailing list.

   From: [email-masked]
   Dkim-signature: d=mipassoc.org
                   i=[email-masked]

Right?

What was the logic behind making i= be part of d=?

-- 
Sincerely

Hector Santos

---

From: Doug Otis <[email-masked]>
Date: Sat, 11 Apr 2009 07:14:21 -0700

> Why is this not desirable/possible?

Hector,

A valid DKIM signature verifies it was added by an entity  
authoritative for the email-address namespace claimed within the i=  
value. This is only true when this namespace is within the signing  
domain as required to be valid.

There was a third-party authorization solution suggested by the  
expired I-D:
  http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-adsp-00.html

If there is interest, perhaps you can co-author an update of this I-D  
to leverage a tag added to ADSP that signals the presence of third- 
party authorization labels. TXT records at these labels authorize  
various uses of the domain by the third-party. This expired draft  
places labels at the wrong location, and does not offer an ADSP  
signaling method.

The tpa label method scales and can include a large number of mailing- 
lists, for example.  This would introduces a transaction to confirm or  
deny a specific third-party authorization.   A vouch by reference  
concept might be combined within the tpa label TXT record as an  
additional means to confirm the behavior of messages having this  
relationship.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 10 Apr 2009 23:09:29 -0400

> i= there don't apply to ADSP because ADSP doesn't use i=.

I am getting increasingly confused about this topic.

The Update substantially alters what RFC4871 says or implies about i=.  It could 
well be that when the -bis effort does a detailed review of RFC4871+Update it 
finds further clarification and removals to make about i=.

Why, then, should ADSP make any comment about i= at all, given that ADSP no 
longer uses i=?

Having tidbits of clarification language can be helpful, but providing them when 
there isn't any experience to suggest their need and especially when they refer 
to something that is not cited anywhere else in a specification is downright 
peculiar.

Given how vigorously you seem to feel that it /should/ be included, I seem to 
keep missing the compelling argument that justifies it.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Jim Fenton <[email-masked]>
Date: Sat, 11 Apr 2009 21:22:52 -0700

Dave CROCKER wrote:
> The Update substantially alters what RFC4871 says or implies about
> i=.  It could well be that when the -bis effort does a detailed review
> of RFC4871+Update it finds further clarification and removals to make
> about i=.

Chairs, correct me if I'm wrong, but I don't think we have a normative
dependence between the ADSP specification and the 4871 Update.  The ADSP
specification doesn't use any of the terminology used in the Update. 
Furthermore, the Update makes no changes to section 3.8 of 4871 which
the Informative Note is intending to address.
>
> Why, then, should ADSP make any comment about i= at all, given that
> ADSP no longer uses i=?
>
> Having tidbits of clarification language can be helpful, but providing
> them when there isn't any experience to suggest their need and
> especially when they refer to something that is not cited anywhere
> else in a specification is downright peculiar.
>
> Given how vigorously you seem to feel that it /should/ be included, I
> seem to keep missing the compelling argument that justifies it.

The Informative Note I'd like to include, of course, changes nothing.  I
just see the potential for people to read RFC 4871, and where it talks
about possible uses for i=, and then read ADSP which is otherwise
completely silent on i=, and not make the connection that ADSP is only
looking at d= and therefore the parent domain signing "feature" in 4871
doesn't satisfy the Author Domain Signature requirements of ADSP.

Yes, the ADSP specification is complete without this note (it's
informative, after all).  But the compelling argument that justifies it
is that it clarifies things in a way that may improve interoperability. 
We should be trying to write specifications that promote
interoperability, not just ones that are technically complete.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Sun, 12 Apr 2009 11:52:35 -0700

On Apr 11, 2009, at 9:22 PM, Jim Fenton wrote:
>
> The Informative Note I'd like to include, of course, changes  
> nothing.  I just see the potential for people to read RFC 4871, and  
> where it talks about possible uses for i=, and then read ADSP which  
> is otherwise completely silent on i=, and not make the connection  
> that ADSP is only looking at d= and therefore the parent domain  
> signing "feature" in 4871 doesn't satisfy the Author Domain  
> Signature requirements of ADSP.
>
> informative, after all).  But the compelling argument that justifies  
> it is that it clarifies things in a way that may improve  
> interoperability. We should be trying to write specifications that  
> promote interoperability, not just ones that are technically complete.

The ADSP compliance issue is limited to a relationship between the  
 From email-address domain and the signing domain.  This relationship  
is not defined in the base draft and is not related to the i= value.

A normative note might mention that parent domain signing for From  
email-addresses will not satisfy ADSP, but it should not reference i=  
values.  Parent domain signing for a mailing list within a sub-domain  
that includes messages with a From email-address of the signing domain  
_will_ satisfy ADSP, for example.  The issue is unrelated to the  
i=value and is only related to parent domain signing of the From email- 
address.   Sub-domains within the i= value are only limited by the "s"  
flag in the key record t= value, but this has nothing to do with ADSP  
compliance beyond defining a valid DKIM signature.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Mon, 13 Apr 2009 00:21:36 -0400

> is not defined in the base draft and is not related to the i= value.

But it is, indirectly.

Consider the possible migration with existing DKIM systems that may 
adopt ADSP when its all said and done.

Currently, the ADSP ignorant DKIM-BASE verifier will do a verification 
and per 4871 should perform DKIM syntax/format tests including the d= 
and i= domain comparison and compliance test.  If it fails d=/i= 
compliance (for whatever reasons), the signature is invalid.

Come ADSP support and the DKIM-BASE implementation MAY update the 
design to focus on optimization by performing an ADSP lookup in call 
cases prior to any heavy message rehashing/crypto processing.

This optimized ADSP implementation design will require it to do the 
DKIM-BASE syntax checking including d=/i= comparison test among the 
other DKIM-BASE checking possible.  If both of the following is TRUE:

    ADSP => DKIM=DISCARDABLE
    DKIM => syntax, formation checking fails

Then there is no need to do any DKIM rehashing, the ADSP/DKIM test 
condition is satisfied and the message is rejected/discarded.

IMV, there will be a minimum of two possible implementations;

  1) Functionality is separate, one feeds the other

     DKIM_BASE_RESULT = DKIM_BASE_VERIFY(payload)
     DKIM_ADSP_RESULT = ADSP(DKIM_BASE_RESULT, payload.from.domain)

  2) Functionality is integrated or updated as one function

     DKIM_ADSP_RESULT = DKIM_ADSP_VERIFY(payload)

Some people in the first group will probably not touch the DKIM-BASE 
mailbots, API or software, and only feed the result to an separate 
POLICY mailbot that only need two parameters - the result of DKIM-BASE 
and the payload from domain.  The ADSP functional specification is 
geared towards this group with the incremental approach to adding 
policy to an existing DKIM-BASE implementation.

But for people who waited and/or more incline to see the whole 
picture, do more integration, do the optimization at the start, not 
later, this group will update their current software, API, etc, and 
perform the steps in a different order.  As long as end result is the 
same - it should not matter.

In this case, the ADSP function might include part of the DKIM-BASE 
checking and for ADSP that means d=/i= checking. The ADSP docs does 
not talk about this approach because it is presumed this DKIM-BASE 
work was already done.

IMV, the ADSP docs should have semantics about what i= means - 
technically:

    From.domain == d.domain == i.domain (or subdomain of d=)

 From what I see here, most agree, it doesn't have to mention i= 
because its implied that it will comply with d= and d must comply with 
from.domain.

But I think it should for better understanding of ADSP as it relates 
to DKIM-BASE.

-- 
Sincerely

Hector Santos

---

From: Douglas Otis <[email-masked]>
Date: Sun, 12 Apr 2009 23:20:09 -0700

> From.domain == d.domain == i.domain (or subdomain of d=)

Disagree.  Constrains on the i=value are well defined by RFC 4871.

A domain within the i= value MUST be at or below the signing domain,  
and when the "s" flag is set within the key record's t= value, a  
domain within the i= value MUST NOT include any sub-domain for the  
signature to be valid.

By having ADSP's reference the From email-address domain constrain d=  
values, signing domains are provided full control over the i= value.   
There is no reason for recipients to enforce i= value use beyond what  
is currently defined by RFC 4871.

> because its implied that it will comply with d= and d must comply  
> with from.domain.

Agreeing with the majority, and when Authentication-Results headers  
are considered, reasons for further constraints on i= values diminish.

It is more important to ensure the i= value retains its defined  
function of indicating on whose behalf the signature was added.  A  
message might be signed on behalf of the Sender header, for example.  
The i= value might even represent a token for this entity.  DKIM is  
never claimed to identify individuals, however a token can still  
assist in mitigating intra-domain abuse.

Some might optimize by checking the d= value for ADSP compliance, and  
the i= value for key record t= compliance prior verifying the  
signature.  Some might even check the d= domain reputation which might  
also signal a need to check the domain's i= reputation.  A reference  
to the i= value could use the hash label defined for third-party  
authorization, for example.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Mon, 13 Apr 2009 02:33:40 -0400

Douglas Otis wrote:
> A domain within the i= value MUST be at or below the signing domain, and 
> when the "s" flag is set within the key record's t= value, a domain 
> within the i= value MUST NOT include any sub-domain for the signature to 
> be valid.

Agree. So which part of my message are disagreeing which.

I'm settle on what DKIM-BASE and ADSP is leaning towards. I've waited 
a long time to reach this point and although I am not at all happy 
with how diminished the POLICY component has become, I believe the 
most important policy (EXCLUSIVE declarations) is possible.  So 
personally, I don't see what all the haggling is about about i=.

> values, signing domains are provided full control over the i= value.  

Sure, but it still must comply as 4871 has it defined.  I would of 
thought making it open ended would of satisfied the 3rd party market, 
but even that was screwed up.  So it is what it is d=/i= have a 
specific compliance to it.

> There is no reason for recipients to enforce i= value use beyond what is 
> currently defined by RFC 4871.

Oh I see what you are thinking.  I was thinking of terms of stupid 
software with no AI to it, no subjective meaning to it, no accessors 
involved and that is basically applying a deterministic algorithm as 
defined by DKIM-BASE for d= and i=.

I'm sorry, if we are not talking about the same thing, I'm talking 
about non-subjective interpretations and simply following a 
deterministic protocol. 1 + 1 = 2, not 3.

-- 
Sincerely

Hector Santos

---

From: Jim Fenton <[email-masked]>
Date: Sun, 12 Apr 2009 22:54:35 -0700

Douglas Otis wrote:
>> signing "feature" in 4871 doesn't satisfy the Author Domain Signature
>> requirements of ADSP.
>>

Agreed.
> i=value and is only related to parent domain signing of the From
> email-address.   Sub-domains within the i= value are only limited by
> the "s" flag in the key record t= value, but this has nothing to do
> with ADSP compliance beyond defining a valid DKIM signature.

But this isn't a normative note, it's an informative note.  All I want
to do with it is to caution the reader that Parent Domain Signing, as
described in section 3.8 of RFC 4871, isn't a practice that results in
an Author Domain Signature as defined in ADSP, and therefore they
shouldn't plan on using it if they're saying that they apply Author
Domain Signatures to all their mail.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Sun, 12 Apr 2009 23:42:04 -0700

On Apr 12, 2009, at 10:54 PM, Jim Fenton wrote:

> But this isn't a normative note, it's an informative note.  All I  
> want to do with it is to caution the reader that Parent Domain  
> Signing, as described in section 3.8 of RFC 4871, isn't a practice  
> that results in an Author Domain Signature as defined in ADSP, and  
> therefore they shouldn't plan on using it if they're saying that  
> they apply Author Domain Signatures to all their mail.

Consider a domain that uses sub-domains for their mailing-lists that  
are signed using Parent Domain Signing.  Even when a parent domain has  
ADSP assertions of either an "all" or "discardable", users can still  
participate in these mailing-lists using Parent Domain Signing and be  
compliant with ADSP.  Compliance can not be defined in terms of Parent  
Domain Signing, since the i= value can contain sub-domains.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Mon, 13 Apr 2009 06:04:20 -0700

Douglas Otis wrote:
>> therefore they shouldn't plan on using it if they're saying that they
>> apply Author Domain Signatures to all their mail.
>

I don't understand what "users can participate in these mailing-lists
using Parent Domain Signing" means.  A signature applied by a mailing
list would be an Author Domain Signature, except in the special case
where the domain of the mailing list signature happens to be the same as
that of the author.  It's possible to avoid this special case by having
the mailing list domain be different from that of any author, and one
way to do that is to give the mailing list(s) a separate subdomain.  But
that doesn't have anything to do with the caution about Parent Domain
Signing.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Mon, 13 Apr 2009 09:40:31 -0700

On Apr 13, 2009, at 6:04 AM, Jim Fenton wrote:

>> Consider a domain that uses sub-domains for their mailing-lists  
>> that are signed using Parent Domain Signing.  Even when a parent  
>> domain has ADSP assertions of either an "all" or "discardable",  
>> users can still participate in these mailing-lists using Parent  
>> Domain Signing and be compliant with ADSP.  Compliance can not be  
>> defined in terms of Parent Domain Signing, since the i= value can  
>> contain sub-domains.
>
> I don't understand what "users can participate in these mailing- 
> lists using Parent Domain Signing" means.  A signature applied by a  
> mailing list would be an Author Domain Signature, except in the  
> special case where the domain of the mailing list signature happens  
> to be the same as that of the author.  It's possible to avoid this  
> special case by having the mailing list domain be different from  
> that of any author, and one way to do that is to give the mailing  
> list(s) a separate subdomain.  But that doesn't have anything to do  
> with the caution about Parent Domain Signing.

A parent domain signature applied by the mailing-list might look as  
follows:

_adsp._domainkey.example.com TXT "dkim=discardable"

From: [email-masked]
DKIM-Signature: i=[email-masked];  
d=example.com; ...

When evaluating ADSP, this type of "Parent Domain Signature" is still  
compliant.  Users of "example.com" can participate in "[email-masked] 
" without special signatures being needed.

The domain might also use sub-domains as their means to tokenize on- 
behalf-of entities.

A parent domain signature applied for tokenized entities might look as  
follows:

From: [email-masked]
DKIM-Signature: i=[email-masked]; d=example.com; ...

When evaluating ADSP, this type of "Parent Domain Signature" is also  
still compliant.  A caution must not refer to i= values or parent  
domain signing.  The caution should be limited to ensuring the signing  
domain and the email-address domain be the same.  "Parent Domain  
Signing" is ONLY about the i= value, where the i= value is ignored for  
ADSP compliance.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Mon, 13 Apr 2009 13:22:23 -0400

> Signing" is ONLY about the i= value, where the i= value is ignored for  

You lost me here. I don't see the different between the two above 
examples as far as 4871 and ADSP is concern.  Specifically 4871 only 
cares for the right hand side of i=.

example:

     i= string1 @ string2

we only care for string2 being compliant with d=.

Why do we care about string1 in 4871 and ADSP?  Are you talking about 
something above and beyond 4871 and ADSP?

-- 
Sincerely

Hector Santos

---

From: Douglas Otis <[email-masked]>
Date: Mon, 13 Apr 2009 10:35:11 -0700

On Apr 13, 2009, at 10:22 AM, Hector Santos wrote:

> Why do we care about string1 in 4871 and ADSP?  Are you talking  
> about something above and beyond 4871 and ADSP?

Parent domain signing is about sub-domains within the i= value that  
are below the d= value.  This is not about the left-hand value.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Tue, 21 Apr 2009 21:26:21 -0400

This discussion seems to have settled down, but I don't see a clear
consensus on it.  Let's take a little poll, then, on this thread.  No
further discussion, for now, just the poll, and please don't assume
that silence means anything.

Post to this thread, one of the following:

"Include the informative note."
"Do not include the informative note."
"I don't care [or I have no opinion] either way."

It will be easier to tally if your note contains only your stated
opinion, and not other quoted text.  Thanks.

Barry (as chair)

---

From: Jim Fenton <[email-masked]>
Date: Tue, 21 Apr 2009 18:41:35 -0700

> "I don't care [or I have no opinion] either way."

Just to clarify the version of the Informative Note that I believe is
"in play" at this point, it should be the one that's based on Ellen

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 21 Apr 2009 22:31:06 -0400

>> "Include the informative note."

Scott K

---

From: Al Iverson <[email-masked]>
Date: Tue, 21 Apr 2009 23:28:08 -0500

Al

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com   --   Chicago, IL, USA
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 22 Apr 2009 07:43:15 -0000

>"Do not include the informative note."

or any other discussion of things not to do that aren't otherwise
mentioned in the ADSP doc

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 22 Apr 2009 06:27:07 -0700

-- 

   Dave Crocker

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 22 Apr 2009 09:53:11 -0400

-- 
Jeff Macdonald
[email-masked]

---

From: Jim Fenton <[email-masked]>
Date: Wed, 22 Apr 2009 07:11:23 -0700

---

From: "Olivier MJ Crepin-Leblond" <[email-masked]>
Date: Wed, 22 Apr 2009 17:16:29 +0200

> "Do not include the informative note."

O.

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Apr 2009 09:35:24 -0700

>> an Author Domain Signature as defined above.

Do not include an incorrect informative note!   The i= value is NOT  
part of ADSP evaluation and therefore plays NO role with respect to  
ADSP compliance.

A signer is free to assert whatever they wish with the i= value that  
is within the signing domain.  The only limitation is the Author  
Domain and the Signing Domain must be the same.  Do NOT refer to this  
requirement as having anything to do with the i= value.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 22 Apr 2009 11:42:57 -0600

> "I don't care [or I have no opinion] either way."

(IF consensus is to include an informative note, it should be the updated 
version currently under discussion.)

---

From: "Siegel, Ellen" <[email-masked]>
Date: Wed, 22 Apr 2009 16:58:56 -0400

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Apr 2009 17:41:42 -0400

> "I don't care [or I have no opinion] either way."

How about, I do care, for what's required to get it right, which might 
suggest I don't care either way, as long as it doesn't hurt the NEW 
SPEC. geez

-- 
Sincerely

Hector Santos

---

From: [email-masked] (Wietse Venema)
Date: Wed, 22 Apr 2009 17:49:04 -0400 (EDT)

> "I don't care

	Wietse