System, apparatus, and method for performing cryptographic validity services6973571Abstract Embodiments of the present invention described and shown in the specification and drawings facilitate electronic authentication services for banking and other industries. Authentication services, often using Public Key Infrastructure (PKI) technology, are used to confirm the identity of the sender of data and to ensure that the data that was received is identical to the data that was sent. Embodiments of the present invention provide authentication services that may be used by a variety of configurations of entities requesting data authentication and entities responding to those requests. Embodiments of the present invention also support compatibility with commercial data authentication standards, integration with third-party data authentication software such as Secude (for Identrus access), and systems to control data authentication risks. Claims 1. A system for performing cryptographic validity services comprising: Description BACKGROUND OF THE INVENTION
b. The SERVICE NAME of the Relying Participant (for example, BANKOFAMERICA AUTHENTICATION SERVICES) providing the validation. c. The SERVICE VERSION of the Relying Participant Service Engine, comprising an identification of the version of software implementing the Relying Participant Service Engine. d. The SIGNATURE VALIDITY determination, having the values VALID and INVALID, as provided by the present invention and indicating whether the Electronic Signature is valid for the Signed Data in the associated Verification Request. e. SIGNATURE DATA MATCH indicating whether the Electronic Signature actually matched the Signed Data. f. The SIGNING CERTIFICATE STATUS of the Digital Certificate used to create the Electronic Signature, for example, VALID, EXPIRED, REVOKED, etc. g. The ISSUING AUTHORITY CERTIFICATE STATUS of the Digital Certificate of the Authority which issued the Signing Digital Certificate. h. The SIGNING CERTIFICATE CONTENTS, providing the information contained in the signing Certificate allegedly used to sign the Signed Data which, in some embodiments, comprises:
9. Query. One or more requests (which may be referred to as Certificate Status Requests) to a Digital Certificate verification facility to verify each of the certificates that was contained in the Certificate Chain of a Validation Request (see the Validation Request definition, above). In an embodiment of the present invention, third-party Secude Software in combination with Identrus Issuing Participant services (Identrus Services are controlled by Identrus LLC, 140 East 45th Street, 16th Floor, New York, N.Y. 10017) form the Digital Certificate verification facility. Other Digital Certificate verification facilities, for example, VeriSign, Inc., 1600 Bridge Parkway, Redwood Shores, Calif. 94065, may be used as is known in the art. 10. Query Response. The response or responses to one or more Certificate Status Requests from a Digital Certificate verification facility. 11. Relying Customer Interface. In some embodiments of the present invention, a Relying Customer Interface is the portion of the present invention that communicates with a Relying Customer. For example, in some embodiments as depicted in FIG. 6, the present invention comprises Validation Services Platform 401. Communications between the Relying Customer, partially depicted in FIG. 6 by Relying Customer Software Application 501, and Validation Services Platform 401, comprise Control and Configure Service 601, Validation Request 520, and Validation Response 504. These communications enter and exit Validation Services Platform 401 through a Relying Customer Interface, which, in some embodiments, comprises System API 603 and Information API 604. As is known in the art, the Relying Customer Interface may be implemented in hardware, in software, or as a combination of hardware and software. 12. Relying Participant Interface. In some embodiments of the present invention, a Relying Participant Interface is the portion of the present invention that communicates with a Relying Participant or with a Relying Participant/Issuing Participant combination. For example, in some embodiments depicted in FIG. 6, the present invention comprises Validation Services Platform 401. Communications between Validation Services Platform 401 and the Relying Participant/Issuing Participant combination, partially depicted in FIG. 6 by Secude Software 505, Identrus Server 506, Issuing Participant Indentrus Servers 508, and Identrus Root Server 509, are represented by the arrow between Relying Participant Service Engine 403 and Secude Software 505. These communications enter and exit Validation Services Platform 401 through a Relying Participant Interface. As is known in the art, the Relying Participant Interface may be implemented in hardware, in software, or as a combination of hardware and software. 13. System API. In some embodiments of the present invention, a System Application Programming Interface (API) provides a predefined set of functions for initializing and terminating the operation of the Relying Customer Service Engine of the present invention, and for recording status information for financial audits, billing, and maintenance. As is known in the art, an API is said to be "exposed" when entities external to the entity containing the API are able to make use of the API. For example, in some embodiments depicted in FIG. 6, System API 603 is contained in the Relying Customer Service Engine 402 portion of Validation Services Platform 401. Validation Services Platform 401 exposes System API 603 to Relying Customer Software Application 501. Relying Customer Software Application 501 uses, as is known in the art, System API 603 to control and configure Relying Customer Service Engine 402 via the Control and Configure Service 601 path. 14. Information API. In some embodiments of the present invention, the Information API provides a predefined set of functions for sending a Validation Request to systems or apparatus of the invention and for obtaining a Validation Response from systems or apparatus of the invention. For example, in some embodiments depicted in FIG. 6, Information API 604 is contained in the Relying Customer Service Engine 402 portion of Validation Services Platform 401. Valdation Services Platform 401 exposes Information API 604 to Relying Customer Software Application 501. Relying Customer Software Application 501 uses, as is known in the art, Information API 604 to transmit Validation Request 520 to Validation Services Platform 401, and to receive Validation Response 504 from Validation Services Platform 401. 15. Policy Engine. In some embodiments of the present invention, the Policy Engine determines if the Electronic Signature contained in a Validation Request is valid or invalid, based, for example, on examination of the Electronic Signature, a Query Response related to the Electronic Signature, and business policies provided by the Relying Participant. For example, in some embodiments depicted in FIG. 10, Policy Engine 610 is contained in Relying Participant Service Engine 403. Business policies related to the acceptance of Electronic Signatures are provided to Policy Engine 610 as dataset Policy Data 611. Policy Engine 610 converts, as is known in the art, Policy Data 611 to Policy tables 1005 which are internal to Policy Engine 610. In some embodiments, this conversion occurs when Policy Engine 610 is initialized as part of the initialization of systems, apparatuses or methods of the present invention. In other embodiments, business policies of the Relying Participant are separately converted into Policy Tables 1005, for example by a computer programmer, and are built into Policy Engine 610. In some embodiments, Relying Participant Service Engine 403 provides Policy Engine 610 with the results of an examination of the Electronic Signature and with the Query Response related to the Electronic Signature for use, in conjunction with the business policies, in authenticating the Electronic Signature. 16. Validation Services Platform. In some embodiments of the present invention, the Validation Services Platform performs authentication on the Electronic Signature contained in a Validation Request by receiving the Validation Request from a Relying Customer Interface, formulating a Query responsive to the Validation Request, transmitting the Query to a Relying Participant Interface, receiving a Query Response from the Relying Participant Interface, formulating a Validation Response responsive to the Query Response, and transmitting the Validation Response to the Relying Customer Interface. The Relying Customer Interface may be in communication with a Relying Customer and the Relying Participant Interface may be in communication with a Relying Participant. For example, in embodiments of the present invention depicted in FIG. 4, Validation Services Platform 401 comprises a Relying Customer Interface that is in communication with Relying Customer 102, and comprises a Relying Participant Interface that is in communication with Relying Participant 103. The Validation Services Platform may be implemented, as is known in the art, as software running on general purpose computers or special purpose computers, as hardware, or as combinations of software and hardware. 17. Relying Participant Service Engine. In some embodiments of the present invention, the Relying Participant Service Engine performs authentication on the Electronic Signature contained in a Validation Request by receiving the Validation Request, formulating a Query responsive to the Validation Request, transmitting the Query to a Relying Participant Interface, receiving a Query Response from the Relying Participant Interface, formulating a Validation Response responsive to the Query Response, and transmitting the Validation Response. In some embodiments, the Relying Participant Service Engine performs as a server, as is known in the art, with one or more clients (for example, Relying Customer Service Engines) sending Validation Requests to the Relying Participant Service Engine. In some further embodiments of the present invention, the Validation Response is responsive to a Policy Engine. For example, in some embodiments depicted in FIG. 6, Relying Participant Service Engine 403 receives Validation Request 520 from Relying Customer Service Engine 402 via an Internet-based communication channel, Internet 507. Relying Participant Service Engine 403 formulates a Query, and transmits the Query to the Relying Participant Interface that is in communication with Secude Software 505. Secude Software 505 sends a Query Response to the Relying Participant Interface. Relying Participant Service Engine 403 receives the Query Response from the Relying Participant Interface, formulates Validation Response 504 based on the Query Response and the operation of Policy Engine 610, and transmits Validation Response 504 to Relying Customer Service Engine 402 via Internet 507. The Relying Participant Service Engine may be implemented, as is known in the art, as software running on general purpose computers or special purpose computers, as hardware, or as combinations of software and hardware. 18. Relying Customer Service Engine. In some embodiments of the present invention, the Relying Customer Service Engine coordinates communications between the Relying Customer and the Relying Participant Service Engine. In these embodiments, the Relying Customer Service Engine has a Relying Customer Interface which is in communication with a Relying Customer, and receives a Validation Request from the Relying Customer Interface and transmits the Validation Response to the Relying Customer Interface. The Relying Customer Interface may include a System API and may include an Information API. In further embodiments, a communication channel is established between the Relying Customer Service Engine and the Relying Participant Service Engine to transport the Validation Request and the Validation Response. In some embodiments, one or more Relying Customer Service Engines are clients, as is known in the art, of a single Relying Participant Service Engine that is a server. In some embodiments, the Relying Customer Service Engine performs consistency checking on the Validation Request. Consistency checking determines, for a particular Validation Request, if the Electronic Signature actually signed the Signed Data. In some embodiments, if the Electronic Signature was found not to have signed the Signed Data, then the Relying Customer Service Engine would send, to the Relying Customer Interface, a Validation Response noting that the Electronic Signature was not valid and would not invoke the Relying Participant Service Engine. If the Electronic Signature was found to have signed the Signed Data, then the Validation Request would be sent to the Relying Participant Service Engine for validation of the Validation Request's Digital Certificates. For example, in some embodiments depicted in FIG. 6, the Relying Customer Interface of Relying Customer Service Engine 402 comprises System API 603 and Information API 604. The Relying Customer Interface is in communication with Relying Customer Software Application 501. A Validation Request 520 is sent to Information API 604 by Relying Customer Software Application 501. Validation Request 502 is received by Relying Customer Service Engine 402 from Information API 604. Relying Customer Service Engine 402 and Relying Participant Service Engine 403 previously established an Internet based communication channel, Internet 507, between Relying Customer Service Engine 402 and Relying Participant Service Engine 403. Relying Customer Service Engine 402 transmits Validation Request 520 to Relying Participant Service Engine 403 via Internet 507, and receives Validation Response 504 from Relying Participant Service Engine 403 via Internet 507. Relying Customer Service Engine transmits Validation Response 504 to Relying Customer Software Application 501 via Information API 604. The Relying Customer Service Engine may be implemented, as is known in the art, as software running on general purpose computers or special purpose computers, as hardware, or as combinations of software and hardware. DETAILED DESCRIPTION Acts performed by systems, methods, apparatus elements, and apparatus functions of the present invention may be implemented, as is known in the art, as software running on general purpose computers or special purpose computers, as hardware, or as combinations of software and hardware. As depicted in FIG. 4, Validation Services Platform 401 is an embodiment of the present invention. In this figure, Validation Services Platform 401 is in communication with Relying Customer 102 and Relying Participant 103. Relying Participant 103 may be in communication with Issuing Participant 104 or may be a Relying Participant/Issuing Participant combination. As depicted in FIG. 4, Relying Customer 102 and Relying Participant 103 may be located in close physical proximity to portions of Validation Services Platform 401, while Validation Services Platform 401 may comprise components that are distributed over a wide geographical area and communicate via communication networks such as the Internet. In some embodiments, a portion of Relying Customer 102 is a computer program running on a computer system that also runs a portion of Validation Services Platform 401. Typically, Subscribing Customer 101 creates an Electronic-Signature by signing certain data. Subscribing Customer 101 submits the Electronic Signature and the data to Relying Customer 102 as part of a commercial transaction. Relying Customer 102 generates a Validation Request from the Electronic Signature and data, as is known in the art, and transmits the Validation Request to Validation Services Platform 401. In some embodiments depicted in FIG. 4, Validation Services Platform 401 has a Relying Customer Interface in communication with Relying Customer 102 and has a Relying Participant Interface in communication with Relying Participant 103. Relying Customer 102 transmits the Validation Request to the Relying Customer Interface and Validation Services Platform 401 receives the Validation Request from the Relying Customer Interface. Validation Services Platform 401 formulates a Query responsive to the Validation Request and transmits the Query to the Relying Participant Interface. Relying Participant 103 receives and processes the Query, as is known in the art, and transmits a Query Response to the Relying Participant Interface. Validation Services Platform 401 receives the Query Response from the Relying Participant Interface, formulates a Validation Response responsive to the Query Response, and transmits the Validation Response to the Relying Customer Interface. Relying Customer 102 receives the Validation Response from the Relying Customer Interface. Responsive to the Validation Response, as is known in the art, Relying Customer 102 informs Subscribing Customer 101 as to the acceptance or rejection, for example, of the commercial transaction depending upon whether the Electronic Signature contained in the Validation Response was valid. In some embodiments depicted in FIG. 4, Validation Services Platform 401 comprises Relying Customer Service Engine 402 in communication with Relying Participant Service Engine 403. In some embodiments, Relying Customer Service Engine 402 is in close physical proximity to Relying Participant Service Engine 403. For example, Relying Customer Service Engine 402 and Relying Participant Service Engine 403 may be software modules running on the same computer system and communicating with each other as is known in the art. In other embodiments, Relying Customer Service Engine 402 and Relying Participant Service Engine 403 are physically distant. For example, Relying Customer Service Engine 402 and Relying Participant Service Engine 403 may be software modules running on different computer systems that are located in different cities, and communicating via computer communications networks such as the Internet as is known in the art. In some embodiments, Relying Customer Service Engine 402 contains the Relying Customer Interface and Relying Participant Service Engine 403 contains the Relying Participant Interface. In some embodiments, multiple Relying Customer Service Engines 402 communicate with a single Relying Participant Service Engine 403. FIG. 5 is a more detailed depiction of some of the entities that may communicate with the Validation Services Platform 401 embodiment of the present invention that was depicted in FIG. 4. In some embodiments depicted in FIG. 5, Relying Customer Software Application 501, a portion of the Relying Customer, communicates with Validation Services Platform 401 via the Relying Customer Interface portion of Validation Services Platform 401. Relying Customer Software Application 501 transmits Validation Request 520, which is comprised of Electronic Signature 502 and Signed Data 503, to the Relying Customer Interface, and receives Validation Response 504. In some embodiments depicted in FIG. 5, a Relying Participant/Issuing Participant combination comprises Secude Software 505, Identrus Server 506, Issuing Participant-Identrus Server 508, and Identrus Root Server 509. As depicted in FIG. 5, Identrus Server 506, Issuing Participant-Identrus Server 508, and Identrus Root Server 509 communicate via Internet 507. Secude Software 505 and the Identrus servers operate together, as is known in the art, to form a Digital Certificate verification facility. As is also known in the art, other Digital Certificate verification facilities could be substituted for the Secude Software/Identrus combination depicted in FIG. 5. In other embodiments, Validation Services Platform 401 could communicate with a plurality of Digital Certificate verification facilities of the same or of different types. In some embodiments depicted in FIG. 5, Validation Services Platform 401 communicates with Secude Software 505 via the Relying Participant Interface portion of Validation Services Platform 401. Secude Software 505 receives a Query from the Relying Participant Interface, processes the Query in conjunction with the Identrus servers as is known in the art, formulates a Query Response, and transmits the Query Response to the Relying Participant Interface. FIG. 6 is a more detailed diagram depicting the Validation Services Platform 401 embodiment that was depicted in FIGS. 4 and 5. In some embodiments depicted in FIG. 6, Validation Services Platform 401 comprises Relying Customer Service Engine 402 and Relying Participant Service Engine 403, as described in connection with FIG. 4. In some embodiments depicted in FIG. 6, Relying Customer Service Engine 402 comprises the Relying Customer Interface of Validation Services Platform 401. In some embodiments, the Relying Customer Interface comprises System API 603 and Information API 604. In some embodiments, Validation Services Platform 401 exposes System API 603 to Relying Customer Software Application 501. Relying Customer Software Application 501 uses, as is known in the art, System API 603 to control and configure Validation Services Platform 401 via the Control and Configure Service 601 path. In some embodiments, Validation Services Platform 401 exposes Information API 604 to Relying Customer Software Application 501. Relying Customer Software Application 501 uses, as is know in the art, Information API 604 to transmit Validation Request 520 to Validation Services Platform 401, and to receive Validation Response 504 from Validation Services Platform 401. In some embodiments depicted in FIG. 6, Relying Participant Service Engine 403 comprises the Relying Participant Interface of Validation Services Platform 401. In some embodiments depicted in FIG. 6, Relying Participant Service Engine 403 includes Policy Engine 610. As depicted in FIG. 6, some embodiments of Relying Participant Service Engine 403 include datasets such as Configuration Data 613, for storing data relating to the configuration of Relying Participant Service Engine 403; Log Files 612, for storing data relating to the operation of Relying Participant Service Engine 403; and Policy Data 611, for storing data relating to the configuration of Policy Engine 610. FIG. 7 is a diagram depicting the System API and Logging interface of some embodiments of the Relying Customer Service Engine of the present invention. In some embodiments depicted in FIG. 7, Relying Customer Software Application 501 transmits configuration data, depicted as Config Data 705, via System API 603 to Relying Customer Service Engine 402 for use in configuring Relying Customer Service Engine 402. In some embodiments depicted in FIG. 7, Config Data 705 specifies the information that is to be logged, as is known in the art, and where the logged information is to be sent. In these embodiments, the logged information, referred to as Logging Data 715, is transferred to logging programs, referred to as Log Routines 710, that are contained in Relying Customer Software Application 501. In some embodiments depicted in FIG. 7, Logging Data 715 is stored by Log Routines 710 externally from Relying Customer Service Engine 402. FIG. 8 is a diagram depicting the Information API of some embodiments of the Relying Customer Service Engine of the present invention. In some embodiments depicted in FIG. 8, Relying Customer Software Application 501 transmits Validation Request 520, comprising Electronic Signature 502 and Signed Data 503, via Information API 604, for processing by Relying Customer Service Engine 402. In some embodiments depicted in FIG. 8, Relying Customer Service Engine 402 transmits Validation Response 504 to Relying Customer Software Application 501 via Information API 604. FIG. 9 is a detailed diagram depicting some embodiments of the Relying Customer Service Engine of the present invention. As will be readily apparent to workers in the art, many other embodiments of the Relying Customer Service Engine may be employed and are within the scope of this invention. In some embodiments depicted in FIG. 9, at the start of operation of Relying Customer Service Engine 402, Relying Customer Software Application 501 provides Config Data 705 to Initialization Function 910 of Relying Customer Service Engine 402 via System API 603. Initialization Function 910 initializes Relying Customer Service Engine 402 using the Configuration Data provided by Config Data 705. As part of the initialization activity, Logging Function 915 is placed in communication with Logging Routines 710, Secure Communication Function 925 establishes a secure communication channel with Relying Participant Service Engine 403, and Secure Communication Function 925 obtains Authorization Key 920 from Relying Participant Service Engine 403. Following initialization, data which is to be logged, denoted by Logging Data 715, is collected by Logging Function 915 and transferred to Logging Routines 710 for storage. When Validation Request 520 is received by Information API 604, it is sent to Signature Validation Procedure 905. In some embodiments, Signature Validation Procedure 905 performs consistency checking on Validation Request 520 and, if the consistency check determines that Electronic Signature 502 was not properly used to sign Signed Data 503, then Signature Validation Procedure 905 will send Validation Response 504 via Information API 604 to Relying Customer Software Application 501 without further processing. If the consistency check determines that Electronic Signature 502 was properly used to sign Signed Data 503, or in those embodiments where no consistency checking is done by Relying Customer Service Engine 402, then Signature Validation Procedure 905 provides Validation Request 520 to Secure Communication Function 925 for transmission to Relying Participant Service Engine 403 via Internet 507. In some embodiments where consistency checking is performed by Relying Customer Service Engine 402, Signed Data 503 is not included in Validation Request 520 when Validation Request 520 is transmitted to Relying Participant Service Engine 403. In some embodiments, Secure Communication Function 925 transmits Authorization Key 920 with Validation Request 520 to Relying Participant Service Engine 403 to demonstrate that Validation Request 520 was provided by an authorized source without, for example, requiring a new exchange of Digital Certificates between Relying Customer Service Engine 402 and Relying Participant Service Engine 403 as is known in the art. After Relying Participant Service Engine 403 processes Validation Request 520 and produces Validation Response 504, Validation Response 504 is transmitted by Relying Participant Service Engine 403 to Secure Communication Function 925 via Internet 507. Secure Communication Function 925 receives Validation Response 504 and provides it to Signature Validation Procedure 905. Signature Validation Procedure 905 then transmits Validation Response 504 to Relying Customer Software Application 501 via Information API 604. A detailed example of some embodiments of Relying Customer Service Engine 402 as depicted in FIG. 9 is provided as follows: System API 603 System API 603 performs the following activities, as are known to workers in the art:
Information API 604 performs the following activities, as are known to workers in the art:
Initialization Function 910 performs the following activities, as are known to workers in the art:
Secure Communication Function 925 performs the following activities, as are known to workers in the art (In some embodiments, Relying Customer Service Engine 402 will be able to communicate with Relying Participant Service Engine 403 using an existing secure communication channel, and alternative communication protocols may be used, as is known in the art. For example, if Relying Customer Service Engine 402 and Relying Participant Service Engine 403 are software modules running on the same computer system, then secure facilities provided by the computer system may be employed for communication between the software modules and some of the following activities would be simplified as is known in the art):
Logging Function 915 Logging Function 915 performs the following activities, as are known to workers in the art: Signature Validation Procedure 905 Signature Validation Procedure 905 performs the following activities, as are known to workers in the art:
FIG. 10 is a diagram depicting a Policy Engine of some embodiments of the Relying Participant Service Engine of the present invention. In some embodiments depicted in FIG. 10, Relying Participant Service Engine 403 comprises Policy Engine 610. In some embodiments of the present invention which are not depicted in FIG. 10, a Policy Engine is located in other portions of the invention where the Validation Response can be made responsive to the Policy Engine. Regardless of location, in some embodiments, the Policy Engine participates in the formulation of Validation Responses by making final determinations as to whether Electronic Signatures are valid. In some embodiments, the Policy Engine's determinations are based on policies provided by a Relying Participant. These policies may also require the Policy Engine to add other information to the Validation Response. For example, in some embodiments, the Policy Engine includes receipt numbers, and billing and administrative information, in Validation Responses. In some embodiments, as depicted in FIG. 10, policy information is provided to Policy Engine 610 by the Relying Participant in the form of a policy data file, depicted as Policy Data 611. Policy Engine 610 converts Policy Data 611 to an internal format depicted as Policy Tables 1005. Policy Engine 610 then uses Policy Tables 1005 in processing Validation Responses. In some embodiments not depicted in FIG. 10, policy decision rules are built into the Policy Engine, and Policy Data and the corresponding Policy Tables are not used. For example, in some embodiments of Policy Engine 610 depicted in FIG. 10, Policy Engine 610 performs the following activities, as are known to workers in the art:
FIG. 11 is a detailed diagram depicting some embodiments of the Relying Participant Service Engine of the present invention. As will be readily apparent to workers in the art, many other embodiments of the Relying Participant Service Engine may be employed and are within the scope of this invention. In some embodiments depicted in FIG. 11, Relying Participant Service Engine 403 is initialized for service by Initialization Function 1125. Initialization Function 1125 obtains Configuration Data for Relying Participant Service Engine 403 from a dataset depicted as Configuration Data 613, and makes the Configuration Data available to Secure Communication Function 1105, Signature Validation Procedure 1110, and Logging Function 1115. In some embodiments, Configuration Data 613 is built into Relying Participant Service Engine 403. In alternative embodiments, Configuration Data 613 is provided by an entity external to Relying Participant Service Engine 403 as is known in the art. For example, the Relying Participant may provide Configuration Data 613. In some embodiments, as part of the initialization activity, Signature Validation Procedure 1110 establishes a secure communication channel with a Digital Certificate verification facility. In some embodiments, and for example, as depicted in FIG. 11, the Digital Certificate verification facility comprises Secude Software 505, Identrus Server 506, Issuing Participant-Identrus Server 508, and Identrus Root Server 509. As depicted in FIG. 11, Identrus Server 506, Issuing Participant-Identrus Server 508, and Identrus Root Server 509 communicate via a computer communication network such as the Internet, which is depicted as Internet 507. In some embodiments, data relating to the activities performed by Relying Participant Service Engine 403, denoted by Logging Data 1120, including for example activities that occurred during initialization, are collected by Logging Function 1115 and transferred to Log Files 612 for storage. Following initialization, in some embodiments, a Relying Customer Service Engine, depicted in FIG. 11 as Relying Customer Service Engine 402, establishes a secure communication channel with Secure Communication Function 1105. In some embodiments, the secure communication channel comprises a computer communication network such as the Internet, and is depicted as Internet 507 in FIG. 11. In some embodiments, Secure Communication Function 1105 generates an Authorization Key and sends the Authorization Key to Relying Customer Service Engine 402. When a Validation Request is received by Secure Communication Function 1105 from Relying Customer Service Engine 402, the Validation Request is sent to Signature Validation Procedure 1110. In some embodiments, Signature Validation Procedure 1110 performs consistency checking on the Validation Request, and the Validation Request will include both an Electronic Signature and Signed Data that was allegedly signed by the Electronic Signature. If the consistency check determines that the Electronic Signature was used to properly sign the Signed Data, or if no consistency checking is performed, then Signature Validation Procedure 1110 formulates a Query based on the Digital Certificates contained in the Validation Request. If the consistency check determines that the Electronic Signature was not used to properly sign the Signed Data, then, in some embodiments, Signature Validation Procedure 1110 will send a Validation Response to Relying Customer Service Engine 402 via Secure Communication Function 1105 without further processing of the Validation Request, while, in other embodiments, Signature Validation Procedure 1110 will proceed to formulate a Query based on the Digital Certificates contained in the Validation Request. After Signature Validation Procedure 1110 formulates a Query, Signature Validation Procedure 1110 transmits the Query to a Digital Certificate verification facility for processing. The Digital Certificate verification facility responds by transmitting a Query Response to Signature Validation Procedure 1110. In some embodiments, information in the Query Response related to the status of individual Digital Certificates is cached in Relying Participant Service Engine 403 for use when a Digital Certificate verification facility is temporarily unavailable. When Signature Validation Procedure 1110 receives the Query Response, or, in some embodiments, when Signature Validation Procedure 1110 determines that the Digital Certificate verification facility is unavailable, Signature Validation Procedure 1110 formulates a Validation Response based on the Query Response and the Validation Request. In some embodiments, if a Digital Certificate verification facility was unavailable, the Validation Response is also formulated based on any cached information concern the status of the individual Digital Certificates that were contained in the Validation Request. In some embodiments, the Validation Response is also formulated based on determinations made by a Policy Engine, depicted in FIG. 11 by Policy Engine 610. After Signature Validation Procedure 1110 formulates a Validation Response, Signature Validation Procedure 1110 transmits the Validation Response to Relying Customer Service Engine 402 via Secure Communication Function 1 105 and Internet 507. A detailed example of some embodiments of Relying Participant Service Engine 403 as depicted in FIG. 11 is provided as follows: Initialization Function 1125 Initialization Function 1125 performs the following actions, as are known to workers in the art:
Logging Function 1115 performs the following activities, as are known in the art: Secure Communication Function 1105 Secure Communication Function 1105 performs the following activities, as are known in the art (In some embodiments, as is known in the art, Relying Participant Service Engine 403 may establish secure communications with a plurality of Relying Customer Service Engines, with Relying Participant Service Engine 403 performing as a server and each Relying Customer Service Engine performing as a client. This configuration is commonly referred to in the art as a client/server architecture. In some embodiments, Relying Customer Service Engine 402 will be able to communicate with Relying Participant Service Engine 403 using an existing secure communications channel, and alternative communications protocols may be used, as is known in the art. For example, if Relying Customer Service Engine 402 and Relying Participant Service Engine 403 are software modules running on the same computer system, then secure facilities provided by the computer system may be employed for communication between the software modules and some of the following activities would be simplified as is known in the art):
Signature Validation Procedure 1110 Signature Validation Procedure 1110 performs the following activities, as are known in the art:
FIG. 12 is a flowchart depicting an embodiment of a method for performing cryptographic validity services of the present invention. This method comprises the activities of receiving a Validation Request from a Relying Customer Interface, formulating a Query responsive to the Validation Request, transmitting the Query to a Relying Participant Interface, receiving a Query Response from the Relying Participant Interface, formulating a Validation Response responsive to the Query Response, and transmitting the Validation Response to the Relying Customer Interface. As depicted in FIG. 12, the activity of receiving a Validation Request from a Relying Customer Interface is accomplished by Receive Validation Request from Relying Customer Interface 1205. In some embodiments depicted in FIG. 9 and discussed in reference to Relying Customer Service Engine 402, Receive Validation Request from Relying Customer Interface 1205 is performed by Information API 604, Signature Validation Procedure 905, and Secure Communication Function 925. In other embodiments, Receive Validation Request from Relying Customer Interface 1205 is performed as is known in the art. As depicted in FIG. 12, the activity of formulating a Query responsive to the Validation Request is accomplished by Formulate Query responsive to Validation Request 1210. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, Formulate Query responsive to Validation Request 1210 is performed by Signature Validation Procedure 1110. In other embodiments, Formulate Query responsive to Validation Request 1210 is performed as is known in the art. As depicted in FIG. 12, the activity of transmitting the Query to a Relying Participant Interface is accomplished by Transmit Query to Relying Participant Interface 1215. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, Transmit Query to Relying Participant Interface 1215 is performed by Signature Validation Procedure 1110. In other embodiments, Transmit Query to Relying Participant Interface 1215 is performed as is known in the art. As depicted in FIG. 12, the activity of receiving a Query Response from the Relying Participant Interface is accomplished by Receive Query Response from Relying Participant Interface 1220. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, Receive Query Response from Relying Participant Interface 1220 is performed by Signature Validation Procedure 1110. In other embodiments, Receive Query Response from Relying Participant Interface 1220 is performed as is known in the art. As depicted in FIG. 12, the activity of formulating a Validation Response responsive to the Query Response is accomplished by Formulate Validation Response responsive to Query Response 1225. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, Formulate Validation Response responsive to Query Response 1225 is performed by Signature Validation Procedure 1110 in conjunction with, in some embodiments, Policy Engine 610. In other embodiments, Formulate Validation Response responsive to Query Response 1225 is performed as is known in the art. As depicted in FIG. 12, the activity of transmitting the Validation Response to the Relying Customer Interface is accomplished by Transmit Validation Response to Relying Customer Interface 1230. In some embodiments depicted in FIG. 9 and discussed in reference to Relying Customer Service Engine 402, Transmit Validation Response to Relying Customer Interface 1230 is performed by Information API 604, Signature Validation Procedure 905, and Secure Communication Function 925. In other embodiments, Transmit Validation Response to Relying Customer Interface 1230 is performed as is known in the art. FIG. 13 is a flowchart depicting an embodiment of a method for performing cryptographic validity services of the present invention. This method comprises the activities of receiving a Validation Request from a Communication Channel, formulating a Query responsive to the Validation Request, transmitting the Query to a Relying Participant Interface, receiving a Query Response from the Relying Participant Interface, formulating a Validation Response responsive to the Query Response, and transmitting the Validation Response to the Communication Channel. As depicted in FIG. 13, the activity of receiving a Validation Request from a Communication Channel is accomplished by Receive Validation Request from Communication Channel 1305. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, Receive Validation Request from Communication Channel 1305 is performed by Secure Communication Function 1105. In other embodiments, Receive Validation Request from Communication Channel 1305 is performed as is known in the art. As depicted in FIG. 13, the activity of formulating a Query responsive to the Validation Request is accomplished by Formulate Query responsive to Validation Request 1310. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, Formulate Query responsive to Validation Request 1310 is performed by Signature Validation Procedure 1110. In other embodiments, Formulate Query responsive to Validation Request 1310 is performed as is known in the art. As depicted in FIG. 13, the activity of transmitting the Query to a Relying Participant Interface is accomplished by Transmit Query to Relying Participant Interface 1315. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, Transmit Query to Relying Participant Interface 1315 is performed by Signature Validation Procedure 1110. In other embodiments, Transmit Query to Relying Participant Interface 1315 is performed as is known in the art. As depicted in FIG. 13, the activity of receiving a Query Response from the Relying Participant Interface is accomplished by Receive Query Response from Relying Participant Interface 1320. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, Receive Query Response from Relying Participant Interface 1320 is performed by Signature Validation Procedure 1110. In other embodiments, Receive Query Response from Relying Participant Interface 1320 is performed as is known in the art. As depicted in FIG. 13, the activity of formulating a Validation Response responsive to the Query Response is accomplished by Formulate Validation Response responsive to Query Response 1325. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, Formulate Validation Response responsive to Query Response 1325 is performed by Signature Validation Procedure 1110 in conjunction with, in some embodiments, Policy Engine 610. In other embodiments, Formulate Validation Response responsive to Query Response 1325 is performed as is known in the art. As depicted in FIG. 13, the activity of transmitting the Validation Response to the Communication Channel is accomplished by Transmit Validation Response to Communication Channel 1330. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, Transmit Validation Response to Communication Channel 1330 is performed by Secure Communication Function 1105. In other embodiments, Transmit Validation Response to Communication Channel 1330 is performed as is known in the art. In some embodiments, the activity of receiving a Validation Request from a Relying Customer Interface is accomplished by a Validation Request Receiver element. In some embodiments depicted in FIG. 9 and discussed in reference to Relying Customer Service Engine 402, the Validation Request Receiver element for receiving a Validation Request from a Relying Customer Interface comprises Information API 604, Signature Validation Procedure 905, and Secure Communication Function 925. In other embodiments, the Validation Request Receiver element for receiving a Validation Request from a Relying Customer Interface is implemented as is known in the art. In some embodiments, the Validation Request Receiver element for receiving a Validation Request from a Relying Customer Interface comprises a Consistency Checker element. In some embodiments depicted in FIG. 9 and discussed in reference to Relying Customer Service Engine 402, the Consistency Checker element comprises Signature Validation Procedure 905. In other embodiments, the Consistency Checker element is implemented as is known in the art. In some embodiments, the activity of receiving a Validation Request from a Communication Channel is accomplished by a Validation Request Receiver element. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, the Validation Request Receiver element for receiving a Validation Request from a Communication Channel comprises Secure Communication Function 1105. In other embodiments, the Validation Request Receiver element for receiving a Validation Request from a Communication Channel is implemented as is known in the art. In some embodiments, the activity of formulating a Query responsive to the Validation Request is accomplished by a Query Formulator element. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, the Query Formulator element comprises Signature Validation Procedure 1110. In other embodiments, the Query Formulator element is implemented as is known in the art. In some embodiments, the Query Formulator comprises a Consistency Checker element. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, the Consistency Checker element comprises Signature Validation Procedure 1110. In other embodiments, the Consistency Checker element is implemented as is known in the art. In some embodiments, the activity of transmitting the Query to a Relying Participant Interface is accomplished by a Query Transmitter element. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, the Query Transmitter element comprises Signature Validation Procedure 1110. In other embodiments, the Query Transmitter element is implemented as is known in the art. In some embodiments, the activity of receiving a Query Response from the Relying Participant Interface is accomplished by a Query Response Receiver element. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, the Query Response Receiver element comprises Signature Validation Procedure 1110. In other embodiments, the Query Response Receiver element is implemented as is known in the art. In some embodiments, the activity of formulating a Validation Response responsive to the Query Response is accomplished by a Validation Response Formulator. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, the Validation Response Formulator element comprises Signature Validation Procedure 1110 in conjunction with, in some embodiments, Policy Engine 610. In other embodiments, the Validation Response Formulator element is implemented as is known in the art. In some embodiments, the activity of transmitting the Validation Response to the Relying Customer Interface is accomplished by a Validation Response Transmitter element. In some embodiments depicted in FIG. 9 and discussed in reference to Relying Customer Service Engine 402, the Validation Response Transmitter element for transmitting the Validation Response to the Relying Customer Interface comprises Information API 604, Signature Validation Procedure 905, and Secure Communication Function 925. In other embodiments, the Validation Response Transmitter element for transmitting the Validation Response to the Relying Customer Interface is implemented as is known in the art. In some embodiments, the activity of transmitting the Validation Response to the Communication Channel is accomplished by a Validation Response Transmitter. In some embodiments depicted in FIG. 11 and discussed in reference to Relying Participant Service Engine 403, the Validation Response Transmitter element for transmitting the Validation Response to the Communication Channel comprises Secure Communication Function 1105. In other embodiments, the Validation Response Transmitter element for transmitting the Validation Response to the Communication Channel is implemented as is known in the art. As described previously in this specification, the present invention may be implemented in hardware, in software running on general or special purpose computers, or as a combination of hardware and software. Software implementations may employ a wide variety of programming languages, such as Java, COBOL, C, C++, and other procedural languages as is known in the art. For example, an embodiment of Application Programming Interfaces of the present invention for the Java programming language is provided as follows: The Java API Specification 1. Information API In this example and some embodiments of the present invention, the Information API defines the flow of information between a Relying Customer Software Application and systems, apparatuses or methods of the present invention. The Information API supports the PKCS7 signature validation functionality, as is known in the art. The PKCS7 signature validation functionality indicates to the Relying Customer Service Application that Identrus PKCS7 did or did not sign particular data, and that the PKCS7 contains or does not contain a valid Identrus signature, certificate status, and certificate chain status. The Information API also provides the Relying Customer Service Application with information about the contents of the PKCS7, as well as additional optional information. This service is provided by a single Java Class with the following specification: public class IdentrusValidation extends Object Constructor: public IdentrusValidation( ) throws IdentrusValidationException The constructor requires no arguments. Method to Check PKCS7 Status: public java.util.Properties checkStatus(String Base64PKCS7, byte[ ] signedData) throws IdentrusValidationException This method is used to check the status of an Identrus PKCS7 signature and its associated data. The input arguments are: The output is a single util.Properties object which contains the following KEY-VALUE pairs: Values returned for SIGNATURE VALIDITY Values returned for CERTIFICATE STATUS Values returned for SIGNATURE-DATA STATUS Class IdentrusValidationException Object | Exception | +- - - - IdentrusValidationException public class IdentrusValidationException extends Exception Constructor: public IdentrusValidationException(String exceptionDiagnosticinformation) { } 2. Policy API In this example and some embodiments of the present invention, the Policy API defines the flow of information between a Policy Engine and the Relying Participant Service Engine portion of the present invention. The general outline is a class:
The method 'policy' is provided a Java Properties object containing all of the known information about the Digital Signature, Digital Certificates and Signed Data. The value for SIGNATURE—IS—VALID must be returned in the Properties object. Any additional values placed into the Properties object will also be returned to the Relying Customer Software Application that invoked the Information API. 3. System API In this example and some embodiments of the present invention, the System API defines the flow of configuration and control information between a Relying Customer Software Application and the present invention. Class IdentrusValidation Object +- - - - IdentrusValidation public class IdentrusValidation extends Object Constructor: public IdentrusValidation(Properties configPropertiesFile) throws IdentrusValidationException The constructor takes a single argument, the Configuration Properties File that, in some embodiments, is supplied by the Relying Participant. This Java Properties file contains configuration specific values such as the Domain Name Server ("DNS") location of the Relying Participant's validation service, etc. public class IdentrusValidation extends Object Constructor: public IdentrusValidation(Properties configPropertiesFile) throws IdentrusValidationException The constructor takes a single argument, the Configuration Properties File that, in some embodiments, is supplied by the Relying Participant. This Java Properties file contains configuration specific values such as the DNS location of the Relying Participant's validation service, etc. System Initialization: public void init(String ConfigurationPropertiesFilename) throws IdentrusValidationException The init( ) method takes a single argument, the Configuration Properties File that, in some embodiments, is supplied by the Relying Participant. This Java Properties file contains configuration specific values such as the DNS location of the Relying Participant's validation service, etc. Register Policy Engine: public String registerPolicyEngine(IdentrusValidationPolicy policyObject)) throws IdentrusValidationException The registerPolicyEngine( ) method takes a single argument, the IdentrusValidationPolicy class that, in some embodiments, is supplied by the Relying Participant. This object conforms to the IdentrusValidationPolicy Interface defined in the Policy API's. After this invocation, the specified object will be invoked for each invocation of the Application API checkStatus( ). Register Log Record Handler: public String registerLogHandler(IdentrusLogRecordHandler LogRecordObject)) throws IdentrusValidationException The registerLogHandler( ) method takes a single argument, the IdentrusLogRecordHandler class that, in some embodiments, is supplied by either the Relying Participant or the Relying Customer, or both. This object conforms to the IdentrusLogRecordHandler Interface defined in the System API's. After this invocation, the specified object will be invoked each time an IRCF Logging Record is available so it may be recorded or transmitted by the LogRecordObject. Any number of objects may be IdentrusLogRecordHandler registered. Each registered IdentrusLogRecordHandler will be invoked for each log record. Interface IdentrusLogRecordHandler {
It should be understood that the preceding is merely a detailed description of some examples and embodiments of this invention and that numerous changes to the disclosed embodiments can be made in accordance with the disclosure herein without departing from the spirit or scope of the invention. The preceding description, therefore, is not meant to limit the scope of the invention.
|
Same subclass Same class | ||||||||||