Re: [openpgp] Followup on fingerprints

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

OK, so looking through the threads, I think we are talking at cross
purposes due to differences in terminology. For me a fingerprint is a
presentation of a digest to be read by a human.

Getting the nomenclature consistent may seem unimportant but it is actually
50% of getting a spec right. I suggest the following.

We have a sequence of two modules as follows.


Digested content = The input into the fingerprint digest function.

Fingerprint digest function = Some function involving SHA-2/SHA-3 and a
version identifier.

Tagged Digest/Binary Fingerprint = The output from the Fingerprint digest
function.

Presentation Function = Converts the Binary Fingerprint for human
readability. Probably involves truncation, BASE32 and inserting dashes.

Fingerprint = What the user sees.


Internally, the Tagged Digest/Binary Fingerprint is the structure that is
closest to the existing OpenPGP 'fingerprint'.



On Wed, Jul 29, 2015 at 11:06 AM, Werner Koch <[e-mail]> wrote:

> On Wed, 29 Jul 2015 16:31, [e-mail] said:
>
> > On Wed, Jul 29, 2015 at 4:37 AM, Werner Koch <[e-mail]> wrote:
>
> >> OpenPGP does not specify a user interface but the wire format.
> >> Obviously we use the most compact format there which is the plain binary
> >> format.  The questions are
> >>
> >
> > That is how we used to work in the 1990s. Since then we have had to do
> > internationalization and such.
>
> I can't see what internationalization has to do with the binary
> representation of a fingerprint.  As I said RFC-4880 is about the wire
> format and not about user interfaces: It tells how to compute a
> fingerprint and that it is the 16 octet MD5 hash or the 20 octet SHA-1
> hash.  Now that a fingerprint is printed like this
>
> pub   dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31]
>       Key fingerprint = 8061 5870 F5BA D690 3336  86D0 F2AD 85AC 1E42 B367
>
> is the choice of the concrete implementation.  It is an interesting idea
> to have a common way of representing fingerprints to the user or in an
> URL but that is not in the scope of RFC-4800bis.


Back in the 1990s, we could ignore the user interface layer completely.
Those times are past. For OpenPGP to work in the real world, people have to
be able to write fingerpints on their business cards in ways that different
implementations can interpret.

When we designed URLs, they were not designed to be written on the side of
a truck but they were designed to be printed in the references section of a
scientific paper.



> > Yes, totally. I am suggesting we put code points in for the SHA-2-512
> > digest and the SHA-3-512 digest.
>
> Until now we have bound the format of the fingerprint to the version of
> the public key format.  The fingerprint for OpenPGP is a well defined
> and internally used property of OpenPGP.  This avoids multiple
> fingerprints as we see with X.509 which does not have a specification
> for a fingerprint at all.


By 'format of the fingerprint' you seem to be referring to the format in
which the digested content is presented, i.e. the input to the Fingerprint
digest function. I think it is better to have the version specify just the
Fingerprint digest function.

We can get domain separation between OpenPGP versions by putting a content
version somewhere in the Digested Content.



> > My preference is to just truncate and use the inferred length. That
> allows
>
> By truncation I mean an arbitary truncation like what we do with keyids.
> Those 64 keyids are for example used to locally lookup the secret keys
> for decryption - there is no need to have security here because it is
> just a convenience method (cf. wild card keyids)


There are two points at which truncation might occur. The Presentation
module really has to do truncation. Even 256 bits is too many.

We might want to truncate the binary fingerprint to 256 bits as well. The
reason for using SHA-2-512 is more rounds, not to get more output bits.




>
> > This is the 'domain separation' issue that was mentioned in the meeting.
> >
> > I believe that we have to be able to revise the algorithm used to revise
> > the fingerprint and the format of the data being formatted independently.
>
> Again, OpenPGP does not specify how to format a fingerprint.  That is
> and should stay out of scope for _this_ RFC but may be an additional
> item for the WG.


Absolutely. This should be a separate document from RFC4880-BIS



>
> > sufficient would be if a completely radical change to the format was
> being
> > considered such as moving all the structures to YANG, CBOR, JSON or
> JSON-B.
>
> The OpenPGP format is the OpenPGP format and not BER, PER, XML, or JSON.


One of the few things Rudy Guiliani ever said to me that made any sense is
that you can't expect every disaster but you plan for all the disasters you
can imagine and then you are most likely to be prepared for the one that
happens. So planning for an invasion by a zombie hoard might sound like it
is completely nuts. But that sort of planning might come in handy if you
were facing a major outbreak of Ebola.

I think its the same with extensibility. We can't predict every future
possible use of the spec and we shouldn't try. But if we can cover all the
possibilities we can imagine without undue burden on the spec, we maximize
the possibility that someone can build the extension that turns out to be
the killer app.