Peter G and Peter B are correct and the reality in the embedded world is that if you want to provide some sort of service (https or otherwise) to an embedded device with known limitations and a software update is not possible, then you have play any number of games with certificates. But my bigger issue is that this back-dating practice hardly seems problematic from strictly a security standpoint. It seems to me the only real problematic aspect is that the BR says don't do it. That said, the practice of forward-dating is not only problematic but actually rather dangerous for one simple reason: revocation, and the fact that revocation can not be forced. If I have a cert with a notBefore date of one year from now and a notAfter date that's two years from now, that cert is basically valid for the next two years no matter what. That becomes a big problem if the private key becomes compromised, for example. I don't think forward dating by 2 months should be a concern but 9 months or more...? That hardly seems like a good security practice to me.
Peter Bowen <[email protected]> writes:
>When we replaced a certificate on a publicly facing server, certain functions >on a consumer electronics device stopped working.After debugging we found out >that the device in question does not have an internal time and date >reference.When the device initializes communication with our servers it first >makes a call using HTTP over TLS to get the current date. That's the old NTP-via-HTTP trick. Another one, used by things like smart cards and other limited embedded devices, is to use the validFrom date as a high-water-mark clock. >As long as we have embedded devices out there, we will run into corner cases >requiring some gymnastics to keep things working. Yep. If you don't have a RTC then you have to get some sort of time reference from somewhere, and validFrom is about as good as you'll get, it's a sort of store-and-forward secure-NTP. Peter. | ||
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
