OpenPGP data in the CERT RR

[Simon Josefsson]

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).

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.

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.

> Having a special name part for such unique specifications might make
> sense:
>
> A4D94E92B0986AB5EE9DCD755DE249965B0358A2.pgpkeys.example.org. IN CERT ...
>
> This way a client can figure out where to look for revocations by
> doing an MX query and prepending the fingerprint and "pgpkeys".

I didn't understand what you meant by a MX query, but in general I
think some way to separate revocation signatures from certificates is
needed.  Otherwise packets will be too large.