2.0.14 --gen-key interface nit

[David Shaw]

On Mar 22, 2010, at 8:48 AM, MFPA wrote:

>> Howdy,
> 
>> Playing around with key generation there was something
>> banging around in the back of my mind and it finally
>> hit me:
> 
>> Possible actions for a RSA key: Sign Certify Encrypt
>> Authenticate Current allowed actions: Sign Certify
>> Authenticate
> 
>>   (S) Toggle the sign capability (E) Toggle the
>>   encrypt capability (A) Toggle the authenticate
>>   capability (Q) Finished
> 
> The thing that stands out to me is the lack of an option to toggle the
> certify capability.

That is by design, though the reason why is different for primary keys and subkeys.  For primary keys, OpenPGP requires this.  All primary keys must be able to certify.  For subkeys, the web of trust is built between signatures on primary keys, so a certifying subkey would not actually serve any purpose (signatures from it would be ignored).  Note there is no official standard web of trust document that defines this, but it is the convention that all current programs that use the web of trust adhere to.

>> Real name: Douglas Barton Email address:
>> dougb at dougbarton.us Comment: You selected this USER-ID:
>> "Douglas Barton <dougb at dougbarton.us>"
> 
>> Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
> 
>> The Q option behaves inconsistently between these two
>> menus. In the capabilities menu it means "we're done,
>> and all is well;" in the uid section O ("oh") means Ok,
>> but Q bails out of the whole key generation process.
> 
>> The easiest way to fix this would probably be to change
>> the capabilities menu since that's an --expert option.
> 
> I always interpreted the capabilities menu as a sub-menu of the key
> generation process, so it seemed logical that quitting the sub-menu
> would revert to the parent menu.

That was my intent when I added that feature.  That doesn't make it ideal, of course :)

I'm open to changing it, but ideally this would be in a backwards compatible way.

David