Fix BIP85 Timestamp Typo

[3rdIteration]

Genesis block time is correct in Unix time, but human readable version is off by 10 minutes. (Single digit typo)

Basically this changes the fingerprint, so should be consistent so as to ensure compatibility between BIP85-GPG implementations.

(I am comparing my SeedSigner to Krux GPGap in this instance, the latter of which has gone with the human-readable time from the BIP whereas I went with Unix time and couldn't work out why the same input produced different results...)

[jonatack]

ACK

Pinging @akarve and @scgbckbone for feedback.

[jonatack]

Suggested change

The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to unix Epoch timestamp 1231006505 (the Bitcoin genesis block time <code>'2009-01-03 18:15:05'</code> UTC) because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of <code>faketime</code>).

The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to UNIX Epoch timestamp 1231006505 (the Bitcoin genesis block time <code>'2009-01-03 18:15:05'</code> UTC) because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of <code>faketime</code>).

[akarve]

Since the creation time is set in GPG (right?) this does not affect the BIP-85 output per se. Nevertheless if someone generated a GPG key according to spec this would make any previously generated keys irreproducible. Moreover, the date is given at MUST. Therefore I recommend we not touch the date and instead add footnote on the discrepancy if desired.

[3rdIteration]

The BIP85 output is unchanged by this, but the fingerprint generated by GPG changes if the created timestamp is changed. (Even if the primary key itself is identical) The problem is that the spec is ambiguous, not that it should change.

[jonatack]

The problem is that the spec is ambiguous

Agree, the spec needs to be clear.

[akarve]

Sorry, I missed the inconsistency and it should indeed be resolved. I request both a footnote containing the old human readable ts and a changelog entry for this correction. That way if someone used the incorrect timestamp they can at least get the same fingerprint.

Does the GPG API have a preferred or default timestamp format? If yes and it's epoch time then this change is less risky.

[3rdIteration]

Not sure about API, but GPG packets include a timestamp in Unix time and while the command line tools will normally display a human readable time in your local timezone, if you ask it for the raw key data, you get Unix time.

[jonatack]

I request both a footnote containing the old human readable ts and a changelog entry for this correction. That way if someone used the incorrect timestamp they can at least get the same fingerprint.

@3rdIteration do you want to update for this feedback?

[3rdIteration]

Just added something in 1887780

[jonatack]

Thanks for updating. Feedback below.

[jonatack]

Suggested change

	*Typo in human-readable timestamp for BIP85 GPG Keys
	* Typo in human-readable datetime for BIP85 GPG Keys that was incorrectly noted as '2009-01-03 18:05:05' rather than '2009-01-03 18:15:05', so implementations that relied on it instead of UNIX Epoch timestamp 1231006505 will produce different key fingerprints.

[scgbckbone]

nit: would use "datetime string" here too

[jonatack]

The usual title for changelog fixes

Suggested change

	====Corrected====
	====Fixed====

[jonatack]

Suggested change

The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to unix Epoch timestamp 1231006505 (the Bitcoin genesis block time <code>'2009-01-03 18:15:05'</code> UTC)<ref>The human readable timestamp was incorrectly noted as '2009-01-03 18:05:05' prior to v1.3.1 of this BIP, so implementations that relied on this will produce different key fingerprints.</ref> because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of <code>faketime</code>).

The resulting RSA key can be used to create a GPG key where the creation date MUST be fixed to UNIX Epoch timestamp 1231006505 (the Bitcoin genesis block time <code>'2009-01-03 18:15:05'</code> UTC)<ref>The human-readable datetime string was incorrectly noted as '2009-01-03 18:05:05' prior to v1.3.1 of this BIP, so implementations that relied on it rather than UNIX Epoch timestamp 1231006505 will produce different key fingerprints.</ref> because the key fingerprint is affected by the creation date (Epoch timestamp 0 was not chosen because of legacy behavior in GNUPG implementations for older keys). Additionally, when importing sub-keys under a key in GNUPG, the system time must be frozen to the same timestamp before importing (e.g. by use of <code>faketime</code>).

[scgbckbone]

ACK