OpenPGP data in the CERT RR

David Shaw dshaw at
Tue Aug 6 07:00:02 CEST 2002

On Tue, Aug 06, 2002 at 02:25:03AM +0200, Simon Josefsson wrote:
> Simon Josefsson <jas at> writes:
> >> I think that this should be the key fingerprint, and then you can
> >> CNAME as many other names to this one canonical name as you like:
> >>
> >>  IN CERT PGP 0 0 <OpenPGP binary>
> >>
> >> email address:
> >>
> >>  IN CNAME
> >>
> >> 4 byte keyid:
> >>
> >> 8 byte keyid:
> >>
> >> etc.
> >>
> >> This should work for either self-published or keyserver sort of
> >> access.
> >
> > Yup.  Are there cases (worth writing specifications for) where you
> > only have a 4 or 8 byte key id?  I would prefer to not add even more
> > flexibility in the owner name guidelines if possible, as flexibility
> > might mean wasted round trips querying for stuff that isn't there.
> > Thanks for your comments.
> Trying to be bit more clear: Changing the document to use the full
> fingerprint all of the time is what I (now) think is the best idea.
> Supporting 4 and 8 byte keyId's too seems like unnecessary work unless
> it is really needed.

The full fingerprint is generally useful since it is the most specific
way to specify a key.  8 byte keyids are useful since that is what
OpenPGP uses inside packets - for example, when verifying a signature,
the program knows the 8 byte keyid of the signer and can use it to
fetch the key.  4 byte keyids are useful since that's what human
beings use.

I really think they all need to be supported.  I don't think it will
lead to particularly large packets since they are CNAMEs in the same
zone as the full fingerprint name and so it would still be one round
trip for the request (since the server can return the pointed-to
result in the "additional" section).  Also, the regular DNS
compression applies and it should do very well since they are in the
same zone.


   David Shaw  |  dshaw at  |  WWW
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

More information about the Gnupg-devel mailing list