initial draft of "naming/fingerprints" section

This commit is contained in:
Heiko Schaefer 2023-11-17 20:14:51 +01:00
parent 3a2d8cad55
commit 060419b34e
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB

View file

@ -437,15 +437,25 @@ Disadvantages/risks of minimizing certificates:
1. Don't minimize certificates unless you have a good reason to
2. When presenting a minimized certificate view, consider when that view needs to be updated. Ideally, minimized certificates are freshly generated, on demand (e.g. the Autocrypt header is constructed while an email is sent or composed) and the client merges all data collected.
### "Naming" a certificate in user-facing contexts - fingerprints and beyond
### Fingerprints and beyond: "Naming" certificates in user-facing contexts
```{admonition} TODO
:class: warning
#### Version 4
In v4, a 20 byte fingerprint in hex representation was used to name certificates, even in user-facing contexts.
With OpenPGP version 4 certificates, it was customary that user-facing software used 20 byte *fingerprints* as an identifier for the certificate. Or alternatively, the shortened 8 byte *Key ID*. Both were represented in hexadecimal format, sometimes with whitespace to group the fingerprint into blocks for easier readability.
For v6, this type of approach is discouraged, but a replacement mechanism is still pending.
```
For example, in workflows to accept a certificate for a communication partner, or during third-party certification of an identity, users were shown hexadecimal representations of a fingerprint, and asked to manually verify that the fingerprint corresponds to the expected certificate.
#### Version 6
The OpenPGP version 6 standard uses 32 byte fingerprints, but explicitly defines no format for displaying those fingerprints in a human-readable form. The standard [recommends strongly against](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-fingerprint-usability) using version 6 fingerprints as identifiers in user-facing workflows.
Instead, "mechanical fingerprint transfer and comparison" should be preferred, wherever possible. The reasoning is that humans tend to be bad at comparing high-entropy data (in addition, many users are probably put off by being asked to compare long hexadecimal strings).
#### Use in APIs
However, both Fingerprints and Key IDs may (and usually *must*) be used, programmatically, by software that handles OpenPGP data, to address specific certificates. This is equally true for OpenPGP version 6.
Note that regardless of the OpenPGP version, software that relies on (8 byte) Key IDs should not assume that Key IDs are unique. It is trivial to generate collisions for Key IDs, so applications must be able to handle Key ID collisions gracefully.
### When are certificates valid?