From 66087b3ec93167d2b2f62c3607c225a8c1020d3c Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Mon, 9 Oct 2023 19:31:31 +0200 Subject: [PATCH] ch4: clarify terms, use "identity components" --- book/source/04-certificates.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/book/source/04-certificates.md b/book/source/04-certificates.md index 3f442ae..bc1335a 100644 --- a/book/source/04-certificates.md +++ b/book/source/04-certificates.md @@ -125,8 +125,11 @@ It is considered good practice to have separate component keys for each type of [^key-flag-sharing]: With ECC algorithms, it's actually not possible to share encryption functionality with the signing-based functionalities, e.g.: ed25519 used for signing; cv25519 used for encryption. +(identity_components)= ### Identity components +Identity components in an OpenPGP certificate are used by the certificate holder to state that they are known by a certain identifier (like a name, or an email address). + #### User IDs An OpenPGP certificate can contain any number of [User IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-user-id-packet-tag-13). Each User ID associates the certificate with an identity. @@ -165,11 +168,11 @@ Internally, an OpenPGP certificate consists of a sequence of OpenPGP packets. Th [^tpk]: When stored in a file, OpenPGP certificates are in a format called [transferable public key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-transferable-public-keys). -However, the owner of a certificate doesn't want a third party to add subkeys (or add identity claims) to their certificate, pretending that the certificate owner put those components there. +However, the owner of a certificate doesn't want a third party to add subkeys (or add [identity components](identity_components)) to their certificate, pretending that the certificate owner put those components there. To prevent malicious addition of components, OpenPGP uses cryptographic signatures. These signatures show that components have been added by the owner of the OpenPGP certificate (these linking signatures are issued by the primary key of the certificate). -So while anyone can still unilaterally store unrelated subkeys and identity claims in an OpenPGP certificate dataset, OpenPGP implementations that read this file should discard components that don't have a valid cryptographic connection with the certificate. +So while anyone can still unilaterally store unrelated subkeys and [identity components](identity_components) in an OpenPGP certificate dataset, OpenPGP implementations that read this file should discard components that don't have a valid cryptographic connection with the certificate. (Conversely, it's easy for a third party to leave out packets when passing on an OpenPGP certificate. An attacker can, for example, choose to omit revocation packets. The recipient of such a partial copy has no way to notice the omission, without access to a different source for the certificate that contains the revocation packet.)