On Mon, Sep 12, 2016 at 9:27 AM, Thijs van Dijk
<schnabbel(_at_)inurbanus(_dot_)nl>
wrote:
Hi Phillip,
As promised, I'll post my two cents' worth about your proposal.
In your talk last Thursday, you've revealed some details about the larger
design of which this V5 fingerprint proposal is a part. I can see now you
weren't kidding when you described it as "encumbered." Though your talk was
certainly interesting, I'll try and stay on topic and evaluate your
proposal as a self-contained unit rather than as a tiny part of a larger
design.
The only part that I believe is encumbered is the 'work hardening' scheme
that is not currently in the drafts at all. All the rest is pretty well
covered by prior art, albeit that is not an absolute guarantee.
To wit:
+1 on dropping SHA-1 in favour of SHA-2. This is kind of a no-brainer.
+1 on prepending a version number to the output for futureproofing.
?? on embedding a content-ID field in the final hash input.
+1 on changing the default fingerprint representation from hex to base32.
+1 on changing the definition of the short/long key ID to n bits from the
start rather than from the end, so even the truncated versions will include
the version ID.
On the content-ID, it's unclear from the above draft which problem you're
trying to solve.
If I were to guess, I
'd say it would open the door to unification of OpenPGP and X509 somewhat,
but currently it's not obvious how exactly this fingerprint format would
help. Could you elaborate a bit?
Today there are several formats that are regularly used to describe trust
anchors:
PGP Key format
X.509 / PKIX root cert
Certificate Trust List (Microsoft)
SSH Public Key format
SAML
DNSSEC
It would be really nice if we could all use the same format to identify a
root of trust. But that is of course not going to happen unless we can get
all six of the major PKI infrastructures to agree on one approach and that
probably isn't even desirable.
The traditional way to solve this problem is with a URI type scheme:
OpenPGP:mwj3e-wj3id-2kqai-2iwiq
But that uses up a lot of bits and not for any real purpose because all you
have is a fingerprint, you don't know how to interpret those bits.
The idea of putting the content-type into the fingerprint calculation is
that it allows each of the six applications described to make use of one
fingerprint format without risk of someone working out how to cause a
semantic attack by confusing one content type for another. It would of
course be a bad thing if someone could generate an OpenPGP key that turns
out to be a legal X.509v3 certificate.
The other reason for having the content-id in is to allow versioning within
OpenPGP. So for example, lets say that there is a V6 key format but we
don't want to change the digest value. We can change the OpenPGP content
definition format as many times as we like without having to use up any of
those scarce fingerprint version IDs.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp