On Mon, 10 Mar 2003 19:06:32 -0300, "Alejandro G. Belluscio"
<baldusi(_at_)uol(_dot_)com(_dot_)ar> said:
I know it's too early to send this kind of proposal, but please keep in
mind the idea that, if signature is required, use the existing business
relationships instead of making the Verisign mistake again.
And my business relationship to you is what, exactly?
This isn't a rhetorical question. There's only a few basic trust models:
1) Our respective cert authorities negotiate a private cross-cert
agreement. This works well for 2 businesses that want to verify each
other's signatures, but doesn't scale to the open internet.
2) a Verisign/X.509 model where somebody runs a central set of servers.
Nobody is going to do one of these that scales to Internet size for free
either (hint - what percent of domains have their own CA that can sign
certs for their users?)
3) A PGP web-of-trust model. Works great once both correspondents are in
the same web, but has some major bootstrapping issues...
The "Verisign mistake" happened because there aren't a lot of other things
that *could* have happened.
(lots of definitions skipped)
Objectives
-To have a certified sender in the sense of a legal entity .
-Keep the privacy of the sender and reciever when necesary.
-Minimize the cost of entity certification.
Reasonable goals..
Description
1. Each SMTP has to enable SMTP-AUTH. This enables the server uniquely
identify the Sending Account sending such mail.
Nice hand-waving. How do you ensure that the *REMOTE* end actually enforces
it? This isn't as easy as it looks - *my* mail systems may do SMTP AUTH,
and I may even pass a cookie to you so if there's a problem with one of
my users, you can give me the cookie and I'll hopefully know who to call
in and beat the snot out of them (which was the *original* purpose of
RFC1413 IDENT, incidentally).
Of course, a spamhaus already knows who's using their server, and has no
need of running SMTP AUTH to verify that they themselves are the ones
sending the mail....
2. Using that information the header is then added a signature using a
certificate of the SM plus a code that let's said SM to uniquely
identify the Sending Account. This code should be chosen so as to be non
desiptive of said account for a third party, even if he recieves
multiple emails.
Read RFC1413, section 6 (Security Considerations)
You're trusting the remote site to give you information.
4. (to discuss or optional) On a recieving SMTP if the email has a valid
signature path, it's signed by himself and given a code that let's the
SM uniquely identify the RA.
Signed how? and what makes this more trusted than the set of Received:
headers?
There's two cases to consider:
1) There exists a PKI. In this case, the sender just uses S/MIME or PGP
or whatever, and all the intermediaries need do *NOTHING*. This message is
PGP signed - if you want you can validate it via the PGP web-of-trust. And
my mail server, your mail server, and the IETF mail server need not get
involved at all. If I sign it with an X.509-style cert, the mail server
STILL doesn't have to get involved, because the cert chain on my signature
already identifies me.
2) There isn't a PKI. If so, then everybody is basically just using self-signed
certificates, which prove approximately nothing...
Note that doing crypto on a hop-by-hop basis will get *expensive* - the note
that I'm replying to had 8 Received: headers, and 15-20 is not at all
uncommon. By the 10th or 12th hop, that's a *LOT* of cert chains you have
to walk through to verify (and remember that *each* cert chain is going
to take a chunk of resources)....
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
pgpyGJsmRaVXY.pgp
Description: PGP signature