4 ms·

OCSP Stapling is incredibly stupid. OSCP Stapling is either ignored because it's not present, or it's effectively just an override for the NotBefore and NotAfte

OCSP Stapling is incredibly stupid. OSCP Stapling is either ignored because it's not present, or it's effectively just an override for the NotBefore and NotAfter fields. There's never a reason as a server operator to present an invalid NotAfter, and it represents a substantial surface area for client libraries to respect them, in the area that's already most prone to mistakes (the recursive descent to find a certificate chain) It's much saner to issue a new, shorter-lived cert. Reduce certificate lifetimes to match whatever you'd use OCSP stapling for. Continue to use ACME. Figure out rotation lifetimes such that I can sleep at night (i.e. they need to be at least 2 days, so that if the rotation fails I've still got time to wake up and start working). Work on building client and server tooling to make it easy to accept rotated certificates (i.e. reload your client certificates on SIGHUP). The advantage of CRLs isn't that they can be used offline, it's that it allows your security team to burn certificates rather than waiting for the CA to do so. You should always subscribe to your CA's CRL too, but you should have a CRL for your own internal use, too.

OrvalWintermute 4y ago
> The advantage of CRLs isn't that they can be used offline, it's that it allows your security team to burn certificates rather than waiting for the CA to do so. You should always subscribe to your CA's CRL too, but you should have a CRL for your own internal use, too. This is incorrect conventionally CRLs are signed by the Originating CA in the conventional trust model. Most CAs won't give you a certificate with the ability to generate your own CRL sharing the same trust, because it can be weaponized to cause a denial of service. This then brings up non-conventional trust models, and Validation Authority as Co-equal to CA situations for validity which can be significantly more challenging, and requiring VA certificate insertion into every Relying Party, just to name a few things, not to mention all the security concerns.
- GauntletWizard 4y ago
  I'm aware. That trust model is inherently broken, and it's not followed anyway. In practice, any CA you trust can sign a revocation for any certificate (the serial numbers are all grouped together) - And that's the way it should be. You should not wait for the issuing CA to get it's act together, you should burn a certificate as soon as anyone distrusts it, and if you have a rogue CA that starts burning Google.com and other important sites, it's better that they burn them (and take you offline) than that they issue false certs (and leak all your data); It's also far more obvious. https://www.imperialviolet.org/2014/04/19/revchecking.html https://www.imperialviolet.org/2014/04/19/revchecking.html Revocation checking is useful for your security team to blacklist site. That's the only useful use.

OrvalWintermute 4y ago

> The advantage of CRLs isn't that they can be used offline, it's that it allows your security team to burn certificates rather than waiting for the CA to do so. You should always subscribe to your CA's CRL too, but you should have a CRL for your own internal use, too. This is incorrect conventionally CRLs are signed by the Originating CA in the conventional trust model. Most CAs won't give you a certificate with the ability to generate your own CRL sharing the same trust, because it can be weaponized to cause a denial of service. This then brings up non-conventional trust models, and Validation Authority as Co-equal to CA situations for validity which can be significantly more challenging, and requiring VA certificate insertion into every Relying Party, just to name a few things, not to mention all the security concerns.

GauntletWizard 4y ago
I'm aware. That trust model is inherently broken, and it's not followed anyway. In practice, any CA you trust can sign a revocation for any certificate (the serial numbers are all grouped together) - And that's the way it should be. You should not wait for the issuing CA to get it's act together, you should burn a certificate as soon as anyone distrusts it, and if you have a rogue CA that starts burning Google.com and other important sites, it's better that they burn them (and take you offline) than that they issue false certs (and leak all your data); It's also far more obvious. https://www.imperialviolet.org/2014/04/19/revchecking.html https://www.imperialviolet.org/2014/04/19/revchecking.html Revocation checking is useful for your security team to blacklist site. That's the only useful use.