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.
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?
--
Thijs van Dijk
6A94 F9A2 DFE5 40E3 067E C282 2AFE 9EFA 718B 6165
On 6 September 2016 at 06:47, Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)com>
wrote:
Here is the revised proposed text. I am trying to work out what the
instructions on using gitlab mean. How does making a pull request put
updates into a repo?
There is a piece of technology that I would very much like to propose
using but it is very much encumbered :-( So I am going to propose that
separately and see if we can get the IPR sorted in time to use it. For the
time being it is not in the draft.
[...]
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp