Eddy... Remember. Most interactions on the Internet are not contracts. Most interactions on the Internet have no need of Real Names. Most interactions on the Internet have no need for this level of knowledge.
Policy must support the user and the user's needs. There are reasons why there's a "policy" field in certificates, since that field uniquely identifies the ruleset under which the identity was verified and certified by the signer. There's a reason why there's a policyMapping construct in root certificates. Your policies, for the certificates that your company issues, specifically try to verify to a certain legal standard. This is fine, this is good -- as far as it goes. BUT. Your insistence on never granting the ability for people to "make a mistake and sign something with a pseudonymous identity" means that you're hindering the growth of the market for your products. (Think about it: people come together and they want to transact, they want to barter. Most of the time they don't check identities since the contract for sale occurs right there... but on the Internet, to transact business, they need to know name and identity.) Instead of On Fri, Mar 27, 2009 at 8:53 AM, Eddy Nigg <eddy_n...@startcom.org> wrote: > On 03/27/2009 04:40 PM, Kyle Hamilton: >>> >>> 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. >> > > I have to cut this response short...but to answer the above, is quite > interesting, perhaps surprising, but certainly logical. As a CA we do > receive perhaps the passport and other identity documents, but we can't > solemnly rely on it. This means, a cross-verification with other sources and > verification of the source must happen, including and with interaction of > the subscriber. The passport and other ID docs only represent the claim made > by the subscriber, it's not the evidence for the successful validation. > That's why I explained that those four non-existent people would NOT have > received a verified certificate. except that in the US, once the passport is issued, that provides a legal framework to obtain state IDs. It also provides a legal framework to request copies of the actual birth certificate, etc. Once that key is pushed into the door, it's a lot less work to turn. >> Too bad you're not authoritative. > > We are, depending for which purpose. The only purpose for which you are authoritative is "issuing a certificate signed by you". You have certain rules that you follow, and your reputation relies on the concept of being "Honest Harry" (reference to an old Disney movie called "The Cat From Outer Space"). However, your reputation is the only thing that you are authoritative for. Everything else relies on other people accepting and believing your reputation. Everything else relies on you being Trent. Everything else relies on "trust". >> 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. > > So the common name would have to remain empty in this case which would lead > to approximately the same. Except that it would be a lot less messy. And it would have the added bonus of showing the certificate-relying software developers that "whoa, look at all these empty certificate names... we need a way to tell them apart" and adding E or something to the list of selectable/administerable columns. >> My alternative is simple: validate based on realm membership. > > But that's an entirely different context. Precisely. Once you're out of the legal context (and don't get me wrong, the legal context is huge, and has a lot of regulations), you don't need to worry about it. Once you're out of the legal context, you can start having fun. Once you're out of the legal context, you don't have to be uniquely identified as an individual snowflake in the universe -- you just need to be identifiable from every other fish in the pond. >> 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. > > Exactly. The context and established rules CAs operate in conjunction with > browser, mail and other software is a different one than the one you are > proposing. One doesn't rule out the other however. I don't understand this particular point. Yes, one doesn't rule out the other -- except that in Custom and Practice, getting the browser or mail or any other software to change to make adoption of X.509 easier and less scary for the end user to use (and easier for me to explain to grandma -- not to mention my friends) (I mean, using your legal identity for everything? what if something you end up using it for turns out to be a contract that you didn't recognize at the time as a contract? Now you have to fight it, and nobody wants to deal with the court system). >> 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. > > Yep. I love how laconic you are with it. >> 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. > > Ahhh, at least here an established policy and framework exists - some simply > don't like it. But it allows to implement the software and establish the > rules for all participants. No, the policy does *not* exist. Right now, the policy can be boiled down to this: "if someone has the account name and matching account password, then they have the Right To Use that account." The 'policy and framework' that exists, as far as they are concerned, is too complex for their needs. I've been trying to get them to understand the concept that they don't need that complexity. If someone proves they have the account name and password, they've already shown they have the credentials, so why not issue an alternate credential that can be used automatically, that can be used atomically? And then, why not give that credential a bit of extra information so that other people can accept what it means -- that someone does in fact have that account name in that specific context? >> 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. > > It wouldn't help me if I need to know who the person is, you can't sign a > contract with a pseudonym usually. Binding a real identity to the possession > of a key only strengthens the claim of both when used universally. Within a > specific space this might not be needed. I think instead of "within a specific space this might not be needed", the proper phrase to use is "only within a specific space might this be needed". Only in the Legal realm, only in the Legal context, is a "real identity" necessary. And the only time you actually need to have anything to do with the Legal realm is when you're doing something that you're going to possibly need to take to court later -- like signing a contract. These people, in these communities, aren't signing contracts. They're conversing. (If they want to sign contracts later, then they need to ensure that they know who they're dealing with, just as in offline commerce.) Otherwise, this is what the legal process called 'discovery' is for. If someone libels you and you are damaged because of it, you subpoena the appropriate identity information (access logs, etc) from the context provider. >> 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. > > That might be quite right ;-) > > But neither of the established rules (Torah and PKI) grew on my turf, I'm > only interpreting and implementing. Shalom, Rabbi Nigg. Who made you Master of the PKI space? -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
