On Wed, Aug 10, 2022 at 10:13 AM Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
> So we're down to mostly non-web-PKI devices and/or the ten year problem, of > which I've encountered the latter several times with gear that sits on a > shelf > for years and then when it's time to provision it all the certificates have > long since expired, which is another reason why you ignore expiry dates > (or at > least you ignore them after you get hit by the first major outage caused by > this because until then no-one realised that it was an issue, a ticking > time- > bomb that may take years to detonate). > Expired CAs are definitely a problem for PKI participation after such a delay, but probably one that is dwarfed by the near certain existence of known vulnerabilities in firmware that hasn't been updated in 10 years. So it's probably best they remain air-gapped and don't participate in active networked systems until they've been updated, which would then include new CA certificates. That leaves revocation, which alongside ignoring expiry dates is another > thing > that's commonly ignored in SCADA, both for the same reason as expiry dates > are > ignored, you don't want to DoS yourself, and because in many cases there's > neither a logical nor a practical basis for revocation or revocation > checks. > For example in typical SCADA networks a device is removed by shutting off > its > access, not by adding an entry to a CRL somewhere and hoping someone > notices. > In fact it's not even clear what certificate would be revoked in order to > achieve some effect, or why. Revocation of device certs to remove their access isn't what I'm thinking of. I'm talking about devices that need to establish trust in remote services via networks of questionable integrity (the public internet, but maybe moreso private networks with lots of hiding places and little active monitoring). Revocation/expiration are complementary tools: periodic expiration means you don't need to maintain revocations forever, and revocation means you don't need expirations to be *too* short and still strictly limit the hazard period resulting from private key compromise. You want to respect both, but for better or for worse the web's threat model has seen revocation as really-nice-to-have and expiration as mandatory-for-interoperation. Consequently, I would not recommend any device interact with the web without being able to establish that server certificates have not expired. That means there is a requirement to somehow bootstrap the current time when needed, whether via device RTC or via some network-connected entity in which trust may be established in some way that is far less general than web PKI. This is a rule-of-thumb: clearly there are ways to safely interact with the web even via cleartext transports, assuming some other kind of out-of-band mechanism for establishing trust in any transferred content. But that goes beyond the scope of the web security model. Ignoring CA billing-cycle^H^H^Hexpiry dates > You repeatedly bring up this point, but you do realize that one of the people you're arguing with was instrumental in the establishment of a mechanism for provisioning *free* web PKI certificates, right? The cost of procuring signed certificates is no longer an obstacle to participating in the web PKI. Kyle
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
