[Catalog-sig] PyPI mirror key rollover

["Martin v. Löwis"]

I came up with a key rollover scheme for the server key on PyPI.
The objective of this key rollover is to protect against brute-force
attacks of people trying to crack the key. If the main server itself
gets compromised (and the private key leaks), this scheme will not
help, and we will need to reset the package database back to a
known-safe point in time.

The idea is this: At any point in time, two keys are known - the
"current" key, and the "new" key,

https://pypi.python.org/serverkey
https://pypi.python.org/serverkey.new

There will be a key rollover every year on July 1st. At this point,
the "new" key becomes current, and a new "new" key is generated and
published.

Tools using the mirror infrastructure are encouraged to hard-code
(cache) both keys in their code base, and attempt validation of
a "simple" page against each of them. If both validations fail,
either the keys are outdated, or the mirror they are using has been
compromised. In this case, they should fall back to not using
mirrors, but contact the master directly.

After a key rollover, mirrors will need some time to refetch the
signatures for all "simple" pages, so the old current key may
be needed some time after the key rollover still. Within one
day, all mirrors should have caught up.

Also after a key rollover, tools should update their cached copies
of the keys, and produce new releases. Users will then have one
year to upgrade their tools to continue to use the mirror
infrastructure. Tools may also chose to offer users to update
the serverkeys (after due validation), or may chose to download
them automatically, in which case they should validate the https
server certicate for authenticity of the keys.

The key rollover will be logged in the PyPI journal,
using an empty package name and an empty release. TOOLS USING
THE JOURNAL MAY NEED TO BE FIXED TO ACCOMMODATE EMPTY PACKAGE
NAMES. Earlier today, such a journal entry was already added;
I took it out again when I noticed that some tools actually
do need to be fixed.

Unless some flaws are detected in this scheme, I'll do the first
key rollover this coming July.

Regards,
Martin