A while back, Stephen and I and some others worked on the 'ni' scheme
which is 'naming things with hashes':
https://tools.ietf.org/html/rfc6920
Now I don't suggest we adopt that approach directly for PGP. But I do
wonder why we assume that the only thing it makes sense to name in
this way is going to be a public key.
Hashes are really flexible and they are simple to implement. That is
not true of any PKI, PGP included. So signing binary applications with
PGP is not necessarily a substitute for having a fingerprint of that
application. The same is true when we are dealing with attachments in
many cases.
Which got me thinking, why not leverage MIME content types and make
them a part of the fingerprint scheme?
fingerprint = "application/pgp-key-binary:" + <data-blob>
fingerprint = "application/pkix-keyinfo:" + <data-blob>
fingerprint = "application/trans-log:" + <data-blob>
or:
fingerprint = "application/java:" + <data-blob>
fingerprint = "application/cli:" + <data-blob>
fingerprint = "application/zip:" + <data-blob>
One of the major advantages of this scheme is that if we were to
decide on a future PKI where all the data structures were encoded in
JSON or XML or whatever, we can use the same scheme without having to
revise the version number at all.
Verifiers need to know what they are verifying of course. But that is
usually obvious from the context and is easily specified in any
situation where it isn't.
The impact of this approach on PGP is almost nothing. All it means is
you have to push the string "application/pgp-key-binary:" or whatever
through the hash before the data.
We are certainly going to change the algorithm. So this is not
breaking backwards compatibility.
Making this a fixed string rather than a header eliminates the need
for canonicalization and stops people turning this into a Christmas
tree for their favorite hacks.
I am also thinking that overloading the hash registry is a really bad
idea. To be useful, fingerprints really need to be as consistent as
possible. It is really desirable that everyone uses the same algorithm
(with possibly different truncation lengths).
32 different possible values is probably enough and consumes one
character in Base32. We might want to choose a memorable character (P,
X, Q, whatever). I am assuming a base of 0.
Using truncation rather than the 'spongeworthy' property of SHA3 means
that it is obvious at a glance that the following all relate to the
same thing:
95 bit strength:
AFRTK-NJSMF-STOMR-WG5ST-ONZXGA
145 bit strength:
AFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB-YHE4T
195 bit strength:
AFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB-YHE4T-YHE4T-SYJQM
245 bit strength:
AFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB-YHE4T-YHE4T-SYJQM-YHE4T-SYJQM
95 bits is arguably borderline for a fingerprint but it is about the
limit of what can be fitted onto a business card.
Now lets imagine that I have someone's business card in front of me
and I try to send them an email that I really want to be sent
encrypted and the machine comes back telling me it has verified the
sender key as
AFRTK-NJSMF-STOMR-WG5ST-ONZXGA-YDKZB-YHE4T-YHE4T-SYJQM-YHE4T-SYJQM.
I can look at the card and quickly see that the first five blocks are
correct and lock this into my personal key store.
Given timing, I suggest we define code points for BOTH the SHA-2-512
and SHA-3-512 algorithms now and decide which to make mandatory at a
later date. We should have exactly one mandatory algorithm and exactly
one backup for all crypto algorithms.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp