Why 2.1 is delayed for so long

Ximin Luo infinity0 at pwned.gg
Tue Sep 23 12:14:40 CEST 2014

On 23/09/14 07:27, Werner Koch wrote:
> On Mon, 22 Sep 2014 19:22, infinity0 at pwned.gg said:
>> Whilst we're on this topic, I think the master key should be
>> certify-only by default, and have two subkeys for signing and
>> encryption. This means that someone can later move the master key to
>> separate storage, if they learn more about GPG and decide that this is
>> suitable for them. If you start off with a master key for
>> sign+certify, this is more awkward.
> I disagree.  Two subkeys are the exception and are only used by a
> minority of people who want to put extra work into setting up their WoT.
> We may ask the keyserver admins whether they can figure out the
> percentage of keys which have a separate signing key.
> In any case, adding a signing subkey is simple and it just works for
> everyone as soon as the public key has been uploaded. It is actually
> much easier than replacing the encryption subkey (the  you need to keep
> the old encryption key online for several months to be able to decrypt
> mails from people who didn't refreshed your key yet).

"Two subkeys are the exception" because it's not the default and people don't know better. If it were made the default, it would become the norm. What is the disadvantage to having two subkeys?

You keep knocking down my suggestions because "it's easy [for the user] to do [X]". However, if you keep making arguments like this, the overall effect is that a typical user has to tweak a lot of things to get a maximal level of security, which is not good usability-wise.

Another suggestion is, a revocation certificate should be automatically generated when a key is generated, with clear instructions on the user what to do with it.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140923/ec950b7f/attachment.sig>

More information about the Gnupg-devel mailing list