[pkg-gnupg-maint] Bug#909693: Bug#909693: gpgsm: seems to be dead slow when verifying pkcs7-signatures from within Sylpheed

Werner Koch wk at gnupg.org
Fri Sep 28 07:35:57 BST 2018


On Fri, 28 Sep 2018 00:57, invernomuto at paranoici.org said:

> It's clear that the CRL revocation check is the step that takes a long
> time.

Right.  And it depends on the certificate issuer and how they maintain
CRLs.  If they release CRLs only once a week, things should be okay
becuase GnuPG caches them.  However, some CAs are creating new CRLs
every hour or even more often and if they are really long (e.g. by
including expired certifciates, which is silly, but some did this) this
is an effective DoS.

> The man page states that disabling CRL checks is especially intended
> for off-line operations (which is not my case, except for infrequent

Yes, that is the theory.  But in practise CRLs don't work and OCSP is
also not much better.

> So, is disabling CRL checks advisable or not?

How often do you run a "gpg --refresh-key" which is basically the
OpenPGP way for checking for revocations?  Does anyone actually revoke
X.509 certifciates.  Weel, some organisations have their in-house use of
C.509 and they can implement everything properly.  But everything else?
I can't decide.

It might be worth to add a black- or whitelist to our CRL checks or add
an option to violate the nextUpdate field (expiration time) of a CRL and
trigger an update only every few days.  


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20180928/ca38e74c/attachment-0001.sig>


More information about the pkg-gnupg-maint mailing list