[openpgp] Clarifiction on v5 signatures

[Werner Koch]

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)

[Werner Koch]

Post by Werner Koch
by requirung that a v5 key must use a v5 signature. That v5 signature
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

[Heiko Stamer]

Hi Werner,

Post by Werner Koch
Any comments?

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

Best regards,
Heiko.

[Werner Koch]

Post by Heiko Stamer
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

[Wiktor Kwapisiewicz]

Post by Werner Koch
+
+ 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

[Werner Koch]

Post by Wiktor Kwapisiewicz
Is the timestamping flag intentional?

I guess so.

Post by Wiktor Kwapisiewicz
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 <***@gmx.net>
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:

-Defined features are as follows:
-
First octet:

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

0x04 - This key may be used as an additional decryption subkey (ADSK).
+
+ 0x08 - This key may be used for timestamping.
--8<---------------cut here---------------end--------------->8---


Salam-Shalom,

Werner

[Wiktor Kwapisiewicz]

Post by Werner Koch
I posted combined diff of Heiko's pacthes. Here is his timestamp patch.
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

[Heiko Stamer]

Hi Wiktor,

Post by Wiktor Kwapisiewicz

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

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.

[Wiktor Kwapisiewicz]

Hi Heiko,

Post by Heiko Stamer

Post by Wiktor Kwapisiewicz
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

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/

[Werner Koch]

Post by Wiktor Kwapisiewicz
Oh, got it, I'll try to find the previous discussion. The second octet
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

[Wiktor Kwapisiewicz]

Post by Werner Koch

Post by Wiktor Kwapisiewicz
Oh, got it, I'll try to find the previous discussion. The second octet
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.

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?).

Post by Werner Koch
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.

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

[Werner Koch]

Post by Wiktor Kwapisiewicz
(I assume changing GnuPG behavior to align with OpenKeychain is not
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

[Paul Fawkesley]

Hi folks,

Post by Werner Koch
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.

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.

Post by Werner Koch
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.

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

[Werner Koch]

Post by Paul Fawkesley
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.

Because they might not be intended for encryption of mail or the keys
are offline etc. Further if you use wildcards extra encryption subkeys
are extra annoying.

Post by Paul Fawkesley

Post by Werner Koch
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.

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

A threat model which can be mitigated by having different private
subkeys on each device. The problem is that you want to read the mails
on every device and thus the sender needs to encrypt it to all subkeys.
The compromise of a single device and its subkey will anyway compromise
all your mails encrypted to that set of subkeys. Thus my conclusion is
copying the private key onto all device is much easier.


Shalom-Salam,

Werner

[Vincent Breitmoser]

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

[Heiko Stamer]

Hey Wiktor,

Post by Wiktor Kwapisiewicz
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.

This was one reason to create DKGPG: https://www.nongnu.org/dkgpg/

Currently, there are some efforts at NIST on threshold cryptography:
https://csrc.nist.gov/projects/threshold-cryptography

Best regards,
Heiko.

[Wiktor Kwapisiewicz]

Hi Heiko,

Post by Heiko Stamer

Post by Wiktor Kwapisiewicz
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.

This was one reason to create DKGPG: https://www.nongnu.org/dkgpg/
https://csrc.nist.gov/projects/threshold-cryptography

That's intriguing, thanks for bringing this up, I'll definitely check this out
as this is something I've been thinking of for quite some time.

Kind regards,
Wiktor