On Mar 24, 2009, at 5:06 PM, Eddy Nigg wrote:
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...
Remember: I'm still in the phase of identifying problems. Some of
these problems can be solved within the context of Mozilla Firefox and
Thunderbird; others cannot. However, the fact that the NSS layer
handles authentication of data makes this the only logical place to
bring up these issues.
'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...
I'm having to take a holistic view here. I promise that I am not
discussing any aspect of TLS, I am addressing the failings of PKIX in
general. Not merely email, not merely web, not merely code-signing
(which is a different matter entirely), not merely IM authentication,
not merely identification, not merely peer-to-peer identity exchange,
not merely any single thing. The X.509 model, and in fact the PKIX,
absolutely fail to bring any reasonable solution to the needs of the
community at large. (It's rather like telling other people what they
can and more importantly can't do.)
In order for cryptography to be useful, it must be ubiquitous -- and
in order for it to be ubiquitous, it must be nearly invisible. This
means that it can't simply throw up "ZOMG THIS ISN'T AUTHENTICATED"
boxes, it must be able to provide information in a way that doesn't
interfere with the user's experience of what they are trying to do.
Remember, security works best when it minimizes the disruption of
workflow. That's the key to EVERY failure to the adoption of X.509 by
the general public -- the fact that IT DISRUPTS WORKFLOW. This is why
Ian proposed an automated protocol to make it possible to enable
cryptography everywhere in the mail system, and I ran with it to
describe a possible mechanism (not specify such a mechanism, but
merely describe).
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?
Because these communities exist, and they are completely unserved by
the traditional CA infrastructure -- infrastructure, I might add, that
is insisted upon by the browser vendors. (Mozilla, Microsoft, Opera,
KDE, Apple: you ALL must share the blame for this.)
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.
See, that's actually the problem. These are *social* communities, not
*companies*. Social communities are, by their very nature,
distributed. You have a bunch of individual principals -- not merely
"end entities", but true "principals" -- who have a valid interest in
making use of their identities whenever and however they might wish.
This flies in the face of traditional X.509 security models: as I've
said before, the ability to work with peer-to-peer systems is
essential, and requires (if there is any adherence to the PKIX
specification) the ability to authenticate as either a client or a
server. Unfortunately, the only way to do this is to allow them to
have certificates which would otherwise violate every aspect of
Mozilla's assumptions as to what a Truly Trustable PKI CA would be.
In addition, certain hosts (and bloggers, and blogs) have become well-
known enough that they would likely be considered trustworthy,
regardless of who signed their certificates. (Look at boingboing.net
for an example. Cory Doctorow is well-known enough that people would
consider him -- if not an authority, at the very least an icon.)
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 if your want had any more sway than mine, or mine had any more sway
than yours. You're right: this specific example was related to the
browser. However, I must also point out that with HTML in email, the
distinction between 'email client' and 'browser' becomes much, much
less.
...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".
...and interrupts the workflow, thus preventing users from using the
site. The "Great Experiment" of having to have at least 4 clicks in
specific sections of the viewport to add an exception, 5 if you don't
want the exception to be stored permanently, has (to my knowledge)
failed.
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?
Lack of documentation on what extensions are necessary. Lack of
integration into the keystores. Lack of easy importation of these CAs
into keystores.
(I look at it this way: for every click necessary to accomplish a
given task, the chances of someone doing it are reduced by an order of
magnitude.)
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.
Except for the fact that the cypherpunks view any "Trent" as
inherently bad, and refuse to allow their official protocol to be
Tainted.
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"...
What if I just want a certificate, issued by Thawte, that contained a
custom extension that contained my bank account number and state that
it resides in? Thawte has the identity on file, in a discoverable
fashion; the bank itself could even communicate with Thawte and verify
that my Subject details match the principal on my account. But why
should I have to send my client certificate in plaintext containing
both my legal name, city, state, and country of residence, AND my bank
account? I know that there are eavesdroppers on public WIFI
networks. Having that information would make it a LOT easier to
commit identity theft against me.
Policy #1: Minimum exposure. This means that you minimize the amount
of data transferred to that which is necessary to process a transaction.
Policy #2: Delegation. This means that you allow another principal
the right to perform certain things as though they were performed by
you. ("Power of Attorney", or "proxy certificate")
One certificate size does not fit all. One certificate paradigm does
not fit all. It fails -- rather miserably, in fact -- to meet the
needs of the paradigm it was designed to support.
Until you (and everyone else) realize that many of the Assumptions
made are what are holding back PKI adoption... nothing is going to
change. And as we've seen, users will route around complex processes
and interpret them as censorship.
-Kyle H
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
