This describes two different semantics for a DKIM signature. Where
does the current DKIM specification provide for such distinction in
the semantics, so that it can be reliably and accurately interpreted
by a verifying agent?
I don't think it does. And I think this is a problem.
If that's true, there'd need to be a third semantic because a
domain level assertion from the originating domain is not
semantically the same as a "author" signature. But I
really don't think that DKIM provides "author" signatures
and I really don't see what that is an important goal;
SMIME or PGP seem a lot better suited for that.
Mumble...I think you are conflating two things - one of which is whether
content is signed or a transmission is signed; the other is whether
we can authenticate individual addresses rather than just domains.
Given that S/MIME and OpenPGP already exist, it seems to me that the
major justifications of DKIM are:
- it's supposedly easier to deploy than S/MIME or OpenPGP, due to its
method of encoding signatures and its method of looking up keys, and
- it provides an opportunity to do things that can't be done with S/MIME
or OpenPGP. e.g. authenticating transmissions, tolerating some
modification of the message in transit.
The tradeoff is that a DKIM signature provides less assurance than an
S/MIME or OpenPGP signature.
Keith
_______________________________________________
ietf-dkim mailing list
http://dkim.org