Sorry – I was answering on my phone. Never a good idea.
Pre-signing OCSP responses for these certs is a waste of time as they’ll expire before the OCSP is ever delivered. Delivered to who? Are you saying you deliver certificates before you've produced OSP responses? * If we pre-sign an OCSP response for a 15 min cert, the OCSP is rarely used. When you are signing certs daily, even signing that first OCSP response eats up lots of processing power without providing any benefit to the user. Removing OCSP for short-lived certs eliminates an external call to the CA Stapling * These are usually on a home network. Getting an OCSP response to staple through the firewall usually doesn’t happen and makes the certificate smaller, both essential in device performance. Plus, Mozilla already supports not checking revocation for these certs, meaning the revocation info is completely useless in at least one browser. Any takers on supporting this? Do you have any new data to suggest clock skew isn't a significant issue, and that such certificates would represent compatibility problems for the ecosystem if deployed? Is the assumption that it's the sites and users' fault/responsibility, despite the overall ecosystem widespread use could cause? - Clock skew is a problem. That is the assumption. But that’s not really relevant to the OCSP issue right? That’s more an issue with certificate lifecycles. My contention is that OCSP provides little value in the context of a three day, or less, cert.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
