|
Re: [ietf-dkim] Issue #1524: Signature semantics
2007-12-12 16:02:40
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:
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:
- Prohibit example.com from being used in the web form
- Sign using a different domain or a subdomain, e.g.,
i=(_at_)articles(_dot_)example(_dot_)com
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=articles(_at_)example(_dot_)com, 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
_______________________________________________
NOTE WELL: This list operates according
tohttp://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|