
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

On 2016-07-28 03:16, Peter Remmers wrote:
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. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Peter Remmers wrote:
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.
participants (3)
-
Brian Inglis
-
Paul Eggert
-
Peter Remmers