4 ms·
I'm not familiar enough with it to assess its veracity, but Serge Egelman's Rachel-as-victim theory is interesting in an I-wouldn't-have-thought-of-that way. >
by paulgb 4y ago
I'm not familiar enough with it to assess its veracity, but Serge Egelman's Rachel-as-victim theory is interesting in an I-wouldn't-have-thought-of-that way.
> Based on that understanding (and again, please let me know if any of that is incorrect), I personally believe it's possible that Rachel may be a victim here, if she really is the primary TrustCor shareholder (e.g., maybe the company was given to employees, after it was no longer useful). If TrustCor's private keys were compromised at its founding or before (e.g., so that Packet Forensics could sell TLS-interception boxes), the company itself would have little continued value, so long as it passed its audits (and remained trusted by browsers and operating systems). It's therefore possible that Rachel had no awareness of this, and as a result is in the denial phase of realizing that she's the victim of a scam. This is not a statement of fact, I'm just offering it as a possibility.
(Rachel vehemently denied this)
Are root cert keys not rotated?
- jffry 4y agoI think root certs are long-lifespan, kept in hardware security modules / other cold offline storage, and only used to periodically sign shorter lived intermediates that are the main thing signing leaf certs for sites. For example, the DigiCert Global Root CA in HN's cert chain is valid from 2006 to 2031.
- masklinn 4y ago> Are root cert keys not rotated? They are but by their nature as core components of OS and devices they have to be long-lived, because they “bound” the lifetime of their sub-certs. So root-certificates usually have an expiry of a decade or two, intermediate certs a few years (about 5), and then leaf certificate lifespans have been cut down drastically: used to be you could get a 10 years cert, then the CABF cut that down to 5, then 3, then 2, and I think now it’s a year (plus a one month grace period, so 13 months), and some registrars issue much shorter certs than that, notably Let’s Encrypt which issues 90 days certificates and basically requires automation.
- cbzoiav 4y ago> notably Let’s Encrypt which issues 90 days certificates and basically requires automation. Which massively reduces expired cert problems. If you only need to do it once a >=year you do it manually and at some point someone forgets / the guy with the calendar reminder leaves... If you have to do it every 2-3 months you automate it with alerts for when it fails.
- tialaramex 4y ago> Are root cert keys not rotated? In effect, no. Such a "rotation" requires all clients trust the new root. Your PC probably gets software updates every week or every month, maybe your phone gets one a month or per quarter (until support runs out). But how about your smart TV ? Car ? Internet-connected Doorbell ? That IP phone you disconnected last winter and forgot to re-install ? Big CAs tend to ship new roots periodically, in addition to their existing roots, so as to begin gradually phasing over, over a period of several years. So e.g. HugeCA mint a new key in 2001, the major trust stores decide to trust it in 2002-2003. In 2005 HugeCA offer certificates from the new root to customers who prefer the new root and understand the risk. Unfortunately these customers see high failure rates, e.g. the all-in-one printer scanners from a big name company they used in their offices have firmware last updated in 1998. In 2008 HugeCA confirm the big name company printer/scanner firmware update is complete and begin in 2009 selling these certs more widely, there are a few hiccups, they don't work in Windows ME which one customer insists is "the latest version". But maybe by 2011 HugeCA can announce retirement of the old CA root with a retirement date of say 2015.
- lokar 4y agoDon’t they tend to cross sign with the old ca cert of a long time due to this?
- tialaramex 4y agoYes, you can do this, particularly it can make sense for a long-lived CA to have root #1 sign a certificate for root #2 as-if it was an intermediate, so then you can bring root #2 into use but older clients can trust it by sending them that intermediate certificate, while newer clients should rely on their direct trust. Some older clients unfortunately can get into a state where they distrust root #1 (e.g. because it is old) but they know it exists, and so even though they trust root #2 they can see this alternate path via the intermediate to root #1 and reject the whole mess. People shouldn't write software which does this, but they did.
- DonHopkins 4y ago>(Rachel vehemently denied this) Thus positively confirming that she was in the denial phase.