The whole problem is that nobody sells certificates that can sign other
certificates.
If verisign gives a "signing" certificate to the ISP then the system works.
If we know who is the sender, then we can actively take action against him
outside the net in the real world. Like Caller ID phoning, they are pretty
reliable.
The most important thing, is that a certificate must be tied up to something
that gives me the contact (legal) of the person in real life (like a bank
account number, or credit card, or something else).
Franck Martin
-----Original Message-----
From: Eric Rescorla [mailto:ekr(_at_)rtfm(_dot_)com]
Sent: Thursday, 13 March 2003 10:18
To: Matt Crawford
Cc: Keith Moore; ietf(_at_)ietf(_dot_)org
Subject: Re: IAB policy on anti-spam mechanisms?
"Matt Crawford" <crawdad(_at_)fnal(_dot_)gov> writes:
Not clear. SMTP can relay a single copy of a message
to multiple
recipients at multiple domains. Your suggestion would force a
separate TLS session, or a separate SMTP session, for
every distinct
recipient domain.
Yes, that's true, but that's inherent in the "one certificate"
model.
Not quite inherent -- if you verify against a SubjectAltName dNSName
you can decide the certificate is valid for many domains.
Yes, this is true in theory, but I want to know how you're going
to get VeriSign to issue you a certificate with subjectAltNames
corresponding to a bunch of unrelated domains. And remember
that ever time the ISP gets a new customer they have to get a new
cert from VeriSign with yet another subjectAltName? This seems
impractical.