On Wed 2015-07-29 11:06:45 -0400, Werner Koch wrote:
By truncation I mean an arbitary truncation like what we do with keyids.
Those 64 keyids are for example used to locally lookup the secret keys
for decryption - there is no need to have security here because it is
just a convenience method (cf. wild card keyids)
I'm not sure we should try to specify this kind of implementation
shortcut. If a machine has a full fingerprint available to it (as it
does if it has the keys themselves), expecting any lookup to be indexed
by the full fingerprint seems like a reasonable expectation, and there's
no need to get into hashtable-style bucketing implementation details as
part of the RFC.
Again, OpenPGP does not specify how to format a fingerprint. That is
and should stay out of scope for _this_ RFC but may be an additional
item for the WG.
The sense i got of the room in Prague was that there were mixed feelings
about this point. In practice, the fingerprint seems to be most often
used when there is a human in the loop, and in that scenario, the
textual representation of the fingerprint is indeed relevant. If two
humans are comparing fingerprints, or a human wants to pass a
fingerprint to another human on a business card or sticker, then an
unambiguous strong representation (not bits on the wire) is important.
The only place where the fingerprint is used explicitly as part of wire
format in RFC4880 is in the designated revoker subpacket, and on this
list in the past there seems to have been no objection to replacing that
with a full public key packet as a way of avoiding concerns about weak
fingerprinting entirely (i'm hoping we can address this change in
4880bis). So the wire format concerns aren't relevant to this case.
The other place where a fingerprint is used concretely is in HKP, as a
lookup string. But again, here, it's not a bit-for-bit wire format.
The fingerprint in hkp is transmitted as an ascii string of hexadecimal,
which is human-readable (to map to an HTTP query parameter that a human
could type or paste into a web form).
As a result, it looks to me like a visual/textual representation of a
fingerprint could be in-scope for a 4880bis, if the WG wants to take it
on.
sufficient would be if a completely radical change to the format was being
considered such as moving all the structures to YANG, CBOR, JSON or JSON-B.
The OpenPGP format is the OpenPGP format and not BER, PER, XML, or JSON.
If we're suddenly defining an entirely new OpenPGP packet format, then
we could indeed move to one of these other models. But that seems like
a pretty radical change to me, though, and not the incremental
improvement/cleanup we're chartered for.
--dkg
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp