Subject: [ietf-dkim] NEW ISSUE: Signature semantics

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 09:23:03 -0800

> 6. Signature Semantics
> 
> DKIM was devised to provide a means of declaring an (organization's) identity
> that is taking "responsibility" for placing a message into the transit stream.
> This is a very constrained semantic for the signature, and really pertains to
> no more than a delivery decision.
> 
> In reviewing the apparent semantics of full SSP use, I believe it seeks to
> move a DKIM signature, which uses the same domain name as is in the From
> field, into the realm of declaring content to be valid.  This is a much more
> demanding semantic and, I believe, moves the DKIM/SSP service into direct
> competition with S/MIME and PGP.  At best, this seems entirely ill-advised.
> At the least, it is considerably more ambitious than the initial functions
> discussed for SSP.  For an initial version of a standard, more ambitious means
> more risky. 

To the extent that the above is not sufficiently clear:

      As discussion on the mailing list this past week has made clear, there 
is continuing working group disparity about the semantics of using DKIM, with 
or without SSP.  The use of SSP's handling options clearly moves things into 
statements about message content.  This exceeds the semantics for which DKIM 
was designed.  See, for example:

    <http://mipassoc.org/pipermail/ietf-dkim/2007q4/008136.html>

Before SSP can be stabilized the working group must reach consensus on basic 
issues of semantics for the mechanism.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jon Callas <[email-masked]>
Date: Tue, 11 Dec 2007 18:45:43 -0800

On Dec 9, 2007, at 9:23 AM, Dave Crocker wrote:

>      As discussion on the mailing list this past week has made  
> clear, there is continuing working group disparity about the  
> semantics of using DKIM, with or without SSP.  The use of SSP's  
> handling options clearly moves things into statements about message  
> content.  This exceeds the semantics for which DKIM was designed.   
> See, for example:
>
> Before SSP can be stabilized the working group must reach consensus  
> on basic issues of semantics for the mechanism.
>

Since I'm being quoted, I'm not sure if I should give a quick comment  
or not. I don't believe that DKIM/SSP can come into competition with  
OpenPGP or S/MIME, even if that became an explicit goal.

The issue is mandatory end-user identification with i=. Now, Jim  
Fenton called me on the phone after that, and explained that there  
are some uses (like using g= for delegation) of i= where the signer  
is not at liberty to put anything they want there. I'm not concerned  
with that. I'm also not saying that an administrative domain *cannot*  
essentially have one key per user. My objection is with any language  
that dictates in the general case what the signer *must* put there,  
so that the receiver can depend on it.

	Jon

---

From: John Levine <[email-masked]>
Date: 12 Dec 2007 03:23:35 -0000

>The issue is mandatory end-user identification with i=.

To make it more concrete, can we take this as a proposal to
change section 2.8 to remove references to the local-part?

  An "Originator Signature" is any Valid Signature where the domain of
  the signing address (the domain of the "i=" tag if present,
  otherwise its default, the value of the "d=" tag) matches the domain
  of the Originator Address.  The domains are matched using the usual
  rule, a case-insensitive ASCII comparison.

I'm all in favor of this for a variety of reasons.  Existing RFCs have
carefully avoided saying anything about local-parts, and in particular
whether two addresses are the "same".  RFC 2821 notes that unlike
everything else in SMTP, you can't even assume that local-parts are
case insensitive so [email-masked] and [email-masked] may be different.
Or they may not.

I sympathize with senders' desire to do DKIM key management, but my
sympathy does not go so far as to require recipients to help them do
it.

R's,
John

---

From: Jon Callas <[email-masked]>
Date: Tue, 11 Dec 2007 22:15:50 -0800

> change section 2.8 to remove references to the local-part?

Yes, thank you for being better at being concrete than me.

	Jon

---

From: Jim Fenton <[email-masked]>
Date: Tue, 11 Dec 2007 23:31:11 -0800

Dave Crocker wrote:
>      As discussion on the mailing list this past week has made clear,
> there is continuing working group disparity about the semantics of
> using DKIM, with or without SSP.  The use of SSP's handling options
> clearly moves things into statements about message content.  This
> exceeds the semantics for which DKIM was designed.  See, for example:
>
> Before SSP can be stabilized the working group must reach consensus on
> basic issues of semantics for the mechanism.
>
>

SSP does require one additional semantic over that of DKIM-base:  in
addition to taking responsibility for the message, those domains that
publish SSP records other than "unknown" must assert that, when the
address in the From: header field is really their domain, that this is
actually true.  Whether this assertion extends to the local-part of the
address is the subject of another issue (1399) so let's discuss that
part separately.

In other words, those publishing SSP records must make sure that they
don't sign spoofed messages claiming to come from their own domain. 
Aside from that, no assertion is made regarding the content.  As I have
frequently said, I would not want a DKIM signature to authorize a
transfer from my bank account.

This new semantic only applies to those who deploy (publish) SSP records
and therefore does not extend to DKIM-base (and therefore does not
require a modification to 4871).  This semantic is not currently
described in the SSP draft, and needs to be in my opinion.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Dec 2007 11:03:02 +0000

Hi Jim,

Jim Fenton wrote:
> actually true.  

That statement isn't very clear to me.

Do you mean: When a domain publishes an SSP != unknown, then it
states that it does not emit messages where the rfc2822.from
domain is outside its own domain?

If so:

- "emit" and "outside" would need defining
- should that be "messages" or "signed messages"

If not, I'm confused.

Regards,
Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 12 Dec 2007 07:21:20 -0800

On Dec 11, 2007, at 11:31 PM, Jim Fenton wrote:

> addition to taking responsibility for the message, those domains  
> that publish SSP records other than "unknown" must assert that, when  
> the address in the From: header field is really their domain, that  
> this is actually true.  Whether this assertion extends to the local- 
> part of the address is the subject of another issue (1399) so let's  
> discuss that part separately.

Jim,

What can be safely deduced when a signature is not "on-behalf-of" a  
particular header's email-address?

The "all" assertion offers no assurance a signature is "on-behalf-of"  
of any header.  The "all" assertion does not require the "originator  
signature" (soon "author's signature").  The "all" simply indicates  
_all_ messages from the domain are signed by _some_ domain.  Such an  
assertion makes no assurance that identities related to email- 
addresses contained within signed messages have been authenticated.   
Such an assertion of authentication of identities related to email- 
addresses goes well beyond DKIM WG's charter!

> In other words, those publishing SSP records must make sure that  
> they don't sign spoofed messages claiming to come from their own  
> domain.  Aside from that, no assertion is made regarding the  
> content.  As I have frequently said, I would not want a DKIM  
> signature to authorize a transfer from my bank account.

Your bank _MUST NOT_ assume identities associated with email-addresses  
contained within DKIM signed messages have been authenticated!  Use of  
DKIM may mean when there is a problem, those causing problems lose  
access.  Review DKIM WG's charter regarding strong external assurances  
of identities related to email-addresses.

> This new semantic only applies to those who deploy (publish) SSP  
> records and therefore does not extend to DKIM-base (and therefore  
> does not require a modification to 4871).  This semantic is not  
> currently described in the SSP draft, and needs to be in my opinion.

I do not agree.  A DKIM signature ONLY means the message was handled  
by the domain adding the signature.  Not even "strict" (should)  
require a domain's signature be "on-behalf-of" the From header.  A  
"strict" assertion likely needs an exception for restricted keys where  
the i= parameter must be "on-behalf-of" the From header.  (Per user  
keys will likely prove to be a mistake.)  When a domain makes an SSP  
"strict" assertion, a message with a From email-address containing  
this domain should only require signature by this domain (or a parent  
of) regardless of which or whether any "on-behalf-of" header can be  
determined.

How domain's making "strict" assertions avoid the spoofing of email- 
addresses within their domain is an internal matter for that domain.   
While such a problem is a concern, SSP does not dictate how this is  
resolved.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 12 Dec 2007 08:52:38 -0800

> - should that be "messages" or "signed messages"

The answer is "no" so let me try again.

Suppose example.com publishes SSP "all".  It signs a message with
resulting header fields:

From: Jim Fenton <[email-masked]>
DKIM-Signature: ...i=@example.com;...

No additional assertion regarding the From: address is made in this
case.  example.com is just taking responsibility for the message; it
might be doing so because it operates a mailing list or because it
allows subscribers to mail articles from "The Example Times" to their
friends.

Now suppose it signs a message with resulting header fields:

From: John Doe <[email-masked]>
DKIM-Signature: ...i=@example.com;...

In this case, the signer must make an assertion that the message indeed
originates from their domain, because a verifier using SSP depends on
the ability to correlate the From: address to the signing address.

We are depending on an assertion regarding the From: address when it
should be easy to provide:  when that address is the same as that of the
signer, and not when it's difficult:  when that address is something else.

Again, I am not considering the issue of whether the address comparison
includes the local-part, because that's being covered under issue #1399.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Dec 2007 17:28:06 +0000

> signer, and not when it's difficult:  when that address is something else.

Thanks for the clarification.

So the upshot of that would be that turning on SSP "all" might
require someone to do additional checks that they're not a relay
when they oughtn't be. Sounds reasonable but I don't know enough
about mail deployments to be sure myself.

A follow-up though. In the case you gave, let's assume
that example.com's "The Example Times" web form doesn't have
a captcha, so that an ad bot could ask to send a newsletter
from <<foo>>@example.com via the form. Would that be something
compliant with the SSP? (Continuing to ignore the specific
value of <<foo>>)

Ta,
S.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 12 Dec 2007 09:42:46 -0800

> compliant with the SSP? (Continuing to ignore the specific

If their web form didn't block the use of example.com as a From address,
the message would be non-Suspicious (I think that's what you mean by
"compliant" in this context), which would violate the likely intent of
the publication of SSP "all".  They could deal with this in several ways:

- Prohibit example.com from being used in the web form
- Sign using a different domain or a subdomain, e.g.,
i=@articles.example.com
- If comparison of the local-part of the address continues in the draft,
sign with a specific address, e.g., i=[email-masked], and have the
web form prohibit that specific address

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 12 Dec 2007 12:29:58 -0800

On Dec 12, 2007, at 9:42 AM, Jim Fenton wrote:

> If their web form didn't block the use of example.com as a From  
> address, the message would be non-Suspicious (I think that's what  
> you mean by "compliant" in this context), which would violate the  
> likely intent of the publication of SSP "all".  They could deal with  
> this in several ways:
>

In this case, "articles.example.com" will obscure which header the  
signature had been added "on-behalf-of".  If the signing domain was  
also "articles.example.com", this would be a third-party signature and  
might make the message somewhat questionable.  Mailing-list may sign  
"on-behalf-of" the List-ID header, where any email-address might be  
allowed in the From header (common for many mailing lists).  The  
mailing-list may wish to exclude the list-id email-address from being  
allowed within the From header to prevent confusion as to which header  
the message was signed "on-behalf-of".  The domain may not care  
whether an ambiguous "on-behalf-of" causes confusion.  The email- 
address could be that of some innocuous role that is never used for  
other messages, where the Subject line also clearly indicates that the  
message is from a list.

> - If comparison of the local-part of the address continues in the  
> draft, sign with a specific address, e.g., i=[email-masked],  
> and have the web form prohibit that specific address

A domain can be completely compliant with an "all" assertion _without_  
prohibiting specific email-address from being signed!  A mailing-list  
is often unable to authenticate identities, even those signed by  
DKIM!  DKIM is _prohibited_ in the charter from asserting identities,  
nor would identity authentication represent a safe assumption.   
Defaults allowed for the i= parameter permits an "on-behalf-of" header  
to remain ambiguous.  While some domains may wish to prevent intra- 
domain spoofing by employing email-address constraints, such  
constraints are not typically, nor is this defined for use with DKIM.

When a message contains a header where the From contains an email- 
address within the signing domain, acceptance depends upon internal  
signing domain policies.  The "all" assertion DOES NOT imply an  
identity associated with an email-addresses has been authenticated!   
Such an assertion violates DKIM's charter, where DKIM is not  
sufficiently suited for such use.  DKIM lacks a means to distribute  
per-user keys, lacks any mandate regarding identity authentication,  
mechanisms to restrict email-address use, etc.   Procedures and  
policies to restrict the use of email-addresses, and whether messages  
are permitted to include From headers containing other email-addresses  
within the domain is completely a matter of internal policy.  This  
internal policy has nothing to do with an "all" assertion.  The "all"  
assertion only indicates to receivers, they can expect all messages  
originating from this domain to have been signed.

Ensuring who can use an email-address is an entirely different problem  
unrelated to "all" or "strict" policy assertions.  Attempting to  
extend DKIM in this manner appears to violate the charter as well.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 12 Dec 2007 23:48:51 +0100

Douglas Otis wrote:

> The mailing-list may wish to exclude the list-id email-address
> from being allowed within the From header to prevent confusion
> as to which header the message was signed "on-behalf-of".

A syntactically valid List-ID doesn't have the form of an email
address or Message-Id, no "@".  

> While some domains may wish to prevent intra-domain spoofing
> by employing email-address constraints, such constraints are
> not typically, nor is this defined for use with DKIM.

RFC 4409 6.1 and 8.1 won't help with "first author" constructs,
and 8.1 arguably does not yet support PRA.  But it's not an
untypical request, compare op=auth for SPF proposed by Scott.

> The "all" assertion DOES NOT imply an identity associated 
> with an email-addresses has been authenticated!

It implies whatever the SSP spec. says.  If it says something
in the direction of op=auth it has to state what signers are
supposed to do to enforce it.  

> sufficiently suited for such use.

It mentions the issue as out of scope, yes, but I'm not sure
if that also limits what an SSP can state.  IMO intra-domain
spoofing isn't an interesting problem, but if an MSA offers
its sending and signing services to more than one domain then
excluding "cross-user forgery" between them is relevant.

RFC 4409 has options for SPF (6.1) and a part of PRA (8.1).
Or is that beside the point ?  Actually a service provider
offering sending and signing for more than one domain has to
do something about "cross-user forgery" for DKIM, no matter
what SSP specifies.

> The "all" assertion only indicates to receivers, they can 
> expect all messages originating from this domain to have 
> been signed.

Kind of tough if they get a message signed by the MSA, but
actually submitted by another domain (ab)using this MSA :-(
 
 Frank

---

From: Hector Santos <[email-masked]>
Date: Wed, 12 Dec 2007 17:56:40 -0500

Doug,

I would like to know one thing:

    When does a signer expect when his signature to be broken?

or

    When is it reasonable for a signer to believe his signature
    can be broken? and if so, what does he expects to happen?

I mean, after all, this is all about mail integrity and an attempt at 
non-repudiation.  It gets to a point where if a domain is going to begin 
to digitally sign its mail, then there is a reasonable expectation that 
it will be non-repudiated.

By definition, non-repudiation occurs when all participants agree that 
something is true.

So given our current email infrastructure what steps are taken to ensure 
full or partial non-repudiation?

There has to be some statements of facts, and in my opinion, a domain 
signing his mail under a set of conditions he holds to be true, can only 
non-repudiated if the receiver can hold him to these expected true 
conditions.

If the domain says "I'm the exclusive signer," than nothing should 
repudiate that true condition of exclusivity.

If the domain expects a different set of relaxed conditions that can be 
repudiated, then he really shouldn't be signing his mail or have his 
signed by others and still expect verifiers to waste its time with it 
trying to reach an impossible state of non-repudiation.

It can't be both ways Doug. Something is got to give here.

-- 
Hector Santos, CTO
http://www.santronics.com

Douglas Otis wrote:
>> address, the message would be non-Suspicious (I think that's what you 
>> mean by "compliant" in this context), which would violate the likely 
>> intent of the publication of SSP "all".  They could deal with this in 
>> several ways:
>>
> signature had been added "on-behalf-of".  If the signing domain was also 
> "articles.example.com", this would be a third-party signature and might 
> make the message somewhat questionable.  Mailing-list may sign 
> the message was signed "on-behalf-of".  The domain may not care whether 
> an ambiguous "on-behalf-of" causes confusion.  The email-address could 
> be that of some innocuous role that is never used for other messages, 
> where the Subject line also clearly indicates that the message is from a 
> list.
> 
>> draft, sign with a specific address, e.g., i=[email-masked], and 
>> have the web form prohibit that specific address
> 
> 
> prohibiting specific email-address from being signed!  A mailing-list is 
> often unable to authenticate identities, even those signed by DKIM!  
> DKIM is _prohibited_ in the charter from asserting identities, nor would 
> identity authentication represent a safe assumption.  Defaults allowed 
> for the i= parameter permits an "on-behalf-of" header to remain 
> ambiguous.  While some domains may wish to prevent intra-domain spoofing 
> by employing email-address constraints, such constraints are not 
> typically, nor is this defined for use with DKIM.
> 
> When a message contains a header where the From contains an 
> email-address within the signing domain, acceptance depends upon 
> internal signing domain policies.  The "all" assertion DOES NOT imply an 
> mechanisms to restrict email-address use, etc.   Procedures and policies 
> to restrict the use of email-addresses, and whether messages are 
> permitted to include From headers containing other email-addresses 
> unrelated to "all" or "strict" policy assertions.  Attempting to extend 
> DKIM in this manner appears to violate the charter as well.
> 
> -Doug
> 
> 
> 
> NOTE WELL: This list operates according 
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
> 
>

---

From: Douglas Otis <[email-masked]>
Date: Wed, 12 Dec 2007 18:24:37 -0800

On Dec 12, 2007, at 2:48 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
>> The mailing-list may wish to exclude the list-id email-address from  
>> being allowed within the From header to prevent confusion as to  
>> which header the message was signed "on-behalf-of".
>

Agreed.  Nevertheless, i=<list-id>@<d=domain> could still be used.  A  
valid signature does not need to match local-parts with the i=  
parameter.  Only the domain component must be at or within the signing  
domain.

>> While some domains may wish to prevent intra-domain spoofing by  
>> employing email-address constraints, such constraints are not  
>> typical, nor is this defined for use with DKIM.
>
> RFC 4409 6.1 and 8.1 won't help with "first author" constructs, and  
> 8.1 arguably does not yet support PRA.  But it's not an untypical  
> request, compare op=auth for SPF proposed by Scott.

DKIM's concept of "on-behalf-of" may offer an advantage when extending  
the MAILFROM email-address to other headers.  The WG should ensure  
nothing interferes with "on-behalf-of" semantics.  Current SSP  
definitions impose an unwarranted constraint on the i= parameter when  
"strict" is asserted.  Currently the From header MUST BE indicated as  
being signed "on-behalf-of".  This is wrong.  Just the domain of the  
 From email-address MUST BE within the domain of the d= parameter.   
The only exception should be for g= restricted keys.

>> The "all" assertion DOES NOT imply an identity associated with an  
>> email-addresses has been authenticated!
>
> It implies whatever the SSP spec. says.  If it says something in the  
> direction of op=auth it has to state what signers are supposed to do  
> to enforce it.

The SSP specification could indicate identities associated with email- 
addresses signed "on-behalf-of" MUST BE authenticated.  Neither SSP  
nor the DKIM base says this anywhere.  Nor is this level of  
authentication normally supported.

> It mentions the issue as out of scope, yes, but I'm not sure if that  
> also limits what an SSP can state.

DKIM can not safely offer strong identifiers without extensive, and  
currently non-existent, specifications.  Perhaps at some point an  
assertion could be defined that specifically indicates what has been  
authenticated and how.  For now, a temporal opaque identifier seems  
less problematic from both a privacy and system compatibility  
perspective.

> IMO intra-domain spoofing isn't an interesting problem, but if an  
> MSA offers its sending and signing services to more than one domain  
> then excluding "cross-user forgery" between them is relevant.

A mailing list should be able to assert "strict" and sign any email- 
address in the From header with an email-address from any other  
domain.  Only domains submitting messages to this list might indicate  
this is a problem with their "strict" assertion.  This issue can be  
resolved using TPA-SSP assertions.  When a domain does not assert  
"strict", cross domain forgery can not be reliably detected.  Few  
issues should prevent a domain having trouble with cross-domain  
forgery from making this assertion.  However, intra-domain forgery  
must be handled internally.

DKIM should not attempt to dictate that email-addresses must only be  
used by their valid owners.  That would be a matter for the signing  
domain to decide.  Lacking a means to assert this authentication is  
being done is a secondary issue.  When DKIM is considered unsuitable  
for providing strong identities, it then becomes important _not_ to be  
able to make an assertion that identities owning a particular email- 
address have been authenticated.

> RFC 4409 has options for SPF (6.1) and a part of PRA (8.1). Or is  
> that beside the point ?  Actually a service provider offering  
> sending and signing for more than one domain has to do something  
> about "cross-user forgery" for DKIM, no matter what SSP specifies.

The provider MUST use the correct signing domain.  The rest sorts  
itself (perhaps along with a check of foreign domain's SSP records).

The TPA-SSP permits a similar MailFrom assertion without using an IP  
address list.

>> The "all" assertion only indicates to receivers, they can expect  
>> all messages originating from this domain to have been signed.
>
> Kind of tough if they get a message signed by the MSA, but actually  
> submitted by another domain (ab)using this MSA.  :-(

The verifier must make an exception for third-party signatures.  Any  
third-party signatures found abusing other domains are likely to be  
dropped from such a list.  Reputation is likely where the correct  
practices become more important than meeting SSP specifications.   
Perhaps signers should check for "strict" assertions.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 13 Dec 2007 12:35:35 -0800

>  When does a signer expect when his signature to be broken?

When sending to a mailing list, would be one example. : )

>  can be broken? and if so, what does he expects to happen?

In the case of a "strict" assertion that "all messages are signed" is  
reasonable.  That verifiers MUST consider unsigned or broken  
signatures having a From email-address within their domain as  
"Suspicious" is not a meaningful assertion.

A domain can only assert what they DO, and not what others MUST THINK!

The "strict" assertion should be defined as "this domain signs all  
messages originating from this domain" AND "this domain avoids  
services that might damage DKIM signatures".  Then the domain is  
asserting what they DO, and not what the verifier MUST THINK.

> I mean, after all, this is all about mail integrity and an attempt  
> at non-repudiation.  It gets to a point where if a domain is going  
> to begin to digitally sign its mail, then there is a reasonable  
> expectation that it will be non-repudiated.

A valid DKIM signature ensures non-deniability or non-repudiation of  
having handled the message.  DKIM, by itself, makes no assertions  
regarding the validity of message content.

> By definition, non-repudiation occurs when all participants agree  
> that something is true.

A valid DKIM signature only means the signing domain has handled the  
message.  What do you think it means?

> So given our current email infrastructure what steps are taken to  
> ensure full or partial non-repudiation?

Huh? Either the signature is valid or it is not.

> There has to be some statements of facts, and in my opinion, a  
> domain signing his mail under a set of conditions he holds to be  
> true, can only non-repudiated if the receiver can hold him to these  
> expected true conditions.

SSP records are not signed.  SSP records are published within DNS for  
a duration of seconds or years.  SSP can not offer non-deniability or  
non-repudiation.

> repudiate that true condition of exclusivity.

You appear to be confusing a concept of non-repudiation with fairly  
temporal operational assertion.

A domain may assert "this domain signs all messages" AND "this domain  
avoids services that might break signatures".   This assertion can not  
ensure all messages received containing a From header email-address  
within this domain are illegitimate or somehow in conflict with their  
assertion.  Dealing with email is _never_ that simple.  These  
assertions provide information that can be used to better evaluate  
message content.  These assertions should not be aimed at telling  
verifiers what to DO or what to THINK, especially when such actions or  
thoughts might be wrong!

> If the domain expects a different set of relaxed conditions that can  
> be repudiated, then he really shouldn't be signing his mail or have  
> his signed by others and still expect verifiers to waste its time  
> with it trying to reach an impossible state of non-repudiation.

Any valid DKIM signature offers non-repudiation.

> It can't be both ways Doug. Something is got to give here.

A DKIM signature does not ensure validity or conversely invalidity of  
message content.  Are you suggesting a domain signing a message with  
"all" assertions (that essentially implies "this domain signs all  
messages") must also authenticate identities associated with the "on- 
behalf-of" email-address?  In my view, authenticating identities  
associated with email-address goes beyond what MTAs are currently  
equipped to safely assure AND this WG's charter as well.

The only consideration a domain may wish to make might be to refuse  
message submissions containing From headers where the foreign domain  
has made a "strict" assertion.  While this could be about "reputation"  
when such act causes a domain to be removed from a list of acceptable  
third-party signers, this should be ignored in order to resolve other  
issues first.  Messages containing From headers with email-addresses  
of domains with "strict" assertions might cause acceptance problems.   
These exceptions may also involve a signing domain with possible acts  
of fraud.  What should DKIM be saying about a signers obligations  
regarding assurances of email-address ownership?

TPA-SSP provides a means for domains wishing to communicate with other  
domains asserting "strict" and avoid interruptions created by dogmatic  
policy handling.  TPA-SSP can scale to accommodate a sizeable list of  
domains which might become necessary to ensure uninterrupted  
communications.  In other words, without the TPA-SSP mechanism, a  
"strict" assertion _will_ create problems that are either impossible  
or unsafe to resolve using ad hoc key exchanges or DNS delegations.

-Doug

---

From: <[email-masked]>
Date: Thu, 13 Dec 2007 15:43:49 -0500

Wordy answer but +1 on what a dkim sig means 

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Thursday, December 13, 2007 3:36 PM
To: Hector Santos
Cc: ietf-dkim WG
Subject: Re: [ietf-dkim] Issue #1524: Signature semantics

-Doug

---

From: Hector Santos <[email-masked]>
Date: Thu, 13 Dec 2007 17:30:35 -0500

> Wordy answer but +1 on what a dkim sig means 

Besides the basic definition of a digital signature, to me, a DKIM means 
there is a new level of expectations of how mail should be viewed and 
handled.  It raises the bar to a new non-legacy level of mail transactions.

So if a DKIM participating domain is expecting verifiers to treat DKIM 
any differently than the rest, then it better do so in a Protocol 
Consistent, collaboration and consistent non-repudiation model or 
framework that is the basis of all digital signature technology.

Without a policy concept, DKIM-BASE has a high degree of implementation 
security and engineering concerns that can potentially make many systems 
vulnerable, including the domain that is attempting to use DKIM-BASE and 
those who are not participating in the DKIM-BASE model.

To assume DKIM-BASE must be tied to a reputation service for it to work 
is only going to make all the security and engineering concerns a reality.

My opinion, but I strongly believe it.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com