On 03/28/2009 12:41 AM, Kyle Hamilton:
Eddy... Remember. Most interactions on the Internet are not
contracts. Most interactions on the Internet have no need of Real
Names.
That's perhaps also the source of many problems on the Internet...and
don't pretend there aren't...
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.
I don't think this is entirely correct. As you mentioned before and in
this mail, policies may implement different claims. I think it's quite
possible to create something based in pseudonymous identities as long as
the basic rules are kept. In the context of client certs, that's the
email address control validation (or omitting of S/MIME capabilities)
and correct claims in the CP/CSP.
As such, email control validated client certs are in my opinion exactly
that. They don't claim any other validations and if there is a CA
willing to put p pseudonymous names into their certificates, why not? If
a pseudonym showing up on Facebook is the type of assurance I'd like to
receive is an entirely different question.
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.
This is certainly a problem, but it's not mine really. As I indicated,
the likelihood that a verified certificate would have been issued to one
the mentioned unreal person is very, very low and would have required a
coordinated and substantial effort on part of the subscriber. But I'm
speaking here only for one CA obviously.
Everything else relies on other people accepting and believing your
reputation. Everything else relies on you being Trent. Everything
else relies on "trust".
Partly. Certificates may be legally binding depending on the local
legislation and the trust exists with the software vendors.
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.
Certainly the email field should be part of the UI for client certs. But
it hasn't a lot to do with the way StartCom and Thawte mark low
assurance certificates.
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.
We are repeating ourselves. There are different ways to establish rules,
most CAs (if not all), software vendors and legislation opted for one
specific way. As you said, there is nothing wrong with it.
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).
I don't see the difference between what happens in real life and on the
Internet. After all, we are all people, companies, professionals etc.
etc. The legality doesn't stop at the button of the mouse. You are a
real person if you are behind the screen or not. On the Internet or on
the road, in both cases I might know who you are (or request to know)
for certain purposes and sometimes it's not. If we just have a drink at
the bar I wouldn't care too much about your identity or if we pass each
other in a car I wouldn't mind, but if you would want to deal with me
otherwise (good or bad), I would most likely need to know who you are,
even by force if you'd do something bad to me...
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."
Yes, that's the absolute minimum apparently. But it's a policy.
The 'policy and framework' that exists, as far as they are concerned,
is too complex for their needs.
You just said that it boils down to having account authorization, how's
that complex?
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?
Atomically I'd rather prefer not ;-)
But yes, there is a step or two, more or less the same as when signing
up with a forum, facebook, twitter or whatever...millions do it. I don't
think this is the problem, perhaps it's that nobody requests anything
else than that...? That's why OpenID is great (once we can use it
everywhere) because it binds the ID always to you in the same way
(except if you have different identities, but that's yet another story))
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?
Indeed why not? We've been doing that, albeit in a more conservative
way, look at my ID card: https://eddyn.startssl.com/
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.
I don't agree. I believe that the binding of a key with a legal entity
(in this case persons) is a rather strong binding which gives a good
assurance. It mustn't be only to take somebody to court.
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.
LOL :-)
Who made you Master of the PKI space?
I'm voicing my opinion the same as you do. A few of us have also some
records to show...
--
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
