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:[EMAIL PROTECTED] > Sent: Thursday, 13 March 2003 10:18 > To: Matt Crawford > Cc: Keith Moore; [EMAIL PROTECTED] > Subject: Re: IAB policy on anti-spam mechanisms? > > > "Matt Crawford" <[EMAIL PROTECTED]> 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.
