Ben Bucksch wrote:
IETF...people are actually working on protocols to make that determination
Do you know any protocol names offhand?
I can't recall the acronym name. I haven't resubscribed to ietf-pkix yet. The list is very high traffic. But you can search the archives. I believe Verisign and Microsoft had something to do with it.
To give you a concrete example, when I worked at Netscape I had a cert with my business e-mail address from the corporate CA. I also had a second cert with my business e-mail address from Thawte. I used the former to login to internal corporate sites with client auth, and the later in my signed e-mails.
That would be fine, as each party would know you only by one cert, ever.
It gets critical when you *change* the cert towards one party. E.g. you wrote an email to me yesterday with the AOL cert, but today using the Thawte cert. I *should* get a bold warning from Mozilla about that, just like SSH does.
SSH doesn't use cert. Your analogy does not apply.
NSS/Mozilla does memorize (cache) the certificates of e-mail recipients.
So we can technically find out if there are existing certificates for the same person. But we can't say any of the certificates is better than the other, because they are all good.
I'd have to re-validate you, which is hard and people wouldn't do in practice, unless there's an automatic way to do it, e.g. by you sending the new cert to all your contacts, that mail signed with the old cert, and the client automatically detects that and chains the 2
You are thinking of re-validation outside of the PKI model.
In the PKI model, there is an automatic way of verifying the certificates, and that's done through the chain of trust. Since no one certificate is more valid than any other, there is obviously no mechanism for passing around which certificate is the most correct. Each program can choose to use any of the valid certificates.
Speaking for NSS/Mozilla, we choose the most recent one, so that if you renew your cert with a different CA, that one will automaticaly be used over your old one.
For e-mail, things were different. ... Unless they specifically checked the certs in my valid e-mail signatures, my correspondents could not tell which cert I was using.
That's exactly the security problem. If I can coerce any root CA to give me a cert for your email address, you lost.
Yes. And if you can do that, then that root CA needs to be revoked, which is done by removing it from the mozilla trust db.
If this is reported and happens repeatedly, that root CA should lose its webtrust CA seal, so we should drop it from Mozilla. That relates to the policy.
However, most root CAs don't typically issue end-user certs, but only intermediate CA certs, which will in turn sign the e-mail certs for users. For those intermediate CA certs, other revocation mechanisms are available - OCSP and CRLs - which are much easier to deploy and don't involve upgrading your browser to remove a root, or explicitly disabling trust on a root.
Actually, that probably wouldn't even be that hard, I don't need to be a government for that, I'd only need to be able to listen to (and maybe intercept) your mailbox (that's exactly the problem that crypto tries to solve, right?), in that case I could apply for a Class 1 certificate (only validates email mailbox) from any CA, catch and respond to the verification mail to your mailbox, and then use that new certificate to pose as you in email towards your correspondants. Given what you said, they wouldn't notice the certificate change, answer me encrypted with the new key, I would catch the email from your mailbox again, decrypt it using my fake cert and be done. Attack successful.
Correct, that would be a successful attack, and nothing can stop it today.
Note that this attack depends on the fact that the verification of your identity by the CA is done through an insecure channel, ie. SMTP . If you could ensure that SMTP/SSL and was used all the way between your mailbox and the CA, nobody could snoop on it. You could then download your mail from your POP/SSL or IMAP/SSL mailbox account. This attack exists because PKI is not fully implemented.
Unfortunately, most e-mail goes through gateways which don't use SMTP over SSL, so in practice, cert enrollments through e-mail aren't secure.
I don't know if there is an RFC that proposes to enforce SMTP/SSL on the Internet for e-mail transports. That would be a very good thing. There probably is. I suspect it will be adopted, and RFC822 dropped, long after IPv6 gets popular :-(
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
