3

I'm configuring a PKI infrastructure with an offline root CA and several issuing CAs. Among other topics, I'm struggling to decide how the revokation of an Issuing CA certificate works.

My Root CA will issue CRL once a year, and as far as I know, a machine with a CRL cached won't download a new CRL until the current one expires. But, what happens if let's say, the current CRL expires in November 2016, but the Root CA revoke an Issuing CA certificate in January 2016? Does this mean that a machine will trust the Issuing CA certificate until November 2016 although it's been already revoked by the Root CA? Is there a way to force the update of the cached CRL?

Thank you!

Angel Muñoz
  • 33
  • 2

3 Answers3

3

You guessed well: revocation is asynchronous. When you revoke a certificate, this becomes really effective only when the last pre-revocation CRL expires. If you issue CRL that are valid for one year, then a revoked certificate may still be trusted by other systems for up to one year.

One should envision CRL as a damage containment feature: with CRL, you can have an explicit boundary on how long the compromise will impact your systems. Long-lived CRL are easier to issue (since you do that less often), but correspondingly take more time to contain the damage. This is a trade-off.

The only mitigation, within the context of an X.509 PKI, is to issue CRL more often, with a shorter life. However, since your root CA is offline (and that's, all other things being equal, a very good idea), issuing a CRL implies a manual operation, hence costs. I am aware of two workarounds:

  1. You could make an indirect CRL: while the root CA is offline, the power to sign a CRL could be entrusted to a distinct, online system with its own key pair. X.509 has support for that, with relevant extensions (see this answer). Unfortunately, indirect CRL are not well supported by existing software.

  2. One could make the root CA half-online. In a setup that I have helped develop and is currently deployed in production, the "offline" root CA produces a CRL on a weekly basis, and sends it over... its audio output. The idea is that the "line out" plug is physically one-way, so even if there is a wire going from that plug to the "line in" plug of another (online) machine, the root CA can still be considered to be "offline". Moreover, a visual inspection can easily notice that the wire is in the right plug (the green one).

    This solution requires some software to encode the new CRL as sound, and decode it back on the other end; the simple code I wrote offered very bad performance (about 300 bits/s), but it was very robust, and the weekly CRL is very short (since it is, under normal conditions, completely empty). Since there is no acknowledge (the link is really one-way), the sender must send the same file repeatedly, again and again, with a recognizable header for synchronization, and a checksum for error detection (for a CRL, you could verify the signature; that's as good as any checksum can get). That way, you can have an offline root CA and still get automated CRL publication on a weekly basis (it could even be daily).

    (My initial design called for an actual speaker and a microphone, but that could prove problematic in a noisy environment, and server rooms are very noisy. People with some electronics skills could build a circuit with a LED and a photodetector. Yet another way is to use a twisted-pair ethernet cable with only one pair connected, but this may fail to work with ethernet interfaces that try to do medium detection; and it is harder to visually check, since you have to unplug the cable to check the wiring.)

Community
  • 1
Tom Leek
  • 172,594
  • 29
  • 349
  • 481
  • Revocation is only asynchronous in some situations - low security use cases, or using deprecated CRLs. High security revocation data distribution such as with Nonced OCSP is definitely synchronous. CRL generation more often is not really an accurate response, since CRLs have so many negatives compared to OCSP, e.g. why OCSP was created in the first place. – Brennan Jun 18 '15 at 18:17
  • 1
    We are here talking about an offline root CA, which, by definition, cannot be an online responder. Moreover, an OCSP response still has a lifetime; while any relying party MAY insist on getting a fresh response (freshness is verified with the nonce), the question is about OTHER machines -- such freshness cannot be enforced externally. – Tom Leek Jun 18 '15 at 19:17
  • You are confusing a root CA, with validation. Many PKIs have offline root CAs while having an online responder. Furthermore, there exists many other trust models for validation besides CA designated and CA delegated. – Brennan Jun 18 '15 at 19:36
0

Yes, the machine may trust the Issuing CA certificate until November 2016. There are a few "solutions" in use -mainly in web browsers- when there's a certificate that which "must be revocated":

  • Launch a new browser version including the revocation. Really inefficient, but it works.

  • Chrome pushes revocation lists (crlsets) separatedly thorough their update channel.

  • OCSP provides a way for verifying online that the certificate hasn't been revocated. That way, you only need to push the revocation to the server handling the OCSP. The problem is that the OCSP server becomes a single point of failure, as you need to treat the certificate as invalid if not receiving an OCSP answer. If you soft-fail, a MITM only needs to block the OCSP check (which given that they are MITM you, they often can), and the connection will succeed. See [1]

Ángel
  • 18,824
  • 3
  • 28
  • 65
  • OCSP is generally not a single point of failure as you can load balance OCSP. Furthermore, you can merely cache responses for non-nonce OCSP through any number of CDNs, further reducing the possibility of a single point of failure. – Brennan Jun 18 '15 at 19:57
  • If the OCSP "server" (balanced or not) fails, the connection fails. If you use a CDN, you move the SPOF to signing the responses and sending them to the CDN. If the responses are valid for X days and do not use a nonce, a MiTM could forge a valid OCSP reply for X days after revocation. You can decrease it but in the end, relying on the OCSP being "online" is the tradeoff that we pay for noticing the revocation. – Ángel Jun 19 '15 at 23:05
  • Just FYI - all Non-nonce OCSP is subject to replay attack. It is a known vulnerability that will likely never be fixed since there are significant performance and scaling tradeoffs associated with Nonced OCSP. Load-Balanced OCSP typically redirects to farms of OCSP servers, not an individual server. – Brennan Jun 22 '15 at 13:59
0

A CA based model of validation fails as it is not capable of performing revocation of itself; there is no trust agility when a Root CA is compromised, as you have to replace your trust anchor. If this is merely an issuing CA rather than a root, the revocation event can succeed. However, let's review basic approaches to validation:

  • Certificate Revocation Lists - a blacklist of revoked certificates distributed as a file. Large CRLs are difficult to consume and cause performance issues.

  • OCSP without Nonce - a repeatable response can be mass produced and cached. Small, fast and efficient.

  • OCSP with Nonce - an OCSP request and response that includes a cryptographic nonce; Nonced OCSP is always live. Small, fast, but introducing slightly more of a performance hit than a vanilla OCSP request/response.

OCSP was previously more oriented towards being a live version of CRLs, a blacklist. However, the newest RFCs for OCSP also enable use of OCSP as a whitelist too. Combined blacklist and whitelist approaches for validation are far more secure.

When thinking about validation, keep in mind that you can, and should consider other alternatives to CA based trust models, particularly for larger networks or networks where the possibility of CA compromise, or flexibility, is needed.

If given the choice between producing CRLs, OCSP, or both, I always plan to utilize a both model, with preference given to fail-closed OCSP, supplemented by CRLs. In general I prefer VA based validation schemes, since they have the ability to revoke compromised CAs.

Now that I've written all this, am going to answer your questions

CRL based validation should almost always be less preferred than OCSP based validation

CRLs can be purged from an IT product, e.g. on Windows 

certutil -setreg chain\ChainCacheResyncFiletime @now
Brennan
  • 257
  • 1
  • 7