vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-11-27 10:02:06 +01:00
Code Issues Projects Releases Packages Wiki Activity

edit ch4, rewrite 3rd-party certifications

Browse source
This commit is contained in:
Tammi L. Coles 2023-10-21 15:01:50 +02:00
parent 25af6a907a
commit 173d23bb65
1 changed files with 20 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
book/source/04-certificates.md
View file

@ -183,7 +183,7 @@ To form an OpenPGP certificate, individual components are interconnected by the
In very abstract terms, the primary key of a certificate acts as a root of trust or "certification authority." It is responsible for: In very abstract terms, the primary key of a certificate acts as a root of trust or "certification authority." It is responsible for:
- issuing signatures that express the certificate holder's intent to use specific subkeys or identity components. - issuing signatures that express the certificate holder's intent to use specific subkeys or identity components;
- conducting other lifecycle operations, including setting expiration dates and marking components as invalidated or "revoked." - conducting other lifecycle operations, including setting expiration dates and marking components as invalidated or "revoked."
By binding components using digital signatures, recipients of an OpenPGP certificate need only validate the authenticity of the primary key to use for their communication partner. Traditionally, this is done by manually verifying the *fingerprint* of the primary key. Once the validity of the primary key is confirmed, the validity of the remaining components can be automatically assessed by the user's OpenPGP software. Generally, components are valid parts of a certificate if there is a statement signed by the certificate's primary key endorsing this validity. By binding components using digital signatures, recipients of an OpenPGP certificate need only validate the authenticity of the primary key to use for their communication partner. Traditionally, this is done by manually verifying the *fingerprint* of the primary key. Once the validity of the primary key is confirmed, the validity of the remaining components can be automatically assessed by the user's OpenPGP software. Generally, components are valid parts of a certificate if there is a statement signed by the certificate's primary key endorsing this validity.
@ -196,18 +196,33 @@ By binding components using digital signatures, recipients of an OpenPGP certifi
This section needs to be written This section needs to be written
``` ```
## Third party (identity) certifications ## Third-party (identity) certifications
```{admonition} TODO ```{admonition} TODO
:class: warning :class: warning
This section needs writing This section needs to be written
``` ```
Third-party identity certifications have historically played a pivotal role in the OpenPGP ecosystem.
In the past, the SKS keyserver network has accepted third party signatures and added them to certificates without any limitations. This has caused problems: anyone can add a large number of certifications to some certificates, which opens the door to a type of "vandalism", by growing certificates unreasonably, and making them annoying to use[^flooding]. ### Security considerations
[^flooding]: Storing third-party identity certifications in the target OpenPGP certificate is convenient for consumers: it is easy to find all relevant certifications in one central location. However, when third parties can unilaterally add certifications, this opens an avenue for denial-of-service attacks by flooding. The SKS network of OpenPGP key servers [allowed and experienced this problem](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html). While a convenience for consumers, indiscriminately accepting and integrating third-party identity certifications comes with significant risks.
Without any restrictions in place, malicious entities can flood a certificate with excessive certifications. Called "certificate flooding," this form of digital vandalism grossly expands the certificate size, making the certificate cumbersome and impractical for users.
It also opens the door to potential denial-of-service attacks, rendering the certificate non-functional or significantly impeding its operation.
The popular [SKS keyserver network experienced certificate flooding firsthand](https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html), causing it to shut down operations in 2019.
### Improved mechanisms in OpenPGP v6
```{admonition} TODO
:class: warning
This section needs to be written
```
## Advanced topics ## Advanced topics