Subject: [openpgp] Issuer Fingerprint

From: Werner Koch <[email-masked]>
Date: Mon, 13 Jun 2016 12:07:33 +0200

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 */

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 14 Jun 2016 08:25:15 -0400

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 <[email-masked]> wrote:

> _______________________________________________
> openpgp mailing list
> [email-masked] <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: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Werner Koch <[email-masked]>
Date: Tue, 14 Jun 2016 15:17:25 +0200

> 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

---

From: Vincent Breitmoser <[email-masked]>
Date: Tue, 14 Jun 2016 15:27:05 +0200

> 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

---

From: Werner Koch <[email-masked]>
Date: Tue, 14 Jun 2016 16:43:23 +0200

> 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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 14 Jun 2016 12:29:35 -0400

Hi there--

> --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

---

From: Werner Koch <[email-masked]>
Date: Tue, 14 Jun 2016 19:18:37 +0200

> 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

---

From: Werner Koch <[email-masked]>
Date: Tue, 14 Jun 2016 19:58:49 +0200

Hi,

here is another try with dkg's suggestions:

 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

Salam-Shalom,

   Werner

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 17 Jun 2016 19:02:05 +0000

Werner Koch <[email-masked]> writes:

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

---

From: Werner Koch <[email-masked]>
Date: Mon, 20 Jun 2016 09:41:01 +0200

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

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

> 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

---

From: Werner Koch <[email-masked]>
Date: Tue, 21 Jun 2016 06:59:24 +0200

> 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 +1 (650) 327-6500",
  year =        "1999",
  ISBN =        "1-58368-014-4",
  note =        "Includes Tom Zerucha's implementation",
}

Shalom-Salam,

   Werner