Page MenuHome GnuPG

dirmngr considers cached CRLs valid after removal of trusted cert
Closed, ResolvedPublic

Description

Tested with dirmngr 1.0.2 and kontact enterprise35 20081001.865016.

CRL checks use the system dirmngr which has Intevation's Wurzel ZS 3
Certificate in /etc/dirmngr/trusted-certs.

In this initial case, validating a signature made by a certificate
issued indirectly by ZS3 succeeds and is shown in green because the
signature is indeed valid and no certificate has been revoked or has
expired. After this check the CRLs in the cache in
/var/cache/dirmngr/crls.d/ have been updated.

Now, remove the ZS3 certificate from /etc/dirmngr/trusted-certs and
restart the system dirmngr. Repeat the signature check. The signature
still shows up as green even though it shouldn't.

Now, clear the CRL cache by simply removing all files in
/var/cache/dirmngr/crls.d/ and restart the dirmngr. Repeat the
signature check. Now the signature shows up as yellow, as expected.

Details

Version
1.0.2

Event Timeline

bherzog added projects: dirmngr, Bug Report.
bherzog added a subscriber: bherzog.

I can't see a bug here. By design CRLs are only loaded once in a while and
valid as long as specified in the CRL. There is no need to re-check the CRL.
If you do not want such a behaviour you need to use OCSP and not CRLs. In fact
that is one of the reasons why the German Qualified Signatures require the use
of OCSP.

The current svn trunk features a user provided trust anchors. Thus if a CRL
could not be validated just because the trust anchor is not available in
trusted-certs/, dirmnngr will casche the CRL anyway and ask back whether the
user trusts the trust anchor. The latest GnuPG implements the counterparts
which uses the /.gnupg/trustlist.txt to answer this.

werner claimed this task.