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
