Why 2.1 is delayed for so long

[Ximin Luo]

On 20/09/14 11:23, Werner Koch wrote:
> On Sat, 20 Sep 2014 04:44, infinity0 at pwned.gg said:
> 
> The reason for having the secret material all in one place is the
> standard crypto practice of placing your eggs/keys all into one basket
> and guard them closely.  You may even symlink the private-key-v1.d to share
> them between different (test) installations.
> 

OK, this is less of an issue than I originally thought. My original concern was for applications like caff, that want to do things separately on the side, so as to not pollute the user's keyrings. But looking at them, they all seem to work on public keys only, rather than secret keys.

But maybe a future one will want a separate pool for secret keys. So it would be good to add a --auto-launch-agent option, to automatically launch a new gpg-agent if the current one has a different --homedir.

At least, the manual page should be updated to say --secret-keyring is now ignored (and to point to the new location).

>> * when auto-generating a key, I'm now prompted to input a passphrase
>> for every single subkey. For newly-generated keys, the message is
> 
> Are you sure that you use the latest agent?  Does 
> 
>   gpg-connect-agent 'getinfo version' /bye
> 
> show the right version number (at least 2.1.0-beta834)>
> 

Yes, this is gpg-agent 2.1. I'm using --edit-key --expert then addkey. It prompts me for a passphrase for each new subkey.

>> "Please enter the passphrase for your new key", you should say "Please
>> enter the passphrase for your new ECC key, <UID>, expires
> 
> Good suggestion.  Hoever, I would keep the algorithm out.
> 

Well, at least it should say the keyid, whether it is a subkey (what use-flags) and (if so) which master key it belongs to?

I like the gpg 1.4 prompt - it's informative, when I sign something and it prompts me to unlock, it says:

"You need a passphrase [...] for user <UID>, 4096 RSA, subkey $ID, created $date (main keyid $ID)."

>> * no more documentation describing batch mode? (I hope it is much
>> improved; last time I checked batch mode it was very limited and not
>> fit for purpose; I had to script up the normal CLI instead. [1])
> 
> I don't understand what you mean.  --batch has always been docuemnted as
> not requiring any user input at runtime.
> 

In DETAILS.gz, it now says:

* Unattended key generation
   Please see the GnuPG manual for a description.

Previously (with gpg 1.4) it contained the actual documentation. Perhaps Debian should just package the manual.

With gpg 1.4 (and it seem the case for 2, [2]), there was a bunch of things stopping me from writing this script [1] using batch mode. The main blocker was:

     Subkey-Type: <algo-number>|<algo-string>
        This generates a secondary key.  Currently only one subkey
        can be handled.

but possibly there was more, I can't remember.

[1] https://github.com/infinity0/l33tutils/blob/master/data/security/gpgen.sh
[2] https://www.gnupg.org/documentation/manuals/gnupg-devel/Unattended-GPG-key-generation.html

>> * Instead of having to confirm yet again "Use this curve anyway? (y/N) y" I would just put it in the key selector display:
>>
>> Please select which elliptic curve you want:
>>    (1) Curve 25519 (not yet part of OpenPGP standard!)
> 
> Doing it the inteactive way is more informative and avoids i18n
> (translation) problems.  At some point the prompt will simply be removed.
> 

OK, my motivation was that not having a prompt makes the input flow more consistent, so easier to script with. But probably the best solution is to fix batch mode (and maybe make it work for an existing key) rather than to make the CLI "more scriptable".

>> * I've always thought the key creation descriptions were
>> counter-intuitive. I guess they were intended to be "simple for
>> newbies", but I don't think this goal is achieved, rather it makes it
>> worse. The current descriptions present to the user a mental model
>> that is completely different from what is actually happening
> 
> Maybe.  But most people use a GUI frontend anyway.  Did you know that you
> could enter a '?' on response to all prompt.  You will see a help text
> which can be locally be changed to suite an organizations needs.
> 
>>    (1) RSA (for sign+certify) and RSA subkey (for encryption)
>>    (2) DSA (for sign+certify) and Elgamal subkey (for encryption)
>>    (9) ECC (for sign+certify) and ECC subkey (for encryption)
> 
> Too much details - not a good idea.
> 

How about:

    (1) RSA (sign) and RSA subkey (encryption)

At least, the (9) ECC option should make it clear there are two keys being made. As dkg pointed out, it is extra confusing when mixed with (10) and (11).

    (9) ECC (sign) and ECC subkey (encryption)
    (9) ECC and ECC

This would also match the existing (1) RSA and RSA.

>> I think this is much clearer. Even for newbies, it at least hints to what is going on, which means they can build up a mental model.
> 
> Thus there is the "(default)" marker which is what newbies should do.
> 
>> would better be named:
>>
>>    (7) DSA (set your own signing capabilities)
>>   (11) ECC (set your own signing capabilities)
> 
> I prefer generic strings.  And well, there is just one signing
> capability, the others are called authentication, encryption, and
> certification.
> 

As I understand, C/S/A all treats the public key as a signature scheme. You can tweak the suggestion, e.g. "(set your own capabilities, except encryption)", the point is to distinguish it from keytypes that can actually support all capabilities.

There is no way to "go back" in the CLI, so I have to quit the whole program if I pick the wrong option. Maybe then we can add a "back" option?

>> Also, +1 for getting Curve25519 encryption working...
> 
> Me too, but there are a couple of problems and encryption is not as
> important as signing (i.e. certification).  Adding an encryption subkey
> can be done at any time. In the meantime you can collect key signatures
> if you like.
> 

That is true, and I can use ElGamal in the meantime.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- 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/20140920/ff05e41a/attachment.sig>