Werner Koch <wk(_at_)gnupg(_dot_)org> writes:
On Fri, 10 Apr 2015 15:23, phill(_at_)hallambaker(_dot_)com said:
There is no need to have an algorithm field, a version field is
sufficient because we should only be using one algorithm at a given
Right. However an algorithm field is as good as a version field because
they have the same purpose in this context. An algorithm field saves us
a mapping to the actual algorithm. Recall that OpenPGP uses an
one-octet indentifier and not an OID.
I'm with Werner on this one. There's not a significant difference
between a version field and an algorithm field. Either option adds a
single byte to the data structure, but using a version field requires
additional lookup map (from fingerprint version # to hash algorithm).
Maybe that's useful to make sure an attacker doesn't use a "bad" hash
algorithm for a fingerprint? But I'd rather just use the hash algorithm
directly.
time. There is no need for a length field either.
Agreed.
It is often useful to have a keyid to quickly (but insecure) refer to a
key. I suggest to take it from the fingerprint bytes 1 to 4 (ignoring
the algorithm byte). There is no need for a long keyid. However, we
may also suggest a use like in git where you may abbreviate it as you
like - however the keyid should be non-normative because the protocol
should not make any use of it.
I presume here you are referring to the "printed" fingerprint, and not
the "internal" fingerprint? Internally we'd still use the full length,
right? Or would we need to somehow know when (and how) to truncate the
hash?
I am also using SHA512 and truncating to 128 bits, then base 32
encoding. The rationale for this is
Because there are several versions of BASE-32 I suggest the use of
z-base-32 which is used by Tahoe-LAFS and ZRTP. The truncation length of
the hash should be match a best match for the base 32 encoding.
Similarly, I think we should be clear that we're talking about two
different things here. Internally (e.g. in a signature packet) it
should be the binary result, not hex- or base-32 encoded.
* Fingerprints are the root of trust, there is an outside chance that
SHA-2-256 might be broken but breaking SHA-2-512 truncated to 256 bits
is a lot harder because it has 80 rounds rather than 64.
I think that should be discussed in the context of the new default hash
algorithm.
The bit that will probably be controversial is how I am calculating
them, over an X.509v3 KeyInfo block. There is method to the madness
X.509 has no definition for a fingerprint but OpenPG already uses a well
defined method to compute the fingerprint. You can't compare the two
protocols or define a unique fingerprint method.
I think "how you take the fingerprint of an X509 key block" should be
out of scope for the OpenPGP WG. I think that you can (and should)
write a separate document that does that.
If people really can't stomach ASN.1 code then we could do some other
key format. But the problem then becomes having to specify how to
We want to do an rfc4880bis and not an entire new protocol. Thus any
ASN.1 encoding is not an option.
Ditto. If the goal here is to have the same key material result in the
same fingerprint regardless of whether it's encoded in OpenPGP or X.509,
I think the answer is going to be "X.509 people are going to need to
convert their key material to OpenPGP packet format and feed into the
hash algorithm". I see no other way, and frankly any other way is
madness (for the OpenPGP group).
I'm sure Phill wont like that answer, but I think it's the right answer
for this (potential) working group.
Salam-Shalom,
Werner
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp