OpenPGP data in the CERT RR

[Simon Josefsson]

Werner Koch <wk at gnupg.org> writes:

> On Wed, 07 Aug 2002 02:09:10 +0200, Simon Josefsson said:
>
>> Actually, wouldn't it make more sense to include a "preferred
>> keyserver" option in the OpenPGP message instead?  That would solve
>> the same problem, and even work in non-email situations.
>
> Both are required.  The preferred keyserver field is required to get
> updates of a key and a mail header to get the key in the first
> instance, say you know someone from a ML but at some point you want to
> send a an encrypted mail.

Ah, good point. 

> OTOH, using the preferred keyserver for revocation checking has a
> security risk: If Alice believes her secret key has been compromised,
> she creates a recocation certificate and puts it on her DNS server.
> Meanwhile Mallory has changed the preferred keyserver of Alice's key
> and distributed the modified key to a lot of sites; there is now a
> risk that someone verifiying a message or sending one to Alice uses
> the modified key and checks the bogus preferred keyserver where he
> does not find a revocation.

Yes.  I'm not sure using the email address is entirely solid either.
Mallory could simply send the faked signed message from another
address and claiming the other address didn't work.  It isn't likely
that a MUA will use the address book to connect this new address with
the earlier mail addresses, and then use the old address to look up
revocation data.  Mallory could even add a new UID to the cert so it
would look quite legitimate.  The user might notice this (which she
wouldn't in your case), but not likely to react.

Hm.  I guess both these problems could be solved by doing a revocation
check on the _old_ cert before incorporating any new information (new
UIDs, new preferred keyserver options).  This seems like a useful
feature.

> We need a distributed and replicated network of keyservers to look up
> revocations. Something like:
>
> 01.rvc.pgp.net.  NS  rvc-a.pgp.net.
> 02.rvc.pgp.net.  NS  rvc-b.pgp.net.
> ..
> ff.rvc.pgp.net.  NS  rvc-d.pgp.net.
>
> where the 2 digits are the last digits of the fingerprint and the
> rvc-?.pgp.net servers then serve the query.  Have several of these
> networks and replicate them so a user can choose the most trustworthy
> network.

How is this better than simply doing

rvc.pgp.net. NS rvc-a.pgp.net.
rvc.pgp.net. NS rvc-b.pgp.net.
...

and storing all the revocation at all servers?  Size isn't a problem,
surely?

The latter is easier to document owner name rules for.  It will simply
be <keyId>.revoke.<zone> where "revoke" is used to prevent RR
collision.