On Mon, 5 Oct 2015 13:44, pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz
said:
Either leave it out or, much better, use an explicit ID stored with the key
rather than one that's implicitly calculated from various bits and pieces
That explicit ID sounds pretty much like a issuer+serialno or one of the
other X.509 methods to identify a key. It is not a fingerprint as we
know it and it can't be used as a secure identification of the key.
surrounding the key. That's how PKCS #15 and (ugh) PKCS #12 do it, it makes
key lookup much less of a pain and avoids the current lost-key problem where
you can't match up a key to a signature even though it's present and
Lost key? Do you mean missing Issuer subpacket (5.2.3.5) or one
pointing two keys with duplicated long keyids? I have never seen the
former and in any case I would consider this a corrupted message. To
fix the latter we will certainly define the use of a fingerprint.
I can't see anything in the charter that would exclude it, it says the work
items "include, but are not limited to ...", and specifically allows for work
that won't unduly delay things and that has support from the WG.
Changing the entire packet structure is not an easy thing and definitely
would delay the listed goals.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp