From ae59a9edf4dbea4a2f8d8f64f8e31a228a041728 Mon Sep 17 00:00:00 2001 From: Heiko Schaefer Date: Sat, 9 Dec 2023 00:32:39 +0100 Subject: [PATCH] ch6: write "Signature versions" --- book/source/06-signatures.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/book/source/06-signatures.md b/book/source/06-signatures.md index 6416bcc..382a618 100644 --- a/book/source/06-signatures.md +++ b/book/source/06-signatures.md @@ -187,10 +187,15 @@ The recipient's hash algorithm preference is defined in metadata of their certif In this workflow, the signed hash digest is created with a hash algorithm that follows the recipient's preferences, and its intersection with the sender's capabilities and preferences. -### Explore viability of having multiple signatures, e.g. v4+v6? +### Signature versions -```{admonition} TODO -:class: warning +As described in the [RFC](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-signature-packet-type-id-2), the version of a generated signature packet must conform to the version of the key that issues the signature. -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. -``` +That is: + +- OpenPGP version 6 keys must generate version 6 signature packets +- OpenPGP version 4 keys must generate version 4 signature packets + +Note that some historical version 3 signature packets may still be relevant for applications that handle old OpenPGP data[^sig-v3]. These version 3 signature packets will have been generated by version 4 keys. + +[sig-v3]Version 4 signature packets were introduced in [RFC 2440](https://datatracker.ietf.org/doc/html/rfc2440#section-5.2) in 1998, which specifies that applications SHOULD generate v4 signature, however generation of v3 signature packets has remained allowed through [RFC 4880](https://www.rfc-editor.org/rfc/rfc4880.html#section-5.2). \ No newline at end of file