On Tue, Mar 24, 2009 at 3:30 AM, Eddy Nigg <eddy_n...@startcom.org> wrote: > On 03/24/2009 06:24 AM, Kyle Hamilton: >>> >>> One thing I'm missing....where comes the email control validation in? >>> >> >> This is where you get to upsell your service. > > This is not something to up-sell, it's basic requirement for certificates I > think, otherwise there is no value with them. Up-selling would be > verification of the identity perhaps.
Remember this: A public key is an identity. It is an identity which is bound to the private key. A certificate is designed to strongly bind an external identity to the identity inherent within the public key. THIS is the reason CAs exist. >> Once a public key goes >> out, you can encrypt something specifically *to* it, and then only the >> private key holder can decrypt it. If they decrypt it and you send it >> only to that email address, you know that the holder of the private >> key can read from that mailbox. >> > > Ahhh, most likely this will never be part of a Mozilla product without the > validation. Ahhh, most likely this is because Mozilla's got far too much invested in The Old Way (and the old Assumptions). However, I detailed my suggestion for how this could be done below, and you started to sound cautiously optimistic about it. ]>> Why are you making the assumption that only a single email certificate >> is worthwhile or even desirable? (what if one of the roots is >> yanked?) Why do you even think that making a choice like this is >> something that will make the user happier? > > I don't. Make multiple request, who cares. Some choice is better than no choice. Too much choice is worse than no choice. (Especially choices that the user doesn't understand -- for for information, http://www.ted.com/index.php/talks/barry_schwartz_on_the_paradox_of_choice.html has a very good explanation.) >> Why not simultaneously >> send certification requests to all of the CAs that Tbird supports >> without having to have the user make a selection of which one? > > That would be a bad idea IMO. I don't want a certificate from XYZ CA nor do > I want them to know anything about me. I'm happy to use ZXY and YXZ CA > however. I'd make simply another request through the same UI... What would they know about you that couldn't be harvested from email lists? That you have a public key, and an email address that you use that public key with? >> Make some kind of automated certificate request protocol (this is the >> CAs' job to push through PKIX, by the way) to request class-1 >> validation of a given email address that Thunderbird has already >> verified that it can log into. > > That's not good enough since the CA must retain evidence about the > verification too. At least StartCom would not issue such a cert and refrain > from participating I guess. I said "to request class-1 validation" -- you call it "verification", but aside from the terminology I meant the same thing: you must verify/validate that a given private key can be used to decrypt something sent to the email address claimed. >> This way, you don't have to trust the >> email program, you only receive an email address and a public key, you >> send a specially-formatted message to the email address that >> Thunderbird can auto-parse, have it decrypt the thing with the private >> key, send another request with the same email address and the >> encrypted nonce, and have it deliver the certificate. > > Yes, this sounds better. We certainly could make those hooks easier and even > automate, agreed. I'd like to see support for such an idea and involvement > perhaps by Gerv and Johnath too. If it's going to be an agreed standard > procedure, allowing all interested CAs in NSS to participate I must say it > sounds interesting. I would very much like to see this standardized. I would prefer not to limit it only to the NSS-included CAs, instead allowing a specially-formatted link from any privately-run online community to enable a request to be sent to that privately-run community's certification system. (As I've said before: membership in a community is a type of identity all its own, and there's no reason that that identity should be given any less weight than any other. In this case, though, I'd want to allow for a logged-in user to request a certificate with his own credentials and a submitted public key, the server send back a challenge for proof-of-possession, and the client send back the decrypted challenge, and have the community issue the certificate immediately. In this case, there would not even need to be an email address associated with it -- whatever email address sends it or transfers it, it's guaranteed to have come from the community member, even if that community member sent it from an unmonitored mailbox.) Honestly, you could do this with StartSSL's system as it stands right now -- you verify email addresses for 30 days, and there's no reason you couldn't simply accept a key submission and request to link it to one of the verified email addresses, and issue the certificate on the spot. (In fact, you already practically do this, just with the manual CSR pasting system or keygen tag.) -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
