On Tue, Mar 24, 2009 at 12:56 PM, Eddy Nigg <eddy_n...@startcom.org> wrote: >> >> Remember this: A public key is an identity. It is an identity which >> is bound to the private key. > > Sure... > >> 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? >> > > So that I would receive even more up-sale spam that my private key isn't > secure anymore from CAs I don't care? No thanks! Neither would I like to > bother subscribers which didn't meant to receive and use a certificate from > StartCom in first place. I think this is a bad idea.
Hate to say it, but anyone who scans for smime.p7s files on the net can already do that. The cat's already out of the bag. Now, if you wanted to require a written contract signed by CAs that Thunderbird would support this capability with by default, which states that they will not spam, they will not allow anyone else to spam on their behalf, and they will aggressively pursue any spammers who violate that, I'm all for that. >> 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. > > Re-read about Class 1 validation and Mozilla minimum requirement for email / > client certificates. No CA is allowed to issue client certs for S/MIME > without performing an email ping or similar verification method. No CA *with a root included in NSS by default* is allowed to issue client certificates for S/MIME without performing an email ping or similar verification method. I'll reiterate what I said, with annotation: "You [the CA] must verify/validate that a given private key [which matches the submitted public key] can be used to decrypt something [which is encrypted with that public key] sent to the email address claimed [in the initial request]." I think this sounds like an "email ping or similar verification method." In fact, in this case, it's arguably more secure. The client requesting the certificate would be able to retrieve the specially-formatted email from the server and automatically act on it, thus minimizing the risk that it would be retrieved on another machine that doesn't have the private key in its local database. >> 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. > > I wouldn't like to promote the use of un-audited and perhaps insecure CAs, > sorry. Neither does it make sense to use them if the root doesn't exist - > and having the root imported via such a back-door of certificate > import/install utility isn't great either. I'd like to point out that you're (once again) raising the barrier to entry to the CA market, without providing any alternative for those online communities. Instead, you're insisting on relying on email addresses, which many community members don't want to make public (probably at least partially in fear of spam). Remember, I'm also all about the process of making sure that only people who explicitly trust a community trust what that community does, and I'm also all about the process of ensuring that the people who run the communities can do what they desire to do. Also remember, there is NO online community that suffers through an audit to be able to open its doors. There is NO online community that can guarantee 'security of accounts'. Yet, people join them all the time, while they don't bother joining CAs. I wonder why this is? (Hint: it's the community.) >> 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.) >> > > Yes, more or less this is correct, but I'm certain that the technical > details could be worked out. Different CAs would have different requirements > and we'd have to align and find a common ground between the ones which care > to participate and contribute to the discussion and standard. For Class 1 certificates, there are very few details that would need to be worked out. For Class 2 and Class 3 certificates, there are more details that would need to be worked out, but those are more related to authentication of credentials before the request is moved to the CA's processing queue. A challenge phrase or one-time-password could be issued by the entity performing the validation. (The US Patent and Trademark Office does it by sending a transaction ID number via postal mail, and a verification code via email to the address-of-record, only after a notarized jurat is physically mailed in. I honestly think the current batch of CAs are too paranoid in this regard; if the USPTO is willing to do something so high-risk with this system, I think that the rest of the world can fall in line.) -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
