Hadmut Danisch wrote:
Keep the road warriors in mind. People keep critizing my RMX proposal
because they want to be able to send e-mail from virtually anywhere
with their mobile computers. You can't address this problem with a
relay-identity-only CA.
Actually, we can -- my original proposal at
<http://www.chaoszone.org/misc/spam.html> proposed using
digital-signature based non-repudiable relays *in addition to* what I
called DNSMX (==RMX) lookups: the RMX technique solves the problem for
the vast majority of considerate SMTP servers, while road warriors (of
whom I have to count myself as one -- this mail is reaching you via a
SMTP server on my laptop) could use the digital signature based
approach. Either way, relays are unambiguously identified.
It's actually just a different implementation
of the RMX approach to reduce the mail origins to a limited number
of authorized relays. It's just a different
authentication/authorization mechanism.
Indeed. The two complement each other quite well, I feel.
The second problem is that you will never get such a CA approach
sufficiently widely spread. What to do with countries which don't
allow cryptography? What to do with admins who don't understand
cryptography?
In my original proposal, to *send* email, there is *no cryptography*
involved -- you only need a static string that can be generated by a CA
for you (or you can generate it yourself).
To receive mail, no cryptography is required either. To verify a relay's
identity, a plug-in inside your MTA needs to verify a digital signature.
(Most countries allow digital signatures because law-enforcement is
typically very interested in non-repudiable messages.) However, if you
live in a country where verifying digital signatures is not permitted,
you can choose to not do this (and use RMX verification solely) or use a
web-service approach to get the signature verified in a country that
does allow signature-verification.
What about administrators who don't understand crypto? Because the work
of signature verification (or RMX verification) is likely to be done by
a plugin in an MTA (Spam-Assassin style), they usually would not have to
know the gory details.
What to do with stolen or lost key? You'll need a
revocation infrastructure, usually based on web or ldap servers.
Stolen/Lost/Compromised Keys can be revoked. Revocation checking can be
done as part of the standard key verification process. Key revocation is
possible in both RFC 2440 as well as X.509, so it is more of an
infrastructure issue. The revocation infrastructure could possibly be
managed by an entity like spamhaus or any responsible entity, perhaps
with an IETF charter and mandate.
--
Prasenjeet Dutta
http://www.chaoszone.org/
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg