I am sorry but I do not have any such document at hand. Tomas On Thu, 2024-02-08 at 16:15 +0100, Eliot Lear wrote: > Tomas, > > Having raised this point myself before, and having been corrected > before > (and I'm glad I was), I wonder this: do you or other people on this > list > have a favorite FAQy-like doc that talks about cert expiration and > verification strategies? And not just expiration but Not-Valid- > Before > as well. There are real challenges with both, especially with IoT. > My > toe still hurts from having stubbed myself on this one repeatedly. > > Thanks, > > Eliot > > On 08.02.2024 15:46, Tomas Mraz wrote: > > On Thu, 2024-02-08 at 14:13 +0100, François Legal wrote: > > > Le Jeudi, Février 08, 2024 11:46 CET, Tomas Mraz > > > <tomas@xxxxxxxxxxx> > > > a écrit: > > > > > > > On Thu, 2024-02-08 at 11:37 +0100, François Legal wrote: > > > > > Hello, > > > > > > > > > > I'm new to this list. > > > > > > > > > > I'm using pkcs7 packages to embbed firmware, to procide > > > > > authenticity > > > > > verification before doing firmware upgrades. > > > > > > > > > > I use the openssl cms command for verification purpose, but > > > > > face > > > > > the > > > > > following problem : > > > > > when doing verify, openssl cms -verify does check whether the > > > > > signing > > > > > certificate is valid today, not whether or not it was still > > > > > valid > > > > > when the package got signed. > > > > > > > > > > I saw the -attime option to specify the verification date, > > > > > but > > > > > found > > > > > no easy way to fetch the signature date from the package for > > > > > each > > > > > signature. > > > > > > > > > > So I was wondering if it was the intended function that the > > > > > certificate validity verification was made at the > > > > > verification > > > > > date > > > > > and not the signature date. > > > > Yes, this was certainly intentional. I could envision that a > > > > new > > > > option > > > > could be added to the cms command that would verify the > > > > signature > > > > at > > > > the date when the signature was made. However please note that > > > > without > > > > some kind of assurance that the signature was really made at > > > > the > > > > time > > > > that is recorded in the message, the signature could have been > > > > done > > > > with a key that was already expired anyway. This assurance is > > > > done > > > > usually by timestamping via a trusted timestamping authority > > > > but > > > > there > > > > might be other means. > > > > > > > Sure I get the point. You can't really be sure that the signature > > > was > > > made at the clained time as the signerInfo structure is not > > > signed > > > itself. Could you please comment however on why verifying the > > > validity of the certificate at the verification date is better in > > > that matter. > > The expiration of the certificate means - albeit in an extreme case > > - > > that the private key is no longer trusted - i.e., it can do > > anything > > like malicious signatures of crafted data, etc. So unless you have > > trusted timestamps on the signed document, after the certificate > > expiration, the signature has no validity. Of course this is a > > little > > bit extreme view but... > > > > > I already have a patch to provide for verifying the signature at > > > signature time. Shall I send a pull request ? > > Yes, sure. I assume you'll have to sign a CLA unless you already > > did it > > before. > > > > > François > > > > > > > > > > -- > > > > Tomáš Mráz, OpenSSL > > > > -- Tomáš Mráz, OpenSSL
