On 12/05/2011 04:21 AM, Lucky Green wrote:
On 2011-12-04 12:09, Ondrej Mikle wrote:
[...]
I re-did the count of CAs whose CRLs had 'CA Compromise' as revocation reason,
about month after Peter Eckersley did. Result was the same (counting "trusted"
CAs). Plus few others (some seemed to be internal company CAs; but did not chain
to a "trusted root").

Ondrej,
Most (but not all) of the CAs that I worked with over the years did not
have anybody on the operations side full time that would know how to
place a revocation reason into the CRL. Which is why the majority of CRL
entries include an unspecified reason code or the ever popular reason
code "NULL".

Matches my observations, especially when looking at CRLs of some small CAs (company internal). I had a hunch some of those revocations could be due to CA compromise, but from my point of view it is be only a speculation. I appreciate sharing your experience working with CAs, it gives me a bit more understanding in my guesswork how they operate internally :-)

Without taking anything away from the work of the folks at the EFF (I
appreciate their effort and have been a long-time financial supporter of
the EFF), determining the number of CA compromises from looking at "CA
Compromise" in reason codes is like determining car theft statistics
from the number of car thieves that turn themselves in at the police
station.

Of course, those marked 'CA compromise' are just the detected and admitted cases (a lower bound). However should I claim any other revocations were due to CA compromise I'd have to back that claim with some evidence.

It does not require disclosing of any confidential information to come
to the conclusion that more certificates have been revoked due to CA
compromise than certs were issued due to CA compromise. Indeed, you only
need to look through the database for certs that very publicly have been
revoked due to CA compromise to find a some that lack that reason code
in the CRL.

Can you elaborate on the part of "coming to the conclusion that revocation was due to CA compromise"? In the first sentence, should the last part say "...than certs were revoked citing CA compromise as the reason"? (I'm having trouble parsing it) My first idea would be to look for a batch of certs revoked in a short time period when looking for CA compromise.

The hunch I wrote above is based on my short period (about 7 years ago) working part-time for a company that did a lot of IT projects for government institutions. One of the projects was a pilot application for eGovernment (which included PKI and CA-ish stuff). Before that project I was tasked with penetration testing for said company, so I had pretty good idea how a hacker could obtain access. There was lot of bad blood between management and developers, experienced people left, inexperienced developers were responsible for gaping security holes. The company's use of bribes to secure government contracts was an open secret (company has gone bankrupt since then).

Did some of the CAs you worked for exhibit similar atmosphere like the company above? I'm asking because in such environment people simply wouldn't be motivated enough to really care about breaches and competent people wouldn't stay there for long.


Also, a friend once mentioned he had direct access to RA/CA interface at a telco operator issuing certs that chained to Verisign for some project (him being project manager from another company). That gave me impression that such interfaces are probably more common than an "uninitiated outsider" might think. Is that guess correct?


Lastly, I am not trying to insinuate that having your CA compromised is
or should ever become a crime.

I agree here. Also CA claiming to have no compromise just might be the case of not being able to detect one or be lying (which is way worse). That's why I did not name CAs from the CRLs (wouldn't be a good motivation to keep them honest about revocation reasons).

Ondrej
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography

Reply via email to