Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive

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

[Discuss] Why the dislike of X.509?

On 8/29/2014 7:12 AM, Derek Atkins wrote:
>>> A bad actor can do *everything* with a compromised KDC.  Yes, there are
>>> steps to prevent compromise, just like there are steps to prevent
>>> compromise of an X.509 CA.  The main difference here is that if I
>> Except there aren't. X.509 lacks mechanisms to prevent and detect root
>> certificate compromises. It was intentionally designed this way. It was
>> designed this way so that, for example, government oversight and the NSA
>> can decrypt all messages within the agencies under their authority. This
>> all happens silently, undetectable by affected users, by design.
> Sure it does, it's called a "CRL"..  And OCSP..  But yes, it's
> definitely more work to remove bad actors from the trusted root CA list.

My understanding (and it's possible I made this up, I can't seem to find
any supporting documentation with a cursory search of the intertubes) is
that the main approach to dealing with CA compromises is to use
chaining: you have the root CA(s) locked up and offline in high
security.  The only certs those root CA(s) sign are for secondary CAs,
and those secondary ones (or ternary ones) are used for day-to-day
purposes.  Then if one of the 'day-to-day' CAs that is much more exposed
gets compromised, you can revoke it (using a CRL or equivalent), along
with all the certs it signed, without requiring a reboot of the whole
system (i.e. replace the root CA on all installed systems worldwide).

Fun fact: I bet you thought certificate expiration was all about
security.  There are some aspects of security, but expiration dates also
solve a practical problem for large scale deployments: they keep the CRL
from growing indefinitely.  For example, this article:
claims that back in 2005 the CRL for the CAC system alone was 50MB.
Having a hard limit for how long certificates can last helps keep the
CRL under control, because once a certificate is expired it no longer
has to be in the CRL.


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 /