Comment 3 for bug 857472

My understanding of the rationale for the addition of the signature file on the servers is as follows.

 - Provided that you don't have to match the key *size* but only the 8-byte key *ID*, it's very easy to create a collision.
 - The --list-sigs / --check-sigs output from gpg, even using --with-colons, does not include the key size in the output for the signatures, only in the output for the signed key
 - Therefore, it's impossible to tell with this interface whether the signing key is the correct one, with a collision-proof key size, or a fraudulent one with a much smaller key size.

However, if we allow for the requirement that we should *never* be importing the master signing key via the server, then I believe a secure method of validating the keys is possible without changing the server-side API.

 - grab the list of keys in the master keyring.
 - grab the list of new keys from the provided file.
 - for each new key:
   - verify that the key ID does not collide with that of any keys in the master keyring.
     - if it does, skip the key (alternatively: abort the entire operation)
   - export this key into a new temporary keyring
   - using only the master keyring and the new temporary keyring, verify that the new key is signed by a master key
   - if it is, import it
   - clean up the temp keyring

By rejecting any keys whose IDs collide with the master keys, and considering each new key in isolation for signature checking, I believe we eliminate any risk of impersonating the master key (barring cracking of the signing algorithm itself).

Does that seem reasonable, or have I overlooked something?