1. 7
  1. 2

    Do newer certificates invalidate older ones? If so, could a combination of TOFU or recording the signed serial number in DNS be used instead of a CRL?

    By newer I mean a cert more recently issued, with a more recent notBefore, or a higher serial number.

    n.b. I only have a journeyman understanding of PKI. I’m sure there’s something wrong with my above idea. I’m curious what it is!

    1. 2

      No they don’t invalidate the previous ones. (Unless that’s the CA’s policy) Certificates are completely independent of each other. You can also have multiple certificates handling the same site - even changing back and forth between requests. And that’s completely valid.

      There’s also no coordination between different CAs - and for good reasons. When you run a big-enough-site™, you will want to have another certificate, from another source, ready to go in case the usual one gets revoked. (For example because of a breach or a dispute with the CA)

    2. 2

      This reminds me of Ron Rivest’s 1998 paper “Can we eliminate certificate revocation lists?”. The answer, even back then, clearly was YES.

      1. 2

        23 years and counting :) I’m betting we get past 30.

        1. 1

          There were debates about this going back to the 1970s too :(.

      2. 2

        This seemed very verbose - it could be a quarter of its current size with no loss of information.

        The big thing I took from this is OCSP stapling is a de-facto reduction in certificate lifetime. The TLS server is periodically (within hours or days) checking a CA for whether its certificate is valid, and conveying that in signed form to the client. In this model, the existence of a multi-year certificate is not much more than legacy compatibility for clients that don’t understand the stapled response. Once those clients are gone, it even opens the door to much longer certificate issuance, so private keys can be retained longer because there’s already an affirmative process to handle any breach.

        What’s strange is this is the outcome the author appears to want and lament that we don’t have, but his own description strongly suggests it’s a path we’re on.

        1. 1

          The private key can remain the same when renewing a certificate, I use acme.sh which seems to do this by default (it has the --always-force-new-domain-key flag to force a new key)

          What I think is interesting though, is that by using TLSA records (the author calls this DANE), you can pin the private key. Revocation of the key is then simply done through DNS, so it has the same expiry mechanism as anything else, and at the same time prevents other keys from being used for your domain. This would allow us to greatly simplify how the CA ecosystem works (which today is an opaque blob consisting of public CAs, CAB, CT and the pinky swear from CAs to honor CAA records)

          1. 2

            It’s a massive footgun though. Many pages went down because they restricted their keys incorrectly. Some had to be rescued by browser vendors ignoring their certificate pins. (https://www.smashingmagazine.com/be-afraid-of-public-key-pinning/ - I know it’s not exactly the same, but still a footgun)

            1. 2

              HPKP (HTTP Public Key Pinning) is indeed a footgun, because the mechanism to deliver the key (HTTPS) is the same mechanism it should protect. This means that as soon a key is pinned, you MUST be able to reproduce that key or the client will refuse to connect, and therefore refuse to update the pins; it’s a footgun because you can get into a deadlock.

              Using TLSA is very different; the keys are in DNS, so replacing them is easier, and clients will not end up in a deadlock situation when you roll keys too quick. As such, it’s not possible to shoot yourself in the foot the same way. You might still be able to pinch yourself in the foot when you forget to update your TLSA records when you rotate your key, but this will only bite you for the duration of your own TTL after you remedy the situation.