Ben, Happy New year!
... Because of the risk of logs becoming untrusted, SCTs in certificates may become invalid before the certificate expires, effectively terminating the cert early.
If a log becomes untrusted then the cert is "invalid" only for the set of clients who relied upon that log. It may be that the cert was fine and the log was misbehaving with respect to other certs. So the term "invalid" is not quite appropriate here, in the usual PKI sense.
You can mitigate this to some extent by including many SCTs, but its clearly better/safer to use SCTs that are retrieved "live" so that you can always be sure they're valid.
I agree that this would be preferable.
This requires either OCSP stapling or the TLS extension. Using the TLS extension puts updating the SCTs in the control of the site operator, which seems like the best way forward.
Maybe. I've been told that site operators are not always very reliable when it comes to maintenance issues. Also, I believe you argued that it was critical to put SCTs in certs because it would take a very long time for site operators to update their software to trans,it SCTs. So, is your argument that, over time, the vast majority of site operators will go to the effort of getting an SCT for their web certs and transmit it instead of just using the SCT that is already embedded in the same certs? Steve _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
