Key strangeness

[Jason Harris]

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.

Correct.

> > 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
unsigned userids.

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
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : /pipermail/attachments/20041215/4f62f108/attachment.bin