OpenPGPv5 wish list
mailinglisten at hauke-laging.de
Mon Apr 29 04:37:32 CEST 2013
Am Mo 29.04.2013, 02:34:07 schrieb Philippe Cerfon:
> If there was a redesign of the OpenPGP formats along with e.g. SHA3,
Wishlist opened? :-D
> 1) much more property fields that describe the key holder
That's easy as it can be done with notations; no need to change the protocol.
Other things we IMHO really need notation standards for:
1) How secure is the key?
2) What is the key used for?
3) How was the identity checked when certifying, how the email address and how
4) What statement does this signature make?
> 2) The UID should no longer
You should not be forced to sign a UID as a whole. If I am sure about the name
and email but not about the comment why do I have to decide for all or
nothing? But this could be done with notations as mentioned above.
Things I want in the protocol:
1) For compatibility with the signature laws: We really need the option to
extend certifications from UIDs to subkeys. That way you could have a "normal"
key and a CA could be sure that a certain subkey is on a smartcard only.
2) Officially supported offline main keys. Currently just a GnuPG extension.
IMHO the most important feature with respect to security (for everyday usage
3) Double-digest signatures and double-cipher encryption in case one gets
4) Signature weight: Limit the signing power of a key (to 1/n) so that
signatures of n different keys are enforced for paranoid applications.
5) Seperate header files for encryption. We have detached signatures. Today
you have to rewrite a huge encrypted file if you want to add (or remove)
6) A kind of detached timestamp signature for public key export files. For a
secure revocation system you need to be able to prove when a key was (not yet)
revoked. See the signature laws. Thus we need a way to show that a certain
state of the key is the current one. And this should be done without polluting
the key with daily certifications which you never get rid of. Furthermore this
would offer a guarantee that the key is complete (which we do not have at all
today). This would also reduce the traffic for key servers caused by formal
(reading) updates: The client sends a hash over the key it has and if that is
the same for the key on the key server then the key server just returns the
latest timestamp signature. These signatures could be distributed
independently of the key servers to further reduce the load on the key servers
and get some privacy (hide which keys you are interested in).
Changes to GnuPG:
1) I would like a setting that a certain key makes local signatures only
(unless --expert --i-really-know-what-i... is given). This would make life
easier for beginners (and the people who train them).
2) Besides ownertrust (which I prefer calling certification trust as this may
vary for different keys with the same owner) we should be able to assign a
security value to a key (not for the public, just like ownertrust) and this
should be shown to the applications on top of GnuPG. It seems crazy to me that
the only relevant characteristic of another one's key is its validity. I am
afraid that this behaviour rather obstructs the users' awareness for the
relevant aspects of a crypto system.
3) I would like to have a more flexible trust system. Why only "complete" and
"marginal" trust? Why is it important to work with such groups? Why can this
value not be set for each key, 1.0 for one, 0.7 for the next, 0.1 for the
4) I miss an explicit per key trust calculation. Today we just see the result
(valid, marginally valid or invalid). But if you want to limit possible damage
by allowing only your keys to make others valid then you are lost because you
cannot make GnuPG show you a list of the trust values of signatures.
PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 572 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel