Updated OpenPGP Security (markdown)
parent
e9e88ce32e
commit
555b41f5f9
|
@ -29,7 +29,7 @@ This is a privacy feature and prevents incidents like http://www.zeit.de/digital
|
||||||
We don't see any advantages in setting an expiry date for OpenPGP keys.
|
We don't see any advantages in setting an expiry date for OpenPGP keys.
|
||||||
* If set, the user is required to extend the key before it reaches the expiry date (-> more interaction needed, less usable).
|
* If set, the user is required to extend the key before it reaches the expiry date (-> more interaction needed, less usable).
|
||||||
* It does not prevent any attack scenario (if set to e.g. 2 years in the future):
|
* It does not prevent any attack scenario (if set to e.g. 2 years in the future):
|
||||||
If a secret key is lost, the public key is still valid for 1 year in average and eventually will be used by others to encrypt stuff.
|
If a secret key is lost, the public key is still valid for 1 year in average and might be used by others to encrypt stuff.
|
||||||
* Some argue that expiry dates help keeping the keyservers clean from valid but unused keys:
|
* Some argue that expiry dates help keeping the keyservers clean from valid but unused keys:
|
||||||
Anyone can upload keys with User IDs containing the email and names of other persons, thus it is easy to flood keyservers with valid keys without the consent of the entity who controls the email address.
|
Anyone can upload keys with User IDs containing the email and names of other persons, thus it is easy to flood keyservers with valid keys without the consent of the entity who controls the email address.
|
||||||
Thus, expiry dates are no valid fix for a much bigger problem that lies in the way OpenPGP keyservers operate currently.
|
Thus, expiry dates are no valid fix for a much bigger problem that lies in the way OpenPGP keyservers operate currently.
|
||||||
|
|
Loading…
Reference in New Issue