Subject: [openpgp] Clarifiction on v5 signatures

From: Werner Koch <[email-masked]>
Date: Tue, 23 Oct 2018 12:46:19 +0200

Hi!

The current draft mentions v5 signatures but did not specify them.
Below and in the repo is a fix for that.

The Literal Data packet never included the filename etc into the
signature which is a bit surprising to the user and implementor.  Given
that we specified a new v5 key format we have an easy way to solve this
by requirung that a v5 key must use a v5 signature.  That v5 signature
now includes the meta data from the Literal Data packet.

This patchalso deprecates the creation of v3 signatures.

Any comments?  Can we start to change the existing rfc4880bis
code accordingly?

Shalom-Salam,

   Werner

============
diff --git a/middle.mkd b/middle.mkd
index 9e5bb58..8bbdf3a 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -671,17 +671,16 @@ ## {5.2} Signature Packet (Tag 2)
 some data.  The most common signatures are a signature of a file or a
 block of text, and a signature that is a certification of a User ID.
 
-Two versions of Signature packets are defined.  Version 3 provides
-basic signature information, while version 4 provides an expandable
+Three versions of Signature packets are defined.  Version 3 provides
+basic signature information, while versions 4 and 5 provide an expandable
 format with subpackets that can specify more information about the
 signature.  PGP 2.6.x only accepts version 3 signatures.
 
-Implementations SHOULD accept V3 signatures.  Implementations SHOULD
-generate V4 signatures.
+Implementations MUST generate version 5 signatures when using a
+version 5 key.  Implementations SHOULD generate V4 signatures with
+version 4 keys.  Implementations MUST not create version 3 signatures;
+they MAY accept version 3 signatures.
 
-Note that if an implementation is creating an encrypted and signed
-message that is encrypted to a V3 key, it is reasonable to create a V3
-signature.
 
 ### {5.2.1} Signature Types
 
@@ -924,11 +923,12 @@ ### {5.2.2} Version 3 Signature Packet Format
 truncated) hash function result is treated as a number and used
 directly in the DSA signature algorithm.
 
-### {5.2.3} Version 4 Signature Packet Format
+### {5.2.3} Version 4 and 5 Signature Packet Formats
 
-The body of a version 4 Signature packet contains:
+The body of a V4 or V5 Signature packet contains:
 
-  * One-octet version number (4).
+  * One-octet version number.  This is 4 for V4 signatures and
+    5 for V5 signatures.
 
   * One-octet signature type.
 
@@ -973,8 +973,8 @@ ### {5.2.3} Version 4 Signature Packet Format
       * MPI of EdDSA compressed value s.
 
 The compressed version of R and S for use with EdDSA is described in
-[](#I-D.irtf-cfrg-eddsa).  The version 3 signature format MUST NOT be
-used with EdDSA.
+[](#I-D.irtf-cfrg-eddsa).  A version 3 signature MUST NOT be created
+and MUST NOT be used with EdDSA.
 
 The concatenation of the data being signed and the signature data from
 the version number through the hashed subpacket data (inclusive) is
@@ -988,6 +988,9 @@ ### {5.2.3} Version 4 Signature Packet Format
 protected by the signature and should include only advisory
 information.
 
+The difference between a V4 and V5 signature is that the latter
+creates signatures which include additional meta data.
+
 The algorithms for converting the hash function result to a signature
 are described in a section below.
 
@@ -1102,7 +1105,7 @@ #### {5.2.3.3} Notes on Self-Signatures
 (type 0x1F), and the subkey binding signature (type 0x18).  For
 certification self-signatures, each User ID may have a self-
 signature, and thus different subpackets in those self-signatures.  For
-subkey binding signatures, each subkey in fact has a self- signature.
+subkey binding signatures, each subkey in fact has a self-signature.
 Subpackets that appear in a certification self-signature apply to the
 user name, and subpackets that appear in the subkey self-signature
 apply to the subkey.  Lastly, subpackets on the direct-key signature
@@ -1714,7 +1717,8 @@ ### {5.2.4} Computing Signatures
 of the Signature packet, i.e., 0x04; 0xFF; and a four-octet,
 big-endian number that is the length of the hashed data from the
 Signature packet (note that this number does not include these final
-six octets).  {FIXME: truncated or wrap that number on overflow}
+six octets).  The four-octet big-endian number is considered to be an
+unsigned integer modulo 2^32.
 
 V5 signatures instead hash in a ten-octet trailer: the version of the
 Signature packet, i.e., 0x05; 0xFF; and an eight-octet, big-endian
@@ -2351,9 +2355,10 @@ ## {5.9} Literal Data Packet (Tag 11)
     network-normal line endings).  These should be converted to
     native line endings by the receiving software.
 
-Note that the formatting octet, the file name, and the date field of
-the literal packet are not included in a signature hash and thus are
-not protected against tampering in a signed document.
+Note that V3 and V4 signatures do not include the formatting octet,
+the file name, and the date field of the literal packet in a signature
+hash and thus are not protected against tampering in a signed
+document.  In contrast V5 signatures include them.

 ## {5.10} Trust Packet (Tag 12)
-- 
2.11.0

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Werner Koch <[email-masked]>
Date: Wed, 24 Oct 2018 17:15:58 +0200

> now includes the meta data from the Literal Data packet.

I revisted the new scheme and changed it to make it easier to adapt by
existing implementations.  I also reworked the section on how to create
the the final trailer.  The new text reads:

--8<---------------cut here---------------start------------->8---
5.2.4.  Computing Signatures

   [...]
   Once the data body is hashed, then a trailer is hashed.  This trailer
   depends on the version of the signature.

   o  A V3 signature hashes five octets of the packet body, starting
      from the signature type field.  This data is the signature type,
      followed by the four-octet signature time.

   o  A V4 signature hashes the packet body starting from its first
      field, the version number, through the end of the hashed subpacket
      data and a final extra trailer.  Thus, the hashed fields are:

      *  the signature version (0x04),

      *  the signature type,

      *  the public-key algorithm,

      *  the hash algorithm,

      *  the hashed subpacket length,

      *  the hashed subpacket body,

      *  the two octets 0x04 and 0xFF,

      *  a four-octet big-endian number that is the length of the hashed
         data from the Signature packet stopping right before the 0x04,
         0xff octets.

      The four-octet big-endian number is considered to be an unsigned
      integer modulo 2^32.

   o  A V5 signature hashes the packet body starting from its first
      field, the version number, through the end of the hashed subpacket
      data and a final extra trailer.  Thus, the hashed fields are:

      *  the signature version (0x05),

      *  the signature type,

      *  the public-key algorithm,

      *  the hash algorithm,

      *  the hashed subpacket length,

      *  the hashed subpacket body,

      *  Only for document signatures (type 0x00 or 0x01) the following
         three data items are hashed here:

         +  the one-octet content format,

         +  the file name as a string (one octet length, followed by the
            file name),

         +  a four-octet number that indicates a date,

      *  the two octets 0x05 and 0xFF,

      *  a eight-octet big-endian number that is the length of the
         hashed data from the Signature packet stopping right before the
         0x05, 0xff octets.

      The three data items hashed for document signatures need to mirror
      the values of the Literal Data packet.  For detached signatures 6
      zero bytes are hashed instead.

   After all this has been hashed in a single hash context, the
   resulting hash field is used in the signature algorithm and placed at
   the end of the Signature packet.
--8<---------------cut here---------------end--------------->8---

A possible drawback of these new V5 signatures is that they make it
impossible to convert a detached signatures into a standard signature.
I am not aware of any actual attack due the possibility of converting
From detached to standard signature but it seems to be more safe to
inhibit this.  And well, to protect the file name etc also by the
signature.

Shalom-Salam,

   Werner

---

From: Heiko Stamer <[email-masked]>
Date: Wed, 24 Oct 2018 20:12:35 +0200

Hi Werner,

> Any comments?

https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/12

Best regards,
Heiko.

---

From: Werner Koch <[email-masked]>
Date: Thu, 25 Oct 2018 11:46:45 +0200

> https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/12

Thanks.  For reference, here is the patch:

--8<---------------cut here---------------start------------->8---
--- a/middle.mkd
+++ b/middle.mkd
@@ -1504,8 +1504,6 @@ assume a fixed size.  This is so it can grow over time.  If a list is
 shorter than an implementation expects, the unstated flags are
 considered to be zero.  The defined flags are as follows:
 
-Defined features are as follows:
-
 First octet:
 
     0x01 - This key may be used to certify other keys.
@@ -1527,6 +1525,8 @@ First octet:
 Second octet:
 
     0x04 - This key may be used as an additional decryption subkey (ADSK).
+    
+    0x08 - This key may be used for timestamping.

 Usage notes:
@@ -1822,7 +1822,7 @@ A version 4 Symmetric-Key Encrypted Session Key packet consists of:
 If the encrypted session key is not present (which can be detected on
 the basis of packet length and S2K specifier size), then the S2K
 algorithm applied to the passphrase produces the session key for
-decrypting the file, using the symmetric cipher algorithm from the
+decrypting the message, using the symmetric cipher algorithm from the
 Symmetric-Key Encrypted Session Key packet.
 
 If the encrypted session key is present, the result of applying the
@@ -3676,8 +3676,8 @@ maintained on the proper User Attribute or User ID packet.
 
 After the User ID packet or Attribute packet, there may be zero or
 more Subkey packets.  In general, subkeys are provided in cases where
-the top-level public key is a signature-only key.  However, any V4 key
-may have subkeys, and the subkeys may be encryption-only keys,
+the top-level public key is a signature-only key.  However, any V4 or
+V5 key may have subkeys, and the subkeys may be encryption-only keys,
 signature-only keys, or general-purpose keys. V3 keys MUST NOT have
 subkeys.
--8<---------------cut here---------------end--------------->8---

Salam-Shalom,

   Werner

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Thu, 25 Oct 2018 14:57:36 +0200

> +    0x08 - This key may be used for timestamping.

Is the timestamping flag intentional?

It doesn't seem to be related to v5 signatures.

(Not that I do have anything against it, actually the topic of
timestamping seems to re-surface from time to time on various sites e.g.
https://www.reddit.com/r/GnuPG/comments/9qhbs0/ ).

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor

---

From: Werner Koch <[email-masked]>
Date: Thu, 25 Oct 2018 18:31:00 +0200

> Is the timestamping flag intentional?

I guess so.

> It doesn't seem to be related to v5 signatures.

I posted combined diff of Heiko's pacthes.  Here is his timestamp patch.
IIRC, we have talked in the past about it.

--8<---------------cut here---------------start------------->8---
commit 5ba02a3d8fcb59ceadf4940b51dc3701d0c60ab5
Author: Heiko Stamer <[email-masked]>
Date:   Wed Oct 24 17:57:36 2018 +0000

    Added a flag for keys used for timestamping

	Modified   middle.mkd
diff --git a/middle.mkd b/middle.mkd
index 2d64c0f..c7657d4 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -1504,8 +1504,6 @@ #### Key Flags
 shorter than an implementation expects, the unstated flags are
 considered to be zero.  The defined flags are as follows:

     0x01 - This key may be used to certify other keys.
@@ -1527,6 +1525,8 @@ #### Key Flags
 Second octet:

Salam-Shalom,

   Werner

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Thu, 25 Oct 2018 19:01:45 +0200

> IIRC, we have talked in the past about it.

Oh, got it, I'll try to find the previous discussion. The second octet
key flags (ADSK and timestamping) look really interesting but the
details are scarce as far as I can see. I've been thinking previously
about the possibility of having separate signing subkeys for different
usages (e.g. code-signing subkey on one hardware token, e-mail signing
in a more accessible place).

Thanks for the info!

Kind regards,
Wiktor

---

From: Heiko Stamer <[email-masked]>
Date: Thu, 25 Oct 2018 22:19:31 +0200

Hi Wiktor,

On 25.10.18 19:01, Wiktor Kwapisiewicz wrote:

> Oh, got it, I'll try to find the previous discussion.

Recently there was a short discussion here: https://dev.gnupg.org/T4108
However, this is an old unsolved topic, e.g. see
https://www.ietf.org/mail-archive/web/openpgp/current/msg07136.html

Best regards,
Heiko.

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Thu, 25 Oct 2018 22:32:09 +0200

Hi Heiko,

> https://www.ietf.org/mail-archive/web/openpgp/current/msg07136.html

Very interesting. Actually I'm familiar with OpenTimestamps and RFC 3161
timestamping. I've also used raw Bitcoin transactions to timestamp my
key's fingerprint [0] and recently did a small PoC of using Google's
Roughtime protocol to timestamp arbitrary data.

It's definitely nice to see timestamping being considered in scope of
OpenPGP. I'll keep an eye on T4108.

Thanks for the pointers!

Kind regards,
Wiktor

[0]:
https://keyserver.ubuntu.com/pks/lookup?op=vindex&search=0x6C8857E0D8E8F074

[1]: https://roughtime.googlesource.com/roughtime/

---

From: Werner Koch <[email-masked]>
Date: Fri, 26 Oct 2018 12:13:43 +0200

> key flags (ADSK and timestamping) look really interesting but the

The ADSK (Additional Decryption Subkey) is an idea of mine on how to
ease ease encryption to several devices.  You would install the separate
private subkeys on each device and if the sender supports the ADSK it
would encrypt to these subkeys.  This is similar to what OpenKeychain
does but a more selective approach.  OTOH, I am not sure whether one can
find a threat model where such a scheme would be useful.

We also have 2 other flags (group key and split key) which are also not
well defined, so the ADSK does not hurt too much.  I have no problems to
drop that flag, though.

Salam-Shalom,

   Werner

---

From: Wiktor Kwapisiewicz <[email-masked]>
Date: Fri, 26 Oct 2018 13:19:34 +0200

> find a threat model where such a scheme would be useful.

I think that would be useful to allow creating encryption subkeys
directly on the hardware token (of course with having a backup
encryption subkey on an offline computer too!).

That way when one hardware token is lost one would revoke only the
encryption subkey that was on that token.

This scheme is currently possible only with signing subkeys, ADSK would
extend the idea to encryption subkeys too.

(I assume changing GnuPG behavior to align with OpenKeychain is not
possible due to backwards-compatibility issues?).

> well defined, so the ADSK does not hurt too much.  I have no problems to

Split key (0x10) looks like a good way to implement separation of duties
(where multiple people are needed to use the key). I don't think this is
possible in OpenPGP now.

Thanks for the flag details!

Kind regards,
Wiktor

---

From: Werner Koch <[email-masked]>
Date: Fri, 26 Oct 2018 15:13:55 +0200

> possible due to backwards-compatibility issues?).

AFAIK, OpenKeychain encrypts to all non-expired subkeys.  I think this a
bit to course of an action.  For example if a subkey has been created
with future timestamp to help with key rollover.  Thus the idea to
explicitly mark suitable subkeys.

Shalom-Salam,

   Werner

---

From: Paul Fawkesley <[email-masked]>
Date: Fri, 26 Oct 2018 14:42:45 +0100

Hi folks,

> explicitly mark suitable subkeys.

I feel OpenKeychain's approach here is sensible. Less complexity is
better: it's a huge burden on implementors to support yet-another-flag.

If a key has multiple valid encryption subkeys, it's advertising that
it's OK to pick *any* of those subkeys. That's pretty arbitrary. I don't
see why picking *all* would be any worse than picking an arbitrary one.

> find a threat model where such a scheme would be useful.

Not sure I understand what you mean about threat model here?

A team I previously worked in abandoned email encryption altogether
because they couldn't access emails on their phones.

Now they use unencrypted email - is that the sort of threat model you
were thinking of?

Paul

---

From: Vincent Breitmoser <[email-masked]>
Date: Fri, 26 Oct 2018 20:30:50 +0200

> For example if a subkey has been created with future timestamp to help with
> key rollover.  Thus the idea to explicitly mark suitable subkeys.

We encrypt to all non-expired, non-revoked, already-signed subkeys. Thus a model
to pregenerate keys with future timestamps is already well supported.

We discussed this with Justus some time earlier this year, see
https://github.com/open-keychain/open-keychain/issues/2374

 - V