[ietf-dkim] Who signs what

[Murray S. Kucherawy]

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-
> bounces at mipassoc.org] On Behalf Of Steve Atkins
> Sent: Thursday, September 16, 2010 11:35 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] Who signs what
> 
> I think you're saying that when I register a domain[1] and use
> that domain in both the From: address and the DKIM signature
> then that's a third-party signature if I use a subdomain in the
> DKIM signature.

Yes.

> In the ADSP world the difference between "non-author-domain"
>  vs "author-domain" is an important distinction, but you're
> using "third-party" vs "first-party" to refer to that.

I don't think there's a difference.  I think having two terms to describe the same thing in different ways only serves to confuse the issue.

> That's contrary to normal use of the term third-party, as there
> is no third party involved in this example - there's me and my
> domain, and there's the recipient.

How is a piece of software supposed to detect and apply that?  As soon as you make that allowance, then one could argue we should also have a heuristic to say "yahoo.co.uk" and "yahoo.com" are related and should share a reputation.

I really don't think we want to go down this path.

> And this isn't a theoretical case. Signing with a subdomain of
> the domain in the From address is DKIM best practice in a
> large fraction of cases.

It's still a third-party signature, with its own reputation.  That is, as I understand it, the whole point of signing with a subdomain.

> If we describe that as a third-party signature we risk confusing
> it with the case of a true third-party signature from a certification
> authority or some such. "Third-party that's the author"
> vs "Third-party that's not the author".

There's only confusion when we pile adjectives onto the end.  It's third-party, or it's not.  Or since some people like ADSP's terms:  It's an author signature, or it's not.

Put another way: If we can't converge on terminology in this area to describe all the variations, maybe there's a reason for that.

> >> Let's not waste time on this.
> 
> The way to avoid wasting time is to use the terminology
> that's in the drafts we already have in place, rather than
> making up new terminology that's misleading.

Actually I think the time is wasted in trying to identify every possible variant of a very simple term that already has a well-defined history, and document them all and treat them all differently.