On Mon, Mar 23, 2009 at 5:35 PM, Ian G <i...@iang.org> wrote:
>>> Hmmm, well, many questions abound: why wasn't it done? where was this
>>> discussed? Why didn't client certs just happen? Why are we still using
>>> passwords?
>>>
>>
>> Good question....it's because it's so much more convenient and everybody
>> is doing it...but guess what, some thought leaders and some leading
>> projects are working on having that changed.
>>
>> But there is indeed no logic to defend Paypal and your bank with XYZ
>> measures as long as they use useless user/pass pairs.
>
>
> Right, so at least we are agreed that client certs did not take off. As
> Kyle would put it, then, the assumptions must have a problem - which you
> would seem to be preferring as "refer to OpenID" if I'm not mistaken.
Going back to the fundamentals of security (at least as I have
understood them -- but please note that I've never taken a course, I
don't have a college degree, I don't have anything except my own
meandering experience and passion for the topic to back me up):
0) Understand the building blocks (primitives and primitive protocols)
available. This does NOT mean TLS, this means "mathematically hard
problems", or "quantum entanglement", or "trusted courier with
suitcase handcuffed to his wrist", or things of this nature. ('trust'
as a concept is an entirely separate problem, one which must be worked
out separately -- but only if there is any non-party which must have
some privilege that other non-parties don't.)
1) understand what must be protected.
2) understand against what it must be protected.
2a) understand against whom it must NOT be protected.
2b) understand what about it must remain protected even against those
who need it to be opened.
3) understand the building blocks available to protect them.
Number 1 is the easiest: "I want to protect this money transfer
order, and ensure that it happens."
Number 2 is difficult: "I want to protect this from tampering." "I
want to protect this from disclosure." "I want to protect this from
repudiation." "I want to protect this from happening twice." "I want
to protect this from being authorized by anyone else." "I want to
protect it from being undone." I'm pretty sure that there are many,
many other aspects that I'm not touching here, but they're not
important for the example.
2a is moderately easy: "I must be able to read this." "The entity
handling the money transfer for me must be able to read this." "The
entity I'm tranferring money to must be able to know something about
this, but not everything."
2b: "I must be able to verify that it's my signature." "The bank must
be able to verify that it's my signature." "The merchant doesn't care
if it's my signature if the bank agrees that it's my signature."
3) Going back to #0, identify the players. "I am Alice. You are Bob.
That guy over there is Charlie, the retailer." For every pair of
players, identify the information that they need from each other (in
an "Alice and Bob" fashion). Once this is done, go through all
players in the protocol and figure out:
a) common data to all players, and who originates it
b) data required between each subset of the players in the protocol,
and who originates it
c) privacy requirements for the subsets (protect A&B's subsetted data
from Carol, protect A&C's subsetted data against Bob, protect B&C's
subsetted data against Alice, and protect all of it from Eve and
Mallory).
Once you have identified this, then you can identify the primitives
and primitive protocols useful for the problem that's facing you.
Until you go through this, you're making assumptions -- you're
assuming -- that certain things are important and other things are
unimportant.
At this point, this is where the TLS/Browser/CA/Server quartet are:
they're assuming certain things (some clearly stated, others
not-so-clearly stated) about the things that are being transferred.
This is why the system is fundamentally broken: nobody wants to
recognize the assumptions, and nobody wants to listen to the guy who
points them out.
> Do you see client certs as products for big corps and gov.ts, too, only?
I don't. I see them as being perfectly valid in the case of
peer-to-peer protocols -- which means that client certificates used
for this also need to be accepted as valid server endpoints, not
merely client endpoints, within these protocols.
(Oh wait! I'm calling out another assumption: that A Server Is A
Server, And A Client Is A Client, And Neither Shall Change Its Role.
The server certificate that I got from StartSSL includes both the
'server' and 'client' bits, while my email certificate only contains
'client' and 'email'.)
> Am I alone here in my understanding of "Mozilla of the people, for the
> people, by the people?" Are we only here to serve the sales of product?
Great gods, I hope not. This is why I'm doing everything in my power
to try to convince the various People In Charge that their assumptions
need to be examined and rethought.
Of course, I'm failing at that, too.
This *IS* the place to discuss this, because this is about the policy
encoded in the code. (Except that I expect that I'll once again be
told by Nelson that the "proper place to bring this up is PKIX-WG or
TLS-WG", since Mozilla doesn't do anything except implement standards
created and ratified by other entities.)
-Kyle H
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
