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

[Francesco Poli]

On Fri, 28 Sep 2018 08:35:57 +0200 Werner Koch wrote:

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

Since these signatures are related to the IMHO absurd [PEC] Italian
system, it is quite likely that the certificate issuer behaves in a
silly way!    :-/

[PEC]: <https://en.wikipedia.org/wiki/Certified_email>

> 
> > 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?

I refresh OpenPGP keys almost everyday, but not all of them.
I usually refresh a bunch of them each day.

I currently use a little [stupid script] that I wrote in order to do
so...
I honestly feel a little ashamed to mention such a stupid script to
you, but... by the way, is there a better way to refresh my public
keyring in a gradual manner?
I mean, maybe I could study [parcimonie], which uses Tor...
But, other than this, is there a gpg option to refresh n keys selected
from the user's own keyring (with the criterion that they must be the n
less recently refreshed keys)?

[stupid script]: <https://www.inventati.org/frx/progs/scripts/refresh-pubring.html>
[parcimonie]: <https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/>

> Does anyone actually revoke X.509 certifciates.

I don't know, frankly speaking...

> Weel, some organisations have their in-house use of
> C.509 and they can implement everything properly.  But everything else?
> I can't decide.

That's understandable...

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

I think a limit to the update frequency would be useful.
Something like an option to decide that one certificate should not be
checked for revocation more than once in Δt (where Δt may be one day,
one week, or any time interval set by the user).

Should we convert my bug report into a feature request?!?



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20180928/a074955b/attachment.sig>