On Fri, Mar 27, 2009 at 5:48 AM, Eddy Nigg <eddy_n...@startcom.org> wrote: > On 03/27/2009 02:16 PM, Kyle Hamilton: >> >> I'm also going to state, once more: your Assumptions (in this case, >> your Beliefs) are what are making this system NOT WORK. Your Beliefs >> are what are preventing people from wanting to participate. Sure, you >> set the rules, you set the UI... but nobody wants to play your game. > > I wouldn't say "nobody", it seems that there are maybe two camps. Those that > believe in our game and those that don't. Incidentally we are working on > something that allows for validated identities with disclosure being > optional at the discretion of the subscriber. But we aren't there yet.
I'm so glad to hear this. But there are other identities that can be validated, that can be proven, that you don't want to validate/verify. I don't mind so much that Mozilla insists on roots in its CA program to do things only with provable facts (including at a minimum the email address). I do mind that it makes it so damnably difficult to manage additional roots. (I've yet to get a softoken working with 1, 3, or even 7 roots of my own, cross-certifying the certificates in Mozilla's root store based on what I know and trust of them. Even if I did, I wouldn't be able to get a Growl popup of any notes that the certificate contains, including "verified on x date, need to recheck its CPS at y date" or "community certificate from the Canis Lupus Clan" or any kind of notation. I seem to recall there being an extension in certificates that may, but not must, be shown to the user of the certificate when it's being evaluated as part of a trust decision.) >> (Not to mention the link that Ian posted, about the US State >> Department issuing 4 valid passports to 4 fraudulent applications all >> made by the same man, which was made possible by having a little bit >> of information about 4 people who were -- fortunately -- not real. > > And fortunately I'm glad to inform you that he wouldn't have received a > verified certificate from StartCom. I'm not saying it's imposable with faked > passports to receive certification, however the hooks and jumps the > subscriber has to go through makes it rather difficult. Since there are > easier targets and easier ways to obtain such certification than through > StartCom, I believe that there are none and most likely never will be. *shrugs* So, you're saying that you're a better arbiter of identity than the government is. Too bad you're not authoritative. > Having said that, there are even arguments against face-to-face validations > and should never be the only source for reliable verification. The above > incident proves this. > >> THIS is why your concept of authentication fails -- because the >> policies that you are trying to impose are policies that are harmful >> to the people you're trying to impose them on! > > Don't mistake between questionable procedures and failures and the concept. I am not mistaking between questionable procedures and failures versus the concept. You are (quite deftly) ignoring the fact that the service you offer is incomplete, and that incompleteness (it only verifies one -- two, if you count email addresses as a separate type -- of identity) is that which scares people away from participating. (Not to mention the fact that you are putting one policy in place -- putting something inane in the CN field -- where there's an impedance mismatch with what the browser/UI is displaying -- where many different Subjects with the same CN show up as a single CN with no differentiation until you go into certificate details.) > The concept isn't failing and if correctly implemented shouldn't. Putting a non-legal name in the CN is absolutely NOT a correct implementation. That rightfully belongs in the "Organization" field, not the common name. > You must > be careful not to draw premature conclusion because of failures which aren't > related to digital certification. Ah, but at least one of these *is* related to digital certification. Another *is* related to a lack of digital certification. I'm not drawing a conclusion based on the US State Department's failure. I'm drawing a conclusion based on FIFTEEN YEARS AND LACK OF SIGNIFICANT CONSUMER MARKET PENETRATION. > Second, I'm certain that you wouldn't have > an alternative to offer - besides no validation at all. My alternative is simple: validate based on realm membership. (Oddly, this is the kind of validation that Kerberos has been offering for decades.) I could create my own realm, and validate your identity within it -- but my realm is only valid for me, and those who choose to participate in it. (If you sign up for my realm, you've made a conscious, affirmative decision to trust that your username within my realm is unique -- and any metadata that I may assign, including my belief of your name, corporate affiliation, country, etc, will be essentially useless to anyone who doesn't trust me, and by extension my signing identity.) In fact, I could take your public key from your certificate from StartCom and certify that. It wouldn't matter to anyone except me, and who trusted me. X.509's trust model is not antithetical to a web of trust. It just takes additional UI to do it -- UI which you and Nelson have fought fang and claw. I've already got several locations which use TLS to secure the server. They are unable, due to the types of service that they offer, to get "trusted" certificates. (MUD servers, actually, which by tradition do not use the legal name of the owner of the machine they run on.) These places want to use client certificates, but they have no idea how to do so -- and since I write the software, I maintain the software, and I haven't been able to get them to agree on a security policy, I can't write code to implement it. If you want to see an example of a thriving realm which exists outside the authentication space of what you're willing to certify, http://forums.xkcd.com/ . All of whose users use pseudonyms, yet within the pseudonymous realm each pseudonym is unique. (Oddly, under the rules you outlined, the pseudonyms in such an environment can be immediately and instantly validated to Class 2, upon verification of the email address associated, because the email address AND the pseudonym both can be identified and validated.) But, that doesn't matter to you. Your beliefs, your assumptions, your demands of the world at large and what it's willing to accept are more sacred and holy than the mitzvahtot contained in the Torah. -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
