severity 671810 minor
tags 671810 + upstream
thanks

On Sun, 06 May 2012 20:27:34 MST, Josh Triplett writes:
>The documentation for --sign-key in the duplicity manpage says:
...
>conflicting 8-character key ID.  Please only recommend the use of full
>40-character key fingerprints to identify GPG keys.

i concur that the full key id is a better choice, but i disagree with
your statement that the short key id is insufficient - for duplicity's usage
pattern, that is.

first, sign-key needs the secret key anyway, and there's no way a stray
secret key with clashing short id will ever enter your secret key ring.

second, duplicity doesn't rely on retrieving anybody else's keys from
the keyservers, and it operates only on what's in your gpg keyring already; 
it's primarily dealing with encryption to your own key or some other 
key that you have already told it to trust ('validity', not 'ownertrust'). 
if a key isn't trusted gpg won't encrypt to it.

i'd call it highly unlikely that you'll download a clashing key on purpose
(how? refresh-keys will only refresh existing stuff), and i'd call it even
more unlikely that you will end up with a clashing stray being trusted
(well, if you use --always-trust you get what you deserve...).

>See http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html
>for more information on the security problems with short key IDs.

there is - at worst - a usability problem; please see jon callas' comment
in the document you cite - and the relevant sections of rfc2440 and 4480.

i'll update the docs to mention that all of gnupg's key-id formats 
are accepted and thus remove the bias towards short ids.

regards
az


-- 
Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/
Unix *is* user-friendly. It is not ignorant-friendly and idiot-friendly.

Attachment: signature.asc
Description: Digital Signature

Reply via email to