Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month, online, via Jitsi Meet.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Why the dislike of X.509?



Richard Pieri <richard.pieri at gmail.com> writes:

> It's not that I hate OpenVPN. It's that I hate key escrow systems. Hated
> them since the early 1990s. I hate them because they're single points of
> compromise for entire systems. I hate them because compromise is
> undetectable by users.

HUH???  Non-sequitor Alert!!!!

How do you jump from X509/OpenVPN to "Key Escrow Systems"???!?!??!?!!?!

Let's get something clear: X.509 does NOT require any kind of Key
Escrow.  Period.  Yes, there are some deployments of PKI/X.509 where the
CA generates the keypair and hands a P12 to the user (private key +
certificate).  And yes, those specific deployments could implement Key
Escrow.  But that's a problem with that deployment model, not a problem
with X.509, and those deployments are the exception, not the rule!

Let me be perfectly clear: In every X.509 system that I have designed,
implemented, or deployed, there was *NO KEY ESCROW*.  The end user
generated the keypair, sent a Certificate Request (CSR) to the CA,
provided some other form or authentication, and the CA signed the CSR
and returned a Certificate.  At no time did the CA have a copy of the
PRIVATE KEY for the user.  In fact, I've never personally encountered a
P12-based system (although I do know they exist).

Now, the problem with CAs as implemented in X.509 (and specifically for
browsers) is that in general ANY root CA can generate and sign a
certificate for ANY name.  So the issue (ala Diginotar) is that a rogue
CA that is accepted in the public (system/browser) roots could
impersonate anyone.  Note that this is *impersonate* which is not the
same thing as having a copy of your key.

You (or someone) also brought up Kerberos.  Kerberos *IS* a key escrow
system.  If an attacker breaks into your KDC they literally have all the
keys to your kingdom.  Not only can they impersonate anyone, they can go
and read any communication that was performed using Kerberos as the
keying system (systems employing a DH-style PFS and authenticating by
Kerberos would not be succeptible, but those are fewer and further
between -- generally the apps just use the KDC-provided session key).

This is far different that someone who breaks into your X.509 CA -- all
they can do at that point is issue new certificates, impersonating you.
This would allow them to act as an authenticated man-in-the-middle
because the client would accept their "fake" certificate as real
(c.f. Diginotar again).

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org