lkml.org 
[lkml]   [2022]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1 1/5] maintainer-pgp-guide: use key terminology consistent with upstream
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

\
 
 \ /
  Last update: 2022-08-02 19:09    [W:0.106 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site