mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-22 07:32:05 +01:00
This commit is contained in:
parent
7e339903fc
commit
e496ee28e7
1 changed files with 11 additions and 9 deletions
|
@ -149,34 +149,36 @@ Linking a User ID to an OpenPGP certificate
|
|||
```
|
||||
|
||||
(primary-metadata)=
|
||||
### Adding metadata to the primary key/certificate
|
||||
### Adding global metadata to a certificate
|
||||
|
||||
The signatures that bind subkeys and identity components to a certificate serve dual purposes: linking components to the certificate and adding metadata to components.
|
||||
|
||||
Unlike subkeys and identities, the primary key of a certificate doesn't require a linking signature since it serves as the central anchor of the certificate. However, associating metadata with the primary key is still essential, as it generally applies to the entire certificate.
|
||||
Adding metadata that applies to the entire certificate is also essential, but doesn't require the function of binding any component to the certificate. Instead, for this use case, the signature mechanism is used just to associate metadata globally with the certificate.
|
||||
|
||||
Metadata can be added to the primary key via two mechanisms:
|
||||
Two types of signature can be used to perform this function, for more details see below:
|
||||
|
||||
- direct key signature on the primary key
|
||||
- *primary User ID* binding signature
|
||||
|
||||
The types of metadata typically associated with the primary key through these methods include:
|
||||
The types of metadata typically associated with the certificate through these methods include:
|
||||
|
||||
- key expiration
|
||||
- key flags
|
||||
- key flags (capabilities)
|
||||
- features
|
||||
- algorithm preference signaling
|
||||
|
||||
(direct_key_signature)=
|
||||
#### Direct key signature
|
||||
|
||||
A [*direct key signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) serves as a key mechanism for storing information about the primary key and the entire certificate.
|
||||
|
||||
In OpenPGP v6, a direct key signature is the [preferred mechanism](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.2.3.10-9) for storing algorithm preferences and features.
|
||||
A [*direct key signature*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-direct-key-signature-type-i) serves as the [preferred mechanism](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.2.3.10-9) in OpenPGP v6 for defining metadata for the entire certificate, by associating it with the primary key.
|
||||
|
||||
#### Self-signature binding to primary User ID
|
||||
|
||||
In an OpenPGP certificate, one User ID serves as the [*primary* User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-primary-user-id). The metadata in the binding self-signature on this User ID applies to the certificate's primary key.
|
||||
In OpenPGP v4, another mechanism was often used for this purpose: Piggybacking the global certificate metadata into a User ID binding signature. Specifically, the binding signature of the [*primary* User ID](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-primary-user-id) of the OpenPGP certificate.
|
||||
|
||||
When using this mechanism, the primary User ID binding signature contains a mix metadata: some that applies just to that particular User ID, and some that applies to the certificate, globally.
|
||||
|
||||
Many existing OpenPGP certificates are using this mechanism, so OpenPGP applications need to be able to handle it.
|
||||
|
||||
(self-revocations)=
|
||||
### Revocation self-signatures: Invalidating certificate components
|
||||
|
|
Loading…
Reference in a new issue