Does the module signing tool timestamp the signed module?
Is there any reason that option is left out? I did look at the sources but I have never used the java.security packages to sign anything so I did not dig into the documentation on those packages.
It’s just not something we thought to implement when we put this tool together.
Right now when a module certificate expires the gateway warns you about it but doesn’t refuse to load or run it. If we had timestamps we could be more strict about this I guess.
(I assume by timestamps you’re talking about RFC 3161)
Yes, we dont want users of our module to be reliant on us creating new releases with updated certs.
If I were to make changes to allow timestamping would you be interested in pulling those changes in? Timestamping would probably just be an optional flag.
You can do that, but it won’t do any good unless Ignition is modified to care about the timestamps as well.
The downside timestamping is that it requires an Internet connection at build time and requires that the Ignition gateway have an internet connection to verify the timestamps, which isn’t always the case. (edit: not necessarily true, but it does need to trust the certificate used to generate the timestamp. common timestamp server certs may already be in the main Java CA)
Again, the way things are right now, the worst case is a warning message, as opposed to the module not functioning.
I would strongly prefer this remain true. Industrial folk are prone to leave old stuff running far longer than any IT person thinks wise.
2 Likes