vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2025-09-09 11:19:41 +02:00
Code Issues Projects Releases Packages Wiki Activity

Merge pull request 'tammi edits to paul-ch8-feedback' (#170) from paul-ch8-tammi into paul-ch8-feedback

Browse source 
Reviewed-on: https://codeberg.org/openpgp/notes/pulls/170
This commit is contained in:
heiko 2023-12-04 13:28:08 +00:00
commit b63a5851f7
1 changed files with 9 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

18
book/source/08-signing_components.md
View file

@ -52,7 +52,7 @@ Third-party signatures are used to make specific statements:
The **certify others** [key flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-flags) (`0x01`) is required to issue third-party signatures. By convention[^primary-certification], only the certificate's primary key can hold this key flag.
```
[^primary-certification]: Most implementations currently assume that only the primary key may hold the "certify others" key flag. However, the RFC doesn't clearly specify this limitation.
[^primary-certification]: Most current implementations assume that only the primary key may hold the *certify others* key flag, although this is not specified in the RFC.
### Distinct functions of self-signatures and third-party signatures
@ -72,7 +72,7 @@ Self-signatures play a crucial role in forming and managing the structure of Ope
Internally, an OpenPGP certificate is essentially a series of packets strung sequentially. When a certificate is stored in a file format known as a [transferable public key](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-transferable-public-keys), packets can be easily added or removed.
To safeguard against unauthorized addition or alteration of components, OpenPGP uses cryptographic signatures. These validate that all components, such as subkeys or [identity components](identity_components), were linked to the OpenPGP certificate by its owner, using the primary key. While anyone can still store unrelated elements to a certificate dataset, OpenPGP implementations will reject them if they lack a valid cryptographic connection with the certificate.
To safeguard against unauthorized additions or alterations of components, OpenPGP uses cryptographic signatures. These validate that all components, such as subkeys or [identity components](identity_components), were linked to the OpenPGP certificate by its owner, using the primary key. While anyone can still store unrelated elements to a certificate dataset, OpenPGP implementations will reject them if they lack a valid cryptographic connection with the certificate.
```{note}
Conversely, omissions of packets by third parties can easily occur when handling an OpenPGP certificate dataset. This could pose a challenge, for example, when an attacker deliberately omits revocation packets. Without access to an alternative, complete certificate source, recipients might not detect these omissions.
@ -115,7 +115,7 @@ Binding subkeys that possess the *signing* key flag to a certificate represents
That is, to bind a signing-capable subkey to a primary key, it is insufficient that the "primary key wants to be associated with the subkey." The subkey must explicitly signal that it "wants to be associated with the primary key."
This mutual binding is crucial for security. Without it, an individual (e.g., Alice) could falsely claim a connection to another person's (e.g., Bob's) signing subkey.
As a consequence, Alice could claim to have issued signatures which were in fact issued by Bob.
Alice could thus claim to have issued signatures which were actually issued by Bob.
To prevent such scenarios, where an attacker might wrongfully "adopt" a victim's signing subkey, a dual-layer of signatures is used:
- the [subkey binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-subkey-binding) (type ID `0x18`), which is issued by the certificate's primary key
@ -137,7 +137,7 @@ Self-signatures also play a vital role in binding identity components, such as U
To bind the User ID `Alice Adams <alice@example.org>` to her OpenPGP certificate (`AAA1 8CBB 2546 85C5 8358 3205 63FD 37B6 7F33 00F9 FB0E C457 378C D29F 1026 98B3`), Alice would use a certification signature.
There are four types of *certifying self-signature*. The most commonly used type for binding User IDs is the [positive certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-positive-cert) (type ID `0x13`). Alternatively, types `0x10`, `0x11` or `0x12` might be used. This binding signature must be issued by the primary key.
There are four types of *certifying self-signature*. The most commonly used type for binding User IDs is the [positive certification](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#sigtype-positive-cert) (type ID `0x13`). Alternatively, type `0x10`, `0x11`, or `0x12` might be used. This binding signature must be issued by the primary key.
The certifying self-signature packet – calculated over the primary key, User ID, and metadata of the signature packet – is added to the certificate, directly following the User ID packet.
@ -153,9 +153,9 @@ Linking a User ID to an OpenPGP certificate
The signatures that bind subkeys and identity components to a certificate serve dual purposes: linking components to the certificate and adding metadata to components.
Adding metadata that applies to the entire certificate is also essential, but doesn't require the function of binding any component to the certificate. Instead, for this use case, the signature mechanism is used just to associate metadata globally with the certificate.
While it is essential to add metadata that pertains to the entire certificate, this does not require binding any component to the certificate. In this case, the signature mechanism is used just to associate metadata with the certificate globally.
Two types of signature can be used to perform this function, for more details see below:
Two signature types can perform this function:
- direct key signature on the primary key
- *primary User ID* binding signature
@ -174,11 +174,11 @@ A [*direct key signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-cr
#### Self-signature binding to primary User ID
In OpenPGP v4, another mechanism was often used for this purpose: Piggybacking the global certificate metadata into a User ID binding signature. Specifically, the binding signature of the [*primary* User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-primary-user-id) of the OpenPGP certificate.
In OpenPGP v4, another mechanism was often used for metadata management: integrating global certificate metadata within a User ID binding signature. This is specifically evident in the binding signature of the [*primary* User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-primary-user-id) of the OpenPGP certificate.
When using this mechanism, the primary User ID binding signature contains a mix metadata: some that applies just to that particular User ID, and some that applies to the certificate, globally.
This method results in the primary User ID binding signature containing a mix of metadata: some specific to that User ID and some applicable to the certificate globally.
Many existing OpenPGP certificates are using this mechanism, so OpenPGP applications need to be able to handle it.
Given the widespread adoption of this mechanism in existing OpenPGP certificates, it is crucial that OpenPGP applications recognize and manage it.
(self-revocations)=
### Revocation self-signatures: Invalidating certificate components