Re: [PATCH v1 1/5] maintainer-pgp-guide: use key terminology consistent with upstream

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Sat, Jul 30, 2022 at 09:12:35PM +0800, Wu XiangCheng wrote:
> They use "primary key" in their interface and document.
> 
> For example in their .po file:
> 
> msgid "Note: The public primary key and all its subkeys will be deleted.\n"
> msgid "using subkey %s instead of primary key %s\n"
> 
> Also in gnupg/doc/gpg.texi:
> 
> By specifying the key to export using a key ID or a fingerprint
> suffixed with an exclamation mark (!), a specific subkey or the
> primary key can be exported.  This does not even require that the key
> has the authentication capability flag set.
> 
> Using the new word?

Hmm.. this documentation must be newer than I last looked at it. Still, I
prefer to call it the "certify" key, because "primary key" is also ambiguous:

- "primary" key suggests that other keys are "secondary", which they are not
- "primary key" clashes with "primary identity" in an important way -- you can
  change your primary identity by adding a new one and assigning it a primary
  status, but you cannot add a new certify key

So, I'm sticking with the wording "certify key".

> > +The **[C]** (certification) key is often called the "master" key, but
> 
> Maybe "The key carrying the **[C]**" is better, match the following
> description. As your said, gpg always create a [SC] key by default.

Sure, I will consider this change.

> > +1. All subkeys are fully independent from each other. If you lose a
> > +   private subkey, it cannot be restored or recreated from any other
> > +   private key on your chain.
> > +2. With the exception of the Certify key, there can be multiple subkeys
> > +   with identical capabilities (e.g. you can have 2 valid encryption
> > +   subkeys, 3 valid signing subkeys, but only one valid certification
> > +   subkey). All subkeys are fully independent -- a message encrypted to
> > +   one **[E]** subkey cannot be decrypted with any other **[E]** subkey
> > +   you may also have.
> > +3. A single subkey may have multiple capabilities (e.g. your **[C]** key
> > +   can also be your **[S]** key).
> 
> Reminding the limit of algorithms' capabilities by the way?
> Like: As long as under the algorithm's capabilities.

I think that's unnecessary in this context. Yes, ed25519 keys cannot be used
for encryption (that's for cv25519 keys), but I'm just illustrating that a
single key can have multiple capabilities, so just leaving it at "may" is
enough here, imo.

Thank you for your suggestions.

Regards,
Konstantin