Modified user ids and key servers and a possible security risk?

[Hauke Laging]

Am Mittwoch 25 August 2010 20:37:08 schrieb Daniel Kahn Gillmor:
> > [good reasons 0-3 skipped]
> >
> > 4) Asymmetric cryptography is computationally expensive.  I would not
> > want to think about the CPU load of a keyserver that did verification of
> > every new certificate, user id, user attribute, etc., etc.
> 
> Keyervers receive relatively few new certifications each day, certainly
> a small fraction of the number of requests they emit.
> 
> Compared to offering hkps service (HKP-over-TLS on port 443), i doubt
> we'd notice a big computational cost differential, but i have no
> quantitative data on that.

And in contrast to TLS this CPU load can be postponed without serious 
consequences. If the load is high then new signatures could simply be added 
and checked later. Only "strange" updates (e.g. many signatures for the same 
key) would be checked at once in order to prevent such a postponing feature to 
be easily abused.

To be on the safe side the keyserver could also prevent not yet checked 
information from being publicly available. So it might take a few hours until 
a key update is visible. Usually not a problem.

If such administrative decisions are possible then I would like the keyserver 
to inform the client (in a signed way...) about its policy.


Hauke
-- 
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20100826/a49eafc8/attachment.pgp>