On Wed, Sep 14, 2016 at 9:39 AM, Thijs van Dijk
<schnabbel(_at_)inurbanus(_dot_)nl>
wrote:
Hi Phillip,
Thanks for clearing that up.
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.
Yes. Out of curiosity, are you currently working with any of the other
five groups to adopt a similar proposal there?
I realise that one has to be the first, and it might as well be us, but I
wouldn't want to be the one to add the n+1'th competing standard. [1]
That is a really bad cartoon to bring up at a standards body.
The point is that we create another standard and THE OTHER ONES DIE. It
really does happen. Before SAML there were 30+ single sign on schemes in
use. Now everything supports SAML.
But in this case we are already proposing a new OpenPGP fingerprint. So
designing that so that other applications can use the same spec is no
additional cost.
The SMIME group has been talking about a fingerprint mode. There is no
guarantee that they will do it. BUT if they do it, they would be doing so
to converge with OpenPGP so it is logical to expect them to do the same
thing.
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.
Ah, so the version ID pertains to the fingerprint method only and not the
underlying key? That's good to know, and probably a good thing to document
for posterity if we choose to adopt this scheme.
In that case I'll have to lower my previous +1 on prepending a version ID.
I'd have loved to have been able to tell at a glance if a fingerprint
belongs to a v5 or a v6 key even if we keep the hash format the same, but I
see now that that isn't going to be possible without downloading the keys
in full.
The current design neither forces the version ID to stay the same nor to
change it. So that isn't a decision we need to take now.
The only thing that forces a change of VersionID is a change in digest
algorithm. Which is probably the thing that would lead to a V6 format
anyway.
Also, one other consequence of prepending a version ID to a key
fingerprint and reading the key ID from the start of the fingerprint rather
than the back is that the Public-Key Encrypted Session Key packet now only
has 24 useful bits of key ID, down from 32.
Which bits OpenPGPv5 uses for the session key can be defined separately.
Since the key must be a v5 key, there is no need for a version ID.
About the text, the last paragraph feels out of place. Did you add it in
anticipation of many backreferences to the term "fingerprint strengthening"
[4], or are you just describing client behaviour? In my understanding, most
operations (verifying a signature, encrypting to someone, etc. [5]) will
require one to have the full public key anyway, not just the fingerprint.
It might therefore be better served by e.g. the following:
I added it out of my usual intent to create as wide a prior art trail as
possible in developing a spec.
```
Client applications MAY import a public key from an external source using
only the short 50-bit key ID as a reference. However, when checking a key's
integrity, applications SHOULD use the full fingerprint for verification.
```
Your thoughts?
I think we should kill fingerprints with a work factor of less than 2^92
as unsafe. No matter what, they just keep coming back and biting in bad
ways.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp