EldoS | Feel safer!

Software components for data protection, secure storage and transfer

CRL cache

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
#19884
Posted: 04/20/2012 08:52:20
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

Hello
When PDF document is signed with AutoCollectRevocationInfo set to true, signature handler knows that it should embed revocation info into a signature. That revocation info (CRL) resides on some server, ready for downloading and information about that location is stored with certificate.
I need to know whether SBB downloading CRL all the time (each time when document is signed with one certificate), or is caching CRL somewhere and uses that cached CRL until it is valid (not expired). This is very important aspect because of optimization when there are a lots of documents to be signed. Certainly we don't want to look for and download CRL each time. If SBB is caching CRLs, I need to know, where physically it is stored on hard disk (path to it)? What is the caching policy, does SBB keeps cache until CRL is valid?

Also since we can register both HTTP and LDAP CRL retriever, is there a possibility to know whether we have downloaded CRL via HTTP or LDAP? We somehow need a way to assure customer that we're able to download it in both ways, because sometimes those servers have to be restarted, but never both in the same time. Is there an event or something like that which I can catch and write down in log how CRL is retrieved?

Thanks.
#19885
Posted: 04/20/2012 09:07:31
by Vsevolod Ievgiienko (EldoS Corp.)

Thank you for contacting us.

SBB used TElX509CertificateValidator internally to collect revocation info (CRLs, OCSPs etc.). TElX509CertificateValidator has internal cache of already downloaded CRLs that can be reused between revocation collection procedures. This cache is stored in memory and is not saved to disk.

However internal instance of TElX509CertificateValidator is destroyed after each revocations collection procedure so you should create your own instance and pass it to a component using TElPDFAdvancedPublicKeySecurityHandler.OnCertValidatorPrepared event handler.
#19886
Posted: 04/20/2012 09:27:14
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

Ok, I can make my own instance of TElX509CertificateValidator outside of the event and then pass it in event handler. But that would mean that if I make a service which is signing documents, and my class lives all the time application lives and I don't restart service for a five days, that I will end up with CRL which is 5 days old?
Is there a way to access to revocation info of TElX509CertificateValidator and check whether it has come a time to download CRL again (DateTime.Now > TElCertificateRevocationList.NextUpdate)?

Thanks.
#19887
Posted: 04/20/2012 09:32:24
by Eugene Mayevski (EldoS Corp.)

CRL cache is a global object, so keeping one instance of TElX509CertificateValidator is not necessary (i.e. it can be recreated safely).

CRLs are kept in cache until they expire or until application shutdown whatever happens earlier.

There's SBCRLStorage.Unit.CRLManagerAddRef() function that returns an instance of TElCRLManager class via which you can get to CRLs kept in the cache. This class is not documented as it was designed for internal use only and we don't plan to make CRL cache public (at least at the moment). You can study the source code (SBCRLStorage.pas) if you are interested in how CRL cache looks like.


Sincerely yours
Eugene Mayevski
#19888
Posted: 04/20/2012 09:40:24
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

Thank you very much for precise answer.

Can I have answer to my second question too please(is there a possibility to know whether we have downloaded CRL via HTTP or LDAP)?


Thanks.
#19889
Posted: 04/20/2012 09:54:58
by Eugene Mayevski (EldoS Corp.)

The only way to do this is create custom retrievers (we provide source code of HTTP retrievers as a sample) and somehow log what they retrieve. Not a straightforward method though


Sincerely yours
Eugene Mayevski
#19890
Posted: 04/20/2012 10:11:11
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

No maybe, I was not clear enough. Let me try explain again. We can register both HTTP and LDAP retriever with:
Code
SBHTTPCRL.Unit.RegisterHTTPCRLRetrieverFactory();
SBLDAPCRL.Unit.RegisterLDAPCRLRetrieverFactory();


This way we tell that TElX509CertificateValidator (or TElCRLManager) can use both HTTP and LDAP CRL retriever. The only information that I need is not what they retrieve, but which of those two retrievers worked. My customer somehow wants to be sure that we can use both retrievers, because their CA sometimes restart HTTP or LDAP server, but never both in the same time.

I saw that TElX509CertificateValidator have event OnBeforeCRLRetrieverUse. Can I use this event to somehow make log which of retrievers will be used to retrieve CRL (HTTP or LDAP)?
#19891
Posted: 04/20/2012 10:28:08
by Eugene Mayevski (EldoS Corp.)

Yes, you can. Check the class name of the retriever, passed via the event parameter.


Sincerely yours
Eugene Mayevski
#19892
Posted: 04/20/2012 10:37:36
by ingbabic  (Standard support level)
Joined: 09/27/2011
Posts: 114

I did it and noticed that SBB have used TElLDAPCRLRetriever retriever and not TElHTTPCRLRetriever retriever. Does it mean that SBB first tries to use LDAP and if LDAP is not available it uses HTTP?

Thanks.
#19893
Posted: 04/20/2012 11:03:49
by Eugene Mayevski (EldoS Corp.)

It depends on the order of CRL extensions specified in the certificate.


Sincerely yours
Eugene Mayevski
Also by EldoS: CallbackFilter
A component to monitor and control disk activity, track file and directory operations (create, read, write, rename etc.), alter file data, encrypt files, create virtual files.

Reply

Statistics

Topic viewed 2512 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

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

Got it!