This timestamp denotes the time at which the secret key material was encrypted or decrypted. This allows implementations to decide which secret key material to keep when merging transferable secret keys.
Consider using a TSK on two devices. At some point, you decide to change the key's password on one device. Now, if for some reason you need to merge the TSKs again, which have diverged at least in the secret key encryption password, implementations previously had no way of telling which secret key packet to keep and which one to drop.
This timestamp allows implementations to make a decision that is at best consistent with user expectations, at worst deterministic.
Previously, this field was an octet count of the secret key material. Re-purposing this field as timestamp preserves compatibility with keys (and, to some extent, with code) created prior to the re-purposing:
-
The largest specified secret key format is RSA with four MPIs. A MPI can store
2**16octets, resulting in2**16 + 2octets. Therefore, the secret key parameters can take up to 32776 octets. This corresponds to "Thu 01 Jan 1970 10:06:16 AM CET", so every timestamp will be newer than that. -
Conversely, every current timestamp will be larger than 1634123369 or so, considerably larger than the packet's remaining extent. Code that pedantically checks whether the octet count equals the packet's extent will not accept keys with a timestamp. But, code that ignores this count (which was redundant to start with) and use the packet's extent will continue to work.