4 ms·
By far the most logical default behavior to me is that if the issuing CA was valid and trusted when the cert was issued, the cert should be considered valid unt
by peanut-walrus 2y ago
By far the most logical default behavior to me is that if the issuing CA was valid and trusted when the cert was issued, the cert should be considered valid until it expires. This of course means you need a trusted timestamping service or I guess CT can fulfill the same purpose.
For CAs who get distrusted due to reasons which imply their issued certs might not be trustworthy, either revoke the certs individually or use a separate "never trust" list.
- zahllos 2y agoThis is what is done for code and document signing, because you want the signed object to continue to be valid even after the certificate expires. However it has a tradeoff: you cannot remove any certificate from a CRL if revoked, ever. Under normal circumstances certificates naturally expire so only need to remain in CRLs if revoked before then, but with timestamps they are valid indefinitely so must be explicitly marked invalid.
- cryptonector 2y agoThe better thing to do for this case is to only check the code signing certificate's validity at install time rather than every time you run the code. Then you don't have to have boundlessly growing CRLs. In general checking code signatures at run-time is just a perf-killing waste of resources. Ideally secure, measured boot would also measure the OS filesystems you're booting, and that kinda requires a content-addressed storage copy-on-write type filesystem such that you can seal boot/keys to a root hash of the root filesystem, but here we are in 2025 and we don't quite have that yet. ZFS comes closest, though it's not a CAS FS, but somehow the last mile of this never got implemented by anyone in any operating system.
- egberts1 2y agoCT is a temporary glue until the keyless Signal protocol takes over TLS.