Heiko Schaefer 2023-11-30 16:55:50 +01:00
parent 7e339903fc
commit e496ee28e7
No known key found for this signature in database
GPG key ID: DAE9A9050FCCF1EB

View file

@ -149,34 +149,36 @@ Linking a User ID to an OpenPGP certificate
``` ```
(primary-metadata)= (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. 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 - direct key signature on the primary key
- *primary User ID* binding signature - *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 expiration
- key flags - key flags (capabilities)
- features - features
- algorithm preference signaling - algorithm preference signaling
(direct_key_signature)= (direct_key_signature)=
#### 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. 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.
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.
#### Self-signature binding to primary User ID #### 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)= (self-revocations)=
### Revocation self-signatures: Invalidating certificate components ### Revocation self-signatures: Invalidating certificate components