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

ch8: rfc links

Browse source
This commit is contained in:
Heiko Schaefer 2023-10-28 13:20:30 +02:00
parent e2d3fabdc5
commit f9ab3ca17b
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
book/source/08-signing_components.md
View file

@ -50,7 +50,7 @@ The resulting User ID certification (typically type 0x13, potentially type 0x10-
Other examples for self-signatures are binding signatures for subkeys. To add an OpenPGP subkey to a certificate, a subkey binding signature is calculated over the public primary key, followed by the public subkey.
The resulting subkey binding signature (type 0x18) can then be inserted into the certificate right after the subkey.
If the subkey itself is intended to be used as a **S**igning key, an extra step is required.
To prevent an attacker from being able to "adopt" a victims signing subkey and then being able to claim to be the origin of signatures in fact made by victim, subkey binding signatures for signing subkeys need to include an embedded "back signature" (formally known as primary key binding signature) made by the signing key itself.
To prevent an attacker from being able to "adopt" a victims signing subkey and then being able to claim to be the origin of signatures in fact made by victim, subkey binding signatures for signing subkeys need to include an embedded "back signature" (formally known as [primary key binding signature](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#sigtype-primary-binding)) made by the signing key itself.
Certifications over User IDs can also be used to certify certificates of third-parties.
If Alice is certain that `Bob Baker <bob@example.com>` controls the key `0xB0B`, she can create a User ID certification signature for that identity and send it to Bob.
@ -322,10 +322,10 @@ Since the issuer fingerprint subpacket is self-authenticating, it can either be
Since the hashed and unhashed areas of a signature are just lists of subpackets, in principle they allow duplicates of the same subpacket, which might lead to conflicts.
Therefore, packets in the hashed area take precendence over the unhashed area.
However, there may still be conflicts between packets in the same area, e.g. two conflicting expiration dates, etc.
The specification recommends that implementations favor the last occurence of a conflicting packet in the hashed area.
However, there may still be conflicts between packets in the same area, e.g., two conflicting expiration dates, etc.
The [specification recommends](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-notes-on-subpackets) that implementations favor the last occurence of a conflicting packet in the hashed area.
In some cases, duplicate packets with conflicting content even make sense, e.g. if a signature was made by a version 4 issuer key whose key material was migrated from an older OpenPGP version such as v3.
In some cases, duplicate packets with conflicting content even make sense, e.g., if a signature was made by a version 4 issuer key whose key material was migrated from an older OpenPGP version such as v3.
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.