EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Save CRL to local file for later use

Posted: 10/30/2012 07:15:27
by Birger Jansen (Standard support level)
Joined: 07/19/2012
Posts: 80

Some other issues had to be solved first (and a vacation) and now I am working on this again...
While I can get the code to TriggerCRLError with the right SB_VALIDATOR_CRL_ERROR_NO_CRLS_RETRIEVED code, I can't find where to inject my code to try to load a local saved CRL. The TElX509CertificateValidator.RetrieveCRLs will skip to the finally... part after the exception, so the TriggerCRLNeeded ( a couple of lines above) is not triggered.

Since I noticed that the CRL Server that we use (Thawte) is offline quite often I really want to het a caching mechanism in place... I hope you can help me!
Posted: 10/30/2012 08:28:12
by Ken Ivanov (Team)


You appear to be quite right. The issue really does exist and needs fixing.

Meanwhile, you can work around the issue by letting the validator 'know' your locally saved CRLs by passing them to its AddKnownCRLs() method. This should be done before validating any certificates with it.
Posted: 10/31/2012 04:07:31
by Birger Jansen (Standard support level)
Joined: 07/19/2012
Posts: 80

The AddKnownCRLs() method is a good approach, it works! Thanks for pointing this procedure out to me, it results in much less code.

Btw, I noticed that sometimes an AddXXX(SomeObject) function makes a clone of SomeObject, so you can free it in the calling method, and sometimes (a reference to) the object itself is added so you must not free it.

For instance TElMemoryCRLStorage.Add(CRL : TElCertificateRevocationList) creates a NewCRL to which CRL is assigned. On the other hand TElX509CertificateValidator.AddKnownCRLs(Storage : TElCustomCRLStorage) just adds a pointer to Storage and the passed Storage must not be freed.

Is there a reason for these different approaches and any (naming) convention so that I can see beforehand if I need to free the added object or not?
Posted: 10/31/2012 04:40:27
by Ken Ivanov (Team)

The exact ownership approach to use in a particular Add*() method is usually chosen basing on the nature of the added object. In the particular cases above, the following considerations were used when designing the interfaces:

1) TElCustomCertStorage/TElCustomCRLStorage and their descendants are heavy components that contain references to objects that might reside in different physical locations. Creating a fully-functional copy of such objects is not always possible, as the copy operation might invalidate the references (e.g. a private key acquired in the original object might become unavailable in the copy). Moreover, storage objects are more or less persistent, are usually created once per task and remain alive for the whole lifetime of the task. This way, using a sort of 'global' storage object will help to omit time-consuming copy operations.

2) CRL and individual certificates are easy-to-clone objects; they are not as persistent as storage objects, and it will be much more easier for the component user to manage their lifetimes if each container object keeps its own copy of them.
Posted: 10/31/2012 04:43:23
by Birger Jansen (Standard support level)
Joined: 07/19/2012
Posts: 80

Ok, thanks for the explanation!



Topic viewed 3137 times



Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!