[openpgp] Issuer Fingerprint

[Werner Koch]

Hi!

It is a long time problem in OpenPGP that signatures have no way to
unambiguously specify the key used to create the signature. The specs
suggest the use of the Issuer subpacket to convey the long keyid of the
issuing key. However, it is possible to create colliding 64 bit keyids
and thus it is possible that a user downloads the wrong key for a
signature; this will yield a bad signature status and the user has no
easy means to decide whether this is is really a bad signature, or due
to the use of a colliding public key.

This can easily be solved by including the full fingerprint of the key
in the signature. Introducing such a feature can be made orthogonal to
a new fingerprint format. I propose this change:

--8<---------------cut here---------------start------------->8---
@@ -1055,6 +1055,7 @@ #### {5.2.3.1} Signature Subpacket Specification
30 Features
31 Signature Target
32 Embedded Signature
+ 33 Issuer Fingerprint
100 to 110 Private or experimental

An implementation SHOULD ignore any subpacket of a type that it does
@@ -1615,6 +1616,16 @@ #### {5.2.3.26} Embedded Signature
in Section 5.2 above. It is useful when one signature needs to refer
to, or be incorporated in, another signature.

+#### Issuer Fingerprint
+
+(1 octet key version number, N octets of fingerprint)
+
+The OpenPGP Key fingerprint of the key issuing the signature. The
+only possible key version number is 4 and thus N must be 20. This
+subpacket is intended to eventually replace the issuer subpacket which
+does not not unambiguously specify the key. It SHOULD be part of all
+signatures.
+
### {5.2.4} Computing Signatures

All signatures are formed by producing a hash over the signature data,
--8<---------------cut here---------------end--------------->8---



Shalom-Salam,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* EFH in Erkrath: https://alt-hochdahl.de/haus */

[Joseph Lorenzo Hall]

Sounds like it doesn't make sense to make this optional for signatures as
implicit signature identity could result in attacks where the attacker
changes an implicit identity and signature verification fails?

On Monday, June 13, 2016, Werner Koch <***@gnupg.org> wrote:

> Hi!
>
> It is a long time problem in OpenPGP that signatures have no way to
> unambiguously specify the key used to create the signature. The specs
> suggest the use of the Issuer subpacket to convey the long keyid of the
> issuing key. However, it is possible to create colliding 64 bit keyids
> and thus it is possible that a user downloads the wrong key for a
> signature; this will yield a bad signature status and the user has no
> easy means to decide whether this is is really a bad signature, or due
> to the use of a colliding public key.
>
> This can easily be solved by including the full fingerprint of the key
> in the signature. Introducing such a feature can be made orthogonal to
> a new fingerprint format. I propose this change:
>
> --8<---------------cut here---------------start------------->8---
> @@ -1055,6 +1055,7 @@ #### {5.2.3.1} Signature Subpacket Specification
> 30 Features
> 31 Signature Target
> 32 Embedded Signature
> + 33 Issuer Fingerprint
> 100 to 110 Private or experimental
>
> An implementation SHOULD ignore any subpacket of a type that it does
> @@ -1615,6 +1616,16 @@ #### {5.2.3.26} Embedded Signature
> in Section 5.2 above. It is useful when one signature needs to refer
> to, or be incorporated in, another signature.
>
> +#### Issuer Fingerprint
> +
> +(1 octet key version number, N octets of fingerprint)
> +
> +The OpenPGP Key fingerprint of the key issuing the signature. The
> +only possible key version number is 4 and thus N must be 20. This
> +subpacket is intended to eventually replace the issuer subpacket which
> +does not not unambiguously specify the key. It SHOULD be part of all
> +signatures.
> +
> ### {5.2.4} Computing Signatures
>
> All signatures are formed by producing a hash over the signature data,
> --8<---------------cut here---------------end--------------->8---
>
>
>
> Shalom-Salam,
>
> Werner
>
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
> /* EFH in Erkrath: https://alt-hochdahl.de/haus */
>
> _______________________________________________
> openpgp mailing list
> ***@ietf.org <javascript:;>
> https://www.ietf.org/mailman/listinfo/openpgp
>


--
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: ***@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871

[Werner Koch]

On Tue, 14 Jun 2016 14:25, ***@cdt.org said:
> Sounds like it doesn't make sense to make this optional for signatures as
> implicit signature identity could result in attacks where the attacker
> changes an implicit identity and signature verification fails?

Well, it is a SHOULD feature:

SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

I can imagine valid reasons not to use this; in particular if you want a
very short signature and the key is already known my other means.

An attacker who wants to mount a DoS can simply flip a bit in the
signature to force the verification to fail.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* EFH in Erkrath: https://alt-hochdahl.de/haus */

[Vincent Breitmoser]

Werner Koch(***@gnupg.org)@Tue, Jun 14, 2016 at 03:17:25PM +0200:
> I can imagine valid reasons not to use this; in particular if you want a
> very short signature and the key is already known my other means.

I'd have thought it's mostly an issue of backwards compatibility?

Generally though, I think this type of "there may be valid scenarios",
which make a standard less strict and give more freedom to the
implementation, result in severely hampered interoperability, defeating
the purpose of having a standard in the first place.

- V

[Werner Koch]

On Tue, 14 Jun 2016 15:27, ***@my.amazin.horse said:

> Generally though, I think this type of "there may be valid scenarios",
> which make a standard less strict and give more freedom to the
> implementation, result in severely hampered interoperability, defeating
> the purpose of having a standard in the first place.

I strongly disagree for OpenPGP. The MUSTs, SHOULDs, and MAYs have been
carefully designed and implemented in a sensible way. Thus there are no
real world interoperability problems between OpenPGP implementations.

Case in point, 23 extra bytes make a big difference on embedded systems
if the signature can be encoded in 86 bytes (detached, Ed25519, no
Issuer subpacket). No, this is not a use case you would handle with a
general purpose tool, but OpenPGP should not forbid this use case.
After all we are all better off if a common standard is used also in -
for most people - esoteric use cases.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* EFH in Erkrath: https://alt-hochdahl.de/haus */

[Peter Gutmann]

Werner Koch <***@gnupg.org> writes:

>I strongly disagree for OpenPGP. The MUSTs, SHOULDs, and MAYs have been
>carefully designed and implemented in a sensible way. Thus there are no real
>world interoperability problems between OpenPGP implementations.

Uhh, I'll have to disagree (strongly) with that, perhaps from the point of GPG
this is true since it's the de facto reference implementation that everyone
makes their code compatible with, but when you need to interop across non-GPG
implementations it can get pretty hairy, I've had to reverse-engineer source
code and create instrumented versions of other apps that hex-dump data so I
can see what they're doing. I've also had to do that with GPG on a couple of
occasions where the spec was unclear on which data needed to be processed in
which way. I assume that a lot, if not all, the code out there is written to
be compatible with the GPG de facto profile, in the same way that SSH code is
written to be compatible with the OpenSSH (server) and Putty (client) de facto
profiles.

Peter.

[Werner Koch]

On Fri, 17 Jun 2016 21:02, ***@cs.auckland.ac.nz said:

> Uhh, I'll have to disagree (strongly) with that, perhaps from the point of GPG
> this is true since it's the de facto reference implementation that everyone

Actually that is only the case for a couple of years. Before that we
(GPG team) had to add a lot of of minor things to our code base to make
GPG interoperable with PGP >= 5. Thus back then PGP was the de-facto
reference implementation. True, there has been Tom Ritter's reference
implementation for OpenPGP (also published as a book) but it had not all
the little bells and whistles you need to have for true
interoperability.

> makes their code compatible with, but when you need to interop across non-GPG
> implementations it can get pretty hairy, I've had to reverse-engineer source
> code and create instrumented versions of other apps that hex-dump data so I

Right, RFC-2440 (from 1998) missed to clearly document a couple of
important things. So back then everyone either had to look at the PGP-5
source of PGP-5 (or had someone else to look at it), or to ask Derek or
Jon. In the end this was taken to this list and eventually put into
RFC-4880.

If you, or any of the other implementers, still remember the problems
encountered while writing your OpenPGP code, I would very much
appreciate if you can tell us, so it can make it into 4880bis.

> be compatible with the GPG de facto profile, in the same way that SSH code is
> written to be compatible with the OpenSSH (server) and Putty (client) de facto

Ack. I consider a spec modeled around _one_ existing implementation a
Good Thing.

My statement "The MUSTs, SHOULDs, and MAYs have been carefully designed
" was not meant to say that OpenPGP is a complete and bug free
specification but that it specifies enough to allow the creation of a
mostly *PGP-5 compatible* implementation without asking too much.
Compare that to the majority of other protocols which not only had
interop problems but also no published reference implementation.

BTW: Lacking an integrative implementers forum (like this OpenPGP WG),
your X.509 style guide was the only way forward to write halfway X.509
compatible implementation.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* EFH in Erkrath: https://alt-hochdahl.de/haus */

[Werner Koch]

On Mon, 20 Jun 2016 09:41, ***@gnupg.org said:

> reference implementation. True, there has been Tom Ritter's reference
> implementation for OpenPGP (also published as a book) but it had not all

Ooops, I had the wrong name in mind: That reference implementation is by
Tom Zerucha:

@Book{Cal:99:OPSC,
editor = "Jonathan D. Callas",
title = "OpenPGP Specification and Sample Code",
language = "USenglish",
publisher = "Printers{, Inc}",
addr = "Phone [phone]",
year = "1999",
ISBN = "1-58368-014-4",
note = "Includes Tom Zerucha's implementation",
}



Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* EFH in Erkrath: https://alt-hochdahl.de/haus */

[Daniel Kahn Gillmor]

Hi there--

On Mon 2016-06-13 06:07:33 -0400, Werner Koch wrote:
> --8<---------------cut here---------------start------------->8---
> @@ -1055,6 +1055,7 @@ #### {5.2.3.1} Signature Subpacket Specification
> 30 Features
> 31 Signature Target
> 32 Embedded Signature
> + 33 Issuer Fingerprint
> 100 to 110 Private or experimental
>
> An implementation SHOULD ignore any subpacket of a type that it does
> @@ -1615,6 +1616,16 @@ #### {5.2.3.26} Embedded Signature
> in Section 5.2 above. It is useful when one signature needs to refer
> to, or be incorporated in, another signature.
>
> +#### Issuer Fingerprint
> +
> +(1 octet key version number, N octets of fingerprint)
> +
> +The OpenPGP Key fingerprint of the key issuing the signature. The
> +only possible key version number is 4 and thus N must be 20. This
> +subpacket is intended to eventually replace the issuer subpacket which
> +does not not unambiguously specify the key. It SHOULD be part of all
> +signatures.
> +
> ### {5.2.4} Computing Signatures
>
> All signatures are formed by producing a hash over the signature data,
> --8<---------------cut here---------------end--------------->8---

I like this proposal. I wonder if there should be some text about its
interaction with the Issuer subpacket beyond "is intended to eventually
replace" ? something like "If an Issuer subpacket is included in the
same packet as an Issuer Fingerprint subpacket, the Issuer Fingerprint
subpacket MUST be version 4, and the Issuer subpacket MUST be the low 64
bits of the fingerprint. If the Issuer Fingerprint subpacket version is
greater than 4, there MUST NOT be an Issuer subpacket included in the
same packet."

--dkg

[Werner Koch]

On Tue, 14 Jun 2016 18:29, ***@fifthhorseman.net said:

> replace" ? something like "If an Issuer subpacket is included in the
> same packet as an Issuer Fingerprint subpacket, the Issuer Fingerprint
> subpacket MUST be version 4, and the Issuer subpacket MUST be the low 64

I considered this but decided against it because I view the Issuer
Fingerprint as an extension to OpenPGP which is independent of any v5
work we will do. It seem more naturally to me to add this along with the
description of the v5 format.

However, if we want to prepare Issuer and this new Issuer Fingerprint
for v5 keys, we can also use the final text.

I'll post a second version based on your idea.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* EFH in Erkrath: https://alt-hochdahl.de/haus */

[Werner Koch]

Hi,

here is another try with dkg's suggestions:

--8<---------------cut here---------------start------------->8---
@@ -1055,6 +1055,7 @@ #### {5.2.3.1} Signature Subpacket Specification
30 Features
31 Signature Target
32 Embedded Signature
+ 33 Issuer Fingerprint
100 to 110 Private or experimental

An implementation SHOULD ignore any subpacket of a type that it does
@@ -1155,7 +1156,9 @@ #### {5.2.3.5} Issuer

(8-octet Key ID)

-The OpenPGP Key ID of the key issuing the signature.
+The OpenPGP Key ID of the key issuing the signature. If the version
+of that key is greater than 4, this subpacket MUST NOT be included in
+the signature.

#### {5.2.3.6} Key Expiration Time

@@ -1615,6 +1618,19 @@ #### {5.2.3.26} Embedded Signature
in Section 5.2 above. It is useful when one signature needs to refer
to, or be incorporated in, another signature.

+#### Issuer Fingerprint
+
+(1 octet key version number, N octets of fingerprint)
+
+The OpenPGP Key fingerprint of the key issuing the signature. This
+subpacket SHOULD be included in all signatures. If the version of the
+issuing key is 4 and an Issuer subpacket is also included in the
+signature, the key ID of the Issuer subpacket MUST match the low
+64 bits of the fingerprint.
+
+Note that the length N of the fingerprint for a version 4 key is 20
+octets.
+
### {5.2.4} Computing Signatures

All signatures are formed by producing a hash over the signature data,
--8<---------------cut here---------------end--------------->8---


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
/* EFH in Erkrath: https://alt-hochdahl.de/haus */

[Werner Koch]

Hi!

I have seen no more comments on the second version of an Issuer
Fingerprint signature sub packet. Thus unless I hear a strong opinion
against it by Thursday, I will push that to the repo so that it gets
included in the next draft version. For convenience I copy the diff below.


Salam-Shalom,

Werner

[https://gitlab.com/openpgp-wg/rfc4880bis/issues/3]

--8<---------------cut here---------------start------------->8---
@@ -1055,6 +1055,7 @@ #### {5.2.3.1} Signature Subpacket Specification
30 Features
31 Signature Target
32 Embedded Signature
+ 33 Issuer Fingerprint
100 to 110 Private or experimental

An implementation SHOULD ignore any subpacket of a type that it does
@@ -1155,7 +1156,9 @@ #### {5.2.3.5} Issuer

(8-octet Key ID)

-The OpenPGP Key ID of the key issuing the signature.
+The OpenPGP Key ID of the key issuing the signature. If the version
+of that key is greater than 4, this subpacket MUST NOT be included in
+the signature.

#### {5.2.3.6} Key Expiration Time

@@ -1615,6 +1618,19 @@ #### {5.2.3.26} Embedded Signature
in Section 5.2 above. It is useful when one signature needs to refer
to, or be incorporated in, another signature.

+#### Issuer Fingerprint
+
+(1 octet key version number, N octets of fingerprint)
+
+The OpenPGP Key fingerprint of the key issuing the signature. This
+subpacket SHOULD be included in all signatures. If the version of the
+issuing key is 4 and an Issuer subpacket is also included in the
+signature, the key ID of the Issuer subpacket MUST match the low
+64 bits of the fingerprint.
+
+Note that the length N of the fingerprint for a version 4 key is 20
+octets.
+
### {5.2.4} Computing Signatures

All signatures are formed by producing a hash over the signature data,
--8<---------------cut here---------------end--------------->8---


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

[Werner Koch]

On Mon, 24 Oct 2016 18:55, ***@gnupg.org said:

> I have seen no more comments on the second version of an Issuer
> Fingerprint signature sub packet. Thus unless I hear a strong opinion
> against it by Thursday, I will push that to the repo so that it gets

I just pushed it to the repo and closed issue 3.



Shalom-Salam,

Werner


[https://gitlab.com/openpgp-wg/rfc4880bis/issues/3]

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