mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Wu XiangCheng <wu.xiangcheng@linux.dev>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v1 1/5] maintainer-pgp-guide: use key terminology consistent with upstream
Date: Sat, 30 Jul 2022 21:12:35 +0800	[thread overview]
Message-ID: <YuUuQ9shkkY7gco4@bobwxc.mipc> (raw)
In-Reply-To: <20220727-docs-pgp-guide-v1-1-c48fb06cb9af@linuxfoundation.org>

[-- Attachment #1: Type: text/plain, Size: 4187 bytes --]

Hi,

话说 Konstantin Ryabitsev 于 2022-07-28 (四) 16:57:04 -0400 曰过:
> GnuPG does not use the word "master key" when referring to the subkey
> marked with the "certification" capability. Our use of this term was not
> only inconsistent, but also misleading, because in real life "master
> keys" are able to open multiple locks made for different keys, while PGP
> Certify key has no such capability.

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?

> 
> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> 
> diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst
> index 29e7d7b1cd44..cdd108f50fe7 100644
> --- a/Documentation/process/maintainer-pgp-guide.rst
> +++ b/Documentation/process/maintainer-pgp-guide.rst
[...]
> +
> +Understanding PGP Subkeys
> +-------------------------
> +
> +A PGP key rarely consists of a single keypair -- usually it is a
> +collection of independent subkeys that can be used for different
> +purposes based on their capabilities, assigned at their creation time.
> +PGP defined four capabilities that a key can have:
> +
> +- **[S]** keys can be used for signing
> +- **[E]** keys can be used for encryption
> +- **[A]** keys can be used for authentication
> +- **[C]** keys can be used for certifying other keys
> +
> +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.

> +this terminology is misleading because it implies that the Certify key
> +can be used in place of any of other subkey on the same chain (like a
> +physical "master key" would). For this reason, this guide will refer to
> +it as "the Certify key" to avoid any ambiguity.
> +
> +It is critical to fully understand the following:
> +
> +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.

> +
> +The key carrying the **[C]** (certify) capability is the only key that
> +can be used to indicate relationship with other keys. Only the **[C]**
> +key can be used to:
>  
>  - add or revoke other keys (subkeys) with S/E/A capabilities
>  - add, change or revoke identities (uids) associated with the key
> @@ -180,7 +190,7 @@ relationship with other keys. Only the **[C]** key can be used to:
>  
>  By default, GnuPG creates the following when generating new keys:
>  
> -- A master key carrying both Certify and Sign capabilities (**[SC]**)
> +- One subkey carrying both Certify and Sign capabilities (**[SC]**)

I suggest to use "primary key" here. Gnupg use it in their doc, and it is
really shown differently when typing --list-keys.

>  - A separate subkey with the Encryption capability (**[E]**)
>  
>  If you used the default parameters when generating your key, then that
[...]

-- 
Thanks,
Wu XiangCheng 
0x32684A40BCA7AEA7


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2022-07-30 13:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-28 20:57 [PATCH v1 0/5] Update the maintainer PGP guide Konstantin Ryabitsev
2022-07-28 20:57 ` [PATCH v1 1/5] maintainer-pgp-guide: use key terminology consistent with upstream Konstantin Ryabitsev
2022-07-30 13:12   ` Wu XiangCheng [this message]
2022-08-02 17:07     ` Konstantin Ryabitsev
2022-07-28 20:57 ` [PATCH v1 2/5] maintainer-pgp-guide: remove keyserver instructions Konstantin Ryabitsev
2022-07-29  1:47   ` Bagas Sanjaya
2022-08-02 17:21     ` Konstantin Ryabitsev
2022-07-28 20:57 ` [PATCH v1 3/5] maintainer-pgp-guide: update ECC support information Konstantin Ryabitsev
2022-07-29  9:11   ` Bagas Sanjaya
2022-08-02 17:16     ` Konstantin Ryabitsev
2022-07-28 20:57 ` [PATCH v1 4/5] maintainer-pgp-guide: add a section on PGP-signed patches Konstantin Ryabitsev
2022-07-28 20:57 ` [PATCH v1 5/5] maintainer-pgp-guide: minor wording tweaks Konstantin Ryabitsev
2022-07-29 22:55   ` Randy Dunlap
2022-08-02 17:09     ` Konstantin Ryabitsev
2022-08-02  9:07 ` [PATCH v1 0/5] Update the maintainer PGP guide Alexander Dahl
2022-08-02 17:00   ` Konstantin Ryabitsev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YuUuQ9shkkY7gco4@bobwxc.mipc \
    --to=wu.xiangcheng@linux.dev \
    --cc=corbet@lwn.net \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®