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 branch 'heiko-ch9' into draft

Browse source
This commit is contained in:
Heiko Schaefer 2023-12-08 01:16:48 +01:00
commit 2277f64b9f
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB
1 changed files with 10 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

17
book/source/09-verification.md
View file

@ -93,7 +93,7 @@ This is required because the issuing component key needs to be qualified to crea
In short, a chain of valid signatures from the signature itself to the primary key of the issuer certificate needs to be established.
For example, a data signature over an email body may be issued by a subkey only if that subkey is validly bound to the issuer's certificate via a subkey binding signature. That binding signature needs to contain a *key flags* subpacket that marks the subkey as *signing* capable.
For example, a subkey may issue a data signature over an email body only if that subkey is validly bound to the issuer's certificate via a subkey binding signature. That binding signature needs to contain a *key flags* subpacket that marks the subkey as *signing* capable.
Similarly, certification signatures over third-party certificates require the issuer key to carry a valid self-signature with the *certification* key flag.
Self-qualifying signatures have no such limitations.
@ -188,14 +188,17 @@ Signatures shadow one another, based on reference time.
Multiple signatures can be attached to an OpenPGP certificate or component. These signatures can contain conflicting information.
When verifying a signature that is not self-qualifying, an implementation needs to consider self-qualifying signatures on the issuer's certificate for qualification.
There might be several signatures per component.
When verifying a signature that is not self-qualifying, an implementation needs to inspect self-qualifying signatures in the issuer's certificate for qualification. The certificate may contain multiple signatures for one component.
For example, there could be multiple subkey binding signatures for one subkey.
In general, for each category of signatures, only the signature with the latest creation time is considered and takes precedence.
For example, there could be multiple subkey binding signatures for one subkey. This could be the case because the expiration time in the original binding signature has expired, and the certificate holder has issued a new binding signature with an extended expiration time.
Alternatively, there might be competing qualifying signatures of different types, e.g., a direct key signature and a self-certification signature on a primary User ID.
In this case, depending on how a key is "addressed," different attributes from both candidates "shadow" another.
In general, for each category of signatures (categories such as binding signatures for one particular subkey), the signature with the latest creation time takes precedence, and only that signature is considered.
Alternatively, there can be competing qualifying signatures of different types, e.g., a direct key signature and a self-certification signature on a primary User ID. Both of these contain metadata associated with the entire certificate. By default, the direct key signature is preferred[^conflicting-prefs] in OpenPGP version 6.
[^conflicting-prefs]: However, the semantics of these cases are not currently fully specified, see [this discussion](https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/103).
Depending on how a certificate is "located," different metadata from possible candidate signatures "shadow" one another. The RFC [states](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-10.html#name-notes-on-self-signatures) that when a certificate is "located" by the OpenPGP software "via an identity", then the metadata associated with that identity takes precedence over more global metadata, such as that associated with the certificate's primary key, with a direct key signature.
```{admonition} TODO
:class: warning