mirror of
https://codeberg.org/openpgp/notes.git
synced 2025-09-09 11:19:41 +02:00
minor edit
This commit is contained in:
parent
03515927b3
commit
4f73c0a917
1 changed files with 2 additions and 1 deletions
|
@ -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.
|
||||
|
@ -192,6 +192,7 @@ When verifying a signature that is not self-qualifying, an implementation needs
|
|||
There may be several signatures per 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.
|
||||
|
||||
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.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue