OpenPGP data in the CERT RR

David Shaw dshaw at jabberwocky.com
Tue Aug 6 07:15:01 CEST 2002


On Tue, Aug 06, 2002 at 02:01:15AM +0200, Simon Josefsson wrote:
> Thanks for the comments, answers inline...
> 
> Werner Koch <wk at gnupg.org> writes:
> 
> > On Mon, 05 Aug 2002 17:46:40 +0200, Simon Josefsson said:
> >
> >
> >> 2.2 E-mail Based RR Owner Name
> >
> >>    used in the RFC 2822 envelope of OpenPGP messages.  A secondary use
> >>    may be to publish OpenPGP Key Revocation Signatures for revoked
> >>    OpenPGP Certificates, in this case the owner name should be the
> >
> >>    standard translation of the email address found in the User ID
> >>    packet(s).  An example:
> >
> >
> > I don't think that this is a good requirement.  If you want to test
> > for a revocation you already have access to the key so it it pointless
> > to search by email address.  It would be better to use the fingerprint
> > in this case because it uniquely identifies a key and it can be used
> > to revoke a subkey (useful in case of compromised box where the
> > primary key was not stored).  If the entirre key has to be revoked
> > CNAMEs to all subkeys can be provided.
> >
> > Revoking a user ID is not that important.
> 
> Makes sense.  Hm.  But it prevents persons for publishing key
> revocation signatures under her own domain (say I revoke my key and I
> want to publish that information myself, I can put it at
> simon.josefsson.org. IN CERT).  Do you think that could be useful?  I
> guess I'm leaning towards allowing both naming styles at all times
> since they might be useful in different cases.  Another disadvantage
> of only using KeyID based owner names for revocation signatures is
> that other people need to configure a DNS zone to look in.  The nice
> thing about using the email address for this is that no configuration
> is required (other than to enable DNS, that is).

I think the email address form will get bloated after a while.  I have
had 4-5 keys over time, many which would be at the same
dshaw.jabberwocky.com. CERT record.  Which do you serve?  You can't
always serve the latest since then you can't revoke the earlier keys.
You would have to serve every revocation certificate, followed by the
latest key and that can get really big.

I like Werner's suggestion of putting revocation certs somewhere else
in the zone.  It would not be bad to also put them in the email
address format, but they should always be findable another way.  Maybe
something like (fingerprint).dshaw.jabberwocky.com. IN CERT ?  That
way you can put it in your own zone, but can still distinguish between
multiple keys.

> People can decide between the two systems, either say
> 
> keyserver dns:
> 
> which uses email owner names all the time, or
> 
> keyserver dns://dnskeys.somewhere.org
> 
> which uses KeyID owner names all the time.  Or specify both, when/if
> that is supported.

This is good.

> Of course, all this is abusing the e-mail address to get a pointer to
> where you can find revocation information.  A cleaner solution would
> perhaps be to introduce a new sub-packet that specifies an URL, but
> this isn't deployed and requiring this now is probably a non-starter.

Note there is already a subpacket for exactly this:

  5.2.3.18. Preferred key server
 
     (String)

     This is a URL of a key server that the key holder prefers be used
     for updates. Note that keys with multiple user ids can have a
     preferred key server for each user id. Note also that since this is
     a URL, the key server can actually be a copy of the key retrieved
     by ftp, http, finger, etc.

GnuPG currently ignores this, but it would be fairly simple to add
support for it.  GnuPG could provide it to the keyserver plugin, and
the plugin could use it as needed.

David

-- 
   David Shaw  |  dshaw at jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "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