Kyle Rose <kr...@krose.org> writes:
>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.
Getting a bit off-track, but the ones I've encountered won't be updated,
typically because there's no way to do so and/or because the software is
written to a higher standard than the usual Internet-facing stuff. One common
defence, although it's not really intended as such, is that there's nothing
there to attack, everything is hardcoded and fixed and does just barely enough
to communicate with the other side, so there's very little attack surface.
>Consequently, I would not recommend any device interact with the web without
>being able to establish that server certificates have not expired.
Sure, but that's web use. For SCADA use you don't care (or check) whether the
certificates have expired or not because that's the difference between "things
work" and "things don't work": "When PLCs’ certificates expire, they just
disappear off the network. Plus, 99 percent of the industrial world has no
idea what a certificate is, so how do they troubleshoot the problem at 2am?"
(from "Control Systems Security from the Front Lines").
I would assume this extends to lots of non-SCADA cases as well: If you want
things to work, you don't check for cert expiry. Or revocation.
>>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.
Sure, and I pointed out that it was a thing for commercial CAs. In any case
though I wasn't commenting on that but on why a 1-year expiration period is
used, because the alternative was to point out that tying a supposed security
parameter to the earth's (approximate) orbital period seems a bit paleolithic
[0]. And in that case I think we should take a less geocentric view of
certificate expiry and instead use the orbital period of the largest planet in
the solar system, Jupiter, over 300 times the size of the earth so it's got to
be more significant. Giving certificates an expiry time of 12 years to match
Jupiter's orbital period should be enough to cover most use cases (extending
this to Pluto, and whether it should actually be Pluto or stop at full planets
like Neptune, is left as an open discussion point).
Peter.
[0] Based on nature-worship dating back to the Old Stone Age, I don't know
whether they knew the earth's orbital period back then or not but I
believe it was well known by the Bronze Age.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
