Please do me a favor and define your following assumptions: 'reasonable security' 'this service' (the one you offer 'for free') -- my own assumption is that you don't offer the service of verifying community membership for web-based communities that don't offer email accounts.
'how these providers operate': I'd point you to the "internet PKI rethought" document that I had up, but I've since cancelled my .Mac account -- but the basic idea is that if someone uses a community, they already trust (and have to trust) the administration of the community to properly arbitrate the identities within that community -- and only within that community. and my definition of "community", as far as I have always used it: Any group of people who use a common service, within which service individuals can be uniquely referenced. Services like 'fanfiction.net'. Services like 'slashdot.org'. Services like 'everything2.com'. Services like MUDs. Services like Second Life. All of these are communities which, because they do not deal with "real-world identities" in any way that you can define or reference in your certification policies (they don't use real-world names, and they don't offer email addresses), are unable to use the services that you (and other CAs) offer "for free". These services are the masters of their own domains -- they are the absolute arbiters of identity within themselves. This means that they are Authorities. Your argument removes their ability to Certify those identities for use between people inside those spheres. (Think of them like company-internal root CAs, only instead of having a legal construct of a company or corporation, it's a loose social construct of association.) This is why I wanted to be able to change the chrome to say "hey, Mozilla hasn't vetted this CA, we recommend you don't put in your credit card number or any private details". This is why I want to be able to use those certificates as, for example, iChat/AIM encryption certificates. This is why I want to expand the OTR IM-encryption protocol to use certificates as a means of authenticating the remote party, without disturbing its other aspects. Thawte's the ONLY provider I know of that even considered adding community membership information to its certificates, but it never considered removing the real-world identity information that it had obtained -- basically, it wanted to bind additional identities to the real-world identity. As a privacy advocate, I do have a problem with this approach. (Really, who on earth would want to have their real name associated with a World of Warcraft character named "Kissybear of the Black Iron Realm"? Yes, Blizzard knows who the account belongs to, and Blizzard can respond to legal queries... but I know I wouldn't want my real name associated with such a charactername, for all the world to see everywhere I posted my certificate, if I wasn't doing anything illegal and thus subject to discovery.) -Kyle H On Tue, Mar 24, 2009 at 2:56 PM, Eddy Nigg <eddy_n...@startcom.org> wrote: > On 03/24/2009 10:21 PM, Kyle Hamilton: >> >> 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. >> > > What's that? You mean scan for email addresses at large, right? That's > nothing new, but look, as a subscriber one has obligations and depending on > the CA it requires a certain commitment. We haven't heard other CAs in > regards to this idea, but there is more than just the email address and > spam. > > Additionally there are email addresses one might own which are nowhere > published. I'm certain you are a privacy advocate, at least so much that it > would bother you to have those emails in the hands of a party you don't > like. > >> 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." >> > > OK, sounds interesting and I'm certain if this idea takes of we can figure > out acceptable procedures. > >>> 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. > > There is perhaps situation where those aren't necessarily compatible with > each other. We can certainly have discussion on this issue, preferable in a > different thread since it wouldn't be helpful for this idea and distract. > But of course we need to define the principals which guide us first and > which would receive the most support by all parties involved (crucial IMO). > > As such the Mozilla CA Policy is clear in this respect and this is what > Mozilla decided long time ago. Additionally Mozilla is the most flexible > software vendor in this regard I don't feel like Mozilla needs to compromise > any further on this issue. Neither do I believe we should promote anything > else. You can't have security and require from CAs to do the audit dance and > then throw it out the backdoor as if it doesn't exist. Either this or that, > but not both. > >> 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? >> > > That's only partly true...but I don't see the reason to support something we > don't believe in. Which means, that there are enough CAs offering this > service for free, we don't NEED alternatives. It would be perhaps a > different argument if there weren't any CAs. > > Now, if you believe in reasonable security which I'm sure is very important > to you and most members here, we want to know about how those providers > operate. In this particular space of cryptography and online security it's > not a privilege, it's a must. Except if you prefer to forgo reasonable > security at which point I'd rather not support it... > > Also, it's not entirely clear where the "community" comes in here. Which > community? Mozilla's? > >> For Class 1 certificates, there are very few details that would need >> to be worked out. >> > > This is up to the CAs to decide, I believe. Perhaps we could work out > something which seems to be reasonable. And CAs would have to decide if this > is acceptable to them or not. > >> 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. >> > > I think this is beyond the scope of the current idea. > > -- > Regards > > Signer: Eddy Nigg, StartCom Ltd. > Jabber: start...@startcom.org > Blog: https://blog.startcom.org > > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
