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?
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?