HK1083252B - System and method for a remote access service enabling trust and interoperability when retrieving certificate status from multiple certification authority reporting components - Google Patents

Description

System and method for remote access to trusted and interoperability services when retrieving certificate status from multiple certificate authority reporting components

Background

Applicant's invention relates to a method for generating a signature for a document such as an electronic document^TMThe creation, execution, maintenance, transfer, retrieval and destruction of electronic original information objects such as documents provides a system and method of verifiable credentials and security.

The present invention advantageously uses applicant's Trusted custody Utility (Trusted stock Utility) that maintains electronic original records and maintains similar system tasks as a virtual electronic safe (vault) in confirming the rights of individuals to perform the necessary actions, confirming the authenticity of submitted electronic information objects, and confirming the status of authentication certificates used in digital signature verification and user authentication processes. Such TCUs and operations are described in U.S. Pat. Nos. 5,615,268, 5,748,738, 6,237,096 and 6,367,013.

The following abbreviation table is used in this specification:

abbreviations

CA certification authority

CRL certificate revocation List

CSS certificate status service

HTML hypertext markup language

ID identification

IETF Internet engineering task force

ITU International Telecommunications Union

LDAP lightweight directory access protocol

OCSP Online certificate status protocol, IETF-RFC 2560 X.509 Internet public Key infrastructure Online certificate status protocol-OCSP, 6 months 1999

PIN personal identification code

PKCS public key cryptography standard

PKI public key infrastructure

PKIX public key infrastructure (X.509)

S/MIME secure universal internet mail extensions

SCVP simple certificate authentication protocol, draft-IETF-PKIX-SCVP-06, 7 months in 2000

SSL secure socket layer

TCU trust supervision utility

UETA unified electronic transaction act

XML extensible markup language

The passage of united states national laws in the global and national business electronic signature act (ESIGN) regulations in the united states and imitating UETA drafted by a united states french specialist conference and approved and recommended for use as a regulation in 1999 made it possible to apply electronic signatures to information objects that have led to government, banking and electronic commerce activities that have led to the efficiency and economy of achieving these potentially complete electronic transactions.

Both PKI and CA are fundamental elements of digital signature technology used in creating electronic source records. PKI is a collection of CAs where credits are established between users and user agencies either by creating hierarchical relationships between CAs or by cross-certification in cooperating CAs. The CA is granted the right to issue a certificate of authenticity that binds the identity of the individual or the identity of the entity to his or its public key (verification), wherein the individual is only given access to the right to match the private key (signature). In such applications, the certificate typically conforms to the ITU x.509 certificate standard and digitally signs itself through the issuing CA. Such a certificate is depicted, for example, in FIG. 10 of U.S. Pat. No.6,237,096, which is incorporated herein by reference. These certificates of authenticity include: the serial number, identification information of the subject (user) and issuer (CA), the validity period of the certificate (the date and time it is not permitted to use before and after), the subject's public key, and cryptographic algorithm information needed to create and verify the digital signature.

To create a digital signature, an information object is obfuscated (processed using a one-way encryption function that can only detect one-bit changes in the object), and then the hash is encrypted using the individual's private (secret) key. Digital signature verification is accomplished by reversing this process. The digital signature is decrypted using the individual public key retrieved from the individual's certificate of authenticity and the result is compared to the re-hash of the original information object. These processes may change when different digital signature algorithms are used. Digital signatures are only as reliable as the credits that exist between the relying party and the issuing CA; and the assurance level is reached through the physical controls, practices and procedures implemented by the CA.

The purpose of PKI technology is to create and maintain a secure environment and a trusted environment for the parties that are communicating. Such principals rely on PKI to establish the identity of the user and notify them when the user's credentials are no longer available. Certificates are revoked when an individual leaves an organization, when a replacement certificate is issued, or when a signing key is lost, stolen, or compromised. Vendors use a variety of methods to report certificate status. These different methods make it more difficult for a user to obtain the status of the credentials of other users.

The formation of trust relationships and interoperability is governed by the PKI certificates and security policies and their enforcement. The certificate policy determines the level of personal review (e.g., photo ID, credit check, both forms) required to obtain approval to issue the certificate (i.e., verifying the appropriateness of the certificate request information and the identity of the intended certificate recipient). The security policy indicates the physical control, program control, and process control needed to support the application environment.

There are two general models for creating and grouping CAs. The first is a hierarchical CA model, which is similar to an inverted tree with the root CA at the top. The root CA signs its directly subordinate CA certificate. These CAs then sign their subordinate CA certificates and the like. These relationships create a chain of certificates that form the branches of the tree. Two CAs prove that a trust relationship exists between them by "walking" through their respective certificate chains until reaching a common node. The CAs may be grouped and associated with one or more service delivery channels, verticals, organizations, or enterprises.

In a second model, a CA is created for a single enterprise and provides CA services to one or more entities within that enterprise. An enterprise CA typically does not have any pre-established trust relationship with any CA of other enterprises. Explicit action must be taken to achieve interoperability in the form of CA cross-certification, whereby two or more CAs agree to trust another to sign each other's certificates and use these mutually certified certificates during digital signature verification. A certificate issued by one CA can then be authenticated by another CA and its user, who have mutually certified.

The CA revokes the certificate when, among other reasons, the information contained in the certificate is invalid, when the user's private key is compromised, or when the user's certificate-based application privileges must be terminated. If the certificate is already in the owner's ownership, the CA cannot simply delete or retrieve the certificate from its owner. Instead, the certificate is marked as "revoked" in the CA's database and the certificate status is published. The user of the PKI can then learn of the validity of the certificate by requesting the status of the certificate from the issuing CA or from an identified status repository (directory).

An earlier method used to report certificate status was by publishing a revocation certificate list (commonly referred to as a CRL) of the CA. The CRL is downloaded by the application and relies on the principal to determine whether the certificate of a particular user has been revoked and by the extension whether the digital signature of that user is still valid. CRLs are long over time, which introduces communication and data processing overhead. Another disadvantage of this solution is that: CRLs are often published at infrequent intervals (e.g., once or twice a day). For this reason, CRLs tend to expire immediately after publication. Only revoked certificates are deleted from the CRL after the certificate expires.

A PKI bridge is a method of providing interoperability between CAs by cooperatively distributing CRLs. Such bridges are actually a central CRL repository that joins a set of CAs that agree to receive each other's certificates and security policies. All CAs forward their CRLs to the bridge. This allows for centralized authentication of any individual certificate or entity's certificate. If the certificate has not been revoked earlier, it is still considered valid. The biggest drawbacks for PKI bridges are: they must be available to any CA or user of the bridge depending on the certificate status. Bandwidth requirements, computational requirements, and memory requirements can be expensive.

A recent approach for obtaining certificate status is IETF OCSP, which performs direct database queries capable of providing real-time certificate status. However, some vendors have implemented CRL-based OCSP responders. The credential status reported by such responders is only as timely as the CRL on which they are based. In an attempt to reach a real-time certificate status, methods such as IETF SCVP continue to be developed. At the time of the present invention, the mixing and matching of status checking methods has not been practiced in an open PKI environment.

Any solution to certificate verification is the decision of the presence or absence of the CA that issued the certificate. All users who issue certificates by one of the member CAs are active/enabled unless their certificates have been aborted or revoked or have expired. The common theme that controls participation is whether certificates are issued. Issuance is governed by certificates and security policies and enterprise rules.

By requiring membership in an enterprise or common interest group, the trusted environment can be changed from a sufficiently open environment where anyone who can pay admission can be issued certificates to a closed or limited environment. In either case, whether interoperability is enabled or not, it is the CA certificate and/or security policy that govern.

From those situations described above, applicants' invention addresses the interoperability issues of PKI and CA from a completely different perspective. Applicants' focus is on establishing a trusted environment suitable for creating, executing, maintaining, transferring, retrieving and destroying electronic raw information objects, which may also be transferable records (ownership may change hands). To achieve these objectives, a system that controls electronic originals or authorized copies must make it possible to identify the originals from any copy thereof. Just as in the case of paper originals, there is only one original. Examples of negotiable records are electronic negotiable securities and valuable securities. The electronic original record may be any source record, regardless of whether it qualifies as a transferable record. The transfer of electronic original records between systems must be done using a method that ensures that only one original exists.

The present invention creates electronic original records by issuing a custody of records held in trusted independent parties, employees or TCU hands for the benefit of the record owner. Creating a trusted environment is necessary, but not enough to maintain electron source recording. For the purposes of the present invention, a trusted environment is created by forming a common interest with tight or limited membership, and wherein the identity of future members, organizations and their users is ensured by using appropriate checking procedures that govern the permission permissions to the community. In addition, the individual's organization, participation, role, and attributes are defined upon registration with the TCU. For the system, individuals must be uniquely identified and in their certificate of authenticity. In addition, it must be possible to remove individuals and organizations from the community and to make this action known to other members of the community. Conventional solutions to CA interoperability do not adequately achieve these goals.

The review minimally requires funding an organization and/or individual through known members of the community. Additionally, Dun and Bradstreet-like valuations for institutions or Equ ifax-like credit checks for individuals, or equivalent credit and payment histories, may be used to estimate acceptability of potential business partners, clients, and customers. Both the checking authority and the user it funded must be considered trustworthy before the TCU registration is granted. After the institution agrees to define contractual terms for the membership, each of their funded individuals will be assigned a unique identifier and password that will enable them to access the TCU.

Once an individual is registered with one or more TCUs, they can be named as a transaction participant by the owner of that transaction and given the right to have specific access to all or an identified subset of the source records based on their identity, role, and/or responsibility. To facilitate identification and verification and to enable transactions to be conducted in a fully electronic form, a selected subset of this identification information is included in the party's certificate of authenticity. The certificate of authenticity binds the user's identity to their public key for validating digital signatures generated by signing private keys with their matches.

The certificate or security policy addresses the identity evidence requirements (e.g., two forms of photo ID, credit check, personal introduction) that are required before issuing the certificate. Such a certificate would be bound to the user's TCU account if digital signature rights were required. The link should include a subset of certificate data elements that uniquely identify the user (e.g., certificate ID, issuing CA name, user common name). Once associated with the user's account, the certificate can be used in conjunction with his or its digital signature to provide proof of identity to effect a predetermined set of authorized actions and to verify the user's digital signature on the submitted information object. This is particularly true when the owner or an agent of the owner that controls a set of electronic records instructs a TCU to transfer ownership (i.e., internal transactions) and/or oversight (i.e., external transactions) of the electronic records to another TCU.

As previously described, user authentication and digital signature verification are supported using authentication certificates and public key encryption. The process of digitally signing certificates, i.e. encapsulating the identity of the recipient with their public key, by the issuing CA. In issuing a certificate, the CA states that the individual identified in the certificate is the owner of the matching private key used to digitally sign the information object or a segment thereof.

The present invention differs from other PKI based e-commerce solutions in that the PKI is only considered to be the only basis for being able to implement a credit environment, but not a credit environment. Both sponsorship and registration to contract for the membership are major factors. While public key encrypted certificates and use are considered enabling techniques, certificates must be uniquely identified and tied to a particular user before they can be bound to that user's TCU account.

When a certificate is employed, the account may be activated only when such binding between the certificate and the user account is complete. This binding may be as simple as adding the certificate ID and issuing CA to the user account information, or may use other information conveyed by the certificate such as a user's recognizable-name component (see ITU x.509 standard). The binding information may be transmitted in a registered form or extracted directly from the certificate in accordance with the TCU system security policy. Whenever a certificate is used, a corresponding check may be used to ensure that the user specification in the certificate matches the user specification in the enrolment data. The user's certificate is signed by the issuing CA's certificate and its integrity and authenticity is verified using the issuing CA's certificate and the public key. The set group of components used for identification must be provably unique. Once this TCU account and user certificate binding is completed, the TCU need only know where to check the certificate status.

In a CA-centric environment, the creation of a single PKI, cross-certificate, or PKI bridge (a complex system that performs certificate status checks, where multiple vendor products are used by many CAs) is required for interoperability. The common element is that all certificates have equal values. Certificates may convey different levels of credit, and applications in an open environment must have the ability to interpret and use these levels of credit differently. This principle can be characterized as "we will build a way to take you anywhere you want to go". The user is checked when the CA registration utilizes various criteria (e.g., credit check, means of payment, cost of certificate).

Instead, the TCU only involves the known "approved CA" group, and only those certificates within that group that are associated with its user accounts. Any other certificates will be ignored. This principle can be characterized as "the only way you will open would be those needed to guide your business". The user is checked twice, once the CA certificate policy is satisfied and for a second time certifies that there are enterprises that they are to register with the TCU. The business rules enforced by the TCU can accommodate certificates issued at different credit levels.

Disclosure of Invention

To date, all certificate status reporting services have used a single means of reporting certificate status (CRL, OCSP, LDAP, etc.). The present invention differs in that it enables interoperability with any CA or PKI in order to retrieve and report certificate status. It also reduces the reliance on real-time continuous connectivity between the system or TCU and CA certificate status reporting elements, to a large extent, by caching certificate status.

In one aspect of applicants' invention, a method of providing CSS for checking the validity of certificate of authenticity issued by each CA, comprising the steps of: identifying information required to retrieve a status of a certificate of authenticity from an issuing CA that issued the certificate of authenticity; configuring the connector for communication with the issuing CA according to the identified information; communicating with an issuing CA according to the configured connector; and retrieving the state of the certificate of authenticity. The issuing CA and connector are specified by a list of approved CAs in the configuration store.

The local date and time may be checked to determine if they fall within the validity period indicated in the validity period of the certificate of authenticity. By checking and approving an issuing CA according to predetermined business rules, the issuing CA may be included in a list of approved CAs, and if the issuing CA is checked and not approved, the issuing CA may be specified on a list of non-approved CAs in a configuration store. Checking and approving an issuing CA may include: a representation of the trust certificate is registered with the CSS and at least the representation, status and lifetime data elements are added to the local cache. The connector is then configured to retrieve the added state when querying the state of the trust certificate. Communication with the issuing CA may also be accomplished according to the order of the connectors.

The method may further include checking the local cache for status and retrieving the status from the local cache if the status is found in the local cache and the local date and time is within the validity period. If no status is found in the local cache or if the local date and time is not within the validity period, the CSS establishes a communication session with the certificate status reporting component of the issuing CA, composes a certificate status request from the configured connectors, retrieves the status from the certificate status reporting component, closes the communication session with the certificate status reporting component, and adds at least the identification, status, and lifetime of the validation certificate to the local cache.

The certificate status may be indicated with a CRL, and the CSS retrieves the CRL from a certificate status reporting component listed in a configuration store according to the publishing schedule of the issuing CA, the CSS flushes a cache associated with the issuing CA, and the CSS determines the status of the certificate of authenticity according to the CRL and stores the status in the cache associated with the issuing CA.

The certificate status may also be indicated with a delta certificate revocation list ("CRL"), and when an issuing CA notifies that a CRL is available, the CSS retrieves the CRL from a certificate status reporting component listed in a configuration store; if the CRL is a complete CRL, then the CSS flushes the cache associated with the issuing CA, determines the status from the CRL, and stores the status in the cache; and if the CRL contains only changes that occur after publishing all CRLs, the CSS determines a status from the CRL and stores the status in a cache memory.

In another aspect of applicants' invention, a method to retrieve the status of a certificate of authenticity issued by an issuing CA in response to a query from a TCU to a CSS to validate the status of the certificate of authenticity comprises the steps of: if the status exists and appears in the cache of the CSS, the status is located and reported; otherwise, the following steps are executed: obtaining a state type and a retrieval method from a CSS configuration repository; reporting the status as valid if the status type is CRL and the status is not found in the cache; if the state type is not a CRL, then a certificate status request is composed based on the state type; establishing a communication session with an issuing CA; using the obtained retrieval method to retrieve a status from a status reporting component of the issuing CA and end the communication session; interpreting the retrieved state; associating a lifetime value representing a period specified by the CSS policy for the state type with the interpreted retrieved state; adding at least an identification of the certificate of authenticity, a status, and a lifetime value to the cache; and reporting the status to the TCU in response to the query.

In yet another aspect of applicants' invention, a CSS for providing an accurate and timely indication of the status of a certificate of authenticity issued by an issuing CA comprises: when the issuing CA of the certificate uses the CRL to indicate the status, the status of the certificate of authentication is provided as instructed by the CRL. Otherwise, when the cache memory includes a status data element and a not-exceeded lifetime data element, the status as indicated by the cache memory is provided. If the age data element is exceeded, the state is purged from the cache and requested and retrieved using the real-time certificate status reporting protocol when the state is not in the cache. At least the identification of the certificate, the status and lifetime data elements are added to the cache and the retrieved status is provided.

A state usage counter data element may be added to the cache and incremented or decremented each time the state of a certificate is checked. If the state usage counter data element exceeds the threshold, the state is provided and the cache is cleared with respect to the state. A state last access data element may also be added to the cache and in combination with the state usage counter data element enables determination of the activity level of the credential state.

When a request is made to the CSS to retrieve the state of the new certificate and the cache has reached the allocated buffer size limit, the CSS searches the cache for the last accessed data element designating the oldest date and clears the corresponding cache entry; and the CSS then retrieves the requested state, places it in the cache, and provides the requested state.

In yet another aspect of applicants' invention, a method to perform a transaction between a first party and a second party by transferring control of a verified information object having a verifiable credential thread (trail), comprising: retrieving a validated information object from a trusted repository, wherein the validated information object includes a first digital signature block having a digital signature of a submitting party and a first validation certificate relating at least an identity and a key to the submitting party; executing the retrieved validated information object by the second party by including the digital signature block of the second party in the retrieved validated information object; and forwarding the executed retrieved validated information object to the TCU.

The TCU verifies the digital signature by at least retrieving the status of the certificate of authenticity from the CSS and validates the certificate of authenticity associated with the digital signature. The TCU rejects the digital signature block if the corresponding digital signature is not verified or the state of the respective certificate of authenticity expires or is revoked, and adds the digital signature block and the date and time indicator of the TCU to the information object and controls the object on behalf of the first party if at least one signature block in the information object is not rejected.

Drawings

The various features and advantages of applicants' invention will become apparent from the specification, when read in conjunction with the appended drawings, in which:

FIG. 1 illustrates a TCU electronic message object validation process using CSS;

FIG. 2 illustrates a background CSS process whereby individual CRLs are added to a certificate status store;

FIG. 3 illustrates the parsed CRL, independent caching of OCSP responses, and the status resulting from other certificate status reporting methods;

FIG. 4 illustrates an extensible syntax of a signature block containing exemplary data elements in which a digital signature is added to the information object segments and additional data (verified attributes);

FIG. 5 illustrates the TCU interacting with CSS and CSS retrieval of certificate status via the Internet from affiliates and foreign CAs;

FIG. 6 illustrates a TCU user registration process terminating at a certificate status check step, wherein a digital signature confirmation demonstrates a successful registration;

FIG. 7 illustrates a TCU user registration process terminating at a certificate status check step, wherein a user certificate is issued by an alien CA, wherein a digital signature confirmation demonstrates successful registration; and

FIG. 8 depicts an auto-lease example showing how CSS is used in e-commerce.

Detailed Description

Certificate status checking is a critical element for any system or TCU reception that an electronic information object submits. To accept the submission, the certificate status must be reported as valid. The querying of the credential status typically requires communication between the TCU and the credential status source. The frequency of these communications will increase in proportion to the number of TCU submissions.

The checking of the certificate status may be a real-time requirement and the status query is performed for each submission. However, as with the CRL, the state may not necessarily be updated in real time. All CRLs are published at regular intervals, usually once or twice daily. CRL retrieval and repeated parsing may have a negative impact on system performance. The present invention significantly reduces the direct computational and communication requirements by eliminating a significant amount of work from the CSS. A single certificate status protocol is implemented between the TCU and the CSS. This status protocol may have attributes similar to IETF OCSP that allow querying the application of the CA for the status of a single certificate and thereby minimize processing overhead.

The CSS is provided with and maintains sufficient information about the location, the communication means and means to handle the certificate status for each CA with which it needs to interoperate. Thus, the CSS may stabilize and optimize an application design. The CSS advantageously parses and caches the certificate status in order to minimize the status response time to TCU status queries. Thus, the CSS eliminates the need for any legacy form of PKI interoperability. The potential compromise recovery is greatly enhanced by being able to easily revoke a TCU user account or delete a group of users by deleting a CA from the CSS list of approved CAs.

Use of the certificate of authenticity:

after logging into the TCU, the participants may be required to further authenticate themselves, but use public key passwords and their authentication certificates. Such verification may be associated with secure session establishment, TCU service or digitally signed requests and submissions of electronic information objects.

Before anyone can interact with the TCU, four conditions must be met: 1) they must first register as system users, 2) if they are not only granted read-only access, they must have issued and possess a public key pair and their matching certificate of authenticity, 3) the certificate must be issued by an approved CA, and 4) the user's certificate must not have expired or must not be reported as invalid or revoked. This last condition typically requires that the TCU direct a query to the issuing CA to retrieve the certificate status. This is not an easy or simple task, as there are a number of standards and CA implementations for reporting certificate status.

As stated in the background section, some form of PKI interoperability is often required when multiple CAs or PKIs are involved. The present invention eliminates this need by creating a certificate status service. CA cross-certification or bridging is unnecessary since the only knowledge required for CSS is the list of approved issuing CAs, their IP addresses, etc., and their way of reporting certificate status.

To retrieve the certificate status, a connector or program module is defined for each certificate status method. Each certificate of authenticity contains a subject (user) field and an issuer (CA) field. The issuer field is used to direct the TCU query to the CSS, which then checks its cache for the presence of credential status. If the state exists in the CSS cache, it is returned to the TCU. If the state does not exist, the CSS will invoke the appropriate connector to retrieve the state of the certificate. There are many ways to report and retrieve certificate status: LDAP, OCSP, CRL, etc.

To perform any TCU action, the user must first log into the TCU. Once successful, users can create or select transactions if they are approved by such regulatory agencies. If they have permission to submit the electronic information object, they can now do so. When an electronic information object is received, the TCU performs the necessary digital signature validation steps. A certificate status query will be composed and sent to the CSS. If a valid status is returned, the TCU will accept and store the commit as an authorized copy, otherwise it will be denied.

Digital signature processing and certificate status checking:

the digital signature may be applied to one or more segments of the information object or to the entire content of the information object. The digital signature may belong to the party to the transaction or to an agent that enables the transaction to reach a condition or state within the scope of the business process. Indeed, a digital signature may be applied to additional information relating to the task being performed. One such example might be the notes of a county recorder on the title deed. Another example might be an application of a signature of a principal that attests to the authenticity of an information object being submitted to a TCU. In this latter scenario, the submission is referred to as a wrapped (wrap) or encapsulated information object because their digital signature is applied to the entire content, which is exempt from any subsequent modification.

Whenever a digital signature is applied, the signer will be required to confirm their intent to bind with their digital signature. This submission action required by recent regulations may take the form of readable text in a display window or flashing screen, and may require invoking a graphical button and/or logging into an encrypted token, which is also a key and credential repository. The practical paradigm of voluntary submission is: the signature block is formed by utilizing a trusted application that uses selected content to compute the user's digital signature and combining it with their certificate of authenticity. The signature block may also contain verified and unverified data elements. Any data elements contained in the digital signature calculation that are verified, such as the base or local date-time for the signature, are protected by the digital signature. The unverified data elements are added after signature computation and are not protected. Fig. 4 shows a layout of a sample syntax and signature block containing data elements. It should not be interpreted literally, but it is merely intended to be an illustrative example.

The information objects and any signature blocks can advantageously be placed on tags in envelopes (S/MIME) or in extensible information syntax (XML, HTML, XHTML) for processing convenience and to simplify information processing. This data structure is then sent to the TCU for validation. Alternatively, the signature block may be sent independently to the TCU to be appended to the actual source record that never leaves the TCU. In the latter case, each signature block is independently validated.

At the time of submission, the process of digital signature validation differs from that performed thereafter. The TCU performs four-step validation when it first sees a digital signature: 1) a process of verifying the digital signature, proving that the content protected by the digital signature has not been changed during transmission; 2) checking whether the current TCU time falls within a validity period of the individual's license for the certificate of authenticity ("not before", "not after") the validity period; 3) requesting and retrieving certificate status from the issuing CA, CRL distribution point or another approved source of certificate status using locally specified CSS; 4) the TCU user account information is confirmed to be consistent with the information conveyed in the certificate and the requested action is approved in the TCU rules database. The process adds an additional step to the submission of the information object. This fifth step checks that the identity of the submitter matches the identity of the party that established the current session with the TCU. If all tests are successful, the action is allowed and/or the information object is accepted and the TCU saves it on behalf of its owner. If either step fails, a remedial procedure is initiated.

After this initial certificate status check, the trusted environment of the TCU maintains the authenticity and integrity of all saved information objects. There is no pre-consideration that any additional certificate status checks will be required unless a new version of the document is submitted.

Both aspects of the invention differ from the normal processes of PKI embodiments. Firstly, the method comprises the following steps: the present invention is based on the existence of an application, that is, the TCU (or any application/system that requires certificate status validation) and its ability to create and maintain an electronic original source record. The second is that only the "issuing CA" needs to be identified as following the policy governing the trusted environment and neither CA cross-certification nor PKI bridging is required. The necessary proof of inclusion of the "issuing CA" is a documented business relationship. During the TCU registration process, a user account is created that references user-specified credential information that actually binds the user account with the user's authentication credentials.

The TCU uses:

typically, once an institution agrees to use the services of the TCU, the agent for that institution is granted control over access to the institution's transactions. The agent of the institution then identifies a group of individuals that they will authorize the performance of the selected action with respect to the institution transaction. All actions require the user to have an account with the TCU, require that the account be active, and require that the user have a registered identity and be able to provide an appropriate password or respond to a query phrase. In addition, each transaction consisting of a versioned set of electronic raw source records has a set of permissions to manage user access at different steps in the business process. When a transaction is conducted through a normal business process, i.e., a business process that is initiated via permanent maintenance or destruction, this is exemplified by the right to approve and remove transaction records. Logging into the TCU only requires viewing the electron source recording if permitted. However, any system-wide action or introduction or change of electronic source records requires that individuals further authenticate themselves by encryption with public keys or by applying their digital signatures and authentication certificates. In all cases, the identity of the individual must be verified. In case of digital signatures, this requires: 1) the user has the appropriate access permission, 2) decrypt the digital signature and verify the content if the underlying hash or message digest that has been applied has not changed, 3) check if the time of submission falls within the certificate validity period, and 4) check if the user certificate is still valid.

Certificate status checks require querying the issuing CA or certificate status responder. Since this step must be done with each authenticated action or electronic source record submission, the communication bandwidth may become excessive and there may be delays, backlogs, and rejections due to unanswered or slow status responses. The present invention addresses these and other highly guaranteed aspects of operating a TCU and ensuring the validity of all parties interacting with the TCU.

In a highly assured environment for operating a TCU, only certificate status checks are required when a qualified user requests a service. For information objects, the certificate status need only be checked at the time of submission. If all digital signatures are determined to be valid, the information object is thereafter considered to be authentic. Security and procedural practices and methods are at appropriate locations at the TCU to prevent malicious behavior and hardware failures that result in unauthorized document changes or loss. Each submission results in the creation of a new version of the electron source record. The TCU is responsible for maintaining knowledge as if it were the latest version of the source record. This version may be determined as an electronic script and as a transferable record. The TCU demonstrates the assumption of control of its original source record by adding a reliable date-time stamp to the source record and then by applying it to its digital signature and appending its certificate. The encapsulation may be applied to the source record for security and handling convenience. Although this versioning process creates independent verified credential cues (trail-of-evidence) and policing, a separate redundant audit record is maintained for validation (correlation).

Applicants' CSS overcomes the above-mentioned limitations that persist with PKI and electronic commerce. When creating the certificate status, the CSS is registered with the source information needed to obtain the certificate status from the member CA. The source information of a foreign approved CA may be entered during the user registration process. CSS retrieval information is required for each certificate status source. There are several types of certificate status sources and the CSS is required to have a connector or method for each type registered.

One method by which some CAs transfer the status of a certificate is the CRL, which includes a list of revoked certificates and the reasons for their revocation, as well as the issuer of the CRL when it is issued and when the next CRL version is to be published. Each CRL is signed by the issuing CA or a designated signatory to ensure its integrity and authenticity. These certificates are deleted from the CRL once the validity period of the certificates has been exceeded.

In the case of a CRL, the CSS retrieves the CRL's most recent interpretation from a CA distribution point, such as, for example, the X.509 v2 CRL profile (IETF RFC2459, 1 month 1999), validates its signature, parses it, and creates a cache to store the results. When the CSS performs the next CRL download, the CSS is managed using the CRL publication time interval of the CA. Each CRL contains a validity field that is typically set to allow some tolerance in the download process. This takes into account traffic congestion and CA failure time and if this time interval is exceeded, the CSS will be forced to require remedial action. Such remediation may include revalidation of any submissions associated with the newly added revoked certificate. Each new CRL replaces the previously loaded CRL. The exception to this rule is the delta CRL line (process). The contents of the delta CRL are added to the current cache contents. Delta CRL baserlnumber refers to the most recently released full CRL. The delta CRL is published at shorter time intervals (minutes, hours) since the last full CRL and only when certificate revocation has occurred. The CSS is responsible for retrieving CRLs and delta CRLs from publication time intervals or notifications and does not exceed the time intervals established in the TCU security policy.

The second method used by the CA to distribute certificate status is OCSP. In the case of using OCSP, the CSS queries the OCSP responder when requesting certificate status. OCSP responses are signed to ensure their integrity and authenticity. The CSS parses the OCSP response and adds the certificate details and status to another cache. An age flag determined by the local TCU security policy is included and determines when an entry is to be deleted from the cache. The purpose of this feature is: communication overhead is minimized when several information objects are uploaded to the TCU by the same party/entity within a short time interval. The lifetime marker will typically be significantly shorter (e.g., 5 minutes) than the normal CRL publication time interval (twice daily, daily). If more than one information object is processed, the CSS may again check the certificate status before clearing it from the cache to ensure that no certificate revocation has occurred. If certificate revocation has occurred during a lifetime time interval, the owner must be notified of the point of contact. Several other query methods exist, but will not be described for the sake of brevity. It is to be understood that when these several methods are employed, they would each require a connector and potentially a separate cache.

FIG. 1 shows a process flow for creating an electronic script. For purposes of illustration, the information object is assumed to be a sales contract. A copy (unexecuted) of the electronic information object is retrieved from the TCU or from the document preparation system and digitally or holographically (handwritten) signed by the appropriate party. If the execution process has been supervised, the owner's agent digitally signs and encapsulates the information object with the trust application and sends it to the TCU.

Having previously created, executed or retrieved the electronic document, the submitter digitally signs it and submits it to the TCU, as in step 101. In this electronic packaging process, an envelope is formed that contains the signed content and a digital signature block that also contains the digital signatures and certificates of the submitter and any other signers. Five processes are depicted in fig. 1: (1) act upon finding an invalid digitally signed and/or revoked certificate, (2) perform certificate status checks where the certificate status must be retrieved, (3) perform certificate status checks where the certificate status must be retrieved, (4) CRL retrieval and processing, and (5) create an electronic script when the electronic package document is determined to be authentic. In step 103, the TCU receives the electronically encapsulated electronic document. In step 105, the TCU confirms that the submitter has the right to add the electronic document to the selected account and/or transaction. In step 107, the TCU cryptographically verifies any digital signature contained in the electronically wrapped digital electronic document. The public key found in the x.509 certificate of the signatory is used during the verification process. In step 109, a certificate validity period is extracted from the signer's certificate of authenticity and, in step 111, the validity period is checked against the current date and time. If any of the above tests fail, the submission is rejected in step 113 and a negative acknowledgement may be sent in step 115. The action is recorded in step 117.

If all tests are successful, the certification status of each certificate contained within the envelope is requested from the CSS in step 119. In steps 121 and 123, the certificate status is checked to see if it exists in the certificate status repository. In step 125, the certificate status is retrieved and the validity of the certificate is checked in step 127. If for any reason any certificate is found to be invalid, the submission is rejected in step 113, a negative acknowledgement may be sent in step 115, and the action is recorded in step 117. The submitter is expected to seek remediation.

If it is determined in step 127 that all digital signatures and certificates are valid for the submission, then the TCU applies another envelope containing a date-time stamp and a TCU digital signature block in step 129. The TCU then assumes control of the submission as an electronic original record on behalf of the record owner. In step 131, the TCU places an electronic script in the protected persistent memory, in step 133, the TCU sends a positive acknowledgement, and in step 117, upon completion, the TCU records the action.

If it is determined in step 123 that the certificate status does not exist in the certificate status repository, then in step 135 the CSS retrieves the issuing CA field from the certificate in the testing phase. In step 137 the CSS sees that the issuing CA is on the approved CA list, which may be maintained and accessed by the CA connector repository in step 139. If the CA is not in the list, an invalid status is returned and the process resumes at step 125 and continues via steps 127, 113, 115, and 117, which results in a rejection of the commit and a transmission of a negative acknowledgement and a record entry. If the issuing CA is found on the approved CA list in step 137 and the certificate status reporting mechanism is determined to be a CRL in step 141, a valid status indication is returned to step 125. If the CA is known and the status of the subject's certificate does not exist but the status mechanism is a CRL, then it may be assumed that the certificate status is valid, providing a CRL that exists and is current to the CA. The process then continues via steps 127, 129, 131, 133 and 117, which results in the creation of an electronic script, a transmission positive acknowledgement and the action record entry just completed.

If it is determined in step 141 that the credential status reporting mechanism is not a CRL, then the credential status reporting mechanism is queried using the connector information obtained in step 137. Included in the connector specification is all configuration information that requires querying the appropriate certificate status repository, which may be a CA, directory, or any other type of certificate status repository. The state repositories associated with steps 145, 147, 149 and 151 (i.e., LDAP directory, OCSP responder, database and server, respectively) are all examples of such repositories. In response to the query in step 143, one of these responds to the certificate status information and adds the status to the certificate status repository in step 153.

When the addition is made in step 153, the process of credential status logging resumes at step 121 and continues through steps 123, 125 and 127 to the end where either the submission is accepted (steps 129, 131, 133, 117) or rejected (steps 113, 115, 117).

The CRL is published at predetermined time intervals in steps 155 and 159, and if necessary, in step 157 when suspicious damage is reported and the policy requires an immediate response. This process is further described in fig. 2. If the CA is known and the status does not exist and the status mechanism is different from the CRL, the certificate status service selects a connector and queries the certificate status mechanism (step 143). The connector contains the necessary information to enable state retrieval and interpretation. Any source of real-time credential status depicted in step 145-151 will respond to credential status queries made regarding the current status, but this process is not limited to only those sources. The state is received and added to the certificate state store in step 153. When a state is added, the response and action is generated back to step 123, with the processing of the state beginning again at step 125 and ending as previously described.

Referring now to fig. 2, the CSS performs CRL retrieval as a background process. The CRL contains a list of all revoked or aborted certificates until the current date and time exceeds the validity period contained in the certificate. Aborted certificates are considered that they have been revoked, but they can be recovered, which can result in their being deleted from the CRL. The revoked certificate cannot be recovered.

In step 155, the CA administrator configures the CA to publish the CRL at predetermined time intervals. In step 157, the CA administrator may also publish the delta CRL as indicated by the local certificate or security policy. The CA administrator or CA will push a notification about the publication of the delta CRL. A delta CRL may be generated whenever a certificate is revoked or aborted during the time interval between the publication of all CRLs. A delta CRL may contain a complete list of revoked CRLs. In step 201, the CRL and the delta CRL are published into a CRL repository or directory.

In step 203 the CSS retrieves a CRL publication schedule or a delta CRL notification, and step 205 depicts a timer for a predetermined time retrieval. The timer also allows retrieval from the "next update" field contained in all CRLs. In step 207, the CRL or the delta CRL is retrieved from the CRL repository. In step 209, the CRL or delta CRL is parsed, or parsed when notified, before being added to the appropriate cache in step 153, or added to the list in the certificate status store in step 121 based on an established schedule. Parsing the CRL allows for easier management and reduced overhead in the CRL entry lookup process. For completeness, steps 119, 123, 125, 135, 137 and 141 of the CSS are illustrated in fig. 2 and are implemented as described in connection with fig. 1.

Referring now to fig. 3, the certificate status store contains a number of caches that hold certificate status from different reporting mechanisms. The caches (five of which are depicted in fig. 3) may map to a single CA (caches 301, 303) or a set of CAs (caches 307, 309). For real-time reported states, the state is kept in cache until space is needed (e.g., least frequently used) or according to policy requirements (e.g., only for a specified time interval). Once the criteria are exceeded, the state is typically cleared.

The purpose of caching is to preserve the certificate state for a period specified by the policy, thereby reducing the communication overhead required during certificate state and CRL retrieval. Thus, the CSS can cross communication breaks.

The CRL may be parsed and individual revoked certificate states may be placed in a cache in order to reduce the computational overhead incurred when the CRL must be repeatedly checked. This is depicted with caches 305, 307. The contents of the cache are replaced each time a new full CRL is retrieved.

Referring now to fig. 4, an exemplary syntax is shown representing some of the more important data elements that need to be contained in the digital signature block. Fig. 4 is a free-form example of data elements that make up a digital signature, where the signature is applied to multiple message segments and date/time stamps. This example is intended to illustrate syntax that can be used for the digital signature block. It is noted that the < cumulant HashValues > data element is applied to HashValues of one or more segments or the entire content, as well as any validated data.

FIG. 5 depicts a secure communication architecture showing building blocks (building blocks) that support certificate status services. The figure shows the interaction between CA, CSS and TCU. Preferably, the CSS is placed locally on the TCU to ensure high efficiency. Its primary purpose is to provide a TCU with a common interface and to ensure secure and timely provisioning of certificate status information. Its secondary purpose is to ensure a guaranteed level or quality of service by managing the communication and computational overhead required in maintaining certificate status information.

As shown in fig. 5, the CSS server and TCU with appropriate communication routers and hubs are advantageously arranged behind the communication firewall. The router and hub pass information to the CSS and TCU as appropriate. Some of this information includes electronic package submissions that are submitted from the user client application to the TCU over a network such as the internet, as described above. CSS and TCU communication via OCSP is also depicted.

Fig. 5 also depicts three CAs in different exemplary environments behind various communication firewalls. The enterprise CA may include a server that interfaces with a rental industry CA enclosed with dashed lines. The foreign PKI or responder may include a server that interfaces with entities such as PKIs, CAs, and certificate status responders. The member PKI of the hierarchy may contain servers that interface with entities such as V3 LDAP for CRL and certificate status, root CA, and CAs for the mortgage and lease industry, settlement agencies, and title insurance companies.

Fig. 6 and 7 depict the use of certificate status services during a user (subscriber and entity) registration process for a member CA and an alien CA, respectively. A member CA is a CA trusted to issue user certificates. Foreign CAs are those CAs that operate by outside entities and need to be approved before using their certificates in conjunction with TCU activities. User identity authorization needs to be strictly enforced by all CAs or delegated to the agency agent. The additional requirements are: the credentials directly associated or authorized to the user are required for use by the accounts of one or more subscription authorities before the TCU can grant access to that user. Once this is done, the TCU will accept the user's digital signature and rely on the CSS for certificate status validation.

In fig. 6, the TCU registration process begins at step 601 with receipt of an organization administrator/agent with user registration information from a patron. In step 603, this manager/agent is responsible for validating the sponsor's authority to issue the request. The patron typically only gives control over their account. In step 605, the administrator/agent registers the user with the TCU, establishing a user account. The administrator/agent may then assign transaction privileges to the user in step 607. Transaction privileges may include the ability to submit, interpret, transfer, etc. electronic scripts and other source records.

In step 609, the encrypted token (digital signature mechanism) is initialized and in step 611 a public key pair is generated on the token. In step 613, a certificate request is created and in step 615 the request is sent to the CA of the authority. In step 617, the certificate is retrieved and placed on the token. In step 619, the credentials are bound to or associated with the user's TCU account.

In step 621, the user's identity is confirmed, for example by displaying the identity of the user to an organizational manager/agent who can personally confirm the user's identity. In general, at least two forms of identification will likely be required. This should be sufficient in addition to high value transactions, where it may be required to vouch for the identity of the user to someone known to the administrator/agent, since the user is initiating participation. In step 623, the user is asked to make a contract, whereby the binding agrees to the user using the user's digital signature. In step 625, the user is assigned an application user manual and whatever instructions are deemed necessary. In steps 627 and 629, the user is provided with a registration ID, a temporary password, and an encryption token.

In step 631, the user logs onto the system and, in step 633, submits a test document to the TCU. In step 635, the TCU validates the user's digital signature and certificate. In step 637, the TCU queries the CSS for certificate status information. In step 639, the TCU receives the status and proceeds accordingly. If the received credential status is valid, then the registration is complete and the user can access and use the TCU in step 641. If the certificate status is invalid, registration ends at step 643 and the administrator/agent determines the cause of the error and begins remediation, which may involve repeating some or all of the outlined registration process steps. The reliability procedure outlined in fig. 6 ensures that the registrant is fully enabled at the end.

In fig. 7, if the condition for specifying the policy is satisfied, the user is allowed to use the encrypted token previously issued by the foreign CA. The registration steps 601 to 607 are then performed as described above. User identity verification and contracting steps 621 to 627 are then also performed, as described above.

The process differs from the process described in figure 6 in that the user already has a token. In step 701, the user places the token in a compatible reader and logs in. In step 703, the administrator application retrieves the user's credentials from the token. In step 705, the certificate information is displayed and the issuing CA identification information is acquired. The CA information is used in step 707 to verify that the CA is in an approved list. If the CA is not on the approved list, the CA information is provided to the TCU administrator in step 709, and the administrator checks the application policy authority for permission to proceed with the registration in step 711. Only the application policy authority can authorize the addition of foreign CAs to the approved list.

If permission is denied in step 713, the registration terminates in step 649, which gives the user three options. One is to request and use a token issued by the member CA. Another option is to request an evaluation of the CA rejection decision. The third option is to request the name of a previously approved foreign CA.

If the issuing CA is approved but not on the list in step 713, the administrator adds the CA and connector information to the approved list and configures the CSS to retrieve the certificate status from the CA in step 715.

In step 619, the user's credentials are bound to or associated with the newly created user account. As shown in fig. 6 and steps 631-639, a trial submission by the user to the TCU is required to confirm that the account has been properly set and that the user has access to the TCU. If the CSS returns valid status information, then the registration is complete in step 641. If the CSS returns an invalid status, the administrator determines the cause of the error and initiates remediation, which may involve repeating some or all of the registration process steps, as described above. The most likely cause of failure may be related to the CSS being able to reach and correctly retrieve the certificate status from the foreign CA.

The CSS plays an important role in confirming that both the user certificate and the issuing CA are authorized when accessing the TCU or other system. If the issuing CA is removed from the approved list and its connector configuration data is removed, all associated users will be denied further access to the TCU. It should be understood that the CSS can work with other applications and systems that require certificate status, including applications and systems that need to interoperate with multiple PKIs and CAs.

For example, another use of CSS is to provide the status of a trusted authentication certificate, including self-signed certificates, where there is an agreement between the client seeking service and the application operator. A representation of the trusted certificate (e.g., PEM, certificate ID, applied digital signature) is cached by the CSS and the status is queried with the trusted certificate connector. This allows applications to have a single certificate status meaning regardless of whether the certificate is self-signed or issued by the CA. Such a trusted certificate approach may be used where a small number of controlled certificates are used by a community rather than querying one or more CAs of the community. It will therefore be appreciated that the terms "CA" and "issuing CA" as used in this application encompass accepted issuers of such self-signed certificates as well as conventional CAs.

Further, the CSS may use a combination of connectors to retrieve the certificate status. At least one connector may be "virtual", such as a connector described only for use with a trust certificate. The CSS invokes connectors in a predetermined order (e.g., a sorted order) until a certificate status is obtained. This approach enables the creation of a hierarchy of state sources (e.g., most trusted to least trusted).

FIG. 8 depicts a car rental example showing how CSS is used in e-commerce. The car dealership or a representative of the dealership (hereinafter referred to as the dealership for the sake of brevity) is issued a corresponding certificate of authenticity by the car CA, which may be depicted as a computer. The bank CA issues the corresponding certificate of authenticity to the car tenants present in the car dealership privileges. The financial CA issues a corresponding certificate of authenticity to the remote lessor. Alternatively, the tenant or lessor either party has created a self-signed certificate that the dealer has registered with the rental application and CSS, for example because the tenant is the dealer's old owner.

As described herein, the CSS utilizes any certificate status reporting means that uses an approved status reporting protocol to retrieve and report the status of these and other certificates. In fig. 8, it is assumed that both the automobile CA and the financial CA use OCSP, and that the bank CA uses CRL, and that both the dealer and the tenant are provided with some form of token (e.g., PKCS #11, PKCS #12, browser key repository, etc.) that contains their certificate and the encrypted signing method. It will be appreciated that FIG. 8 is merely one example of performing a transaction; more or fewer CAs may be connected to the communication as necessary for a particular transaction.

In step 801, the dealer creates the rental contract or retrieves it from the rental application, such as a computer program running locally at the agent or remotely at a remote site (e.g., on an application server). In step 803, the dealer arranges for the rental to be performed by the tenant and lessor. The lease may be displayed to the local tenant and the remote lessor at this point and the dealer may be asked to answer any questions and corrections may be made if needed. The dealer can arrange for a lease to be displayed to a lessor by providing the lessor with a URL (uniform resource locator) that enables the lessor to review and execute the lease and return the executed version to the dealer on-the-fly. After being signed locally by the tenant and distributor, for example using a tablet PC that captures the tenant's digital signature for the lease, and remotely signed by the lessor, the lease is transmitted to an electronic vault (step 805) which is shown in communication with an application server. Advantageously, digital signing by tenants and distributors is dynamic, while the application server updates the display by applying a "signed by. Preferably, the actual digital signature is not displayed.

It will be appreciated that the application server and associated electronic vault may be used by a dealer to implement a contract that is remotely signed by a lessor. In steps 807, 809, and 811, the lessor retrieves the lease from the safe, agrees to the terms of the lease by a digital signature, and returns its digitally signed version to the safe. Steps 807, 809, and 811 illustrate multi-site collaborative and asynchronous transaction processing.

In steps 813, 815, and 817, the received electronic document (the lease) is checked for digital signatures and, if found, the digital signatures are verified and the corresponding certificate of authenticity is validated. In step 817, the local time is checked to ensure that it falls within the validity period of the certificate, and in step 819, the CSS is queried for the status of the certificate. In response in step 821, the CSS first checks its local cache or data store for certificate status, and if the status of the certificate exists and is current, the CSS returns the status of the certificate as "valid" in step 827. In step 823, if the certificate status does not exist or is not current, the CSS queries the issuing CA with the connector type created for this purpose. In step 825, the issuing CA (e.g., a bank CA) or its status reporting method (e.g., a directory) returns status to the CSS, preferably using the same connector, and in step 827, the CSS reports the status of the queried certificate to the application server.

In step 829, the application server assumes control of the electronic document and saves it as a new version in the electronic vault, assuming that all digital signatures and certificates are verified and validated, proving that the electronic document is authentic. Thus, it will be clear that, for proper characteristics, the application server and the electronic vault cooperate like a TCU. In step 831, the new version is designated as an authorized copy, electronic script record, which may also be a transferable record, by adding a date-time stamp to the document and applying the digital signature of the TCU to the document. This step occurs as long as at least one digital signature on the document is valid.

In step 833, if either of the digital signatures or certificates fails all tests, the dealer is alerted to seek remediation, which typically involves repeating steps 801 through 829 until a valid substitute digital signature is applied. If the status of the signer's certificate is revoked or expired, the remediation process cannot be completed until a new certificate and cryptographic material is issued.

It will be appreciated that information objects such as car leases may exist in electronic form, e.g., XML, PDF, PKCS #7, S/MIME, etc., which enables the placement and detection of digital signatures and prevents unauthorized modification. Many of these forms can therefore be viewed as providing a secure envelope or envelope for the contained information.

It is also understood that the CSS can be used to check the status of the certificate regardless of the key usage. Such credentials include, but are not limited to: the primary uses certificates that are not identity and authentication, e.g., key agreement/redemption, certificate signing, CRL signing, key encryption, data encryption, encryption only, decryption only, and Secure Sockets Layer (SSL). It will therefore be understood that the term "certificate of authenticity" as used in this application generally encompasses such certificates which are not used for identification.

In addition, the CSS connector can advantageously embed more than one certificate status check in a single communication. This capability may be used, among other things, in validating some or all of a chain of user/entity certificates and CA certificates, such as from a root CA down to a CA hierarchy of issuing CAs. This provides an additional guarantee that: all CAs in the certificate path are still valid.

The application has described a method for configuring a Certificate Status Service (CSS), the method comprising the steps of: the method includes determining setting information required to retrieve certificate status for the necessary issuing CA, identifying a connector compatible with a certificate status lookup technique used to retrieve certificate status from the issuing CA, configuring the connector with settings and communication parameters specific to the selected connector and the issuing CA, and establishing CSS mapping between the issuing CA and the connector. Adding the CA designation and connector to a list of approved CAs in a configuration store.

A method for performing a transaction by transferring an authenticated information object having a corresponding verifiable credential thread, comprising the steps of: the verified information object is retrieved from the trusted knowledge base by the first party. The validated information object includes: submitting a first digital signature of the party, a first certificate relating at least the identity and the encryption key to the submitting party, a trusted date and time, a digital signature of the trusted repository, a certificate relating at least the identity and the encryption key to the trusted repository; the submitting party's digital signature and certificate have been validated by the trusted repository at the time of submitting the certifying information object's authenticity; and the authentication information object has been placed in the memory as an electronic original information object set under the control of a trusted knowledge base.

The transaction execution method further comprises the steps of: prior to signing the action, any signing entity is required to submit to use their digital signature and to be bound by their digital signature, the information object is executed by any party, the party's at least digital signature and verification certificate is signed by the application, a signature block is created containing the signing party's at least digital signature and verification certificate, the signature block is associated with the information object, the foregoing execution steps are repeated, wherein multiple entities digitally sign the information object and/or envelope, and the digitally signed and/or enveloped information object is forwarded to the TCU. The TCU verifies each digital signature and validates each associated certificate of authenticity and retrieves the status from the CSS. If the signer's digital signature is not verified or the signer's certificate of authenticity has expired, the signature block is rejected or the report is revoked. Rejection of any signature block results in a request to replace the signature block or initiate remediation. If at least one signature block is determined to be valid, the TCU adds its own signature block (also containing a reliable date and time) to the subject information object, creating an electronic script that it holds and controls on behalf of the owner.

Creating a digital signature block may include the steps of: calculating one or more content hashes for one or more information object segments or for the whole information object, calculating hashes throughout the one or more content hashes and any added data, such as local date and time, signing principle or instruction, encrypting the calculated hashes with the signing party's private key, thereby forming a signer's digital signature, and placing the signer's digital signature in a signature block along with the signer's verification certificate. If the added data includes a local date and time, creating the digital signature block may further include the steps of: either the local date and time is displayed, the signatory is asked to confirm that the date and time are correct, and if either is incorrect, the local date and time is corrected, or the system date and time is trusted if these are set by the trusted time service and the local date and time are protected from tampering. The local date and time may be checked to ensure that they are accurate and fall within the validity period of the user's certificate of authentication, and that the local data and time are neither before nor after the date and time specified by the validity period.

The remedy for verifying a failed digital signature requires re-computing the digital signature and re-transmitting the signature block. Remedying violations of certificate of authenticity validity include: the user is notified that the user's credentials have expired and must be updated, and the transaction owner is notified that the transaction is not complete.

The one or more signature blocks and the layout of the information contained therein are specified by at least one signature marker. One or more handwritten signatures and dates are digitized and used for information object execution, and the layout of the signatures and dates is specified by at least one signature marker. One or more signature blocks may be independently transmitted to the TCU along with an indication of the corresponding signature marker, and the TCU is able to validate each signature block transmitted independently or as a whole. If the digital signature verification or certificate validation step fails, the TCU rejects the signature block and may request remediation, while if the signature block validation step succeeds, the TCU places the signature block at the indicated marker. To send signature blocks independently, the TCU may add a reliable date and time to each signature block. According to business rules, the TCU adds its own signature block containing a reliable date and time to the envelope containing the subject information object and the inserted signature block fields, thereby creating an electronic original information object. Multiple user signature blocks may be added within the envelope and the envelope applied recursively to implement other business and security processes.

The TCU may validate the digital signature and certificate of authenticity present in the signature block to be contained or added to the contents of the electronic original information object by performing the following operations: checking in a business rules database that a signing entity identified by a verification certificate has authority to perform the requested action, verifying the signing entity's digital signature, checking that the certificate validity period overlaps with the current reliable date and time, checking that the local date and time of transfer falls within a tolerable deviation of the TCU date and time, and checking the certificate status with CSS. If any of these steps result in an invalid output or false output, then the digital signature is deemed invalid, the requested action is prohibited and remediation is sought; otherwise, the digital signature is deemed valid and the requested action is allowed.

The registration of the issuing CA with the CSS may include the steps of: the issuing CA contained in the CSS repository is checked and approved as "authorized" according to industry or institutional business rules and system policies. If the checking step fails, the issuing CA is added as "unauthorized" to the CSS configuration repository and/or CA enrollment is terminated; otherwise, the issuing CA is added as "authorized" and the communication parameters (IP address, SSL key and certificate) and the method used to report the certificate status (OCSP, CRL, LDAP) are added to the CSS configuration repository and, if not already implemented, a connector is added to interpret the certificate status. As such, the CSS enables interoperability between a system or TCU and different certificate status responder groups.

The certificate status check advantageously uses CSS for establishing communication, retrieving and caching certificate status from an approved certificate issuing CA. When a CSS receives a certificate status query from the system or TCU, the CSS first checks its local cache to see if certificate status exists and returns status if found and within a lifetime time interval. If the certificate status does not exist or exceeds the scope of the lifespan interval, the CSS retrieves the status by first requesting connection information from its configuration store. The CSS then establishes a communication session with a certificate status reporting component identified in its configuration store. The CSS composes a certificate status request according to the methods contained in the CSS configuration repository, and the CSS retrieves the certificate status from the certificate status reporting component and closes the session with the component. The CSS adds at least the ID of the certificate, the certificate status and the lifetime to its cache and returns the certificate status to the requesting system or TCU.

The certificate status report may be based on the CRL and the processing of the CRL. The CSS retrieves the CRL from the certificate status reporting component listed in the CSS configuration store according to the publishing schedule of the issuing CA. The CSS clears its cache associated with the issuing CA, resolves the certificate status from the CRL, and places the certificate status into its cache associated with the issuing CA. When the issuing CA notifies that the CRL is available, the CSS may retrieve the CRL from a certificate status reporting component listed in the CSS configuration store. In the case where the standard requires that the CRL be a complete CRL, the CSS flushes the cache associated with the issuing CA, parses the CRL, and places the certificate status and related information into the cache associated with the issuing CA. Where the CRL contains changes that occur only after publishing the entire CRL, the CSS parses the certificate status from the CRL and places the certificate status and related information into a cache associated with the issuing CA.

Using CSS to obtain a credential state that allows a user, system, or TCU to use a single means for obtaining a credential state may comprise the steps of: the CSS is queried for the status of a certificate of authenticity that exists in a signature block on an information object, where the status query can use a single means (e.g., OCSP), translate the status query into a form required by the issuing CA, and retrieve and/or report the certificate status. If the certificate status is revoked, the signature block is not used and remediation is required; if the digital signature verifies and the certificate status is valid, the signature block is added to the electronic original information object.

If the state exists and is currently located in the CSS cache/data store, the TCU can query the CSS by locating and reporting the certificate state to confirm the signer's certificate of authenticity status and retrieve the type and method used to retrieve the certificate state from the CSS configuration store. If the particular certificate status method is a CRL and the status of the specified certificate is not found in the issuing CA cache in the CSS, then the CSS reports the certificate status as valid. If the certificate status method is not a CRL, the CSS composes a certificate status request according to the methods contained in the CSS configuration store and establishes appropriate communication with the issuing CA. The CSS utilizes the identified certificate status checking method to retrieve the certificate status from the status reporting component and close the communication session. The CSS parses or interprets the retrieved certificate status, associates a lifetime value equal to the period specified by the status type as set forth in the CSS policy, and adds at least the ID, status and lifetime value of the certificate to the certificate status cache of the issuing CA. The CSS then returns the certificate status to the requesting system.

A method for registering a user in a system or TCU in which a certificate is issued by an approved issuing CA known to the CSS, the method comprising: the user is checked using established member programs and criteria, user registration information is entered that also has been signed by an approved agency sponsor, and a certificate request is created and sent to the identified issuing CA. The user's authentication credentials are retrieved, issued, and placed on the token to be transferred. Digital signature, digital signature verification, and CSS certificate status checks are performed to ensure that both public key pair generation and certificate issuance processes are done correctly. The user is required to sign on an acceptance agreement that promises that the user gives the same weight to use their digital signature as they give to him or his handwritten signature, the token is delivered to the user, and the user's system or TCU account is activated.

A method of registering a user in a system or TCU, wherein the user already has a certificate issued by a CA and not known in advance to CSS, may comprise: query the user's token and obtain issuer information for the user's authentication certificate, and query the CSS repository to see if the issuing CA is contained therein. Otherwise, an industry or institutional policy manager is contacted to determine if the issuing CA satisfies the system rules for CA inclusion. As described above, in the case where the issuing CA is regarded as "unauthorized", registration is terminated, whereas in the case where the issuing CA is regarded as "authorized", registration proceeds.

A portion of the user authentication credential content may be used to bind the credential to a user account by: after granting the user access to the system or TCU, the user registration information is entered, the user's token is inserted, which saves their authentication credentials to a local token reader, the credential content is retrieved and displayed, the user is assured that the content is correct, and selected fields such as the credential ID, the issuing CA, the user's recognizable name conveyed in the credential extension, or a subset of other identifying information (e.g., objectaltname) are added to the system or TCU user registration data extracted from the credential. The extracted data may be specified in a system or TCU policy so that extraction and data entry may be automated.

A method whereby a presenter of an information object vouches for the authenticity of the presented information object, the method comprising the steps of: the submitter's signature block is appended to the information object and/or envelope and forwarded to the system or TCU. If the signature block validation fails, the TCU requests retransmission or remediation, and if the signature block validation succeeds, the TCU then checks whether the identity of the submitter matches the originator of the communication session, and rejects the submission if the originator and the submitter are different. If all checks are successful, the TCU adds its signature block to the submission, creating an electronic original information object.

A method in a CSS to maintain accurate and timely certificate status for a real-time certificate status reporting method employing lifetime data elements includes the following steps. If the CRL status method is used, the CSS reports the status. The CSS reports status if the certificate status is in the cache and the age data element is not exceeded. If the age data element is exceeded, the CSS clears the certificate status entry from the issuing CA cache. If the status is retrieved using a real-time certificate status reporting method (e.g., OCSP, LDAP query, etc.) and is not in the cache, then the certificate status is requested, retrieved, and reported. The CSS then adds at least the ID of the certificate, the certificate status and the lifetime to its cache and returns the certificate status to the requesting system or TCU.

A certificate status usage counter data element may be added to the status entry for the certificate in the CSS's issuing CA cache and the status usage counter can be incremented or decremented each time the status of the certificate is checked. If the status usage counter exceeds a threshold set by the CSS policy, then the certificate status may be reported, but the CSS then clears the certificate status entry from the issuing CA cache. If the CSS returned certificate status is invalid or revoked, then the system or TCU logs and/or reports the error to the submitter and/or transaction owner, and the requested action is disabled and remediation is sought. Otherwise, the digital signature is deemed valid and the requested action is allowed. The last accessed data element of the credential state may be added and used in conjunction with a usage counter to determine the activity level of the credential state.

When the criteria in the CSS policy are met, the background process may cause the CSS to automatically retrieve the updated certificate status and establish new age and usage counter data elements. Such prefetching may be implemented to reduce the average time between system or TCU certificate status requests and CSS responses.

If a request is made to the CSS to retrieve the certificate status for a new certificate and the issuing CA cache has reached its allocated buffer size limit, the data element last accessed by the certificate status is added to the entry for the certificate status in the issuing CA cache of the CSS. The CSS searches the issuing CA cache for the last accessed data element corresponding to the oldest date (least frequently used) and clears that entry. The CSS then retrieves the requested certificate status, places it in a free location in the issuing CA cache, and reports the status to the system or TCU acting according to the policy.

A method of status checking in a distributed CSS, comprising: coordination is performed between CSSs whenever a new issuing CA is introduced, establishing entries in all CSS repositories if another CSS is primarily responsible for querying the issuing CA, querying other CSSs instead of querying the issuing CA to reduce communication between CSSs and issuing CA, synchronizing and caching certificate status locally if multiple local systems have a high concentration of certificate status requests with respect to the issuing CA, and sharing or transferring query responsibilities if another CSS has more burdensome activity with respect to the designated issuing CA than the original primary CSS.

Excluding a set of users associated with an issuing CA by changing the issuing CA reference in the CSS repository to "unapproved", can be done by: requesting that approval of the issuing CA be reclaimed, reviewing the request for advantages and determining what actions, if any, are required, and changing the status of the issuing CA in the CSS repository to "unapproved" if it is determined that the issuing CA should be invalidated for any reason. Any subsequent certificate status request issued by a CA listed as "unapproved" will result in the CSS returning a failed status.

A method of re-authorizing a group of failed users by pre-setting the issuing CA reference to "unapproved" can be accomplished by: requesting permission to grant approval to the issuing CA, reviewing the request for advantages and determining which actions, if any, are required, and if it is determined that the issuing CA should be granted permission to the issuing CA, changing the status of the issuing CA in the CSS repository to "approved". The CSS handles certificate status requests for the restored issuing CA as if it were any other "approved" CA.

Communication with the status reporting component may be established by: creating modular and reusable devices for each certificate status protocol used to locate, request and retrieve such information, using versions of the devices that are compatible with all CAs and responders understanding the particular certificate status protocol, and holding versions of the devices for each status reporting protocol in use. The device is designed so that it is easily adapted to support future certificate status reporting protocols.

Performing a transaction in which the submitter is a first TCU and the submission is to transfer the administration of one or more electronic scripts to a second TCU may include: the owner of the transaction instructs the first TCU to transfer the administration of one or more electronic original documents to the second TCU. The owner of the transaction instructs the second TCU to transfer the administration of one or more electronic original documents, and the owner provides the first TCU with a list identifying which electrons would otherwise be transferred to the second TCU. The first TCU establishes communication with the second TCU and identifies its intent for the second TCU to act upon. The first TCU or owner may transmit a manifest to the second TCU so that it can determine when the supervisory transfer has completed. The first TCU transfers each identified electronic script to a second TCU that uses the CSS to ensure that the digital signature of the first TCU on each transferred electronic script is valid and that the electronic script is unchanged. If any of the digital signatures of the first TCU is invalid, the second TCU notifies the first TCU and seeks remediation (e.g., requiring the first TCU to re-sign with the current certificate of authenticity). If the first TCU is unable to fulfill, the second TCU records the event and notifies the transaction owner that the requested administrative transfer has failed; otherwise, the second TCU creates a new envelope for each successfully transferred information object, adding a date-time stamp and its signature block. The second TCU informs the first TCU of each successful transfer and, when completed, the first TCU may mark or retain the copies at the owner's discretion, either in such a way that they cannot be translated into originals, the intent being to destroy all transferred copies of the information object that exist. This process is repeated until all of the identified electronic scripts have been transferred. As such, the second TCU becomes the supervisor of the transferred records, which are authorized copies. The second TCU may add a reliable date and time, digitally sign the manifest, envelope, and store so that it becomes an independent element of the regulatory thread.

In performing the transaction, the owner's instructions may also state that an ownership transfer is occurring, and the ownership transfer document may be placed in either the first TCU or the second TCU. The responsible TCU confirms the authenticity of the ownership transfer document by verifying all digital signatures, certificate validity and checking the certificate status using CSS. The TCU then adds a reliable date and time and digitally signs, envelopes and stores these current electronic raw information objects added to the manifest. In the case where these electrons were all placed in the first TCU, the transfer of ownership is conducted prior to the transfer of administration, and the launch manifest becomes part of the ownership thread.

Some records of transfers may be simple electronic information objects and not just electronic scripts. The CSS may use any suitable certificate status protocol to communicate with the system or TCU.

The present invention may be embodied in many different forms without departing from the essential characteristics thereof, and the embodiments described above should therefore be considered in all respects as illustrative and not restrictive. It is emphasized that the term "comprises/comprising" as used in this specification and the appended claims is intended to specify the presence of stated features but does not preclude the presence or addition of one or more other features. The intended scope of the invention is set forth by the following claims, rather than the foregoing description, and all variations that fall within the scope of the claims are intended to be embraced therein.

Claims (28)

1. A method of providing a certificate status service CSS for checking validity of certificates issued by respective issuing certification authorities CA, comprising the steps of:

receiving one or more status queries regarding the issued certificate from the requesting entity;

extracting a certificate validity period from the issued certificate in a test phase, and checking whether a current date and time is within the validity period;

if the current date and time is within the validity period, checking for certificates in a test phase to see if a current certificate status exists in a certificate status cache;

if the current certificate status is found in the CSS certificate status cache and the age data element of the certificate status is not exceeded, then returning the status of those certificates;

retrieving an issued CA field from the certificate in the testing phase, the CA field being required to retrieve the status of each certificate from the respective issued CA, if the certificate status of any of the certificates in the testing phase is not present in the CSS certificate status cache or the certificate status present in the CSS certificate status cache exceeds the lifetime data element;

detecting to see if the retrieved issued CA is listed on the approved CA list and returning an invalid certificate status for those certificates whose CA is not listed on the approved CA list if the CA is not listed on the approved CA list;

configuring the connector for communication with the issuing CA in accordance with the identified information;

communicating with an issuing CA to request a certificate status according to the configured connector;

retrieving the status of all queried certificates;

processing certificate status according to an appropriate certificate status reporting method including certificate revocation list CRL retrieved at specified issuance intervals, Delta certificate revocation list DeltaCRL retrieved upon notification, LDAP, OCSP, and any other certificate status method that uses real-time protocol query and retrieval;

recording the retrieved certificate status in a cache memory of the CSS;

reporting the retrieved certificate status to the requesting entity;

wherein issuing CAs and connector address information are specified in a configuration store on a list of approved CAs, and connectors for each certificate status reporting method used by an issuing CA specified on the list of approved CAs are added to the configuration store to interpret certificate status to enable interoperability between CSS and CAs or CA domains using different certificate criteria and policies.

2. The method of claim 1, wherein a certificate is deemed to have expired if the local date and time falls outside of a validity period indicated in the certificate.

3. The method of claim 1, wherein the issuing CA and the connector information of the CA are added to a list of at least one organization of approved CAs by checking and approving the issuing CA according to predetermined business rules, and if an issuing CA is checked and not approved, the issuing CA is added to a list of organizations of unapproved CAs in a configuration repository.

4. The method of claim 3, wherein reviewing and approving an issuing CA comprises: a representation of the CA's trust certificate is registered with the CSS and at least a representation of the CA's certificate of authenticity, a status type and a lifetime data element are added to a configuration repository.

5. The method of claim 4, further comprising the steps of: after said step of returning the credential state found in the credential state cache, clearing the credential state from the credential state cache if the usage counter data element value exceeds a threshold; wherein if the status is not found in the local cache or the age data element is exceeded, the CSS establishes a communication session with a certificate status reporting component of the issuing CA, composes a certificate status request using one of the CRL or real-time reporting methods from the configured connector, retrieves the certificate status from the certificate status reporting component, closes the communication session with the certificate status reporting component, and adds at least one of an identification of the certificate, the certificate status, a usage counter, and the age data element to the local cache.

6. The method of claim 1, wherein the certificate status reporting method is indicated as a CRL according to a publication schedule of the issuing CA, the CSS retrieves the CRL from a certificate status reporting component listed in a configuration store, the CSS flushes a cache associated with the issuing CA, and the CSS analyzes the CRL and stores the status in the cache associated with the issuing CA.

7. The method of claim 1, wherein the certificate status reporting method is indicated as DeltaCRL; when the DeltaCRL is notified by the issuing CA that it is available, the CSS retrieves the DeltaCRL from a certificate status reporting component listed in a configuration store; and if the DeltaCRL is a complete CRL, then the CSS clears the cache associated with the issuing CA, extracts all certificate status from the CRL, and stores the status in the cache; and if the DeltaCRL contains a change that occurs after publication of the entire CRL, then the CSS extracts all certificate states from the DeltaCRL and stores the states in a cache.

8. The method of claim 1, wherein the communicating step comprises communicating with multiple CAs and PKI according to a plurality of connectors.

9. The method of claim 1, wherein the connector allows multiple certificate status checks in a single communication step.

10. The method of claim 1, wherein if any CSS is specified in all CSS repositories primarily responsible for querying an issuing CA, the CSS can query another CSS for certificate status.

11. The method of claim 1, wherein the requesting entity is a trusted supervisory utility trusted knowledge base; the steps of receiving one or more certificate status queries from the trusted repository and reporting the retrieved certificate status to the trusted repository are done by performing a single certificate status reporting method between the CSS and the trusted repository.

12. The method of claim 1, for providing a certificate status report of a certificate issued by an approved CA, further comprising:

reporting a valid credential status when the status type is a CRL, the CRL is current, and the status is not found in the cache;

reporting a status when the status is found in the cache and the age element is not exceeded;

clearing the state from cache if the age element is exceeded;

after reporting the status, clearing the status from the cache if the status usage counter data element value exceeds a threshold;

when the credential status or the out-of-life element is not found in the cache and the status type is not a CRL, requesting connection information from its configuration store and establishing a communication session with the credential status reporting component indicated in the configuration store to retrieve the status;

when the status type is a CRL, retrieving and analyzing a new CRL at the next indicated publication time;

adding the identification, status and age of the certificate to the cache; and

the retrieved status is reported to the requesting entity.

13. The method of claim 12, wherein the state usage counter data element is added to a cache; incrementing or decrementing the state usage counter data element each time the state of a certificate is checked; and if the state usage counter data element exceeds the threshold, reporting the credential state and clearing the cache for the credential state.

14. The method of claim 13, wherein a data element that records when each cached credential state was last accessed is added to the cache and the data element that records when a credential state was last accessed in combination with a state usage counter data element enables the CSS to determine the activity level of a credential state.

15. The method of claim 14, wherein when a request is made to the CSS to retrieve the state of a new certificate and the cache has reached the allocated memory size limit, for each certificate state entry whose current time exceeds the age limit, each usage counter data element value exceeds the threshold and a certificate state entry having an oldest value for recording when each cached certificate state was last accessed data element, the CSS searches and flushes the cache, wherein the CSS then retrieves the requested certificate state, places the certificate state in the cache, and reports the requested certificate state to the requesting entity.

16. A method of performing a transaction between a first party and a second party by transferring control of an authenticated information object having a verifiable credential thread, comprising the steps of:

retrieving a verified information object from a trusted repository, wherein the verified information object comprises a first digital signature block having a digital signature of a first party and a first certificate relating at least an identity and an encryption key to the first party, a date and time indicator, and a second digital signature block comprising a second digital signature of the trusted repository and a second certificate relating at least an identity and an encryption key to the trusted repository;

confirming, by the trusted repository, the first digital signature block; and storing the verified information object as an electronic original information object under control of the trusted knowledge base;

executing the retrieved verified information object by the second party by including a third digital signature block in the retrieved verified information object, the third digital signature block including at least a third digital signature and a third certificate of the second party; and

forwarding the executed retrieved verified information object to a trusted repository, wherein the trusted repository verifies the digital signature and validates the certificate associated with the digital signature contained in the information object by retrieving the information object of the state of the certificate at least from a certificate status service CSS provided according to the method of claim 1; the trusted repository rejecting the digital signature block if the corresponding digital signature is not verified or the state of the corresponding certificate expires or is revoked; and

if at least one signature block in the information object is not rejected, the trusted knowledge base adds the digital signature block of the trusted knowledge base and a date and time indicator to the information object and controls the object on behalf of the first party.

17. A method as claimed in claim 16, wherein each of said signature blocks comprises at least one hash of at least a part of the information object containing the signature block, said at least one hash being encrypted with the encryption key of the respective signatory of said block, thereby forming a digital signature of the signatory, and the digital signature of the signatory is included in the signature block with the certificate of the signatory.

18. The method of claim 17, wherein the performing step comprises displaying a local date and time to the second party, confirming by the second party that the displayed local date and time is correct, and if either is incorrect, correcting the local date and time.

19. The method of claim 16, wherein if the trusted repository rejects the digital signature block, the trusted repository requests remediation that requires re-computation of the digital signature and re-forwarding of the signature block.

20. The method of claim 16, wherein the trusted repository checks the accuracy of local dates and times and checks whether they are within the validity period indicated by the certificate of the second party.

21. The method of claim 20, wherein if the local date and time is not within the validity period indicated by the certificate of the second party, the trusted repository notifies the second party that the certificate is rejected and notifies the first party that the transaction is not complete.

22. The method of claim 16, wherein one or more digitized handwritten signatures are contained in an information object, and the location of the digitized handwritten signature in the information object is specified by at least one signature marker.

23. The method of claim 16, wherein the location of one or more signature blocks in the information object is specified by at least one signature marker.

24. The method of claim 23, wherein one or more signature blocks are independently forwarded to a trusted knowledge base with corresponding signature tags, and the trusted knowledge base validates the signature blocks by:

rejecting the signature block if the corresponding digital signature is not verified or the corresponding certificate is not validated, an

If the signature block is not rejected the signature block is placed according to the corresponding signature tag,

wherein for independently transmitted signature blocks the trusted knowledge base adds a date and time indication to each signature block and appends the signature block of the trusted knowledge base in a package containing the information object and the placed signature block according to business rules.

25. The method of claim 24, wherein the trusted repository verifies the digital signature and validates the certificate in the signature block by:

determining whether the first or second party associated with the certificate of authenticity has rights in accordance with the business rules,

verifying the digital signature of the first or second party,

it is checked whether the validity period of the certificate overlaps with the current date and time of the trusted repository,

checking whether the local date and time falls within a tolerance deviation from the current date and time of the trusted repository, an

The status of the certificate is retrieved from the CSS and the digital signature is considered invalid and the transaction is not executed if any of the preceding steps results in an invalid or false export, otherwise the digital signature is considered valid and the transaction is executed.

26. The method of claim 16, wherein the CSS provides the credential status to the trusted supervisory utility TCU at least by the step of checking the status of the local cache and retrieving the status from the local cache if the status is found in the local cache and the local date and time is within the validity period;

if the status is not found in the local cache or if the local date and time is not within the validity period, the CSS establishes a communication session with the certificate status reporting component of the issuing CA, composes a certificate status request from the configured connector, retrieves the status from the certificate status reporting component, closes the communication session with the certificate status reporting component, and adds at least the identification of the certificate, the status, and the age data element to the local cache.

27. The method of claim 16, wherein the first party is a first trusted repository and the transaction is for transfer of a custody of one or more electronic scripts from a second trusted repository to the first trusted repository, the owner of the transaction providing a manifest to the second trusted repository, the manifest identifying electronic scripts to be transferred to the first trusted repository, the second trusted repository establishing communication with the first trusted repository and identifying the purpose of its action, the manifest being communicated to the first trusted repository so that it can determine when the custody transfer has ended, the second trusted repository transferring each identified electronic script to the first trusted repository, the first trusted repository retrieving a status of a certificate of the second trusted repository and digitally signing the second trusted repository on each transferred electronic script, if the digital signature or certificate of any of the second trusted repositories is invalid, the first trusted repository notifies the second trusted repositories and seeks remediation, and if the second trusted repository does not provide remediation, the first trusted repository notifies the transaction owner that the requested supervised transfer has failed, otherwise the second trusted repository creates a new envelope for each successfully transferred information object, adding a date-time stamp and a signature block for the first trusted repository.

28. The method of claim 27, wherein the transaction is an ownership transfer in response to the instruction, placing the ownership transfer document in the first or second trusted repositories, the trusted repositories with ownership transfer documents confirming authenticity of the ownership transfer document by verifying all digital signatures, certificate validity periods and checking certificate status of all certificates contained in the ownership transfer document using CSS, adding a date and time indication, and digitally signing, wrapping and storing the ownership transfer document added to the manifest.