vanitasvitae/openpgp-notes
1
0
Fork 0
mirror of https://codeberg.org/openpgp/notes.git synced 2024-11-23 08:02:05 +01:00
Code Issues Projects Releases Packages Wiki Activity

myst markup fixes

Browse source
This commit is contained in:
Heiko Schaefer 2023-10-17 16:06:11 +02:00
parent 9b3d3c51b2
commit 1b95fa95a3
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D
1 changed files with 10 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
book/source/06-certifications.md
View file

@ -56,10 +56,12 @@ Data signatures are always calculated using a **S**igning key.
Certifications are separated into *self-certifications* and *third-party certifications*. Certifications are separated into *self-certifications* and *third-party certifications*.
A certification made by a key over components of the same certificate is referred to as a *self-certification*. A certification made by a key over components of the same certificate is referred to as a *self-certification*.
:::{note}
The **C**certify Others key flag is not required in order to issue self-certifications. ```{note}
The **C**ertify Others key flag is not required in order to issue self-certifications.
It is only necessary to issue valid third-party certifications. It is only necessary to issue valid third-party certifications.
::: ```
A typical use-case for a self-certification is to attach a User ID, such as a name and email address to a certificate. A typical use-case for a self-certification is to attach a User ID, such as a name and email address to a certificate.
This is done by calculating the signature over the User ID and the public primary key. This is done by calculating the signature over the User ID and the public primary key.
The resulting User ID certification (typically type 0x13, potentially type 0x10-0x12) can then be inserted into the certificate, right after the User ID packet. The resulting User ID certification (typically type 0x13, potentially type 0x10-0x12) can then be inserted into the certificate, right after the User ID packet.
@ -309,9 +311,11 @@ There are some subpackets that are expected to be included in any type of signat
* **Signature Creation Time**: Every OpenPGP signature MUST contain a Signature Creation Time subpacket (2) containing the timestamp at which the signature was made. This packet MUST be present in the hashed area of the signature and SHOULD be marked as critical. * **Signature Creation Time**: Every OpenPGP signature MUST contain a Signature Creation Time subpacket (2) containing the timestamp at which the signature was made. This packet MUST be present in the hashed area of the signature and SHOULD be marked as critical.
* **Issuer Fingerprint**: In order to be able to verify a signature, the verifier needs to know, which (sub-)key was used to issue the signature in the first place. Therefore, every OpenPGP v6 signature SHOULD contain an Issuer Fingerprint subpacket (33) containing the 32 byte fingerprint of the particular component key that was used to create the signature. * **Issuer Fingerprint**: In order to be able to verify a signature, the verifier needs to know, which (sub-)key was used to issue the signature in the first place. Therefore, every OpenPGP v6 signature SHOULD contain an Issuer Fingerprint subpacket (33) containing the 32 byte fingerprint of the particular component key that was used to create the signature.
:::{note}
```{note}
The issuer key might be a subkey. The issuer key might be a subkey.
::: ```
Since the issuer fingerprint subpacket is self-authenticating, it can either be included as a hashed or unhashed subpacket, but the authors of this book recommend to place it in the hashed area of the signature. Since the issuer fingerprint subpacket is self-authenticating, it can either be included as a hashed or unhashed subpacket, but the authors of this book recommend to place it in the hashed area of the signature.
### Potential conflicts and duplication ### Potential conflicts and duplication
@ -325,7 +329,7 @@ In some cases, duplicate packets with conflicting content even make sense, e.g.
In this case, either the v3 or v4 key could be used to validate the v4 signature, but since the key ID calculation scheme was changed between v3 and v4, these identifiers would differ. In this case, either the v3 or v4 key could be used to validate the v4 signature, but since the key ID calculation scheme was changed between v3 and v4, these identifiers would differ.
Therefore, the signature could contain two isuer key ID subpackets with conflicting, but correct values. Therefore, the signature could contain two isuer key ID subpackets with conflicting, but correct values.
```{admonition} ```{admonition} TODO
:class: warning :class: warning
- Key Flags - Key Flags