On Tue, Nov 11, 2008 at 9:06 AM, Eddy Nigg <[EMAIL PROTECTED]> wrote:
> On 11/11/2008 03:54 PM, Ian G:
>>
>> And, in particular, the PKI industry's obsession with some concept that
>> you refer to as "legal identity" is ruining its own market.
>>
>
> I personally don't perceive it as such nor do I think that there is such an
> obsession. I *do* believe that more verified identities may be good for the
> Internet in general - which would allow to view unverified ones with a grain
> of suspicion. Or lets make some comparison to transportation, where one in
> order to drive a car must undergo some training and carry a license. I could
> imagine something similar applied to the Internet, where one carries a
> license in order to drive on the network. Anybody without a license can't
> drive along.
I have absolutely no problem with "verified identities" -- what I do
have a problem with is that public, general-purpose CAs limit the
range of identities which can be verified.
The 'legal identity' concept is the mechanism for using name and
metadata associated with that name to refer to the entity in some
context which nearly everyone can be referred to within, and thus can
be used nearly universally to resolve disputes which relate to things
which violate the law in some context. (The 'legal name' is the
primary search key to be able to reference records associated with the
'legal identity'.) However... this identity is only truly useful when
you're dealing with things that the law covers.
I love the idea of comparing data transportation to physical
transportation... except the analogy breaks down rather terribly for
several reasons, not the least of which is that governments have
allowed for licensure of individuals to be able to operate
physically-dangerous machinery on governmentally-funded roads, and
there is no such governmental licensure for individuals to exercise
technologies used to share information. (In the US, such a licensing
policy would be illegal under the Constitution as an unlawful prior
restraint on free speech -- since speech is protected more than
conduct when said conduct involves physical objects that can cause
harm or death if they're mishandled.)
One of the things that I want to see is the ability for individual
communities to be able to assure identities in their own contexts --
their own usernames, their own primary keys to look up records
associated with those identities (passwords, number of posts made,
date of joining, etc). These records may not have any bearing outside
the community that holds them, but they are still identities -- two
individuals with identities in a community who meet each other in the
flesh still share membership in at least one common community. Two
individuals with identities in a community who bump into each other on
IRC or such still share community membership. I'd like to be able to
make knowledge of membership something that doesn't have to be
broadcast or promiscuously offered.
(TLS operates with the server identifying itself through presentation
of a certificate as the first stage. Unless an ephemeral key
agreement is used to negotiate unauthenticated encryption before the
certificate presentation, the plain-text form of the certificate and
thus all information therein is transmitted across an unencrypted
channel, allowing for eavesdropping. IPsec is a bit different, in
that the client must identify itself before the server chooses to
create a security association -- and it must do this before it gets
knowledge of the server's identity. Both identification models are
useful in some circumstances, and useless in other circumstances.)
> However - and this might be interesting for the other camp - one doesn't
> stick the drivers license in bold letters onto the rear window for everybody
> to see, instead you've got license plates for the car. In some way, the
> driver remains anonymous to some extend. Applying this to the Internet, I'd
> know that you've got a license and I'd even know the number. I still don't
> know your personal details - which I could request from you if I wanted to.
> It would be known by an authority should need arise (in case of unlawful
> actions like malware distribution).
Realistically, any certificate which is bound by a private party who
was paid to bind the identity has a paper trail -- if nothing else,
the method of payment. Regardless of any illusory feeling of safety
provided by someone choosing to do the electronic equivalent of
branding of their software (like they would brand their cattle), the
fact is that the user is the one who makes the decision to run it.
This would be the equivalent of taking a cow that was already branded
home. Regardless of whether the cow is rabid or cantankerous or the
sweetest, most lovable creature in the world.
There is another mischaracterization in your statement. In the
currently-dominant X.509 paradigm combined with the application of
TLS, anyone who runs a server (their vehicle) must hang their license
on the site (in the form of the X.509 server certificate). It's not a
license plate -- and if it is, then I'd really like to know who gets
off on making me jump through additional hoops (eating up time which I
could apply to other things, and time really is a finite resource and
thus as valuable as money -- and in most circumstances including an
additional monetary component as well) just to be able to run a damned
TLS server that web clients will talk to without inflicting or
invoking The Fear Of The Unverified.
> Now of course this is some form of reducing the freedom of the individual,
> but on the other hand would bring some piece of mind (with malware and fraud
> removed, children clearly protected and so forth). Similar to the
> transportation system where not every individual can do as he likes.
>
> In such a network where "drivers" hold "licenses to drive", one could
> according to preferences and policies apply rules, for example require a
> license to send mail to a server, or to view some private content, or
> publish software etc. Where it's permissible, no license should be required
> like posting a message on an anonymous blog.
>
> Don't eat me alive here, it's a possible solution to solve a problem
> differently (instead of arming ourselves with anti-spam, anti-viruses,
> anti-malware etc. a game which never can be won). :-)
So, essentially, you want to get together with others to build a set
of tools that the user can use that just happens to implement your own
ideas of what Policy Should Be (thus inflicting your policies on
Everyone Who Uses Those Tools Even If They Are Not In Your
Organization).
There's a very unhappy word for this kind of behavior: collusion.
There's another concept, too: using an improper position to demand
money. If you're so interested in personal information protection,
you should realize that the underlying concept of the EU personally
identifiable information directive is that the person has the right to
choose who to give information to, and in what manner. By railroading
them into sharing their personal information to a private entity (a
CA), you're removing their choice to share, you're only giving them a
choice between who to share it with. Since authenticated personal
information has monetary value, you're essentially demanding that the
CA industry -- any one of the players therein -- is given a valuable
asset simply on the strength of fear. (Fear that the end-user won't
go to the page. Fear that the end-user won't click through the
warnings. Fear that they're artificially limiting their market. Fear
that the chrome will present an unwelcoming first impression of the
site.)
That is extortion. Since you're positioning it as a prerequisite to
commerce, it's like you're trying to claim ownership of the right to
transact commerce -- and I'm pretty sure that 'restraint of trade'
would also be a good description.
>> Sure, that's a claim that is frequently made, albeit *only in PKI
>> circles*.
>
> Really?
Generally, yes. The only times I've ever seen anything like a "be
sure of who you're talking to" campaign has been in the context of a
PKI shill.
I do want to know who I'm talking to -- but I want the label for the
identity that's bound to the key I'm talking with to be a label that
makes sense to /me/.
It's a little like nicknames. I don't need to know that the nickname
'grandma' actually refers to a woman named [[grandmother's legal name
redacted]]. You don't really need to know that the nickname 'Aero'
actually refers to Kyle in some circles I traverse -- everyone in
those circles has an association of Aero which is more useful to them
than the association of Aero to Kyle, and Kyle to me. (If I were to
explain it in UNIX terms, I'd say that their association of Aero is
like a hard-link -- to them, it's more canonical a means of
referencing me than my legal name is, since I've interacted with these
people for many years, and that's the name by which they've always
referred to me. An association of a nickname is by necessity a
soft-link (a redirection to the hard-link, which is then used to refer
to the actual subject).
Since computers are tools, it makes sense for the people I know to be
able to see a certificate that has the name that they know me by
within it. Since I want to maintain control over
personally-identifiable information, I don't necessarily want my legal
name to be bound to the name I use in those circles (unless and until
I choose to share that information). Since those communities are
relatively small, it doesn't make any sense for me to try to use that
nickname outside of the circles in which I travel. Because of this
last point ('limited usefulness'), even if I did try to create a CA
which delegated CA certificates to any and all communities that
requested the ability to bind nicknames directly to keys, and that
adhered to the Mozilla guidelines for inclusion, I still wouldn't be
able to get it approved for inclusion. (Plus, the proposed audit
requirements for every issued sub-CA would be extremely onerous, since
I would have to hire an actual auditor for each and every one of them,
not do it myself.)
I also need to point this out: the common view here is that DNSSEC
would not relieve the universe of the need for X.509 certificates
(since even if the DNS is secure, the packet routing is not). This
means that X.509 certificates can be used to identify whatever's on
the other end, regardless of what its name is or how it's referenced.
It's a historical remnant that demanded CNs and SANs match the name
that was used to look up the IP address... but what everyone forgets
is that a certificate is used to bind an identity to a key, and proof
of knowledge of the corresponding private key is used to authenticate
the certificate. This is true regardless of the name used in that
certificate, or the forward lookup -- so why should I have to have an
identity bound with a specific email addess? Why shouldn't I be able
to talk to a server that presents a certificate that doesn't have the
specific name under which I connected to it within its certificate?
Just pop up a non-invasive warning of who the certificate's subject
is, and who issued the certificate.
I'm also very annoyed at the device used for naming in certificates.
When a user types in https://kyanha.net/, if the only name in the
certificate is www.kyanha.net the user's still going to get a warning
-- even if the only thing that the server does with that hostname is
issue a redirect to https://www.kyanha.net/. Thus, certificates
demand planning and artificially inflate the cost (in terms of time,
equipment, and effort required) of any potential site reorganization
(such as splitting www.kyanha.net from secure.kyanha.net onto
different machines or farms). As well, it reduces flexibility of
network configuration, sometimes preventing an efficient architecture
from being deployed just because of the need to handle network traffic
such that the naming isn't screwed up according to the web browser's
(i.e., the PKIX) rules.
If I'm identified as an endpoint (I or something operating under my
authority), why does it matter what name you use to get to me?
>> That's what that whole CN is about. Some name that is fairly
>> clear, and an implied CA claim that there really is only one Paypal in
>> its list of certs, so you can rely that this is "the one".
>
> There is one in San Jose, CA, USA. The claim is that of Paypal that they
> hold the trademark, there is a difference.
So why does the CA also have an 'enforcement' role that it steps into?
Paypal has legal authority and standing to challenge anyone who uses
'Paypal' to refer to anything that isn't their site, under trademark
law. If it's also being used to defraud them or defraud customers of
theirs, they become an aggrieved party to a criminal suit. If the CA
revokes a certificate, isn't it trying to step into a role that it's
not allowed to -- the judical role?
>
>> Then there is the one between the end user and the website business.
>> This might or might not be the one that is central in the dispute. Then
>> there are other agreements that pop in and out in the normal course of
>> business.
>
> Of course. There shall be no difference from when I walk into their shop or
> buy from the web site. Confirmations of CAs provide the verified information
> (like a Notary as I said earlier). CAs don't interfere in the handling of
> their respective businesses nor legal system. I think this is very clear.
...except when they do. CAs which revoke certificates 'according to
trademark law' (or which refuse to issue certificates because of their
reading of trademark law) definitely interfere with businesses, not to
mention the demand for a specific network traffic path.
> I have the feeling you are trying to create a problem where there isn't one
> and make something up which never was claimed. And there is no sand castle
> either...
I have the feeling that you don't recognize the problems that actually
do exist... very likely because you're clinging to a viewpoint which
attempts to impose order on what is truly chaotic. "TLS wasn't ever
designed for that! The X.509 system wasn't ever designed for that!"
The problem with standard protocols is that people want to apply them
in places where they're otherwise inappropriate -- such as Verisign
and Netscape's idea to apply X.509 certificates to web browsing
according to specific policies they wrote, and the writing of those
policies into the standards documents. (among other things, a TLS
webserver that wants to use the authentication model of IPsec is
completely screwed -- IPsec requires that the client identify and
authenticate itself before the server does, but at least earlier
versions of SSL and TLS required that if the server did not
authenticate itself, the server could not ask for credentials from the
client, and that doing so was an error which must be responded to with
a fatal alert.)
>> Yes, you are almost there. The purpose is to resolve a dispute.
>
> Duuuh?
Many disputes cannot be brought up in court, simply because the
disputes do not involve the legal system and the only
dispute-resolution mechanism which can be applied is based on
intellectual property rights (including right-of-access to a
privately-owned forum). When multiple individuals share the same
communities, those communities define their own rules for what
disputes to handle and when to handle them. The administration of
those communities can inflict punishments that relate to the
intellectual property rights the administration holds in their
services without having to involve the court system at all. That's
another reason to allow individual communities to issue their own
certificates -- so that individuals can figure out what rules apply to
them and their interactions with others, and what dispute resolution
mechanisms exist.
Everyone -- and I mean everyone -- views the commercial aspect of the
web as being too important to try to slough off. However, I think the
current paradigm throws the baby out with the bathwater; not all
traffic is commercial in nature, after all, and mandating
commerce-grade identification requirements on all traffic (even that
which doesn't need it) is not legal in many jurisdictions, including
the United States. If I play World of Warcraft, and I want to prove
that I have a specific character on a specific server... I can't,
without logging into that server and character. What if I could?
What if I were at Blizzcon, say, and wanted to prove my bona fides
about a specific cultural phenomenon (like, say, being the player of
the first character on a given server to reach level 70 following the
release of the Burning Crusade expansion pack -- which I'm not, but
there has to be someone who is)? What if said person was sending to
an email list, and wanted to sign it as being from the owner of that
character (without revealing the legal name of the owner of that
character)?
You may not see the use of this type of desire, since it falls out of
your preconceived notions of what a CA should be -- and it's not
generally useful in terms of commerce. But... fan-sites are generally
viewed as being "in support of something which can be commercial", and
it might also be useful to have a certificate which can say
"trademarks used by permission, and permission is proven by the
trademark owner having signed this certificate", to reduce the need
for courts to get involved. It's almost a kind of alternative dispute
resolution, by virtue of preventing the disputes from occurring in the
first place. But, the current paradigm does not allow for this. Only
one certificate (and that certificate's chain) can be presented in TLS
-- which also prevents things like users' homepages from having
certificates separate from the hostname.
The entire TLS protocol was (originally) designed with only one
purpose in mind, and thus policies have been improperly embedded into
(at least earlier versions of) it. TLS's mechanism for using the
X.509 certificate issuance and verification protocol was adopted in a
manner which only allows one end-entity certificate and no attribute
certificates for each peer to be verified (there was an attempt to get
around this, in certain limited circumstances, via proxy certificates,
but even in that case only one attribute certificate can be used --
and that only in light of one end-entity identity certificate). Now
people are complaining, and you're clinging to the bastion of "it was
developed with this intent"... without realizing that the intent of
the design really doesn't matter, if it's causing problems elsewhere.
(A hint: cryptography is not limited only to its application in
commercial interactions, except in certain jurisdictions. I'm not in
those jurisdictions, and I want to apply cryptography to something
else -- but by positioning the chrome of Firefox as it exists, Mozilla
is colluding with the CAs that it includes to ensure that anyone who
wishes to serve https to its users without imposition of fear and
heavy-handed intimidation tactics on those same users... for the
purpose of ensuring that the personal identification information of
any site is held in 'trust' by at least one of those CAs. This means
that the publishers of any information in the US who want to make it
available under cryptographic cover are required to register in a
manner which precludes their right to speak anonymously simply because
the site doesn't want to get a certificate from a "legitimate" CA.)
I hold my right to speak anonymously very important. I hold my right
to listen to anonymous speech without undue intimidation very
important as well. Since as a US citizen I'm entitled to equal
protection of the law, this means that everyone else is entitled to
the same equal protection -- which means that everyone is entitled to
listen to anonymous speech without undue intimidation.
-Kyle H
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
