mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-22 23:52:05 +01:00
edit ch8 section on distinct functions of self- v third-party sigs
This commit is contained in:
parent
2340333f40
commit
560f75d703
1 changed files with 8 additions and 10 deletions
|
@ -9,7 +9,7 @@ SPDX-License-Identifier: CC-BY-SA-4.0
|
|||
This chapter examines OpenPGP signatures associated with certificate components, applying to:
|
||||
|
||||
- component keys, encompassing primary keys and subkeys
|
||||
- identity components, namely user IDs and user attributes
|
||||
- identity components, namely User IDs and User attributes
|
||||
|
||||
Signatures on components are used to construct and maintain certificates, and to model the authentication of identities.
|
||||
|
||||
|
@ -52,19 +52,17 @@ 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. Only the certificate's primary holds this key flag.
|
||||
```
|
||||
|
||||
### Self-signatures and third-party signatures convey different meanings
|
||||
### Distinct functions of self-signatures and third-party signatures
|
||||
|
||||
The meaning of a signature depends in part on who issued it. A self-signature performs a different function than the same type of signature issued by a third party.
|
||||
The meaning of an OpenPGP signature depends significantly on its issuer. Self-signatures and third-party signatures, even when of the same type, serve distinct functions. For example:
|
||||
|
||||
For example:
|
||||
- Certifying self-signatures (type IDs `0x10` - `0x13`) bind a User ID to a certificate.
|
||||
- Third-party signatures of the same type IDs endorses the authenticity of a User ID.
|
||||
|
||||
- Certifying self-signatures (type IDs `0x10` - `0x13`) are used to bind a User ID to a certificate, while
|
||||
- third-party signatures of the same type IDs indicate that the signer endorses the authenticity of a User ID.
|
||||
In another instance:
|
||||
|
||||
Or:
|
||||
|
||||
- A [direct key signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) issued as a self-signature can be used to set preferences and advertise features that apply to the whole certificate, while
|
||||
- a similar [direct key signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) issued by a third party delegates trust to the signed certificate, when it carries a [trust signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-trust-signature) subpacket. The issuer thereby configures the signed certificate as a trust root in the *Web of Trust*, for themselves.
|
||||
- *When issued as a self-signature*, a [direct key signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) sets preferences and advertises features applicable to the entire certificate.
|
||||
- *When issued by a third party*, especially when it carries a [trust signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-trust-signature) subpacket, a similar direct key signature delegates trust to the signed certificate. This designates the signed certificate as a trust root within the issuer's *Web of Trust*.
|
||||
|
||||
## Self-signatures: Forming certificates and life-cycle management
|
||||
|
||||
|
|
Loading…
Reference in a new issue