4 ms·

I'm not aware of how the COVID certs work, but the way that's solved in TLS certificates (used for https) is that when signing, you have to use an approved time

I'm not aware of how the COVID certs work, but the way that's solved in TLS certificates (used for https) is that when signing, you have to use an approved timestamping authority. A timestamping authority will basically say "Yes, this action was taken at exactly this time". See [0]. [0]: https://en.wikipedia.org/wiki/Trusted_timestamping https://en.wikipedia.org/wiki/Trusted_timestamping

tialaramex 5y ago
Timestamping does exist but it isn't used in the Web PKI (what you're calling "TLS certificates") Both backdating and forward dating have been done in the Web PKI for various reasons, both legitimate (e.g. historically if you couldn't randomise serial numbers enough it was acceptable to randomise the notBefore time parameters slightly, this is no longer allowed) and illegitimate (we have pretty good circumstantial evidence that StartCom issued SHA-1 certificates long after such issuance was forbidden, probably for $$$ from companies that realised they should have bought one before the cut-off) but there is no inclination to insist upon timestamping to try to prevent that. The most likely place you'll see timestamping in arguably publicly trusted certificates is code signing.
- av8avenger 5y ago
  Something that is currently being used (sort of widely) is X509 OCSP. As the Cert gets signed, the CA also embeds an OCSP URL which clients can later use on the fly to determine if a cert is revoked. In case of a leaked private key where the actual PKI wasn't breached, they still have authority over the CA itself and can therefore determine which certs are valid and which are fake. This retains validity of the known issued certificates, but invalidates fraudulently issued certificates. The downside is that its an optional check and that every client needs an online connection in order to validate the cert. Anyway, the COVID certificates don't seem to be actual X.509 certificates and are rather just a signed message, so this isn't something that could be utilized right now.
  - tialaramex 5y ago
    > In case of a leaked private key where the actual PKI wasn't breached, they still have authority over the CA itself and can therefore determine which certs are valid and which are fake. In a very important sense the private key is the CA. The OCSP responses are not encrypted (you'll notice that URL you mentioned is HTTP, you can't use HTTPS for this) but they are signed documents. They're signed by the issuer using its Private Key. So, somebody who has the Private Key can mint bogus OCSP responses signed with that key too. The recovery from losing a signing key is to revoke the entire tree under that key. This will usually involve pushing out software changes e.g. a Firefox or Chrome gets fresh data from the vendor saying "This CA is no longer trustworthy, disregard it". This disaster scenario is why the root keys aren't (must not be) online. If you break into the computer systems of a famous but competent CA and seize total control of everything, you could perhaps (it should be difficult because they're using HSMs but if you've really got control of everything it may be possible) steal the private keys for the online intermediates. But their root is physically locked in somebody's safe, so, you can't steal that by this route for the same reason you can't steal gold bars from Fort Knox by hacking the Pentagon's web site.

tialaramex 5y ago

Timestamping does exist but it isn't used in the Web PKI (what you're calling "TLS certificates") Both backdating and forward dating have been done in the Web PKI for various reasons, both legitimate (e.g. historically if you couldn't randomise serial numbers enough it was acceptable to randomise the notBefore time parameters slightly, this is no longer allowed) and illegitimate (we have pretty good circumstantial evidence that StartCom issued SHA-1 certificates long after such issuance was forbidden, probably for $$$ from companies that realised they should have bought one before the cut-off) but there is no inclination to insist upon timestamping to try to prevent that. The most likely place you'll see timestamping in arguably publicly trusted certificates is code signing.

av8avenger 5y ago
Something that is currently being used (sort of widely) is X509 OCSP. As the Cert gets signed, the CA also embeds an OCSP URL which clients can later use on the fly to determine if a cert is revoked. In case of a leaked private key where the actual PKI wasn't breached, they still have authority over the CA itself and can therefore determine which certs are valid and which are fake. This retains validity of the known issued certificates, but invalidates fraudulently issued certificates. The downside is that its an optional check and that every client needs an online connection in order to validate the cert. Anyway, the COVID certificates don't seem to be actual X.509 certificates and are rather just a signed message, so this isn't something that could be utilized right now.
- tialaramex 5y ago
  > In case of a leaked private key where the actual PKI wasn't breached, they still have authority over the CA itself and can therefore determine which certs are valid and which are fake. In a very important sense the private key is the CA. The OCSP responses are not encrypted (you'll notice that URL you mentioned is HTTP, you can't use HTTPS for this) but they are signed documents. They're signed by the issuer using its Private Key. So, somebody who has the Private Key can mint bogus OCSP responses signed with that key too. The recovery from losing a signing key is to revoke the entire tree under that key. This will usually involve pushing out software changes e.g. a Firefox or Chrome gets fresh data from the vendor saying "This CA is no longer trustworthy, disregard it". This disaster scenario is why the root keys aren't (must not be) online. If you break into the computer systems of a famous but competent CA and seize total control of everything, you could perhaps (it should be difficult because they're using HSMs but if you've really got control of everything it may be possible) steal the private keys for the online intermediates. But their root is physically locked in somebody's safe, so, you can't steal that by this route for the same reason you can't steal gold bars from Fort Knox by hacking the Pentagon's web site.