Re: [openpgp] Followup on fingerprints

[Werner Koch <[e-mail]>]

On Thu, 30 Jul 2015 05:53, [e-mail] said:

> I'm not sure we should try to specify this kind of implementation
> shortcut.  If a machine has a full fingerprint available to it (as it

Please have a look at Public-Key Encrypted Session Key Packets (Tag 1):

| The body of this packet consists of:
| 
|   * A one-octet number giving the version number of the packet
|     type.  The currently defined value for packet version is 3.
| 
|   * An eight-octet number that gives the Key ID of the public key to
|     which the session key is encrypted.  If the session key is encrypted
|     to a subkey, then the Key ID of this subkey is used here instead of
|     the Key ID of the primary key.
| 
|   * A one-octet number giving the public-key algorithm used.

This requires the 64 bit key id.  I doubt that anyone want to change
this basic packet - implementations would need to implement two
different types of these packet for no real benefit.

The ECDH algorithm also needs a 20 byte identification of the key and
thus we need a second truncation type here for non-SHA-1 fingerprints.

Thus having a way to compute a keyid from a fingerprint is required.
Quite some time ago this has already been discussed and the suggestion
was for a future fingerprint format to right truncate it instead of the
left truncation we do right now.

> about this point.  In practice, the fingerprint seems to be most often
> used when there is a human in the loop, and in that scenario, the

The fingerprint is the unique identifier for a key and it has the nice
property that it has a fixed length.  It is used at a lot of places to
represent the key - not necessary for humans.

> textual representation of the fingerprint is indeed relevant.  If two
> humans are comparing fingerprints, or a human wants to pass a

Sure this is important for the use of an OpenPGP implementaions.  But it
is not required for the correct working of the protocol.  The protocol
is independet of the UI.

> The only place where the fingerprint is used explicitly as part of wire
> format in RFC4880 is in the designated revoker subpacket, and on this

And the ECDH algo.

> list in the past there seems to have been no objection to replacing that
> with a full public key packet as a way of avoiding concerns about weak

I see no reason to do this.  It would require a lot of changes in
existing code because both method will need to be supported for backward
compatibility.  If also does not ease the real complexity which is to
evaluate whether that key is still valid (not revoked, not expired
etc.).  Supporting in addition a new type of fingerprint is much
simpler.

> The other place where a fingerprint is used concretely is in HKP, as a
> lookup string.  But again, here, it's not a bit-for-bit wire format.
> The fingerprint in hkp is transmitted as an ascii string of hexadecimal,
> which is human-readable (to map to an HTTP query parameter that a human

This just an encoding required by the keyserver protocol.  It is not
intended for humans.

> As a result, it looks to me like a visual/textual representation of a
> fingerprint could be in-scope for a 4880bis, if the WG wants to take it

If we begin to extend the scope to the UI we have no reason to reject
other UI things.  I do not think this belongs into RFC4880bis.
The human readable format of a fingerprint should either be in
implementations hints or in a separate RFC.



Salam-Shalom,

   Werner


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