Hadmut Danisch <hadmut(_at_)danisch(_dot_)de> wrote:
- This is based on cryptography. This means it has to cope with
secret keys. We do not have the hardware to keep secret
keys secret.
The keys don't have to be that secret if they can change
periodically.
The same people who wrote this software would immediately
start to write routines to collect the keys to generate
false records.
How?
You would need to have a highly protected issuer of such
records. Do you thing thats practical and feasible?
People already control access to their MTA's. I don't see this as
much of a problem.
- If you, on the other hand, give every sender or domain owner
a key to generate the record himself, why to bother with this
at all? Why not simply signing the message itself?
The message is not the SMTP transation.
Putting the policy exchange into the SMTP transaction is
semantically similar to using STARTTLS with a client certificate
signed by a CA, and then supplying the policy in-line in the TLS
tunnel. All of the key exchange issues devolve to getting the key for
a root CA, and using it to verify another certificate.
The difficulty with that approach is the repudiation of certificates
is hard. There's no easy way to distribute certificate revocations,
unlike putting ephemeral keys into DNS, where they can expire as
quickly as you want.
Alan DeKok.