jharris at widomaker.com
Wed Dec 15 20:36:29 CET 2004
On Tue, Dec 14, 2004 at 10:36:19PM -0500, David Shaw wrote:
> On Tue, Dec 14, 2004 at 09:34:20PM -0500, Yaron Minsky wrote:
> > > On Tue, Dec 14, 2004 at 07:17:48PM -0500, Jason Harris wrote:
> > > > Not "the entire Public Key packet starting with the version field,
> > > > with whatever fixes you have to make so the key is fully
> > > > RFC-compliant."
> > starting with the version field. It seems like a mistake to calculate
> > the fingerprint of a "corrected" version of the key.
> The RFC does say that, but it is not the whole story. It also says:
> The length field of an MPI describes the length starting from its
> most significant non-zero bit. Thus, the MPI [00 02 01] is not
> formed correctly. It should be [00 01 01].
> MPIs with leading zeros are not RFC compliant.
> > this way. That said, I'm not eager to fix it, since the keys in
> > question are clearly broken, and, I'm hoping, quite rare.
> Which is exactly my point. The keys are made up of noncompliant MPIs.
> The keys are thus corrupt/broken/not RFC compliant. Whatever we call
> it, the keys are outside the purview of the RFC. There is no language
> in the RFC that dictates how a program should handle a noncompliant
> key. This is a good thing, since questions like this can rapidly
> spiral out of control - how much corruption is too much?
Keys like this with non-compliant MPIs don't have valid selfsigs -
unless and until the MPI is fixed _and_ the keyids in the selfsigs
are changed to match the correct[ed] keyid. Then, the key can
be imported and used for signature verification and/or encryption.
However, the keyholder - as long as their software continues to be
broken - will perpetually report the wrong key fingerprint and thus
nobody should be willing to sign/trust the key.
> So given that noncompliant keys are outside the purview of the RFC, it
> is correct to canonicalize the MPIs in an effort to "rescue" the key.
> It is also correct to do nothing. It is also correct to reject the
> key altogether.
It is best to reject the key and issue a warning, to stay consistent
with GPG's rejection of unsigned subkeys and (default) rejection of
Actually, this kinda happens now:
%gpg --recv 3A546EC2
gpg: requesting key 3A546EC2 from hkp://keyserver.kjsl.com
gpg: request is "x-hkp://keyserver.kjsl.com/pks/lookup?op=get&search=0x3A546EC2"
gpg: key 7EDB7A47: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg: w/o user IDs: 1
but can be circumvented with --allow-non-selfsigned-uid. However, the
imported key lacks a subkey and the selfsigs are useless, being from
0x3A546EC2 instead of 0x7EDB7A47.
Interestingly, 0x7EDB7A47 somehow has (valid) selfsigs made two days
after its creation and 0x3A546EC2 [self]sigs, but its subkey still
isn't importable. (Also, it was revoked the same day the usable
selfsigs were added.)
NB: ldap://horowitz.surfnet.nl:11370 stores the key under the same
two keyids that pks and SKS does, which seems inconsistent with the
PGP encryption program(s?).
Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it?
jharris at widomaker.com _|_ web: http://keyserver.kjsl.com/~jharris/
Got photons? (TM), (C) 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : /pipermail/attachments/20041215/4f62f108/attachment.bin
More information about the Gnupg-users