Updated OpenPGP Security (markdown)

OpenPGP-Security.md

@@ -55,11 +55,21 @@ No real argument here. Just shows that OpenPGP is complex.
 TODO: Yes we must do this. Important TODO
 
 #### Support for Image Attribute Subpacket?
-No, in about 99% of all use cases there are better photos to be found in Android's contact database.
+No, in about 99% of all use cases there are better photos to be found in Android's contact database. Photos are displayed only if a key has been confirmed.
 
-## Fingerprints and key IDs
-* In most places key IDs are useless!
-* https://www.debian-administration.org/users/dkg/weblog/105
+## Why aren't key IDs displayed?
+* Short key IDs (last 32 bits of the key's fingerprint) are trivially to replicate via a [preimage attack](https://en.wikipedia.org/wiki/Preimage_attack). See https://github.com/coruus/cooperpair
+* Two equal long key IDs can be generated using a [collision attack](https://en.wikipedia.org/wiki/Collision_resistance)
+
+We want two things from a key management framework: unforgability, and human-intelligible handles. Key IDs fail at both.
+
+* Fingerprints are unforgable (as much as SHA-1's preimage resistance, anyway -- that's a separate discussion), but they aren't human-intelligible.
+* User IDs are human-intelligible, and they are unforgable if we can rely on a robust keysigning network.
+* Key IDs (both short and long) are neither human-intelligible nor unforgable (regardless of existence of a keysigning network), so they are the worst of all possible worlds. 
+
+So reasonable tools should not expose either short or long key IDs to users, or use them internally if they can avoid them. They do not have any properties we want, and in the worst case, they actively mislead people or lead them into harm. What reasonable tool should do that?
+
+Based on https://www.debian-administration.org/users/dkg/weblog/105 (CC-BY 4.0)
 
 # Key creation