[openpgp] Fingerprints

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Apr 10, 2015 at 7:38 AM, Stephen Farrell
<[e-mail]> wrote:
>
>
> Hiya, here's the 2nd thread, starting from DKG's list. Please
> discuss... (We don't need +1's for this, just tweaks, corrections,
> additions etc.) If someone wanted to put this on github or
> somewhere else the group can edit it, that'd also be fine.
>
> Ta,
> S.
>
> a) update the fingerprint format (avoid inclusion of creation date, use
>    stronger digest algorithm; i'm dubious about embedding algorithm
>    agility in the fingerprint itself, but explicit version info in the
>    fingerprint might be reasonable so we don't have to keep guessing by
>    fpr structure for future versions)

I would like to get started on this bit ASAP as it is the one that has
the most long term consequences.


There is no need to have an algorithm field, a version field is
sufficient because we should only be using one algorithm at a given
time. There is no need for a length field either.

Right now, I am using a one byte version field for my scheme.

I am also using SHA512 and truncating to 128 bits, then base 32
encoding. The rationale for this is

* Case sensitivity breaks in many applications where fingerprints
might be used. Reading over the telephone, putting them in the DNS,
etc.

* Fingerprints are the root of trust, there is an outside chance that
SHA-2-256 might be broken but breaking SHA-2-512 truncated to 256 bits
is a lot harder because it has 80 rounds rather than 64.

* The birthday attack is not relevant, nor are key substitution
attacks for most situations where you might want to use a fingerprint.
Occasionally however, they do matter. Using SHA-2-512 and truncating
makes it possible to 'upgrade' the fingerprint by just adding back the
bits that were omitted. This has particular advantages when enrolling
fingerprints in a TRANS like log. We can enroll the full 512 bit
fingerprint without impact on things like business cards.


The bit that will probably be controversial is how I am calculating
them, over an X.509v3 KeyInfo block. There is method to the madness
however:

First, fingerprints and key hashes are appearing in many different
IETF specs. We have them in HTTP key pinning and in many other specs.
I would like to be able to use one key fingerprint in any situation.
Adding a key or fingerprint into an identifier allows it to be
'hardened', basically we have a self authenticating identifier. This
is very powerful.

To have one fingerprint format that supports every protocol requires
that we have a single registry of identifiers that can be used for any
protocol. There will always be an OID for any protocol the IETF uses
and this mechanism requires no maintenance by either IETF or IANA. If
people want to use vanity crypto, they can and they don't need to come
to us with a draft. They don't get to claim IETF endorsement either.

As a practical matter, the impact on coding is virtually nil. The
conversion between the ASCII and byte format of OIDs is a bit of a
pain but it results in a byte sequence that can just be prepended to
the key bytes. It is not necessary to implement a DER encoder just to
calculate KeyInfo blobs any more than it is necessary to do this for
implementing PKCS #1 for RSA.

Low level crypto has always involved bits of ad-hoc ASN.1 and probably
always will. And quite often it turns out that even the crypto
libraries that contain full ASN.1 parser/encoders implement these
particular structures by hand.


Now if the group really wants to do something different, then I could
do that. But I want to start shipping my stuff and getting people
using the code.

If people really can't stomach ASN.1 code then we could do some other
key format. But the problem then becomes having to specify how to
express new algorithms in that format.