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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 2 Aug 2022 13:07:42 -0400
From:   Konstantin Ryabitsev <konstantin@...uxfoundation.org>
To:     Wu XiangCheng <wu.xiangcheng@...ux.dev>
Cc:     Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org
Subject: Re: [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