[tz] Public Key Wanted

[Peter Remmers]

Hello,

I've been trying to find the public key that was used to sign the tzdata
and tzcode files on ftp.iana.org/tz.

I found this:

https://mm.icann.org/pipermail/tz/2014-June/020967.html

which says the key ID is 62AA7E34, but it's not.

gpg -vv tzdata-latest.tar.gz.asc says the files were signed using key
ID 043DB63744AD418C (or short 44AD418C), but this key isn't to be found
on any keyserver I tried.

I kindly request a pointer to the public key that was used for the
current files on the ftp server, so we can verify the signatures.


Regards,

Peter Remmers

[Brian Inglis]

Post by Peter Remmers
I've been trying to find the public key that was used to sign the tzdata
and tzcode files on ftp.iana.org/tz.
gpg -vv tzdata-latest.tar.gz.asc says the files were signed using key
ID 043DB63744AD418C (or short 44AD418C), but this key isn't to be found
on any keyserver I tried.
I kindly request a pointer to the public key that was used for the
current files on the ftp server, so we can verify the signatures.

The TZ RFC 6557/BCP 175 states:

"Moving forward, the TZ database, supporting code, and any appropriate
supporting information SHOULD be cryptographically signed prior to
release using well known public keys, along with any appropriate
supporting information and distributed from
<http://www.iana.org/time-zones>."

"The reference implementation shall be distributed along with an
associated cryptographic signature verifiable by a public key."

"Maintenance of a cryptographic private key that is used to sign
the database and that will survive a change of TZ Coordinator."

Looks like 2 and 3 have been achieved but 1 has not yet occurred.

[Paul Eggert]

Post by Peter Remmers
gpg -vv tzdata-latest.tar.gz.asc says the files were signed using key
ID 043DB63744AD418C (or short 44AD418C), but this key isn't to be found
on any keyserver I tried.

I just now submitted it to pgp.mit.edu so you should be able to find it there
after the usual delays. This whole business about signing keys etc. is such a
pain that I plan to go back to the old key for future releases. It's not
entirely clear to me that cryptographically signing the database is worth all
this hassle, to be honest.