On 5/22/2011 10:43 AM, John R. Levine wrote:
VBR queries are about an actor, not a message.
Certs can be coupled to a particular message -- this was an interesting
semantic distinction about Goodmail's certification scheme -- although I
believe that typically they, too, are only scoped to the actor, not the
specific content.
Now I'm really confused. If the third party knows enough about each
message to decide whether to provide the cert, why don't they just add
their own DKIM signature?
(Note that you are the one who introduced the construct of certifying a
message.)
In any event, there always needs to have an independent means of authenticating
that a statement by a third party really is by them, whether it is through
querying a portion of the DNS they own or by using their domain name to verify
something in a message. So they probably /will/ add their own DKIM signature.
But that's quite different from adding a signature with the domain of the
organization producing the message, since this latter is the subject of the
reputation/certification. (One could design this to remove the need for the
latter signature, even while still including their domain name, I suppose.)
The bottom line to this sort of exchange is that it seems pretty clear that as
a
community we are not clear about concepts or details for this topic. That one
or another person thinks one or another issue has an obvious answer is turning
out to be a poor indicator of actual community understanding or agreement.
As an impressive example of even deeper misunderstanding:
On 5/22/2011 10:49 AM, Michael Thomas wrote:
On 05/22/2011 10:27 AM, John R. Levine wrote:
It occurs to me that since mail certification is likely to make assertions
about behavior as well as identity, the SSL model in which certs last for
a year won't work, since behavior can change rapidly. Either the
certifier has to issue a stream of short-term certs to everyone it
certifies, or the verifiers have to check CRLs, which is tedious. By the
time you do all that, a DNS check, even one with DNSSEC, looks pretty
attractive.
But this is exactly what DKIM is. You prove yourself fsvo "prove"
to the registrar who "certifies" you by virtue of placing your NS
records in the root servers instead of issuing a cert. Nothing
different in *essence* to x.509 certs.
DKIM has almost literally nothing to do with proofs made to a DNS registrar.
For example, it says nothing about the relationship between a domain name and a
brand or company name.
DKIM merely says that who ever owns use of a domain name is asserting "some"
responsibility for the signed message.
In extremely abstract terms, a DKIM signature relates to a reasonably constant
construct that one might call an "identity" but it does not label the identity,
except with the domain name.
More importantly, there are none of the claims, assertions or endorsements that
go along with Certs, except for the mild one noted above.
One would have expected a former author of the spec who so-often proclaims
their
expertise to understand the semantics of DKIM better. On the other hand, it
does nicely show that implementing code doesn't mean understanding what it is
for...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html