OpenPGPv5 wish list

[Hauke Laging]

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 
the comment?
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 
keys).

3) Double-digest signatures and double-cipher encryption in case one gets 
broken.

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) 
recipients.

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 
other?

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.


Hauke
-- 
☺
PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04)
http://www.openpgp-schulungen.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 572 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20130429/123ded25/attachment-0001.sig>