Subject: [openpgp] Fingerprint schemes versus what to fingerprint

From: Bryan Ford <[email-masked]>
Date: Wed, 6 Apr 2016 15:15:59 -0300

To followup on today’s in-meeting discussion of evolving OpenPGP fingerprints beyond SHA-1, I want to propose that there are at least two orthogonal issues to decide (and I’m probably not the first to suggest this):

1. What fingerprint scheme(s) should OpenPGP move to going forward?

2. What exactly should the OpenPGP “application” fingerprint with that scheme?

To clarify, I propose to define a “fingerprint scheme” as an algorithm that takes a raw octet string and produces an ASCII string of some kind for users to cut-and-paste, compare, read off over the phone, etc.  By this definition, just like a cryptographic “hash scheme” or “signature scheme”, the “fingerprint scheme” itself doesn’t need to know or care what octet string gets fed into it.

As such there’s no reason such a “fingerprint scheme” itself needs to be in any way specific to OpenPGP, and I would support the proposals that Phillip and others have made that it would be ideal to standardize future fingerprint scheme(s) independently of particular protocols such as OpenPGP, and just have OpenPGP use that scheme.  CFRG might be the obvious place to do this.  Of course, I understand the logistical downsides of having an OpenPGP work-item depend on work elsewhere (e.g., CFRG) that isn’t even started yet…  But this approach might still be worth considering from a “get it right” perspective if there isn’t currently some kind of severe time pressure on the OpenPGP side.

The other, very OpenPGP-specific, question is of course what exact octet-string should get fed into whatever fingerprint scheme is chosen.  DKG  brought up the question of whether that octet-string should still include the Unix timestamp like it currently does.  I think that question leads to a bigger set of issues that I’ll try to tease apart in a subsequent E-mail.

But first I just wanted to propose this explicit separation of the two questions, “which fingerprint scheme?” (i.e., which function from octet-strings to ASCII-strings), and “what to fingerprint?” (how does OpenPGP get from a key to the octet-string to feed the fingerprint scheme?).

Thanks
Bryan

---

From: Werner Koch <[email-masked]>
Date: Thu, 07 Apr 2016 08:39:53 +0200

> 1. What fingerprint scheme(s) should OpenPGP move to going forward?

A SHA-256 hash of the artificial OpenPGP key packet as we use it right
now.  The open question is whether to 

  - include a creation timestamp,
  - a timestamp but fixed to 0 (as Google End-to-End does),
  - some other static info data to surely separate that fingerprint from
    other protocols fingerprint using the same key (i.e. token based)
  - no creation timestamp

The rationale for SHA-256 is that this is the only fast algorithm on all
platforms.

A related question is how to identify the new fingerprint scheme in
OpenPGP objects which store a fingerprint:

  - Implicit by the length of the fingerprint,
  - or by a prefix byte with the hash algorithm,
  - or by a prefix byte with the key version number,
  - or by a prefix byte with the length of the fingerprint.

All but the first options allow to store a truncated fingerprint in some
object (the forthcoming Issuer-Fpr signature subpacket, the updated
Revocation Key subpacket).  I tend to prefer the second option because
this reflects existing usage:

  5.2.3.25.  Signature Target

   (1 octet public-key algorithm, 1 octet hash algorithm, N octets hash)

The public-key algorithm byte does not make much sense, though.

> To clarify, I propose to define a “fingerprint scheme” as an algorithm
> that takes a raw octet string and produces an ASCII string of some

You describe how a fingerprint is presented to the user.  This has been
out of scope for OpenPGP.  Implementations have settled for a de-facto
standard outside of the protocol.  I think we should keep it this way
and at best give only a suggestion for a human readable format.

Humans are bad at comparing fingerprints; this should in general be left
to the software and additional protocols to establish a connection
between an identity and a key/fingerprint.

Shalom-Salam,

   Werner

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

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 7 Apr 2016 11:02:50 +0000

Bryan Ford <[email-masked]> writes:

>DKG  brought up the question of whether that octet-string should still
>include the Unix timestamp like it currently does.

Definitely not.  What you want is a means of generating a unique lookup key
(e.g. for a database or hash table) that locates a public key.  By mixing a
nonce, the timestamp, into the calculation, you lose the uniqueness, and in
fact the locatability, because the search key is no longer just a hash of the
public key but a hash of the public key and some other metadata that you may
or may not have.

Peter.

---

From: Werner Koch <[email-masked]>
Date: Thu, 07 Apr 2016 16:17:55 +0200

> public key but a hash of the public key and some other metadata that you may

In other words: With the current fingerprint scheme it is not possible
to find the fingerprint for given public key parameters.  For example
this inhibits the use of arbitrary smartcards because there is no way to
get the fingerprint form the smartcard data.  To help with that we had
to add creation timestamp fields to the OpenPGP smartcard specs.  For
other smartcards special hacks are required.

Some expressed concerns about cross-protocol attacks w/o an OpenPGP
specific fingerprint.  This could be fixed by including a few _constant_
magic bytes into the OpenPGP fingerprint computation.  Similar to the
yesterday proposed signature prefix to distinguish OpenPGP signatures
from signatures uses by other protocols.

Shalom-Salam,

   Werner

---

From: Bryan Ford <[email-masked]>
Date: Thu, 7 Apr 2016 11:44:11 -0300

> On Apr 7, 2016, at 3:39 AM, Werner Koch <[email-masked]> wrote:
> 

What about Blake2?  If OpenPGP will be using Argon2 for password hashing, then all implementations will need to have a Blake2 implementation anyway because Argon2 builds on Blake2.

>  - or by a prefix byte with the length of the fingerprint.

This is tricky: a further related question is how OpenPGP implementations decide what “kind” of fingerprint to produce, or present to the user, or expect to get, when doing something with a particular public key.  As many people have pointed out, it will be terrible for user experience if users have to start juggling “new-style” and “old-style” fingerprints for the same public key: e.g., you sent me your pub key and I want to verify it but your OpenPGP implementation defaulted to the new fingerprint but mine is giving me an old-style fingerprint to compare against.

A couple possible solutions occur:

- Define each pub key scheme as having one and only one corresponding fingerprint scheme.  i.e., all existing/legacy pub key schemes remain stuck with old SHA1 fingerprints and only new pubkeys generated under a new pub key scheme will get new-style fingerprints.  This would have the desirable property of ensuring that users never confusingly see two different legitimate fingerprints for the same public key - but it might mean that we never get to use new fingerprints with RSA/DSA key pairs etc, which may be a non-starter.

- Add a “preferred fingerprint scheme” field of some kind to the self-signed cert that public keys are created with, so it becomes a property like E-mail address etc.  Benefit: users still only ever see one fingerprint for a given public key, SHA1 for old public keys or SHA256 (or whatever) for newly-created public keys, even if the new public key uses an “old” pub key scheme like RSA/DSA.  Drawbacks: implementation complexity; users need to regenerate (or at least re-self-sign) their keys if they want to get a new-style fingerprint for their pre-existing public keys.

> between an identity and a key/fingerprint.

Although it might be good enough to rely in practice on “de facto” standards for fingerprint presentation, it would suck if two users with different OpenPGP implementations had no way at all of comparing/verifying fingerprints because one uses presentation X and the other uses presentation Y and there’s no common ground.  Wouldn’t it at least be worth recommending at least one “common” fingerprint presentation format be supported for cross-implementation verifiability, even if individual implementations might have their own “preferred” presentation/verification mechanism for when both users are using the same implementation?

B

---

From: Werner Koch <[email-masked]>
Date: Thu, 07 Apr 2016 17:15:46 +0200

On Thu,  7 Apr 2016 16:44, [email-masked] said:

> What about Blake2?  If OpenPGP will be using Argon2 for password
> hashing, then all implementations will need to have a Blake2

I was out of the room for some ninutes while this was discussed
yesterday.  I did not assume that this will be a MUST algorithm.

> This is tricky: a further related question is how OpenPGP
> implementations decide what “kind” of fingerprint to produce, or

That is easy: a v4 key creates a v4 fingerprint (SHA-1) and for the new
fingerprint we will requires a v5 key format.  We have a lot of
experience with that given that v3 keys used yet another fingerprint

> present to the user, or expect to get, when doing something with a
> particular public key.  As many people have pointed out, it will be
> terrible for user experience if users have to start juggling
> “new-style” and “old-style” fingerprints for the same public key:

IIRC, we agreed that there will be only one fingerprint format for a
given key.  Obviously this means that existing keys can't use the new
fingerprint format - which is not a problem at all.

> - Define each pub key scheme as having one and only one corresponding
> fingerprint scheme.  i.e., all existing/legacy pub key schemes remain
> stuck with old SHA1 fingerprints and only new pubkeys generated under
[..]
> might mean that we never get to use new fingerprints with RSA/DSA key
> pairs etc, which may be a non-starter.

Why should one not be able to create an RSA, DSA, or ECDSA key with the
new format?  It will take some time until one can switch to the new
format so that most user are able to handles this.  But this
unavoidable in any case.

> - Add a “preferred fingerprint scheme” field of some kind to the

Ah no, this defeats the goal of having a unique fingerprint for one
key.

> Although it might be good enough to rely in practice on “de facto”
> standards for fingerprint presentation, it would suck if two users

It worked well the last 20 years (modulo the need to compare date and
size of the v3 keys).

> with different OpenPGP implementations had no way at all of
> comparing/verifying fingerprints because one uses presentation X and

Let them enter the fingerprint into their GUI and the software does the
match.

Shalom-Salam,

   Werner

---

From: Bryan Ford <[email-masked]>
Date: Thu, 7 Apr 2016 14:50:28 -0300

> experience with that given that v3 keys used yet another fingerprint

Sounds reasonable; I didn’t know that was the precedent for PGP but given so it makes sense to stick to it.

And I’m coming around to agreeing with the KISS position that fingerprints should deterministically depend only on the raw key material.

But I’m still interested in hearing any discussion of the idea of designing the new fingerprint function so that users can (optionally) get some fingerprint-mining protection, as proposed in my other E-mail.

Thanks
Bryan

---

From: Bill Frantz <[email-masked]>
Date: Thu, 7 Apr 2016 12:59:05 -0700

>other protocols fingerprint using the same key (i.e. token based)

If we use the string, "PGP Fingerprint", or some such, we get 
pretty good protection against cross protocol confusion. That 
string could go in the former timestamp field.

>between an identity and a key/fingerprint.

Bryan discussed the issue of verifying keys via fingerprints 
from e.g. business cards -- a procedure I have actually 
performed. And I verified all of the characters in the finger 
print too. :-)

This use case makes a strong case for a standard print format 
for fingerprints, so a fingerprint from one application can be 
input to another application for verification (a very good idea 
Werner), or in true desperation, eyeball verified.

I do not see this use case going away because it allows people 
to eliminate third parties (e.g. web of trust or CAs) and reduce 
the number of different actors they are depending on for their security.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | Re: Hardware Management Modes: | Periwinkle
(408)356-8506      | If there's a mode, there's a   | 16345 
Englewood Ave
www.pwpconsult.com | failure mode. - Jerry Leichter | Los Gatos, 
CA 95032

---

From: Derek Atkins <[email-masked]>
Date: Mon, 11 Apr 2016 11:32:53 -0400

Peter,

> public key but a hash of the public key and some other metadata that you may

Other than Werner's use-case, when would you ever have the raw key
paramters without the metadata and need to generate a fingerprint from
it?

The use cases I can imagine are:

1) You receive a signed message and want to look up the signing public
   key.  In this case, you have the keyID/fingerprint in the signature
   and look it up from there.  Including the timestamp is okay.

2) You receive an encrypted message and want to see if you can decrypt
   it.  Again, in this case there is the keyID/fingerprint in the ESK
   packet, so you can look up the key this way.  Including the timestamp
   is okay.

3) You have a smart card with raw key material and want to see which
   OpenPGP keys are there.  I'm not sure I completely understand this
   use-case, but it's true that you don't have the metadata so cannot
   easily include a timestamp and use that to generate a fingerprint to
   lookup the public key from the raw key material.  But is this a real
   use-case?

4) You receive a business card and want to verify the key using the
   fingerprint.  In this case you have the fingerprint and can use it to
   lookup the key.

*) Other use cases???

So frankly, except for #3 I don't see a use-case where you need to
derive a fingerprint without already having the OpenPGP certificate.
Ergo, including the timestamp (and other metadata) is Just Fine.

Indeed, not including the meta data opens you up to lots of other
cross-protocol issues.  It means that if someone reuses the key material
then you cannot differentiate the original from the subsequent
certificate.  E.g., if I take your certificate, extract the public key,
and then create a new certificate with different timing information on
it, then the fingerprints would be the same.  Granted, existing
signatures would not work for the new certificate, but for a lookup
don't you want these to be considered unique certificates?  I suppose
the counter-argument is that if the metadata is included an attacker
could duplicate that info, too, but then they are literally replicating
your existing key.  That would be like someone taking your public key
certificate and adding their own userID to it.  This is why we require
self-signatures.

> Peter.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Apr 2016 15:41:02 +0000

Derek Atkins <[email-masked]> writes:

>   OpenPGP keys are there. 

That's PKCS #11, which means pretty much all crypto hardware that uses a
standardised interface.

>*) Other use cases???

You have keys stored in a non-PGP format.  It makes keys from anywhere else
pretty much unusable for PGP because you can't look them up.

>It means that if someone reuses the key material then you cannot
>differentiate the original from the subsequent certificate.

That assumes you re-use the same key over and over, rather than just
generating a fresh key when you need one.  That's X.509 practice, not PGP.

Peter.

---

From: "Derek Atkins" <[email-masked]>
Date: Mon, 11 Apr 2016 12:21:39 -0400

Hi,

> That's PKCS #11, which means pretty much all crypto hardware that uses a

Are you expecting this would work in a vacuum?  I.e., would you expect
that you can take your OpenPGP smart card to a fresh system on which
you've never used OpenPGP ever and be able to plug in that smart card and
have it be able to sign a document?

If the answer is "no", then you're fine.  You can have private key lookup
metadata on the OpenPGP system online that gives you the handle to the
PKCS11 key.

If the answer is "yes", then the follow up question is whether there are
additional data available (e.g. storing associated public keys/certs) that
you could use to provide the additional metadata.  But I only see this
being an issue where you want to make a signature (which needs to know
your keyID) using a smartcard on a system that does not contain any
additional metadata.

Is this a real use case?

> pretty much unusable for PGP because you can't look them up.

It depends.  If I've got an X509 cert I can convert that to an OpenPGP
cert, and all the appropriate metadata is there.

I admit I'm not familiar enough with PKCS12 to know what data is included
there, or whether there is enough information in an X509 private key data
file to stand on its own.

> generating a fresh key when you need one.  That's X.509 practice, not PGP.

Yes, it does assume that.

This goes back to my arguments that we should include expiration time in
the key identifier/fingerprint so that there is a hard expiration.  In
order to change that you could copy the key material but it would
necessarily be a new "key" (certificate) because changing the expiration
would change the keyID/fingerprint.

-derek

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Apr 2016 19:21:49 +0000

Derek Atkins <[email-masked]> writes:

>Are you expecting this would work in a vacuum?  I.e., would you expect that
>you can take your OpenPGP smart card to a fresh system on which you've never
>used OpenPGP ever and be able to plug in that smart card and have it be able
>to sign a document?

I'm not sure what OpenPGP cards have to do with this, since I'm talking about
PKCS #11.  I can use a PKCS #11 device with X.509, with S/MIME, with TLS, with
SSH, with IKE, and quite probably with a number of other, lesser-known
Internet security protocols.  The one significant one I can't use it with is
PGP.

>Is this a real use case?

Yes, see above.

>It depends.  If I've got an X509 cert I can convert that to an OpenPGP cert,
>and all the appropriate metadata is there.

You still can't use it with PKCS #11.

Peter.

---

From: "Derek Atkins" <[email-masked]>
Date: Mon, 11 Apr 2016 15:30:43 -0400

Paul,

On Mon, April 11, 2016 3:21 pm, Peter Gutmann wrote:
>> that

Sorry, by "OpenPGP Card" I mean "a smart card to use with OpenPGP".

You can absolutely use PKCS#11 with PGP; there are plenty of instances
today where that is the case.  You just need an implementation where the
secring.skr file contains the reference handle to your smartcard key
materials.

More specifically:  when you have your card generate your key material,
you pull off the public key and then generate your public key, compute
your fingerprint data (including OpenPGP metadata), and also create
secring data
 that contains whatever PKCS#11 reference data you need to re-access that
key.  Later when you use that card/key you know how to reference it.

So what exactly is the issue?

>> cert,

Sure you can.

-derek

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Apr 2016 19:42:33 +0000

Derek Atkins <[email-masked]> writes:

>More specifically:  when you have your card generate your key material, you
>pull off the public key and then generate your public key, compute your
>fingerprint data (including OpenPGP metadata), and also create secring data
>that contains whatever PKCS#11 reference data you need to re-access that key.
>Later when you use that card/key you know how to reference it.

Where do you store all this stuff?  PKCS #11 doesn't provide a means of
storing it, you can search by something like the public key or
issuerAndSerialNumber, but not by hash-of-the-public-key-and-nonce.

Peter.

---

From: "Derek Atkins" <[email-masked]>
Date: Mon, 11 Apr 2016 15:50:56 -0400

Hi,

On Mon, April 11, 2016 3:42 pm, Peter Gutmann wrote:
>> you

Like I said, you put it into your secring.skr file.

-derek

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 11 Apr 2016 20:00:52 +0000

>Like I said, you put it into your secring.skr file.

But you can't store a secring.skr file on a PKCS #11 device.  Or are you
expecting the user to carry around a smart card and a separate USB key with
all the stuff that can't be stored on the smart card, with an app that knows
how to combine all the bits and pieces together to make use of it?

Peter.

---

From: "Derek Atkins" <[email-masked]>
Date: Mon, 11 Apr 2016 16:07:47 -0400

> how to combine all the bits and pieces together to make use of it?

Okay, now I feel like we're going around in circles.  In my VERY FIRST
message I asked whether you are expecting the user to make a signature on
a system that has never used or seen their key material before?

By your lack of answer to that very specific question I went ahead with a
workable architecture where, yes, there are data files that need to be
carried along with the smartcard.  The smartcard is the "protected" data,
but there are other data that need to be carried along, too.

Maybe this isn't as "pure" as using PKCS#11 for X509.  But it certainly is
a workable (and working) solution.

-derek

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 11 Apr 2016 16:28:18 -0700

Peter Gutmann <[email-masked]> writes:

> I'm not sure what OpenPGP cards have to do with this, since I'm
> talking about PKCS #11. I can use a PKCS #11 device with X.509, with
> S/MIME, with TLS, with SSH, with IKE, and quite probably with a number
> of other, lesser-known Internet security protocols. The one
> significant one I can't use it with is PGP.

I have not had any problems using PKCS#11 with GnuPG.
See http://gnupg-pkcs11.sourceforge.net/

Most recently, I have used it with YubiKey NEO and YubiKey4.
See https://www.yubico.com/products/yubikey-hardware/yubikey4/

	-- Mark

---

From: Werner Koch <[email-masked]>
Date: Tue, 12 Apr 2016 18:28:23 +0200

On Thu,  7 Apr 2016 21:59, [email-masked] said:

> fingerprints, so a fingerprint from one application can be input to
> another application for verification (a very good idea Werner), or in

That was not my idea, someone told me that they implemented it in their
software.

Salam-Shalom,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Tue, 12 Apr 2016 18:32:07 +0200

> See http://gnupg-pkcs11.sourceforge.net/

Which uses an internal interface of GnuPG and thus breaks with newer
GnuPG versions.

Shalom-Salam,

   Werner