On Thu, Apr 27, 2023 at 12:52 PM Neal H. Walfield <neal(a)walfield.org&gt; wrote: Well, it sure does relate to Fedora development, and constitutes one thrilling read about a great job done well. Thanks for sharing!

On 27-04-2023 19:55, Robert Relyea wrote: It's the beginning of Unix time (time of the epoch): https://en.wikipedia.org/wiki/Unix_time -- Sandro

Hi Bob, On Thu, 27 Apr 2023 19:55:42 +0200, Robert Relyea wrote: Thanks, I'm happy you enjoyed it :). Good catch! In Sequoia, we have high-level policy objects that are passed to every method that directly or indirectly does a cryptographic operation. Before doing something that relies on cryptography, a method checks that the operation is allowed by the policy. If the policy returns an error, the caller adds some additional context to the error message, and then returns the error. For instance, before using a signature in a context that requires second pre-image resistance, a method might do: ```rust policy.signature(&sig, HashAlgoSecurity::SecondPreImageResistance) .context("Checking ...")?; ``` Our `StandardPolicy` associates a cutoff time with each algorithm. By default, SHA-1 is considered acceptable in a context that requires collision resistance until 2013, and acceptable in a context that requires second pre-image resistance until 2023: https://docs.sequoia-pgp.org/src/sequoia_openpgp/policy.rs.html#628 https://docs.sequoia-pgp.org/src/sequoia_openpgp/policy.rs.html#646 We had two use cases in mind when we designed the cutoff system. First, using cutoffs, it is possible to sunset an algorithm. For instance, we released version 1.0 of sequoia-openpgp in 2020. At that time, the world already knew that SHA-1 was broken. To allow a transition period, we decided to set the cutoff for SHA-1 to 2023. (We already worked on tooling to help with the transition, like `sq-keyring-linter`, https://gitlab.com/sequoia-pgp/keyring-linter .) In this way, no software update was required to disable SHA-1; all Sequoia users disabled SHA-1 at the same time. Second, OpenPGP is often used to work with archived data. When verifying a signature, we should apply the policy from the time the signed data was initially received. (If we don't know when the data was received, then we conservatively assume the current time.) This means if I have a signature that relies on SHA-1, and I store the data on a trusted medium, then I can use the time that it was stored as the reference time, like so: ```shell $ sq verify --time 20080428 /tmp/msg.asc ``` When we spoke about this with the Fedora Crypto Policy team, they decided to not use cutoffs, but a simpler binary allowed / not allowed. Since OpenPGP time started on January 1, 1970, setting the cutoff time to January 1, 1970 means that an algorithm is always considered to be broken. And, that's how it is implemented, and why the error message includes that time. That said, yes we realize the error is confusing, and we plan to add a special error message for this case: https://gitlab.com/sequoia-pgp/sequoia/-/issues/1000 Thanks! :) Neal