Idea: Add a way to use pgp/gpg keyid in control.ctl

Russ Allbery rra at
Sun Jul 3 01:17:32 UTC 2005

Sebastian Wiesinger <inn at> writes:

> Today I discovered a glitch with pgpverify. The control key for the at.*
> hierarchie has the uid:

> pub  1024R/AE548CCD 1997-04-10 austrian usenet coordinator <control at>

> which, when parsed with pgpverify, will return different uids after
> parsing:

> When using pgp, pgpverify returns control at as uid.

> When using gpg, pgpverify return austrian as uid.

> Because of this, the default control.ctl wouldn't recognize a valid
> at.* control when checked with gpg.

Yeah, there is some discussion of this problem at:


Basically, you don't want any UIDs on Usenet control message signing keys
other than simple e-mail addresses or they won't work at a lot of sites.

> This led to another thought: If someone made a key with the same uid as
> a key in the control.ctl file and uploads that key to the keyservers, it
> could be possible that some users download the wrong key from the
> keyserver when they search for the uid, and in the worst case could
> automatically execute faked controls.


Really, that should be taken care of upstream of pgpverify, though.  Don't
load untrusted keys into the keyring that you use for control message
verification.  This is one of the reasons why we distribute a PGPKEYS file
as part of the pgpcontrol distribution.

> A much more robust solution would be:

> Make it possible to specify a keyid in the control.ctl, perhaps
> something like:

> rmgroup:control at*:pgpkey-AE548CCD=mail

> This would make it much easier to parse the gpg output[1] and also would
> make it harder to fake a control key. In addition this will not break
> when keys have non-standard uids or multiple uids.

> Comments, Suggestions?

> [1] I don't know the format of the pgp output right now, I hope that
> there is a keyid somewhere in the output?

Nope.  You have hit upon exactly the problem.

It should be possible to do this provided that you have GnuPG.  I don't
think there's a good way to do this with PGP 2.6.2.

Now, at this point, we probably don't have to worry too much about
supporting new features for PGP 2.6.2 deployments; as long as the old
method is still supported for those sites, they're probably fine.  PGP 5.x
and later I believe do include the key ID, for those who care about them
(I don't, really, but pgpverify does support them).

I don't have time to work on this right now, but I think it's a reasonable
idea.  I'm happy to take patches that implement the above, or otherwise
will add it to my to-do list and may get around to it sometime (but I
can't give any guarantees).

It's probably worth some thought on whether there's anything better than a
key ID that can be used.  Key IDs are pretty good and probably wouldn't
conflict, but they can, and are not supposed to be used for security
purposes.  It would be nice to get the fingerprint or soemthing else more
substantial instead.

Russ Allbery (rra at             <>

    Please send questions to the list rather than mailing me directly.
     <> explains why.

More information about the inn-workers mailing list