CAcert System Admins discussion list

[Michael Tänzer <michael.taenzer AT cacert.org>]

Hi Wytze,

On 17.10.2013 19:52, Wytze van der Raay wrote:
> Michael Tänzer schreef op 17-10-2013 19:00:
>> On 17.10.2013 18:22, Wytze van der Raay wrote:
>>> On 17.10.2013 17:55, Michael Tänzer wrote:
>>>> On 17.10.2013 13:10, Wytze van der Raay wrote:
>> ... OK, how about this temporary fix: we temporarily drop expired 
>> certificates from the published CRL and only provide this state
>> via OCSP. The OCSP servers get their state via the CRL too right?
>> So we would export four CRLs, one complete for the OCSP and one
>> only with unexpired certs for each root.
> 
> Yes, I've been thinking along that line too. The OCSP servers are
> also driven by a CRL, so yes, they could run with the complete one,
> while CRL downloaders would only see the "clean" one with unexpired
> certs only. The disadvantage of such a setup is that the answer about
> the validity of an expired certificate may differ, depending on whether
> one checks against the OCSP server or against the current CRL.

Well, that's a problem we can't avoid and probably causes no harm as
software relies on one method or the other. And the CRL thing we
basically rely on the RFC definition as you said an provide no
information on expired certs.


>> When the signer rewrite is finished we can the have a split CRL.
> 
> You mean the above scheme? Besides a change of the signer, it also
> requires a change to the communication process between signer and
> webdb server, to deal with updating two rather than one CRL after
> a revocation.

No I mean a per issuance year scheme. But yes, even that scheme above
needs changing the CommModule. But that can be done. What bothers me
more is that the "openssl ca" command we use in the background has no
option to export a crl without expired entries. So it all comes down to
rewriting the signer.


>> ... OK, maybe because I didn't put much thought into how our
>> firewall configuration is set up exactly. Reducing the frequency
>> (e.g. to daily) makes sense on monitor where nothing really bad
>> happens if a compromised cert is used but I would not put that on
>> board as it carries our complete bookkeeping, and motions might
>> move there too.
> 
> If you are using wget, you should use the -N option to avoid downloading
> the CRL when it hasn't changed. It might help a bit ...

Well it changes whenever a certificate is revoked or next-update is
triggered so I guess rather often but I'll include that in the script.
BTW: for curl it's -z or --time-cond <file>

-- 
Cheers,
Michael Tänzer

Attachment: signature.asc
Description: OpenPGP digital signature