On 03/25/2009 12:35 AM, Kyle Hamilton:
'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.
Nope, and it's beyond the scope of what we do generally. So it doesn't rule out communities...
'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.
I don't understand how this is connected to the initial idea of finding some better ways to use client certificates for mail (was actually client certificate authentication IIRC). I think I lost you here...
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".
OK, so how are they relevant to this idea?
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.)
I have no problem with any of them as long as their usage and trust remains limited with their domain and internal activities.
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".
No, I don't want that. But that's for web sites anyway, not connected to mail I think...
...as such, Mozilla goes a step fuhrer and tells you correctly "hey, we can't know if you are connecting to the site you intend to connect to and we recommend not to connect to the site...it might be somebody different really".
This is why I want to be able to use those certificates as, for example, iChat/AIM encryption certificates.
What does prevent you from doing that? With and without CA issued 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.
Also here, I don't think that anything prevents you from doing so. But that's not the scope of the idea I found interesting.
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.
It's hard to serve two masters...either it's disclosed or anonymous. It could be even something like "we have validated those details, but ask him if he wants to show those details to you"...
-- 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
