gopenpgp
gopenpgp copied to clipboard
ProtonMail
packet.Config.Time should return time with 999999999 nsec
Currently verifySignature accepts seconds for verification, but internally it uses time.Time for comparison. That means if we created openpgp.Entity with default time field, test can fail with "key expired" error because PublicKey.KeyExpired will think that key creation happened before verifyTime when in reality we just lost the nsec precision.
Hello :wave: Timestamps in OpenPGP only have second precision. I assume that if you'd serialize and parse the key before using it, this issue would go away - which implies that the fix should be something else, i.e. round down the current time when generating keys (and signatures). Though, that would probably need to be done in go-crypto, not gopenpgp.
Both
https://github.com/ProtonMail/go-crypto/blob/58e86b2947569471f4657525aeb6e835e7c7d3eb/openpgp/packet/signature.go#L604-L615
and
https://github.com/ProtonMail/go-crypto/blob/58e86b2947569471f4657525aeb6e835e7c7d3eb/openpgp/packet/public_key.go#L791-L802
Make no requirements about passed and creation time having second prevision. We can use Trunc there, but is it correct way?
The thing is that both pk.CreationTime and sig.CreationTime, when parsed, come from an integer-precision timestamp (see section 3.5 of RFC 4880). So in that case, truncating them should be unnecessary - but when the objects are created directly (e.g. in NewRSAPublicKey, etc), rather than parsed, we should probably truncate the times, for consistency, yeah. Or, alternatively, we could do it in config.Now - that might be simplest.
openpgp.Entity.EncryptionKey is public method which accepts non-truncated time. I suppose there are also other ways to pass nsec time to KeyExpired functions. Truncating there should safe-guard against that getting in.