#316 Confirmation dialog should display short, not long keyIDs

[Michael Echerer]

When the confirmation dialog is used, Enigmail shows the key IDs used to encrypt.
These are long key IDs... However all other dialogs like the key management only show the short key IDs. So you cannot match easiliy and see if things work as expected.

Also using CLI gpg options is quite bizzare for long keyIDs, gpg --help is no help and googling, well works.

Probably either show short IDs or add long IDs in the key management for usability reasons. I'm not sure that key ID collisions due to long/short security discussions are really relevant here.

[Devin]

I disagree with this. In fact, I would argue that all displays should move to using full fingerprints. Short keyids are easily spoofed and should not be relied upon for any purpose.

[Daniel Kahn Gillmor]

I agree with Devin here. When displaying information to the user, there are two qualities we care about:

0) human-meaningful data
1) cryptographic integrity (unspoofability)

short keyIDs have neither aspect -- they are not human-meaningful, and they are not cryptographically strong identifiers.

Instinctually, i think that the default prompts should show only human-meaningful data (like User ID, calculated validity, and maybe creation/expiration date), and have a way for advanced users to get access to the full fingerprint if they care about spoofability.

Providing the short keyID provides no advantages i can see.

I've written about this in more detail here:

https://www.debian-administration.org/users/dkg/weblog/105

[Patrick Brunschwig]

Enigmail 2.0 will display the fingerprint or the long key ID thoughout all the application.