Abstract:
A distributed digital certificate validation method of a client connectable in communication with a host is provided. A first connection is made with the host to establish data communication with the host. A request for a certificate validation result is sent to the host. A file containing at least the requested certificate validation result is imported from the host and the imported file is stored locally for later retrieval of at least the requested certificate validation result.

Description:
BACKGROUND 
     The present invention relates to digital certificates, and is particularly directed to a distributed digital certificate validation method and system. 
     In a typical known digital certificate validation method, a certificate validation service runs on a host which is centrally located relative to a number of clients. Each client operates independently of the host. When needed, each client can connect on-line to the host to obtain certificate validation results in real-time. 
     A drawback in known digital certificate validation methods is that the client needs to connect and communicate with the host each time the client needs to validate a certificate. Since the client operates independently of the host and usually has limited resources, it may be quite inefficient for the client to make the connection and communicate with the host each time a certificate validation result is needed. It would be desirable to provide a more efficient digital certificate validation method and system. 
     SUMMARY 
     In accordance with one embodiment of the present invention, a distributed digital certificate validation method of a client connectable in communication with a host comprises making a first connection with the host to establish data communication with the host, sending to the host a request for a certificate validation result, importing from the host a file containing at least the requested certificate validation result, and storing the imported file locally for later retrieval of at least the requested certificate validation result. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWING 
       In the accompanying drawings: 
         FIG. 1  is a schematic block diagram of a distributed digital certificate validation system embodying the present invention; 
         FIG. 2  is a flowchart depicting a distributed digital certificate validation method embodying the present invention; and 
         FIG. 3  is a flowchart depicting another distributed digital certificate validation method embodying the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     The present invention relates to digital certificates, and is particularly directed to a distributed digital certificate validation method and system. A distributed digital certificate validation system  10  is illustrated in  FIG. 1 . The system  10  comprises a host  12  which communicates with a first client  14  and a second client  18 . The host  12  includes a processor  13  which accesses data from a database  20 , and executes application programs stored in a program store  30 . 
     The database  20  includes a first data store  22  which stores digital certificates. The digital certificate preferably meets the Internet X.509 PKI (“public key infrastructure”) profile which is known. Such a digital certificate has required field attributes. Required field attributes include Version, Serial Number, Signature, Issuer, Validity, Subject, Subject Public Key Info, AKI Key Identifier, SKI, Basic Constraints, and Key Usage. Each certificate is uniquely identifiable by the combination of the field attribute values of Issuer and Serial Number. 
     The database  20  further includes a second data store  24  which stores certificate revocation lists (CRLs). A CRL is issued by a certificate authority (CA). A CRL contains information about digital certificates which have been placed on hold. A CRL also contains information about digital certificates which have been revoked. CRLs and the information contained therein are known and, therefore, will not be described. The CRLs also preferably meet the Internet X.509 PKI profile. Such a CRL has required field attributes. Required field attributes include Version, Signature, Issuer, This Update, and Next Update. Each CRL is uniquely identifiable by the combination of either the field attribute values of Issuer and This Update or the field attribute values of Issuer and CRL Number. 
     The program store  30  contains a number of application programs. More specifically, the program store  30  contains an executable certificate validation program  32  which, when executed, provides certificate validation results. The certificate validation program  32  may comprise a typical known algorithm for validating digital certificates. 
     The first client  14  and the second client  18  may be substantially the same. For simplicity, only the first client  14  will be described. The first client  14  includes a processor  15  and a user interface  16  having typical input and output devices which allow a human operator to make a request to validate a digital certificate. The first client  14  further includes a storage device  17  which is local to the first client. When a human operator desires to validate a digital certificate, the operator interacts via the user interface  16  to make a request to validate the digital certificate. In response to the request, the client processor  15  communicates with the host processor  13  which, in turn, invokes the certificate validation program  32  to validate the digital certificate in a known manner. 
     Referring to  FIG. 2 , a flowchart  100  depicts operation of a distributed digital certificate validation method of the client processor  15  in response to the operator making a request to validate a digital certificate. When the operator desires to make a request to validate a digital certificate, the operator takes the necessary steps to establish communication between the client processor  15  and the host processor  13  (step  102 ). The operator then sends a request to the host  12  to obtain certificate validation results (step  104 ). This may be a single request or a multiple number of different requests. 
     After the host  12  generates the certificate validation results (as will be described later with reference to the flowchart  200  shown in  FIG. 3 ), the first client  14  imports the generated certificate validation results from the host (step  106 ). The format of the imported results may be of any type. For example, the format of the imported file containing the certificate validation results may be a file transfer protocol (FTP) type of file. 
     The first client  14  then stores the imported certificate validation results in the local storage device  17 . The certificate validation results stored in the local storage device  17  can be later retrieved by the client processor  15  without having to first connect and establish communication with the host processor  13 . For example, the operator at the first client  14  may decide at a later time to request certificate validation results for a particular digital certificate. 
     After the imported certificate validation results have been stored locally in the storage device  17 , a determination is made at the first client  14  as to whether a predetermined amount of time has elapsed since the last file containing certificate validation results has been imported from the host  12  (step  110 ). As an example, the predetermined amount of time elapsed may comprise the amount of time in a regular business day. If the determination in step  110  is affirmative (i.e., the predetermined amount of time has elapsed), then the process returns to step  102  so that the client processor  15  can again establish communication with the host processor  13  to repeat the process just described hereinabove to update the certificate validation results stored locally at the storage device  17 . However, if the determination in step  110  is negative, the process loops back on itself in step  110  until the predetermined amount of time has elapsed. 
     Referring to  FIG. 3 , a flowchart  200  depicts operation of a distributed digital certificate validation method of the host processor  13  in response to the client processor  15  making connection and communicating with the host processor to validate a digital certificate. After communication is established between the client processor  15  and the host processor  13  (step  202 ), the host processor receives a one or more requests from the client processor for certificate validation results (step  204 ). The host processor  13  then executes the certificate validation program  32  (step  206 ) to obtain certificate validation results corresponding to the specific requests which have been made. The certificate validation results obtained in step  208  are then transmitted in a file to the client processor  15  for storage in the storage device  17  local to the first client  14  (step  212 ). 
     From the processes  100  and  200  described hereinabove, it should be apparent that the host  12  is “pre-validating” certificates and providing validation results along with the certificates in a file which can be imported by the first client  14 . This file containing validation results may be called a “pre-validation file”. When the first client  14  needs to validate certificates, the certificates and their validation results can be retrieved from the locally-stored pre-validation file. 
     It should also be apparent that the client processor  15  need not be continuously connected in communication with the host processor  13  to allow a request for a certificate validation to be fulfilled. When an operator makes a request to validate a digital certificate, the client processor  15  just needs to query the local storage device  17  to retrieve the desired certificate validation results. The result is a more efficient process since the operator can obtain certificate validation results without having the client processor  15  be continuously connected in communication with the host processor  13 . The resources of the client processor  15  need not be tied up in making a connection to the host processor  13  each time a request is made to validate a digital certificate. Since validation results are stored local to the first client  14  and the first client  14  does not need to perform a validation process on certificates, the performance of the first client  14  is improved. 
     Although the above description describes that the predetermined amount of time elapsed is the amount of time in a regular business day, it is conceivable that the predetermined amount of time elapsed may be a different amount of time. As another example, the predetermined amount of time elapsed may be the amount of time in a regular business week. 
     Also, although the above description describes a human operator making a request via the user interface  16  to validate a digital certificate, it is conceivable that the request or multiple requests could be received in an automated stream from an external source without any human intervention. 
     Also, although the above description describes the certificate validation program  32  as being a single program, it is conceivable that two or more separate programs could comprise the certificate validation program. 
     The particular arrangements disclosed are meant to be illustrative only and not limiting as to the scope of the invention. From the above description, those skilled in the art to which the present invention relates will perceive improvements, changes and modifications. Numerous substitutions and modifications can be undertaken without departing from the true spirit and scope of the invention. Such improvements, changes and modifications within the skill of the art to which the present invention relates are intended to be covered by the appended claims.