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

edit new ch6

Browse source
This commit is contained in:
Heiko Schaefer 2023-10-26 18:04:55 +02:00
parent 604c801710
commit 4000e1efdc
No known key found for this signature in database
GPG key ID: 4A849A1904CCBD7D
1 changed files with 47 additions and 35 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

82
book/source/06-signatures.md
View file

@ -14,68 +14,74 @@ Without signatures, there would only be loose keys, impossible to associate with
The term *signature* can have multiple meanings in the context of OpenPGP: The term *signature* can have multiple meanings in the context of OpenPGP:
- Cryptographic keys create raw signatures which are byte sequences calculated according to some signature scheme. - Cryptographic keys create raw signatures which are byte sequences calculated according to some signature scheme.
- OpenPGP packs these raw signatures up into OpenPGP signature packets, which carry additional information in the form of signature subpackets. - [*OpenPGP signature packets*](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-packet-type-id-2), which combine a *type* setting, additional metadata, and a raw cryptographic signature.
For the purpose of this document, the term signature will refer to an OpenPGP [signature packet](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-packet-type-id-2). For the purpose of this document, the term signature will refer to OpenPGP signature packets.
```{admonition} VISUAL
:class: warning
show our visuals for these two layers of meaning:
- "sig-circle", vs
- box with yellow tag-thing, including sig-circle
```
## Structure of an OpenPGP signature
As outlined above, an OpenPGP signature is a composite data structure, which combines:
- A *signature type ID*, which specifies the intended meaning of the signature,
- Metadata (which is variable and depends in part on the type ID),
- Most of this metadata is encoded as so-called "subpackets," see {ref}`signature_subpackets`,
- A raw cryptographic signature.
The cryptographic signature is calculated by its issuer. It certifies a hash digest, which in turn combines a set of input data. The exact input data depends on the signature type. Roughly: the hash digest is over the elements that the OpenPGP signature makes a statement about, combined with the metadata in the OpenPGP signature packet itself. More on this later.
## Types of signatures in OpenPGP ## Types of signatures in OpenPGP
The OpenPGP standard defines a set of [Signature Types](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-types), each identified by a numerical signature type ID. Signature types define the intent of a signature, and how it needs to be interpreted. The OpenPGP standard defines a set of [Signature Types](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-types), each identified by a numerical *signature type ID*. Signature types define the intent of a signature, and how it needs to be interpreted.
```{figure} mermaid/06-terminology.png ```{figure} mermaid/06-terminology.png
An overview of signature types in OpenPGP An overview of signature types in OpenPGP
``` ```
OpenPGP signatures can be classified as either: Most OpenPGP signature types can be classified as either:
- *Signatures on components* (that is: signatures that apply to component keys or identity components), or - *Signatures on components* (that is: signatures that apply to component keys or identity components), or
- *Signatures over data*. - *Signatures over data*.
The same OpenPGP signature mechanism is used for all of these cases. So at first, we will discuss the general shape of OpenPGP signatures.
In this chapter, we discuss the general principles of OpenPGP signatures. In this chapter, we discuss the general principles of OpenPGP signatures.
For more detail about the two classes of signatures, see the chapters {ref}`component_signatures_chapter` and {ref}`signing_data`, respectively. For more detail about specific types of signatures, see the chapters {ref}`component_signatures_chapter` and {ref}`signing_data`, respectively.
## Structure of an OpenPGP signature
However, there are differences in some details of the signatures for these different cases, which we will also look into. The semantics differ between these types of signatures. We'll discuss all of this in this chapter.
XXX: Todo
- type
- what is being signed / hashed
- cryptographic signature co-exists with metadata, in a signature packet
- some of the metadata is encoded as "subpackets"
(signature_subpackets)=
## Signature subpackets ## Signature subpackets
A cryptographic signature alone is often not expressive enough to serve certain use-cases. Just a cryptographic signature, combined with a signature type identifier, is often not sufficiently expressive. For this reason, the OpenPGP protocol introduced signature subpackets (in [RFC 2440](https://datatracker.ietf.org/doc/html/rfc2440)).
For this reason, the OpenPGP protocol introduced signature subpackets with rfc4880.
These are well-defined data structures that can be placed as subelements into signature packets, which give additional context and meaning to a signature.
Typical examples are the issuer fingerprint subpacket, which contains the fingerprint of the issuer key, or the key flags subpacket which states, what purpose a component key is intended for.
Signature subpackets can reside in two different areas of a signature packet. Subpackets are well-defined data structures that can be placed into signature packets as subelements. They give additional context and meaning to a signature. Subpackets encode data in a key-value format. All possible keys are defined in the RFC as [subpacket type IDs](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-subpacket-types-r), and the value format (and meaning) are defined in the RFC for each subpacket type ID.
Subpackets in the *hashed area* are incorporated in the digest calculation that is done during signature calculation and are therefore covered by the cryptographic signature.
In other words; hashed subpackets are *authenticated*.
If a subpacket is placed in the *unhashed area* instead, it is not included in the signature calculation procedure and is therefore not protected against tampering.
The unhashed area can be used to retroactively add, change or remove subpackets from a signature without invalidating it.
Due to the fact that the unhashed area doesn't provide any cryptographic guarantees, it is only intended for advisory packets, or packets that self-authenticate (e.g. the issuer fingerprint subpacket, whose "correctness" can be proven by successfully verifying the signature using the referenced issuer key). Typical examples are:
In most cases, signature subpackets are simply added into the hashed area. - the *issuer fingerprint* subpacket, which contains the fingerprint of the issuer key, or
- the *key flags* subpacket which defines what purpose a component key is used for, in a certificate.
Signature subpackets can reside in two different areas of a signature packet:
- Subpackets in the *hashed area* are incorporated in the digest calculation that is done during signature calculation and are therefore covered by the cryptographic signature. In other words; hashed subpackets are *authenticated*.
- If a subpacket is placed in the *unhashed area* instead, it is not included in the signature calculation procedure and is therefore not protected against tampering. The unhashed area can be used to retroactively add, change or remove subpackets from a signature without invalidating it. Since the unhashed area doesn't provide any cryptographic guarantees, it is only intended for advisory packets, or packets that self-authenticate (e.g. the issuer fingerprint subpacket, whose "correctness" can be proven by successfully verifying the signature using the referenced issuer key).
In most cases, signature subpackets are stored in the hashed area.
### Criticality of subpackets ### Criticality of subpackets
Each signature subpacket has a flag that indicates whether or not the subpacket is *critical*. Each signature subpacket has a flag that indicates whether the subpacket is *critical*.
Since different OpenPGP implementations might support subsets of the standard, it would be fatal, if for example an implementation did not understand the concept of signature expiration.
Such an implementation would potentially accept an already expired signature. Since different OpenPGP implementations might support subsets of the standard, it would be fatal if, for example, an implementation did not understand the concept of signature expiration. Such an implementation would potentially accept an already expired signature.
By marking the expiration date subpacket as critical, the user can indicate, that implementations that do not understand this type of subpacket are supposed to reject the signature as invalid. By marking the expiration date subpacket as critical, the user can indicate that implementations that do not understand this type of subpacket are supposed to reject the signature as invalid.
Sections 5.2.3.11 - 5.2.3.36 give guidance on which subpackets are usually marked as critical. Sections 5.2.3.11 - 5.2.3.36 give guidance on which subpackets are usually marked as critical.
## Advanced topics ## Advanced topics
### Notations ### Notations
@ -83,3 +89,9 @@ Sections 5.2.3.11 - 5.2.3.36 give guidance on which subpackets are usually marke
### "Negotiating" signature hash algorithm based on recipients preference subpackets ### "Negotiating" signature hash algorithm based on recipients preference subpackets
### Explore viability of having multiple signatures, e.g. v4+v6? ### Explore viability of having multiple signatures, e.g. v4+v6?
```{admonition} TODO
:class: warning
C-R 5.2. says: An implementation MUST generate a version 6 signature when signing with a version 6 key. An implementation MUST generate a version 4 signature when signing with a version 4 key.
```