US20020029200A1 - System and method for providing certificate validation and other services - Google Patents

System and method for providing certificate validation and other services Download PDF

Info

Publication number
US20020029200A1
US20020029200A1 US09/950,440 US95044001A US2002029200A1 US 20020029200 A1 US20020029200 A1 US 20020029200A1 US 95044001 A US95044001 A US 95044001A US 2002029200 A1 US2002029200 A1 US 2002029200A1
Authority
US
United States
Prior art keywords
certificate
transaction
participant
transaction coordinator
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US09/950,440
Inventor
Charles Dulin
David Solo
Mack Hicks
Larry Nepomuceno
Mark Stirland
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Barclays Bank PLC
Bank of America Corp
Identrust Inc
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US09/950,440 priority Critical patent/US20020029200A1/en
Application filed by Individual filed Critical Individual
Publication of US20020029200A1 publication Critical patent/US20020029200A1/en
Assigned to IDENTRUS LLC reassignment IDENTRUS LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: VASANTHAKUMAR, NAVIN
Assigned to ZIONS BANCORPORATION reassignment ZIONS BANCORPORATION SECUIRTY AGREEMENT Assignors: IDENTRUS, LLC
Assigned to BANK OF AMERICA reassignment BANK OF AMERICA ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: NEPOMUCENO, LARRY
Assigned to BARCLAYS BANK PLC reassignment BARCLAYS BANK PLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: STIRLAND, MARK
Assigned to IDENTRUS, LLC reassignment IDENTRUS, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BARCLAYS BANK PLC
Assigned to IDENTRUS, LLC reassignment IDENTRUS, LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: IDENTRUS, LLC
Assigned to IDENTRUS, INC. (SUCCESSOR-IN-INTEREST TO INDENTRUS, LLC) reassignment IDENTRUS, INC. (SUCCESSOR-IN-INTEREST TO INDENTRUS, LLC) RELEASE OF SECURITY AGREEMENT Assignors: ZIONS BANCORPORATION
Priority to US11/603,755 priority patent/US8818903B2/en
Assigned to IDENTRUST, INC. reassignment IDENTRUST, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: IDENTRUS, INC.
Priority to US14/467,926 priority patent/US20150278808A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821Electronic credentials
    • G06Q20/38215Use of certificates or encrypted proofs of transaction rights
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829Payment protocols; Details thereof insuring higher security of transaction involving key management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00Business processing using cryptography
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • This invention relates generally to the field of facilitating electronic commerce by providing services via a public key infrastructure.
  • One remedy for this problem is to provide each contracting party with a private key for signing transmitted messages.
  • the signing party makes available an associated public key that decrypts messages signed with the party's private key, and thus enables a receiving party to confirm the identity of the sender.
  • the sender's public key may not be known a priori to the recipient.
  • the sender may transmit with its signed message a digital certificate issued by a certificate authority.
  • the certificate is itself a signed electronic document (signed with the private key of the certificate authority) certifying that a particular public key is the public key of the sender.
  • the recipient may be unfamiliar with the public key of the certificate authority or may not know whether the certificate is still valid. In that event, the recipient may wish to check the authenticity and validity of the certificate with an entity that it trusts.
  • One known protocol for checking certificate status is the on-line certificate status protocol (OCSP).
  • a system and method are disclosed for facilitating electronic commerce by securely providing certificate-related and other services including certificate validation and warranty.
  • these services are provided within the context of a four-corner trust model.
  • the four-corner model comprises a buyer, referred to as the subscribing customer, and a seller, referred to as the relying customer, who engage in an on-line transaction.
  • the buyer is a customer of a first financial institution, referred to as an issuing participant.
  • the issuing participant acts as a certificate authority for the buyer and issues the buyer a hardware token including a private key and a digital certificate signed by the issuing participant.
  • the seller is a customer of a second financial institution, referred to as the relying participant.
  • the relying participant acts as a certificate authority for the seller and issues the buyer a hardware token including a private key and a digital certificate signed by the relying participant.
  • the system also includes a root certificate authority that issues digital certificates to the issuing and relying participants.
  • the buyer creates a hash of the transaction data, signs the hash, and transmits the transaction data, the signature, and its digital certificate to the seller.
  • the seller may then request system services via a connection with its financial institution, the relying participant.
  • these system services may include a certificate status check service and a warranty service.
  • the certificate status check service allows the relying customer to validate the subscribing customer's certificate.
  • the warranty service allows the relying customer to receive a collateral-backed warranty that the subscribing customer's certificate is valid. Detailed message flows for providing these services are provided in the detailed description.
  • each participant and the root entity is provided with a transaction coordinator for combining services and operations into a single transaction having the qualities of atomicity, consistency, isolation, and durability.
  • the transaction coordinator provides a single consistent interface for certificate-status messages and requests, as well as messages and requests relating to other services.
  • the present invention provides the necessary flexibility to permit centralized and consistent capture of transactional information relating to a plurality of offered services for audit and non-repudiation purposes.
  • the present invention facilitates the integration of additional services and provision of those services to customers.
  • the disclosed transaction coordinator provides a single interface to facilitate electronic communications amongst banks or other financial institutions or between banks or other financial institutions and their customers.
  • the transaction coordinator also provides a single entry point for customers to obtain certificate-check services and provides the flexibility to add new business application services, such as warranty service, payment guarantee service, or certified mail service, while still providing a single entry point for these additional services. It is preferably designed to be easily extended to support additional services as they are created.
  • the disclosed transaction coordinator provides parsing, flow control, and error handling for the present messaging infrastructure and acts as a message switch to route message components to an appropriate system service (e.g., to an OCSP responder, warranty engine, etc.). In addition, it collates responses from these services into a consolidated response and dispatches the responses to requesting clients.
  • an appropriate system service e.g., to an OCSP responder, warranty engine, etc.
  • the disclosed transaction coordinator also records billing data for the certificate check service or other services in a centralized general fashion. Because all of the banks and other financial institutions have their own requirements for billing, the billing data can be extracted and modified to an individual financial institution's needs by writing simple extraction functions.
  • the disclosed transaction coordinator also allows banks or other financial institutions to cross-charge each other for different types of transactions as needed. Further, the disclosed transaction coordinator allows for the integration of commercial off-the-shelf software applications and provides a single electronic signing service to electronically sign and verify documents.
  • the disclosed transaction coordinator isolates all core services, thereby promoting reuse of components and simplifying the maintenance and enhancements of these services.
  • the disclosed transaction coordinator does not require changing the on-line certification check functionality that would render it non-standard and might result in vendor locking and implementation delays.
  • FIG. 1 is a block diagram of a preferred embodiment of the four-corner model employed by the present system
  • FIG. 2 is a block diagram depicting components preferably provided at entities in the four-corner model
  • FIG. 3 is a block diagram of a preferred embodiment of a transaction coordinator
  • FIG. 4 is a composite block/flow diagram that demonstrates certain aspects of transaction coordinator operation in a preferred embodiment
  • FIG. 5 is a composite block/flow diagram depicting preferred operation of the signing component of a transaction coordinator
  • FIG. 6 is a composite block/flow diagram demonstrating a preferred embodiment of the steps performed by a transaction coordinator in performing a certificate status check
  • FIG. 7 is a composite block/flow diagram illustrating a preferred embodiment of the transaction flow for validating a certificate
  • FIG. 8 is a composite block/flow diagram illustrating the transaction flow for one preferred embodiment of a warranty service
  • FIG. 9 is a composite block/flow diagram of a preferred embodiment of server-side authentication
  • FIG. 10 is a composite block/flow diagram of a preferred embodiment of client-side authentication
  • FIG. 11 is a composite block/flow diagram illustrating a preferred message authentication process
  • FIG. 12 is a composite block/flow diagram of a preferred embodiment of the security-relevant flows associated with components of a transaction coordinator
  • FIG. 13 is a composite block/flow diagram that depicts the (estimated) sizes of messages that are passed between system entities in a preferred embodiment
  • FIG. 14 is a composite block/flow diagram that depicts the transaction flows for an OCSP-proxy centric embodiment of the present system.
  • the present disclosure relates to a system that allows financial institutions to securely perform electronic certificate status checks and other services for their customers.
  • the disclosed system employs a four-corner trust model to provide these services.
  • a preferred embodiment of the four-corner model employed by the present system is shown in FIG. 1.
  • the four-corner model comprises a first institution 102 and a second institution 104 .
  • First institution 102 is referred to as the “issuing participant” because it is a participant in the present system and issues smart cards to its customers, as described below.
  • Second institution 104 is referred to as the “relying participant” because it is a participant in the present system and its customers rely on representations made by issuing participant 102 and issuing participant 102 's customers, as described below.
  • Participants 102 , 104 are typically banks or other financial institutions.
  • First customer 106 and second customer 108 are preferably customers of issuing participant 102 and relying participant 104 , respectively.
  • First customer 106 is referred to as the “subscribing customer” because it subscribes to services provided by issuing participant 102 .
  • Second customer 108 is referred to as the “relying customer” because it relies on representations made by both issuing participant 102 and subscribing customer 106 .
  • Root entity 110 is typically an organization that establishes and enforces a common set of operating rules for facilitating electronic commerce and electronic communications. Root entity 110 may be owned jointly by a plurality of banks and/or other financial institutions that have agreed to adhere to these operating rules.
  • One exemplary embodiment of such a root entity is described in copending application Ser. No. 09/502,450, filed Feb. 11, 2000, entitled System and Method for Certification-Related and Other Services, which is hereby incorporated by reference.
  • FIG. 2 is a block diagram depicting components preferably provided at entities in the four-corner model.
  • participants 102 , 104 and root entity 110 are each provided with a transaction coordinator 202 that serves as a gateway for transmitting and receiving all inter-entity messages related to services provided by the present system.
  • transaction coordinators 202 provide a single interface to issuing participant 102 's and relying participant 104 's on-line services, and implement safeguards necessary to ensure secure electronic communications between transaction coordinators 202 and other entities in the four-corner model.
  • One preferred embodiment of a transaction coordinator 202 is described below in connection with FIGS. 3 - 6 .
  • Participants 102 , 104 and root entity 110 are each further preferably provided with an OCSP responder 204 and hardware security module (HSM) 206 .
  • HSM hardware security module
  • Exemplary requirements for an OCSP responder 204 are described below.
  • HSM 206 is adapted to sign messages and verify signatures on messages, as described below, in connection with FIG. 6.
  • each participant 102 , 104 and root entity 110 is further preferably provided with a billing data database 208 (connected to a bank billing application 210 in the case of participants 102 , 104 ), a raw transaction log, 212 , a customer data database 214 , a risk manager 216 (connected to customer data database 214 ), and a second hardware security module 218 , each of which is connected to transaction coordinator 202 .
  • a billing data database 208 (connected to a bank billing application 210 in the case of participants 102 , 104 ), a raw transaction log, 212 , a customer data database 214 , a risk manager 216 (connected to customer data database 214 ), and a second hardware security module 218 , each of which is connected to transaction coordinator 202 .
  • relying customer 108 is preferably provided with a Web server 220 that is adapted to receive and transmit information via the Internet.
  • Relying customer 108 is further preferably provided with a bank interface 222 for communicating with relying participant 104 , as described in more detail below.
  • bank interface 222 (as well as additional components preferably provided at the relying customer) is described in copending U.S. patent application Ser. No. 09/657,604, filed Sep. 8, 2000, entitled System and Method for Facilitating Access By Sellers to Certificate-Related and Other Services, which is hereby incorporated by reference.
  • Relying customer 108 is preferably further provided with a hardware security module 230 for signing and verifying system messages.
  • subscribing customer 106 is preferably provided with a Web browser 224 for browsing the Internet and a smart card 226 (and associated reader) for signing digital messages, as described below.
  • each system entity is provided with two digital certificates (and corresponding private keys) to facilitate authentication: An identity certificate (also referred to, in some cases, as a warranty certificate) and a utility certificate.
  • An identity certificate also referred to, in some cases, as a warranty certificate
  • a utility certificate also referred to, in some cases, as a warranty certificate
  • each transaction coordinator 202 is preferably provided with its own identity certificate and utility certificate and associated private keys.
  • the identity private key is used to produce digital signatures that are required by root entity 110 as evidence of an entity's contractual commitment to the contents of an electronic transaction.
  • a certificate chain is needed to support operations using this key.
  • the status of the identity certificate may be obtained by authorized entities, as described below.
  • the utility private key is used to produce digital signatures that allow additional transactional security.
  • utility certificates are used to support secure socket layer sessions, to sign S/MIME messages, and for other utility applications.
  • a certificate chain is also needed to support operations using the utility key. The status of the utility certificate, however, may not be available to a requestor.
  • the term “certificate” refers to an identity certificate unless otherwise stated.
  • subscribing customer 106 's digital certificates and associated private keys are provided to it by issuing participant 102 .
  • Issuing participant 102 preferably issues smart cards or other suitable instruments to subscribing customer 106 that include at least the private key associated with the subscribing customer's identity certificate.
  • the smart card may also include the subscribing customer's identity certificate.
  • Preferred specifications for the smart card, its manufacture, and contents are described in U.S. provisional patent application serial No. 60/224,994, filed Aug. 14, 2000, entitled Signing Interface Requirements, Smart Card Compliance Requirements, Warranty Service Functional Requirements, and Additional Disclosure, which is hereby incorporated by reference.
  • FIG. 3 is a block diagram of a preferred embodiment of a transaction coordinator 202 .
  • transaction coordinator 202 preferably comprises an interface 302 comprising two components: a TC request manager 304 and a transport services component 306 .
  • Interface 302 passes communications to and from a plurality of service modules 308 and core components 310 .
  • Service modules 308 preferably include a certificate status check module 312 , warranty service module 314 , a payment guarantee module 316 , and may comprise other service modules 318 for providing additional services.
  • Core components 310 preferably include a logging component 320 , a billing component 322 , and a signing component 324 .
  • Transport services component 306 provides a single entry point into the transaction coordinator and acts as an isolation layer between a requestor and the transaction coordinator's service modules and core components.
  • Request manager 304 receives service requests from transport services component 306 and forwards them to appropriate service modules and/or core components, as described in more detail below.
  • the function of certificate status check service 312 is to validate the certificates of entities within system 200 of FIG. 2.
  • the function of warranty service 314 is to guarantee the identity of an entity that signs an electronic communication relating to a particular business transaction.
  • the participant providing the warranty typically issuing participant 102 , accepts financial responsibility for some or all of the transaction amount if it is later discovered that subscribing customer 106 did not execute a digital signature created with the subscribing customer's private key.
  • the function of payment guarantee service 316 is to further decrease the risk associated with a transaction by providing relying customer 108 with immediate confirmation of subscribing customer 106 's ability to fulfill a financial obligation.
  • issuing participant 102 may issue a payment guarantee for some or all of the transaction amount if for some reason subscribing customer 106 fails to pay relying customer 108 .
  • Payment services may also be established as described in copending U.S. patent application Serial No. 09/657,622, filed Sep. 8, 2000, entitled System and Method for Providing Payment Services in Electronic Commerce, which is hereby incorporated by reference.
  • certified mail service 318 The function of certified mail service 318 is to support off-line transactions. Off-line transactions occur when the receiving entity, instead of servicing the request immediately, puts the request in a processing queue. Typically, an acknowledgment of receipt is sent to the requestor. This scenario may preferably be implemented when the transaction volumes are so large that it is not feasible to provide on-line responses to every request. Certified mail service 318 may preferably be used to satisfy requests between relying customer 108 and relying participant 104 , relying participant 104 and issuing participant 102 , and any request made to root entity 110 .
  • the function of logging component 320 is to log all service requests and OCSP responses in a raw transaction log 58 (see FIG. 5) for non-repudiation and security auditing purposes.
  • billing component 322 The function of billing component 322 is to create and store a transaction billing history for messages (responses and requests) received by transaction coordinator 202 . Preferred operation of these modules and components is further described below.
  • FIG. 4 is a composite block/flow diagram that demonstrates certain aspects of transaction coordinator operation in a preferred embodiment.
  • transport services component 306 of transaction coordinator 202 receives a service request from another system entity and sends the service request to request manager 304 .
  • request manager 304 checks to see if the service request format is valid. If the service request format is valid, request manager 304 requests information on the requestor, the billing data, and the service request type by calling a message validation module 404 .
  • Message validation module 404 calls a parser component 406 to extract the relevant information from the raw service request.
  • request manager 304 calls an authentication module 408 to authenticate the requestor.
  • Authentication module 408 is described in more detail below.
  • authentication module 408 authenticates the requestor by calling signing component 324 of transaction coordinator 202 which, in turn, calls hardware security module 218 .
  • signing component 324 A preferred structure and operation for signing component 324 is described in more detail below.
  • authentication module 408 calls certificate status check component 414 that in turn calls an OCSP responder 204 to perform a certificate status check on the requestor.
  • certificate status check component 414 A preferred structure and operation for certificate status check component 414 is described in more detail below.
  • authentication module 408 calls a customer authorization check module 418 to verify that the requestor is authorized to place the service request.
  • customer authorization check module 418 A preferred structure and operation for customer authorization check module 418 is described in more detail below.
  • request manager 304 calls logging component 320 to log the raw service request for non-repudiation purposes.
  • messages stored in the raw transaction log are stored in either ASN.1 or XML format.
  • request manager 304 forwards any billing data necessary to appropriately bill for services provided to billing component 322 to for logging in the billing log.
  • step 4018 request manager 304 forwards the service request to a service request router 426 .
  • step 4020 service request router 426 calls an appropriate service module 308 to fulfill the request.
  • a service response is received by service request router 426 from the service module that was called in step 4020 .
  • Service request router 426 forwards the service response back to request manager 304 which, in turn, sends the service response to transport services components 306 .
  • Transport services component 306 forwards the service response to the entity that made the service request.
  • FIG. 5 is a composite block/flow diagram depicting preferred operation of signing component 324 .
  • Signing component 324 preferably provides a single interface to different signing devices, such as smart cards and hardware security modules, and uses cryptographic processing to verify signatures.
  • signing component 324 determines whether it is a request for signature or for verification. If the request is for verification, signing component 324 sends the request to a hardware security module 218 for verification (step 5004 ). In step 5008 , hardware security module 218 responds to this request with a signature verification response to signing component 60 .
  • signing component 324 sends the request (which should include the document to be signed) to hardware security module 218 for signature (step 5006 ).
  • hardware security module 218 responds to this request by signing the document and returns the signed document to signing component 324 .
  • signing component 324 returns the signature-verification response or signed document to the component that made the request.
  • FIG. 6 is a composite block/flow diagram demonstrating a preferred embodiment of the steps performed by a transaction coordinator 202 in performing a certificate status check.
  • certificate check service module 312 receives an unparsed certificate status check request from service router 426 and forwards it to a parser component 406 that extracts the relevant customer information (comprising the certificate to be checked) from the request.
  • certificate check service module 312 obtains any additional service-specific fulfillment information from a customer database 606 .
  • step 6006 if the certificate to be checked belongs to a customer of the participant whose transaction coordinator 202 received the request, certificate check service module 312 hands the request off to a local-customer handler 602 . Otherwise, certificate check service module 312 hands the request off to a non-local-customer handler 610 .
  • step 6008 local customer handler 602 sends a certificate check request to a certificate status check component 312 .
  • Certificate status check component 312 obtains a certificate status for the certificate to be checked from its associated OCSP responder 204 (i.e., the OCSP responder 204 belonging to the same transaction coordinator 202 as certificate status check component 312 ). Flow in these cases then continues with step 6032 below.
  • non-local-customer handler 610 looks up the IP address of the issuing participant that issued the certificate that is the subject of the request in a static DNS table 604 .
  • Transaction coordinator 202 RP is preferably adapted to use the AIA extension in a certificate to identify the location of issuing participant 102 .
  • non-local-customer handler 610 forwards the subject certificate to an OCSP request formulation module 608 .
  • OCSP request formulation module 608 formulates an OCSP request for the certificate and sends the request to signing component 324 for signature.
  • signing component 324 returns the signed request.
  • step 6018 OCSP request formulation module 608 sends the signed request to the issuing participant 102 that issued the subject certificate.
  • that issuing participant 102 returns an OCSP response to the request to OCSP request formulation module 608 .
  • step 6022 OCSP request formulation module 608 forwards the response to non-local-customer handler 610 .
  • non-local-customer handler 610 logs the raw response data to raw transaction log 212 for non-repudiation purposes.
  • non-local-customer handler 610 sends the raw response data to parser component 406 to extract the certificates of issuing participant 102 and its transaction coordinator 202 IP from the response.
  • non-local-customer handler 610 validates the issuing participant's transaction coordinator certificate by repeating steps 6012 - 6024 but transmitting the OCSP request created in step 6014 to root entity 110 rather than issuing participant 102 .
  • non-local-customer handler 610 validates the issuing participant's certificate by repeating steps 6012 - 6024 but transmitting the OCSP request created in step 6014 to root entity 110 rather than issuing participant 102 .
  • step 6032 the certification check response data received by non-local-customer handler 610 or generated by local-customer handler 602 is sent to signing component 324 which signs the response.
  • step 6034 the signed response is sent back to certificate check service module 312 which, in turn, transmits the response to service request router 426 .
  • FIG. 7 is a composite block/flow diagram illustrating a preferred embodiment of transaction flow within system 200 for validating a certificate.
  • subscribing customer 106 creates a hash of data representing a transaction between subscribing customer 106 and relying customer 108 and sends the hash to smart card 226 for signature.
  • smart card 226 signs the data and returns the signed data along with the certificate of subscribing customer 106 and issuing participant 102 .
  • step 7006 subscribing customer 106 sends the signed data and the two certificates to relying customer 108 .
  • relying customer 108 verifies the signature on the data sent by subscribing customer 106 . This verification preferably includes checking the validity period of the received certificates. Alternatively, verification may be provided as a service to relying customer 108 by relying participant 104 . Relying customer 108 then creates an OSCP request containing the subscribing customer's and issuing participant's certificates and transmits the request to hardware security module 230 for signature. In step 7010 , hardware security module 230 returns the signed request.
  • step 7012 relying customer 108 transmits the signed OCSP request to relying participant 104 , along with its own certificate.
  • transaction coordinator 202 RP of relying participant 104 receives the signed OCSP request and checks customer database 214 RP to make sure that the request was signed by an existing relying customer before processing the request. In a preferred embodiment, a relying participant 104 does not process requests received from a customer of a different participant.
  • step 7016 transaction coordinator 202 RP stores the raw transaction data (i.e., the unparsed request, signature, and accompanying relying customer certificate) in raw transaction log 212 RP .
  • any billing data necessary to appropriately bill for services provided is stored in billing log 208 RP . Alternatively, billing data may be extracted from the raw-transaction log by an off-line process to increase system performance.
  • transaction coordinator 202 RP verifies the relying customer's signature on the service request using the relying customer's certificate, the relying participant's certificate, and the root public key.
  • the relying participant's certificate and the root public key may preferably be stored in hardware security module 218 RP .
  • transaction coordinator 202 RP In step 7022 , transaction coordinator 202 RP generates an OCSP request containing the relying customer's certificate, signs it, and sends it to its OSCP responder 204 . Alternatively, if the transaction coordinator and OCSP responder are co-located, a signature on the request may not be necessary.
  • OCSP responder 204 verifies the signature of the request, checks its local repository to determine the validity of its relying customer's certificate, and sends a response back concerning that certificate's status to transaction coordinator 202 RP .
  • relying customers 108 will often need to validate the certificate of a subscribing customer 106 that is a customer of a participant other than relying participant 104 . Because, in that case, relying participant 104 is not the issuing participant that issued the certificate to be validated, it does not have first hand knowledge of that certificate's status.
  • the present system addresses this problem by having each participant that receives an OCSP request for a certificate issued by another participant, forward the request to the issuing participant for that certificate.
  • relying participant 104 determines the subscribing customer's issuing participant. If the subscribing customer is a customer of a different participant, relying participant 104 generates a signed validation request for the subscribing customer's certificate and sends it to the identified issuing participant 102 along with its own certificate.
  • the relying participant may instead provide client-side authentication to issuing participant 102 as, for example, in the OCSP-proxy centric model described below.
  • step 7028 issuing participant 102 checks its customer database 214 IP to make sure that the request was signed by an entity authorized to make the request.
  • step 7030 issuing participant 102 stores the received raw transaction (i.e., the unparsed request, signature, and accompanying certificate) in its raw transaction log 212 IP .
  • step 7032 issuing participant 102 stores relevant billing data for the request in its billing log 208 .
  • billing data may be extracted from the raw-transaction log by an off-line process to increase system performance.
  • step 7034 issuing participant 102 verifies transaction coordinator 202 RP 's signature on the request using the relying participant's transaction coordinator certificate (sent with the request) and the root public key (which may be stored in hardware security module 218 IP ).
  • step 7036 the issuing participant's transaction coordinator 202 IP generates a signed OCSP request for the relying participant's transaction coordinator certificate and sends the request to root entity 110 .
  • transaction coordinator 202 R of root entity 110 receives the request and stores the raw request in its raw transaction log 212 R .
  • transaction coordinator 202 R stores billing data for the request in billing data log 208 R .
  • transaction coordinator 202 R verifies the signature on the request and then sends the request to OCSP responder 204 R .
  • OCSP responder 204 R checks its local repository to determine the status of the subject certificate and sends a response back concerning its status to transaction coordinator 202 R .
  • transaction coordinator 202 R sends a signed response to transaction coordinator 202 IP indicating the status of the relying participant's transaction coordinator certificate.
  • transaction coordinator 202 IP of issuing participant 102 stores the OCSP response from root entity 110 in raw transaction log 212 IP for non-repudiation purposes.
  • transaction coordinator 202 IP generates an OCSP request for the subscribing customer's certificate, signs it, and sends it to its own local OCSP responder 204 IP along with its own certificate.
  • OCSP responder 204 IP if transaction coordinator 202 IP and OCSP responder 204 IP are co-located, a signature on the request may not be necessary. Also, if the two are co-located, the transaction coordinator may simply act as a pass through, as opposed to re-signing requests and responses.
  • step 7052 OCSP responder 204 IP verifies the signature on the request, generates a response, signs it, and returns the signed response to transaction coordinator 202 IP .
  • transaction coordinator 202 IP verifies the OCSP responder's signature, resigns the response, and returns it to transaction coordinator 202 RP along with its own certificate.
  • transaction coordinator 202 RP of relying participant 104 stores the raw response data received from issuing participant 102 in raw transaction log 212 RP for non-repudiation purposes.
  • transaction coordinator 202 RP verifies the signature of transaction coordinator 202 IP on the response using the issuing participant's transaction coordinator certificate (sent with the request) and the root public key (which may be stored in hardware security module 218 RP ).
  • transaction coordinator 202 RP generates a signed OCSP request for the issuing participant's transaction coordinator certificate and sends it to root entity 110 .
  • transaction coordinator 202 R of root entity 110 stores the raw request data in raw transaction log 212 R .
  • transaction coordinator 202 R stores relevant billing data in billing log 208 R .
  • transaction coordinator 202 R verifies the signature on the request and sends the request to OCSP responder 204 R .
  • OCSP responder 204 R checks its local repository to determine the status of the issuing participant's transaction coordinator certificate and sends a response back concerning its status to transaction coordinator 202 R .
  • transaction coordinator 202 R sends a signed response concerning the status of the subject certificate to transaction coordinator 202 RP .
  • step 7072 transaction coordinator 202 RP of relying participant 104 stores the response in raw transaction log 212 RP for non-repudiation purposes. At this point, processing of the subscribing customer's certificate is complete.
  • transaction coordinator 202 RP now processes the second half of the request: the issuing participant's certificate, by generating a signed OCSP request for the issuing participant's certificate and sending it to root entity 110 .
  • step 7076 transaction coordinator 202 R of root entity 110 stores the raw request data in raw transaction log 212 .
  • step 7078 transaction coordinator 202 R stores relevant billing data in billing log 208 .
  • step 7080 transaction coordinator 202 R verifies the signature on the request and sends the request to OCSP responder 204 R .
  • step 7082 OCSP responder 204 R checks its local repository to determine the status of the subject certificate and sends a response back to transaction coordinator 202 R .
  • step 7084 transaction coordinator 202 R sends a signed response to transaction coordinator 202 RP .
  • transaction coordinator 202 RP of relying participant 104 stores the response from root entity 110 in raw transaction log 212 RP for non-repudiation purposes.
  • transaction coordinator 202 RP creates an OCSP response from the responses received from transaction coordinator 202 IP of issuing participant 102 and its local cache, signs it, and sends it to relying customer 108 along with its own certificate.
  • step 7090 relying customer 108 verifies the response using the root's public key certificate stored in hardware security module 230 .
  • step 7092 relying customer 108 sends a request to transaction coordinator 202 RP for the relying participant's transaction coordinator certificate in order to determine if that certificate has been revoked.
  • transaction coordinator 202 RP verifies the signature on the request and sends a request to local OCSP responder 204 RP to ensure that the relying customer's transaction coordinator certificate has not been revoked.
  • step 7096 local OCSP responder 204 RP responds to this request from transaction coordinator 202 RP .
  • transaction coordinator 202 RP sends an OCSP request for the relying participant's transaction coordinator certificate to transaction coordinator 202 R of root entity 110 .
  • transaction coordinator 202 R verifies the signature on the request and checks with local OCSP responder 204 R to determine the status of the relying participant's transaction coordinator certificate.
  • transaction coordinator 202 R forwards the response received from local OCSP responder 204 R to transaction coordinator 202 RP .
  • step 7104 transaction coordinator 202 RP forwards the response received from root entity 110 to relying customer 108 .
  • step 7106 relying customer 108 provides acknowledgment to subscribing customer 106 .
  • relying customers 108 will typically need to obtain the status of relying participant 104 's transaction coordinator certificate.
  • the transaction coordinator and OCSP responder certificates of issuing participant 102 and relying participant 104 are signed by root entity 110 . While root entity 110 operates an OCSP responder, this service is accessible only to participants. Consequently, relying customer 108 cannot request validation of its relying participant's certificates directly from root entity 110 .
  • the present system addresses this problem by having each participant 102 , 104 operate a root responder proxy.
  • This proxy accepts requests from customers on behalf of the root, typically through a different uniform resource locator, forwards the request to the root over an authenticated secure sockets layer channel, and returns the response (still signed by the root) to the requesting party.
  • the four-corner model described above may also be used to provide a warranty service that warranties the identity of a particular entity (e.g., the subscribing customer) that signed a transaction.
  • a warranty service that warranties the identity of a particular entity (e.g., the subscribing customer) that signed a transaction.
  • One embodiment for providing such a warranty service is described below. Additional embodiments for providing warranty services are described in U.S. provisional patent application serial No. 60/224,994, filed Aug. 14, 2000, entitled Signing Interface Requirements, Smart Card Compliance Requirements, Warranty Service Functional Requirements, and Additional Disclosure, which is hereby incorporated by reference.
  • FIG. 8 is a diagram of the transaction flow for one preferred embodiment of a warranty service.
  • subscribing customer 106 creates a hash of date representing a transaction between subscribing customer 106 and relying customer 108 and sends the hash to smart card 226 for signature.
  • smart card 226 signs the data and returns the signature along with the subscribing customer's certificate and the issuing participant's certificate.
  • this message may also include card and signature security data (CSSD) to inject additional security such as protection against duplicate messages.
  • CSSD card and signature security data
  • step 8006 subscribing customer 106 sends the signed data, the signature, the subscribing customer's certificate, and the issuing participant's certificate (and optionally the CSSD) to relying customer 108 .
  • step 8008 relying customer 108 verifies the signature on the data sent by subscribing customer 106 . Alternatively, verification may be provided as a service to relying customer 108 by relying participant 104 . Relying customer 108 then creates a warranty request and transmits the request to hardware security module 230 for signature.
  • step 8010 hardware security module 230 returns the signed request along with a copy of the relying customer's certificate.
  • step 8012 relying customer 108 sends the signed warranty request and relying customer certificate to relying participant 104 .
  • transaction coordinator 202 RP of relying participant 104 checks customer database 214 RP to make sure that the request was signed by an existing customer before processing the request.
  • transaction coordinator 202 RP stores the raw transaction data relating to the transaction (i.e., the “unparsed” request, signature, and accompanying certificate) in raw transaction log 212 RP .
  • transaction coordinator 202 RP stores relevant billing data in billing log 208 RP . Alternatively, billing data may be extracted from the raw transaction log by an off-line process to increase system performance.
  • transaction coordinator 202 RP verifies the relying customer's signature on the request using the relying customer's certificate (sent with the request), the relying participant's certificate, and the root public key (both of which may be stored in hardware security module 218 RP ).
  • Transaction coordinator 202 RP then generates an OCSP request containing the relying customer's certificate, signs it, and sends it to its local OCSP responder 204 RP .
  • a signature on the request may not be necessary.
  • step 8022 OCSP responder 204 RP verifies the signature on the request, check its local repository for the status of the relying customer's certificate, and sends a response concerning that status back to transaction coordinator 202 RP .
  • transaction coordinator 202 RP calls a risk manager 216 RP to determine if relying customer 108 is financially authorized to make the warranty request. If it is, then, in step 8026 , transaction coordinator 202 RP determines the participant responsible for responding to warranty requests concerning subscribing customer 106 (i.e., the participant of which subscribing customer 106 is a customer). In the present example, this entity is issuing participant 102 . Transaction coordinator 202 RP then creates a warranty request for subscribing customer 106 , signs it, and sends it to issuing participant 102 along with its own certificate. It should be noted that if the relying customer and subscribing customer are both customers of the same participant, the warranty request may instead be processed locally by the participant.
  • transaction coordinator 202 IP checks customer database 214 IP to make sure that the request was signed by an entity authorized to make the request.
  • transaction coordinator 202 IP stores the raw transaction data (i.e., the “unparsed” request, signature, and accompanying certificate) in raw transaction log 212 IP .
  • transaction coordinator 202 IP stores relevant billing data for the request in the billing log 208 IP .
  • billing data may be extracted from the raw transaction log by an off-line process to increase system efficiency.
  • transaction coordinator 202 IP verifies transaction coordinator 202 RP 's signature on the request using transaction coordinator 202 RP 's certificate (sent with the request), and the root public key (which may be stored in hardware security module 218 IP ). Transaction coordinator 202 IP then generates a signed OCSP request for the relying participant's transaction coordinator certificate and sends it to root entity 110 .
  • transaction coordinator 202 R of root entity 110 stores the raw request in raw transaction log 212 R .
  • transaction coordinator 202 R stores relevant billing data for the request in billing data log 208 R .
  • transaction coordinator 202 R verifies the signature on the request and then sends the request to OCSP responder 204 R .
  • OCSP responder 204 R checks its local repository to determine the status of relying participant's transaction coordinator certificate and sends a response concerning that status back to transaction coordinator 202 R .
  • Transaction coordinator 202 R then sends a signed response back to transaction coordinator 202 IP .
  • transaction coordinator 202 IP of issuing participant 102 stores the raw response in raw transaction log 212 IP for non-repudiation purposes.
  • transaction coordinator 202 IP then generates an OCSP request from the request it received containing the subscribing customer's certificate, signs it, and sends it to its local OCSP responder 204 IP along with its own certificate.
  • the transaction coordinator and OCSP responder are co-located, as signature on the request may not be necessary. Also, if the two are co-located, the transaction coordinator may simply act as a pass through as opposed to re-signing requests or responses.
  • step 8046 OCSP responder 204 IP verifies the signature on the request, generates a response, signs it, and returns the signed response to transaction coordinator 202 IP .
  • transaction coordinator 202 IP calls risk manager 216 IP to determine whether or not to issue a warranty for subscribing customer 106 .
  • risk manager 216 IP returns a signed message to transaction coordinator 202 IP indicating whether a warranty should be issued.
  • transaction coordinator 202 IP stores the signed response in raw transaction log 212 IP .
  • transaction coordinator 202 IP sends a signed request to transaction coordinator 202 R of root entity 110 to determine if issuing participant 102 has enough collateral to issue the warranty.
  • transaction coordinator 202 R interacts with risk manager 216 R to determine if issuing participant 102 is adequately collateralized and, if so, decreases issuing participant 102 's collateral level by an amount appropriate for the warranty being issued and returns a response to issuing participant 102 .
  • transaction coordinator 202 IP verifies transaction coordinator 202 R 'S signature, creates a warranty response, and returns it to transaction coordinator 202 RP along with its certificate.
  • transaction coordinator 202 RP of relying participant 104 stores the raw response in raw transaction log 212 RP for non-repudiation purposes.
  • transaction coordinator 202 RP verifies transaction coordinator 202 IP 's signature on the response using transaction coordinator 202 IP 's certificate (sent with the response), and the root public key (which may be stored in hardware security module 218 RP ).
  • Transaction coordinator 202 RP then creates a signed OCSP request for the issuing participant's transaction coordinator certificate and sends it to root entity 110 .
  • transaction coordinator 202 R of root entity 110 stores the raw request in raw transaction log 212 R .
  • transaction coordinator 202 R stores relevant billing data in billing log 208 R .
  • transaction coordinator 202 R verifies the signature on the request.
  • Transaction coordinator 202 R then sends the request to its OCSP responder 204 R .
  • OCSP responder 204 R checks its local repository to determine the status of the subject certificate and sends a response back to transaction coordinator 202 R .
  • Transaction coordinator 202 R then sends a signed response to transaction coordinator 202 RP .
  • step 8070 transaction coordinator 202 RP of relying participant 104 stores the raw response data in raw transaction log 212 RP for non-repudiation purposes.
  • transaction coordinator 202 RP checks with transaction coordinator 202 R of root entity 110 to ensure that the issuing participant has sufficient collateral to issue the warranty.
  • transaction coordinator 202 R stores the raw request in raw transaction log 212 R .
  • transaction coordinator 202 R stores relevant billing data in billing log 208 R .
  • transaction coordinator 202 R sends a yes or no response to transaction coordinator 202 RP of relying participant 104 concerning whether issuing participant 102 has sufficient collateral to issue the warranty.
  • transaction coordinator 202 RP stores the raw response data in raw transaction log 212 RP for non-repudiation purposes.
  • transaction coordinator 202 RP creates a warranty response from the responses received from transaction coordinator 202 IP , signs it, and sends it to relying customer 108 along with transaction coordinator 202 RP 's certificate.
  • step 8084 relying customer 108 verifies the response using the root public key stored in hardware security module 230 .
  • step 8086 relying customer 108 sends a request to transaction coordinator 202 RP for transaction coordinator 202 RP 's certificate to see if it has been revoked.
  • step 8088 transaction coordinator 202 RP verifies the signature on the request and sends a request to its local OCSP responder 204 RP to ensure that relying customer 108 's transaction coordinator certificate has not been revoked.
  • step 8090 local OCSP responder 204 RP sends a response to this request to transaction coordinator 202 RP .
  • step 8092 transaction coordinator 202 RP sends an OCSP request for its certificate to transaction coordinator 202 R .
  • transaction coordinator 202 R verifies the signature on the request and checks with its local OCSP responder 204 R to determine the status of transaction coordinator 202 RP 's certificate. Transaction coordinator 202 R then forwards the response received from local OCSP responder 204 R to transaction coordinator 202 RP .
  • step 8096 transaction coordinator 202 RP forwards the response received from transaction coordinator 202 R to relying customer 108 .
  • relying customer 108 sends an acknowledgment to subscribing customer 106 .
  • each transaction coordinator 202 provides atomicity, consistency, isolation, and durability to transactions coordinated by the transaction coordinator.
  • Atomicity means that all actions required to complete a transaction succeed or all fail; the transaction is an indivisible unit of work.
  • Consistency means that after a transaction is executed, the system is left in a correct, stable state, or returns to the state preceding initiation of the transaction.
  • Isolation means that each transaction is unaffected by other transactions that may execute concurrently.
  • Durability means that the effects of each transaction are permanent after the transaction is committed.
  • the combination of atomicity, consistency, isolation, and durability are sometimes referred to as ACID properties.
  • Transaction coordinators 202 preferably provide ACID properties in a distributed computing environment by incorporating a transaction processing monitor or component transaction monitor.
  • Suitable transaction processing monitors may include BEA TUXEDO from BEA Systems, Inc., MSMQ from Microsoft, Top End from NCR Corporation, and Encina from IBM Transarc.
  • Suitable component transaction monitors may include Orbix OTM from Iona Technologies Inc. and BEA WebLogic from BEA Systems, Inc.
  • Any combination of steps to be coordinated by a transaction coordinator may be combined to form a transaction having the ACID properties.
  • one or more pre-defined transactions are provided for each of the process flows depicted in FIGS. 5 - 7 .
  • the steps occurring between the request and response depicted in FIG. 5 may be combined to form a transaction having ACID properties.
  • transaction coordinator components interact with the transaction processing monitor via a transaction processing library.
  • libraries may be written to access transaction-processing-monitor functionality regardless of the particular brand of transaction processing monitor used.
  • Each of the above-listed transaction processing monitors has certain features that relate to its suitability for incorporation in a transaction coordinator of the present system.
  • TUXEDO transaction process monitors are designed to provide: (1) a high-performance message-passing engine (2) distributed transaction management, allowing clients and servers to participate in a distributed transaction and to manage two-phase commit processes transparently to applications (3) an application to transaction manager interface allowing developers to write BEA TUXEDO applications regardless of the hardware hosting program (4) dynamic workload balancing that automatically generates and manages parallel copies of applications and ensures that they are evenly utilized (5) transaction queuing that allows distributed applications to work together in an asynchronous, connectionless fashion and that prioritizes queues based on message context, content, and time of day (6) data dependent routing that enables transactions to be processed where the data can be most efficiently utilized (7) automatic recovery from application failures, transaction failures, network failures, and node failures in which the server manager restarts the failed process and recovers the failed program by rolling back the transaction that was in progress.
  • MSMQ transaction processing monitors from Microsoft are designed to provide: (1) full COM component support (2) access from a range of programming languages (e.g. Visual C++, Visual J++) (3) five APIs (open, close, receive, send, and locate) providing advanced message queuing benefits (4) sliding-window protocols, recoverable storage, dynamic routing to deliver messages, and on-time, in-order message delivery (5) the ability to be included within transactions that contain other activities, such as database updates (6) the ability to commit or abort operations with other resources to preserve data integrity during transactions (7) built-in message encryption, integrity, and signature support and (8) administrators the ability to specify which MSMQ events should create an audit record in the Windows NT Security Log.
  • a range of programming languages e.g. Visual C++, Visual J++
  • five APIs open, close, receive, send, and locate
  • sliding-window protocols recoverable storage
  • dynamic routing to deliver messages and on-time, in-order message delivery
  • the ability to be included within transactions that contain other activities such as database updates
  • MSMQ is typically included as a feature of both MS Windows NT Server, Standard Edition 4.0 and MS Windows NT Server, and Enterprise Edition 4.0. If support for more than twenty-five clients, cost-based routing, or the MSMQ Connector is needed, MSMQ is preferably run on NT Server and Enterprise Edition 4.0. It should be noted that although MSMQ is a high-performance message-passing engine, it does not have necessary features of a transaction process monitor, and therefore may not be suitable for use in the present system.
  • IBM Encina is available from Transarc on many hardware platforms including Sun, IBM, Digital Equipment Corp., Hewlett Packard, and Windows. IBM Encina transaction processing monitors are designed to provide: (1) interoperability to allow the development of distributed transaction processing applications that integrate a wide variety of systems (2) concurrent use of multiple XA-compliant databases or resource managers, such as Oracle, Ingres, Informix, or Sybase through an X/Open XA application programming interface and provide mainframe LU6.2 interoperability, including sync-level 0, 1, and 2 services, without requiring additional software on the mainframe (3) performance and reliability required by transaction processing applications (4) an efficient, fully-distributed two-phase commit mechanism (5) automatic load balancing and replication of application servers to increase performance and to eliminate single points of failure (6) inherited security mechanisms of the underlying DCE thereby allowing both clients and servers to verify the identities and privileges of participants in a transaction (7) additional security mechanisms, including automated authorization checking and facilities to allow the construction of audit trail records (8) enterprise-wide scalability in order to
  • Top End transaction processing monitors are designed to provide: (1) robust middleware (2) distributed transaction management (3) client/server interaction (4) reliable file transfer (5) dynamic workload balancing (6) recoverable transaction queuing (7) application parallelization (8) two-phase commit processing (9) automatic recovery (10) message-sensitive routing (11) multiple database support (Microsoft SQL Server, Oracle, and Sybase) and (12) Internet application scalability and availability.
  • each transaction coordinator in the present system is adapted to provide a plurality of security services including: authentication, authorization, session security, message security, non-repudiation, and auditing.
  • the transaction coordinator uses PKIX authentication based on a PKI defined by root entity 110 .
  • Other authentication mechanisms for services outside the present system may be supported as determined by the entity operating the transaction coordinator.
  • authentication is provided through the use of digital signatures. Authentication may take place at the session level, the message level, or both.
  • the secure socket layer protocol provides session level authentication.
  • the secure sockets layer protocol consists of two phases: server-side authentication and optional client-side authentication.
  • a given transaction coordinator 202 acts as a server when it receives requests from a customer or another transaction coordinator and as a client when it transmits a request to another transaction coordinator.
  • FIG. 9 depicts server-side authentication.
  • a server 90 receives a request from a client 95 (step 9002 ), and sends its utility certificate to the client (step 9004 ).
  • client 95 generates a public key, encrypts it with the server's public key and sends it to server 90 (step 9006 ).
  • server 90 uses its private key to recover the public key sent by client 95 , and authenticates itself to client 95 by returning a message authenticated with the public key received from the client. Subsequent data is encrypted and authenticated with keys derived from the client-generated public key.
  • Secure socket layer server-side authentication allows client 95 to know with whom it is communicating. Server-side authentication is preferably required for all sessions over which network transactions take place. In order to authenticate server 90 , client 95 must possess the public key certificate of the root certificate authority in server 90 's utility certificate chain.
  • FIG. 10 depicts optional client-side authentication.
  • server 90 sends a challenge to client 95 .
  • Client 95 authenticates itself to server 90 by signing the challenge with its private key and returning the signed challenge, with its public key certificate, to the server (step 10004 ).
  • Secure socket layer client-side authentication ensures that client 95 possesses a valid utility certificate and the accompanying private key.
  • secure socket layer client-side authentication is optional but is employed if relying and issuing participants 104 and 102 do not require digitally signed requests from clients 95 .
  • Transaction coordinators 202 IP , 202 RP , and 202 R must possess the public key certificate of the root certificate authority in the client's utility certificate chain in order to determine that client 95 holds a valid root certificate.
  • issuing participant 102 and relying participant 104 authenticate themselves to their customer clients. Issuing participant 102 and relying participant 104 may also require customer clients to authenticate themselves to transaction coordinators 202 IP , 202 RP , and 202 R at the time a session is established. Thus, if client 95 is not an authorized customer of the participant with which it is communicating, the transaction coordinator for that participant may terminate the session before processing a message. Participants may also require customer client-side authentication at the session level in lieu of requiring message level authentication.
  • authentication between transaction coordinators 202 IP , 202 RP , and 202 R may occur either at the session level or at the message level, or both.
  • relying customers are preferably required to provide authentication at the message level by digitally signing all requests sent to transaction coordinator 202 RP .
  • a participant may also require relying customers to provide client-side authentication at the session level.
  • FIG. 11 is a composite block/flow diagram illustrating a preferred message authentication process. As will be described, this process operates to authenticate messages (responses or requests) sent to transaction coordinators 202 by applying a digital signature to data contained in the message.
  • authentication module 408 calls a time source 11 to obtain the current time and verify that none of the certificates comprising the sender's chain have expired. All participants and root entity 110 are preferably provided with synchronized time sources.
  • authentication module 408 calls OCSP responder 204 to check that the certificates in the signer's chain, other than those stored in hardware security module 218 , have not been revoked.
  • Message authentication provides a stronger level of authentication than session authentication.
  • Session authentication uses utility keys. In general, OCSP checks are not performed on utility keys, therefore neither a client nor a server will learn during the authentication process if an SSL certificate has been revoked.
  • utility keys are stored unprotected so that anyone in possession of the token on which the key is stored can masquerade as the authorized user.
  • Warranty keys on the other hand, which are used to provide message authentication, are protected so that merely possessing the token is not sufficient to gain access to the key and masquerade as the authorized user.
  • customer authorization check module 418 checks to make sure the requestor of a service is authorized to receive that service.
  • the requestor's identity may be determined from session level authentication or message level authentication.
  • customer authorization check module 418 performs an authorization check by extracting the user's authenticated identity or distinguished name from its presented utility or warranty certificate, and comparing this against a list of authorized users in customer database 214 .
  • the customer authorization check may be based on a part of the distinguished name, such as any user with a distinguished name subordinate to the financial institution's certificate authority's distinguished name, or it can be based on the entire distinguished name, such that only specific users are authorized.
  • Customer authorization check module 418 may perform authorization checks at multiple levels. For example, it may have the capability to allow or deny services at the user level, or to allow or deny services based on finer criteria, such as the amount of collateral a user has.
  • transaction coordinators 202 provide session security using a secure socket layer (SSL).
  • SSL typically provide three levels of session security: confidentiality, data integrity, and session authentication.
  • all communications to and from transaction coordinators 202 are encrypted using SSL.
  • Digital signatures provide two levels of message security: authentication and data integrity. Digital signatures typically provide authentication through the use of protected private keys, which are used for signing messages.
  • digital signatures preferably provide data integrity through the use of a hash or message digest that is generated during the signature process.
  • Message digests provide a “fingerprint” of the data such that if any bit of the signed data is modified, a different “fingerprint” will result and the recipient of the data will not be able to verify the signature.
  • confidentiality is provided at the session level for all root communications.
  • the transaction coordinator preferably complies with confidentiality rules specified by root entity 110 .
  • each transaction coordinator 202 records all data needed to ensure non-repudiation of a performed service in logs and ensures the integrity of those logs.
  • relying participant 104 preferably provides such non-repudiation for all services it performs for relying customer 108 .
  • transaction coordinator 202 RP not only provides a response to relying customer 108 but also retains all data necessary to ensure that none of the parties involved in performing the service can repudiate having provided the service.
  • digitally signed messages provide the basis for this non-repudiation.
  • transaction coordinators 202 maintain a log of all received messages for non-repudiation purposes.
  • transaction coordinators 202 log messages exactly as received and do not parse, modify, or store messages in any format other than the format in which they were received. Modification of received messages renders the message's digital signature unverifiable and thus makes the message unsuitable for non-repudiation purposes.
  • each received message is time stamped as part of the non-repudiation service.
  • Responses are associated with authorization checks performed at a certain point in time.
  • the time of the authorization check is a signed attribute in the response and is captured in raw transaction log 212 .
  • transaction coordinator 202 also logs information for auditing purposes.
  • Security audit logs may be used to detect potential attacks against the system, such as a suspicious number of requests from non-customers or a suspicious number of invalid signatures.
  • Security audit logs may also assist when a key compromise occurs because a key may be compromised before it is reported and its associated certificate is revoked.
  • the security audit logs may preferably be used to determine if transactions occurred using a compromised key.
  • a transaction coordinator logs every message that it sends or receives and logs the entire message. Messages may be logged in “raw” format. Alternatively, the transaction coordinator may break the message into its constituent parts and store it in a schema such that the entire message can be reconstructed in a manner that preserves the signature. In a preferred embodiment, logs are of such a nature that log entries cannot be falsified (added/deleted/altered) without being detected. In addition, if a transaction coordinator logs a message in raw format, it preferably includes the capability to convert the raw data into a format readable by a COTS solution.
  • This may be a loosely coupled utility or a part of the transaction coordinator functionality that runs as a separate and perhaps lower priority I background process. It may also run on an entirely separate system.
  • the logs may contain other data related to the transport and the session. As an example this may include, sender/recipient IP address, the URL of the post, SMTP header etc.
  • Transport services component 306 (shown in FIG. 3) preferably comprises a secure communications component that establishes a secure socket layer session between transaction coordinator 202 and the entity with which it is communicating.
  • the secure communication component performs session authentication, as described above.
  • the secure communications component provides server-side session authentication and may request client-side session authentication.
  • the secure communications component is responsible for authenticating server 90 .
  • transaction coordinator 202 is also preferably responsible for establishing session security by generating a session key and sending the key, which is encrypted with the server's public key, to the transaction coordinator server with which it wants to communicate. Subsequent communications between the two parties are encrypted with that session key.
  • FIG. 12 is a composite block/flow diagram that depicts a preferred embodiment of the security-relevant flows associated with components of transaction coordinators 202 .
  • a request is received by transport services component 306 .
  • transport services component 306 delivers the request to request manager 304 .
  • request manager 304 ensures that all security-related functions are performed on incoming messages before the messages are processed.
  • step 1206 request manager calls logging component 320 to log the raw request data.
  • Logging component 320 gathers the data required to support non-repudiation and auditing. As noted above, all requests and responses are preferably logged as received.
  • request manager 304 determines if a signature on the request is required. In step 1210 , if request manager 304 determines that the request does not need to be signed, request manager 304 calls customer authorization check module 54 with the client's utility certificate.
  • step 1212 if request manager 304 determines that a signature is required, request manager 304 calls customer authentication module 408 .
  • customer authentication module 408 verifies the signature on the request and validates the certificate chain by calling signing component 324 .
  • signing component 324 provides message security and supports the session and message authentication services. Signing component 324 interfaces with hardware security module 218 , which performs all cryptographic functions. Root 110 preferably specifies the digital signature method that will be used to sign all transactions. Signing component 324 preferably interfaces with hardware security module 218 to perform all cryptographic functions involved in the signature verification process.
  • customer authentication module 408 checks the status of the customer's warranty certificate by sending a request to OCSP responder 204 via certificate status check component 414 , as described above.
  • step 1218 customer authentication module 110 calls customer authorization check module 418 with the customer's warranty certificate.
  • customer authorization check module 418 checks customer database 214 to make sure the request came from a customer authorized to obtain the requested service.
  • step 1222 a response regarding authorization is returned to request manager 304 and processing of system provided services continues as described above.
  • transaction coordinator 202 RP of relying participant 104 receives a request from a relying customer 108 , transaction coordinator 202 RP authenticates the request. Signatures are typically required on all messages sent to transaction coordinator 202 RP by relying customer 108 . In addition, transaction coordinator 202 RP may require relying customer 108 to provide secure socket layer client-side session authentication.
  • transaction coordinator 202 RP provides authentication of all messages it sends to relying customer 108 .
  • transaction coordinator 202 RP provides secure socket layer server-side session authentication when any session is established with relying customer 108 .
  • transaction coordinator 202 RP performs authorization checks to determine if relying customer 108 is an existing customer of relying participant 104 .
  • Transaction coordinator 202 RP may also perform authorization checks to determine if relying customer 108 is authorized to receive the type or level of service being requested.
  • relying customer 108 has an entry in customer database 214 RP that lists the services to which it is entitled.
  • relying customer 108 is identified by a distinguished name as it exists in its warranty certificate and may also be identified by its distinguished name as it exists in its utility certificate if secure socket layer client-side session authentication is employed. This aspect of the transaction coordinator may be integrated with COTS access control/authorization packages.
  • transmissions between relying customer 108 and transaction coordinator 202 RP are encrypted in accordance with specifications specified by root entity 100 and server-side authentication is required.
  • messages exchanged between relying customer 108 and transaction coordinator 202 RP are digitally signed.
  • transaction coordinator 202 RP verifies all signed messages received, validates the certificate chain, and ensures that the certificates within the chain have not been revoked.
  • transaction coordinator 202 RP signs all messages it sends to relying customer 108 .
  • transaction coordinator 202 RP provides a non-repudiation service for relying customer 108 .
  • Transaction coordinator 202 RP typically logs all responses relating to requests for service received from any root component. This includes other components of transaction coordinator 202 RP as well as components of other participants and root 110 .
  • relying participant 104 logs all requests for services from relying customer 108 and all acknowledgments received from relying customer 108 indicating the receipt of a response in order to protect itself from repudiation claims from its customers.
  • transaction coordinator 202 RP logs all requests for services from relying customer 108 for auditing purposes. Accordingly, a system administrator can detect potential attacks against the system and determine if requests for services were received after a key compromise occurred. Auditing of requests may also be used to support any billing disputes that may arise.
  • transaction coordinators 202 IP , 202 RP , and 202 R communicate respectively with OCSP responders 204 IP , 204 RP , and 204 R only, i.e., OCSP responders that are within their financial institution.
  • OCSP responders 204 IP , 204 RP , and 204 R only, i.e., OCSP responders that are within their financial institution.
  • communications must preferably go through the other financial institution's transaction coordinator 202 .
  • OCSP responders 204 IP , 204 RP , and 204 R know the identity of the entity from which they are receiving a request and transaction coordinators 202 IP , 202 RP , and 202 R know the identity of the entity from which they are receiving an OCSP response.
  • co-located transaction coordinators 202 IP , 202 RP , and 202 R and OCSP responders 204 IP , 204 RP , and 204 R know that they are receiving messages from a local process without any explicit authentication. In this case, neither secure socket layer authentication nor signed requests are required.
  • OCSP responders 204 IP , 204 RP , and 204 R may typically sign all responses and transaction coordinators 202 IP , 202 RP , and 202 R may typically accept signed responses in accordance with the Internet PKI OCSP specification.
  • transaction coordinators 202 IP , 202 RP , and 202 R and OCSP responders 204 IP , 204 RP , and 204 R are not co-located and cannot ascertain unambiguously with whom they are communicating, authentication between the components is preferably required. Authentication of requests may be either at the session level or the message level. Authentication of responses is preferably at the message level and may be at the session level, as well.
  • transaction coordinators 202 IP , 202 RP , and 202 R do not typically perform authorization checks on OCSP responders 204 IP , 204 RP , and 204 R since OCSP responders 204 IP , 204 RP , and 204 R do not typically request services from transaction coordinators 202 IP , 202 RP , and 202 R .
  • OCSP responders 204 are preferably co-located with their respective transaction coordinators 202 , transmission security mechanisms do not typically have to be provided for communications between them. Because the two components are contained within a physical environment that is completely under the control of one financial institution, protection can preferably be provided through policy as opposed to implementation of security mechanisms.
  • the transmissions are preferably protected against network attacks that could compromise the confidentiality or the integrity of the transmissions.
  • SSL is used to provide this protection.
  • each OCSP responder 204 is co-located with its respective transaction coordinator 202 and transaction coordinator 202 therefore need not sign OCSP requests. However, OCSP responder 204 may sign responses if required by specifications specified by root entity 110 .
  • OCSP responses are signed, they are preferably logged with the signature of the responder intact, in particular when the response is directly related to the service being provided.
  • transaction coordinator 202 has requested an OCSP response as part of an authentication check on a request for service, the OCSP response is typically not logged for non-repudiation purposes. This is because the OCSP check is performed to determine whether or not to process the incoming request, not as part of processing the request itself. Only information relating to the processing of the request is necessary to retain for non-repudiation purposes.
  • local OCSP responses are typically only logged when relying participant 104 is also issuing participant 102 of the certificate in question and the OCSP request is part of the process for providing a service, e.g., checking the subscribing customer's certificate during a validation request for that certificate.
  • transaction coordinators authenticate all requests from other transaction coordinators. This is typically accomplished either by secure socket layer client-side authentication or by a financial institution configuring its transaction coordinator to require signatures on all requests from other transaction coordinators.
  • a first transaction coordinator that receives a request from a second transaction coordinator performs an authorization check to determine if the requesting transaction coordinator is authorized to make the request.
  • This authorization check is facilitated by providing all authorized transaction coordinators 202 IP , 202 RP , and 202 R with an entry in the customer database of the transaction coordinator from which they desire to obtain service. If transaction coordinator 202 from whom services are being requested requires a signature, the requestor may preferably be identified by its distinguished name as it exists in its warranty certificate. If not, identification from its utility certificate should preferably be permitted only if secure socket layer client-side authentication is required.
  • transmissions between relying customer 108 and transaction coordinator 202 RP are encrypted and server-side session authentication is required.
  • a participant may require that all requests sent to its transaction coordinator from other transaction coordinators be signed. In lieu of this, a participant may require secure socket layer client-side session authentication.
  • transaction coordinators 202 IP , 202 RP , and 202 R sign all responses being sent to other transaction coordinators.
  • transaction coordinators 202 IP , 202 RP , and 202 R provide a non-repudiation service. To this end, transaction coordinators 202 IP , 202 RP , and 202 R log all responses relating to a request for service received from other transaction coordinators.
  • all requests for services received by transaction coordinators 202 IP , 202 RP , and 202 R will be logged for auditing purposes. This enables a system administrator to detect potential attacks against the system and also enables the system administrator to determine if requests for services were received after a key compromise occurred. Auditing of requests may also be used to support any billing disputes that may arise.
  • Components of a transaction coordinator are preferably implemented as customized software code although other software products may be used as described herein.
  • a participant may write and implement its own additional service modules.
  • participants may implement their own business specific rules for the certificate status check service described above and other services that may be offered via the four-corner model.
  • a customer software development kit is used as a tool-set to facilitate the interface between transaction coordinator 202 and customers or other transaction coordinators.
  • the software development kit is preferably integrated with transport services component 306 .
  • the software development kit is preferably adapted to intercept all hyper-text transfer protocol requests destined for an application's original web server at a web site maintained by relying customer 108 .
  • the software development kit preferably determines whether the message needs to be signed based on a defined set of rules.
  • the customer software development kit also authenticates signatures and public key certificates with the help of hardware security module 230 .
  • a preferred embodiment of one such SDK is described in copending U.S. patent application Ser. No. 09/657,604, filed Sep. 8, 2000, entitled System and Method for Facilitating Access By Sellers to Certificate-Related and Other Services, which is hereby incorporated by reference.
  • a MicrosoftTM SQL server may preferably be used as the database for storing billing data.
  • transaction coordinator 202 is adapted to interact with the server via a database library.
  • interaction with the server may be done using JAVATM Database Connectivity if the transaction coordinator development is done in JAVATM.
  • database libraries may be written for other servers thereby permitting the replacement of a Microsoft SQL server by another database without impacting transaction coordinator 202 .
  • Microsoft's MS SQL Server provides the following features and functionality: (1) Online Analytical Processing (OLAP) Services to efficiently analyze complex information essential to reporting, data analysis, decision support, and data modeling (2) on-disk storage architecture (3) a Multiphase Query Optimizer (4) auto statistics to enable the query optimizer to use the latest information and to increase query efficiency (5) active backup to provide high performance online backup with minimal impact on operational systems (6) merge replication to allow users to work independently, then combine their work later (7) built-in priority-based conflict resolution to resolve merge conflicts (8) ability to publish data on the Web (9) a data transformation service to simplify the process of importing and transforming data from multiple, heterogeneous sources (10) ability to check physical and logical database consistency (11) dynamic row-level locking (17) a query optimizer that manages statistics gathering and guaranteeing an efficient plan (13) an intra-query parallel execution of a single query across multiple processors to improve performance; steps in a single query are executed in parallel thereby delivering an optimum response time (14) a redesigned query processor to better
  • each and every incoming and outgoing message generated by a transaction coordinator is stored in successive records in a database.
  • Such messages include: all requests received, all requests made, all responses generated, and all responses received. This ensures availability of all the necessary data to generate invoices on a per transaction basis.
  • transaction coordinator 202 records billing data in a centralized general fashion. Participants may obtain records by writing their own routines to extract the billing data relevant to the participant from the centralized billing data. In addition to providing data in the database, data may also be provided in EXCELTM spreadsheets.
  • TymeServe Network Time Server (“TYMSYNC”)TM by Datum Inc. is used as the transaction coordinator's time stamping component.
  • TYMSYNC is a time synchronization package that acquires time from the Global Positioning System Navstar satellite constellation with absolute accuracy to the nearest microsecond relative to the Universal Time Coordinator as maintained by the United States Naval Observatory.
  • This product may be adapted to synchronize workstations in TCP/IP (transmission control protocol over internet protocol) and LAN (local area network) networks.
  • time is distributed within the network using the Network Time Protocol.
  • TYMSYNC may be configured to continuously synchronize a computer system's clock to the Universal Time Coordinator. The times when requests and responses are generated and when messages are received and sent are preferably stored for non-repudiation and auditing purposes.
  • all communications with transaction coordinator 202 are conducted over secure connections.
  • the secure socket layer encryption scheme for synchronous communications is used.
  • Secure socket layers are used in a fashion compatible with commercial/web server implementations and provide security and privacy over electronic networks such as the Internet. Secure socket layers are application independent, thereby allowing protocols to be layered transparently on top of them.
  • Secure socket layers provide confidentiality, data integrity, and authentication for all network communications. Secure socket layers typically ensure confidentiality by encrypting all data being passed between the communicating entities. When a secure socket layer-enabled client 95 and server 90 first communicate, they agree on a protocol version and select encryption algorithms. Preferably, network endorsed encryption algorithms and key lengths are specified by root entity 110 .
  • Secure socket layers also typically ensure data integrity through the use of encryption. If a message does not decrypt correctly, the recipient can tell that someone has tampered with the message.
  • Secure sockets layers also support server and client authentication, negotiate encryption keys, and authenticate the server before data is exchanged by the higher-level application. Authentication is preferably provided through the use of digital signatures and public key certificates, which are exchanged at the time an electronic communication session is first established.
  • each transaction coordinator is capable of accepting and sending messages over the public Internet using SMTP to send S/MIME messages and communicating via the HTTP protocol over an SSLv3 connection (HTTPS).
  • HTTPS HTTPS
  • each transaction coordinator is preferably adapted to support the following two modes of communication:
  • HTTPS Secure Sockets Layer
  • SSLv3 Secure Sockets Layer
  • HTTPS is a hypertext transfer protocol that incorporates secure sockets layer between Web servers and Web browsers in order to transfer Web pages securely. Use of HTTP keep alive is recommended.
  • each transaction coordinator acts as an HTTPS server during communications with the relying customer and as an HTTPS client when it makes a request to a transaction coordinator at another financial institution.
  • all SSL communication for credential status checking may employ only server authentication.
  • each transaction coordinator may accept messages delivered via other transport protocols (e.g., IIOP) approved by root entity 110 .
  • participants may implement other transport protocols locally by arrangement. In the absence of prior agreement, however, only HTTPS support should be assumed.
  • Valicert'sTM OCSP responder is used for certificate status check service 312 .
  • access to OCSP responder 204 may be achieved using libraries.
  • new OCSP responder vendors may be implemented.
  • OCSP responder 204 determines certificate status without using a certificate revocation list.
  • OCSP responder 204 may move most of the processing involved to a certificate authority, a component that issues, verifies, and revokes certificates, and eliminate the need to download potentially large certificate revocation lists.
  • these functionalities may be divided among different components which may be provided with separate signing keys.
  • the function of issuing certificates may be separated from the revocation function, and components for performing these functions may be provided with separate signing keys.
  • a hardware security module is used as a signing component.
  • the hardware security module is preferably a high-speed device for signing and verifying signatures.
  • the hardware security module is typically a networked hardware device that provides cryptographic services to authenticated entities.
  • a suitable hardware security module is manufactured by NCipher.
  • transaction coordinator 202 is always available to process requests during its normal operating times, which may be twenty-four hours a day seven days a week. To make sure the system meets availability requirements, a detailed requirement analysis of system-availability should be conducted. Because different participants may have different requirements, many different types of failures may occur. As is known, many different hardware and software vendors offer different options for high-availability systems. However, these options may or may not be available for the hardware and software that is chosen by a given financial institution.
  • the power supply to the server may fail.
  • a multiple redundant hot-swap power supply automatically swaps to a redundant power supply.
  • the transaction coordinator preferably provides for high availability clustering for automatic fail over.
  • the transaction coordinator preferably comprises a self re-start capability for automatically rebooting the server in the event of a network operating system (NOS) hang.
  • NOS network operating system
  • the transaction coordinator also preferably comprises multiple redundant hot-swap disk drives and a disk array controller to handle disk failure or crashes.
  • the transaction coordinator also comprises a network interface to provide support for redundant network interface cards (NICs) in the event of NIC failure.
  • NICs network interface cards
  • the transaction coordinator preferably uses redundant hot-swap cooling systems comprising hot swappable redundant fans which are individually removable.
  • the transaction coordinator also preferably comprises an Intelligent Platform Management Interface to detect hardware and software failures.
  • the Intelligent Platform Management Interface is an open specification which simplifies and standardizes communications for device management.
  • the transaction preferably uses self-correcting memory.
  • the self-correcting memory is preferably a managed error checking and correcting system memory and cache memory.
  • transaction coordinator 202 preferably uses transaction processing monitoring to restart the application.
  • the transaction coordinator may also run redundant copies of an application and the transaction process monitor may transfer transactions to the redundant copies.
  • Certain application availability features may require that the application to be coded in a specific way which may also help address application crashes.
  • transactions are preferably transferred to a standby machine that is supported by the network.
  • Directory services including middleware like CORBA, may also be used to re-direct any new transaction requests to the new machine.
  • a monitoring infrastructure is preferably used to monitor the applications and the network.
  • a software monitoring tool (such as Trivoli) is used to monitor applications. This tool is preferably configured to page the administrator in the event of application failure.
  • a network monitoring system (such as that made by NetView) may also be used to allow administrators to monitor the network.
  • custom written application daemons are used to simulate transactions. If these transactions fail, system administrators may be informed. Also, database vendor tools may be used for database monitoring. Most databases provide database-monitoring tools that detect deadlocks and other databases problems.
  • a distribution approach for the transaction coordinator may preferably be defined that is a function of what root entity 110 wishes to distribute to participants.
  • Application distribution may typically be performed via Web-download from root entity 110 .
  • the Web-download mechanism may provide for selective download, authentication, and tracking.
  • the transaction coordinator may be adapted to support integration with existing operational systems such as CICS, IMS and other legacy systems.
  • Participants may choose to use the entire transaction coordinator architecture and functionality described above, or may instead choose to use components of the transaction coordinator and add their own implementations to those components.
  • the Web-download approach is preferably configured to fulfill the varying requirements of participants.
  • the download mechanism preferably provides at least three download options: (1) a download transaction coordinator executable option (2) a source code or binaries of the transaction coordinator option and (3) a source code of transaction coordinator classes option.
  • the first option preferably accommodates participants that choose to use the transaction coordinator in its entirety. This option provides options for different platforms.
  • the second option preferably accommodates participants that choose to plug components of the transaction coordinator described above into their own implementations. This download mechanism also provides options for different platforms.
  • the third option preferably accommodates financial institutions that opt for heavy-duty development and choose only to use certain pieces of implementation of the transaction coordinator described above.
  • the download mechanism allows financial institutions to not only download the executable, but also the source code. Because the downloaded executable may be used on its own and the source code may be used to develop other custom applications, root entity 110 preferably provides download access only to those institutions that are trusted partners with root entity 110 and hence are authorized to use the transaction coordinator. Preferably, this is achieved via an authentication/authorization process.
  • Root entity 110 may preferably track which participants download particular components of the transaction coordinator. This way root entity 110 may determine the versions of the transaction coordinator and/or its components that are being used at any given time. Root entity 110 may use this information to (1) charge a fee from the financial institutions for the downloaded component(s) and to (2) track versions of the transaction coordinator for maintenance purposes.
  • the transaction coordinator is adapted to be scalable to accommodate a growing user base without significant performance degradation.
  • One step in fulfilling the scalability requirements for an application is to forecast the potential growth in the user base.
  • an application with a distributed architecture facilitates higher scalability by allowing distributed multiple instances of heavily loaded components to be running at a given time.
  • the transaction coordinator architecture is preferably a distributed one and, therefore, supports scalability.
  • the load-capacity of the transaction coordinator is preferably base-lined on a chosen development machine. This information is used to select appropriate hardware to support the anticipated number of transactions.
  • the transaction coordinator (and OCSP responder) are adapted to reliably handle up to 1000 validation transactions per minute.
  • OCSP checks are typically not performed on utility certificates. If signatures are not required on requests, there is no mechanism in place to ensure that the secure socket layer client-side certificates have not been revoked. Preferably, if a secure socket layer certificate has been revoked, financial institutions are informed out of band (e.g., a broadcast message) and the affected users are removed from the participant's customer database.
  • band e.g., a broadcast message
  • Each transaction coordinator typically trusts some set of certificates that are stored on its hardware security module. No OCSP checks are performed on these certificates. If a revoked certificate exists on a hardware security module, it will not be detected during on-line processing. Preferably, financial institutions are notified if a certificate stored on a hardware security module has been revoked so that they can remove the certificate from the hardware security module.
  • Transaction coordinators when acting as clients, authenticate servers with whom they are communicating. But this check typically only guarantees that the server has a certificate that was issued by a certificate authority that the transaction coordinator trusts. There are no checks regarding the identity or status of the server itself. In a preferred embodiment, the transaction coordinator checks servers against a list of trusted servers and performs OCSP checks of the server's certificate. However, since there is little to be gained by a server intercepting requests, the degradation of performance resulting from these additional checks is typically not warranted.
  • the transaction coordinator does not have automated processes for detecting potential attacks.
  • system and security administrators inspect audit logs periodically in order to identify such potential attacks.
  • requests that do not pass a secure socket layer client-side authentication check are not logged. If an attack (e.g., a denial of service attack) occurs at this level, there are no logs to reference.
  • an attack e.g., a denial of service attack
  • the transaction coordinator is protected by a firewall.
  • the firewall component maintains logs of incoming requests.
  • the transaction coordinator is preferably provided with automated intrusion detection mechanisms. These processes typically watch incoming traffic or scan audit logs looking for suspicious activity, and take appropriate actions if necessary.
  • the transaction coordinator preferably maintains logs for non-repudiation purposes. Often, however, the system will not include functions to assist a user in retrieving the data necessary to support non-repudiation. The user manually searches through the logs to find all the supporting data. In other embodiments, automated non-repudiation tools may be used to assist the user in this process.
  • transaction coordinators and OCSP responders employ normal Internet time out values for certificate status check requests.
  • the time out value may be set as appropriate for the service.
  • timeout values are configurable in the transaction coordinator.
  • the main server used for the transaction coordinator may be a Hewlett Packard Netserver LH4.
  • the server has the following specifications: 4 P2-450 MHZ processors, 512-768MB RAM, 40-60 GB HD with Raid 5 Array, UPS, and an external DLT 40E DLT 4000 tape drive for tape backup.
  • at least five workstations are used each having the following specifications: P2400 MHz processors, 128 MB RAM, and 6 GB HD.
  • the transaction coordinator is preferably platform independent so that it can be supported on servers based on Microsoft Windows NT 4.0/2000, Sun Solaris, and Hewlett Packard HP-UX. Implementation is preferably done in JAVA however some coding may be done in C/C++ as well.
  • a Windows NT Server w/Service Pack 3 may be used as the operating system.
  • Microsoft Visual SourceSafe 6.0 may be used for source control.
  • Visual Café Professional Edition 3.0 from Symantec (Java Version 1.2) may be used for development.
  • SSL/J SDK from RSA Security Systems may be used for secure socket layer implementation and is also required by XETI's JKIX.
  • nCipher's hardware security module may be used.
  • Datakey smart cards may be used.
  • OCSP responders are provided with a toolkit that provides an interface to cryptographic functions and for ASN.1 Communication.
  • XETI's JKIX may be used for this purpose.
  • Datum's TYMSYNC or other trusted time source may be used.
  • An MS SQL Server may be used for the databases described above.
  • Code Warrier from Metro Works may be used for the development of portable C/C++ development.
  • CodeIntegrity may be used to perform code integrity checks to verify code portability.
  • the size of the data that is passed between different entities is instrumental in the performance of a public key infrastructure system. Messages submitted between entities are therefore preferably analyzed to estimate the size of the data that is transmitted. The analysis may be done on the basis of the certificate fields defined in RFC2459 along with specific root extensions.
  • the exact data lengths of the certificate fields are preferably taken into account during the estimation. However, there are many fields for which the length varies. For these fields, a liberal estimate on the size is preferably made (i.e., larger rather than smaller). Also, estimates of overall message size preferably include the sizes for all extensions, i.e., if a message allows five different extensions, the size is preferably calculated on an assumption that all five extensions are being sent with the request.
  • FIG. 13 depicts the different message (estimated) sizes passed between system entities in a preferred embodiment.
  • the total estimated message size of messages passed from subscribing customer 106 to relying customer 108 is 2610 bytes.
  • the message typically comprises two certificates, each 1146 bytes, the issuing participant's certificate signed by root entity 110 , 128 bytes, the issuing participant's signature, 128 bytes, and an HTTP header, 62 bytes.
  • the total estimated message size of messages passed from relying customer 108 to relying participant 104 is 2022 bytes.
  • the message typically comprises two requests, one concerning the subscribing customer's certificate and one concerning the issuing participant's certificate, each 55 bytes, a message extension, 210 bytes, a version number, 4 bytes, the relying participant's name, 132 bytes, the relying participant's signature, 128 bytes, the relying customer's certificate, 1146 bytes, and an HTTP header, 62 bytes.
  • the total estimated message size of messages passed from relying participant 104 to issuing participant 102 is 1601 bytes.
  • the message typically comprises a request concerning the subscribing customer's certificate or the issuing participant's certificate, 55 bytes, a message extension, 210 bytes, the root entity's signature on the relying participant's transaction coordinator certificate, 128 bytes, the relying participant's transaction coordinator certificate, 1146 bytes, and an HTTP header, 62 bytes.
  • the total estimated message size of messages passed from issuing participant 102 to relying participant 104 is 2086 bytes.
  • the message typically comprises a response concerning either the subscribing customer's certificate or the issuing participant's certificate, 456 bytes, a message extension, 294 bytes, the issuing participant's certificate, 1146 bytes, the root entity's signature, 128 bytes, and an HTTP header, 62 bytes.
  • the total estimated message size of messages passed from relying participant 104 to relying customer 108 is 2213 bytes.
  • the message typically comprises a response concerning the subscribing customer's certificate or the issuing participant's certificate, 55 bytes, a message extension, 210 bytes, the response from the relying participant's transaction coordinator, 127 bytes, the relying participant's transaction coordinator certificate, 1146 bytes, the root entity's signature on the relying participant transaction coordinator's certificate, 128 bytes, and an HTTP header 62 bytes.
  • Name is defined as sequence of Relative Distinguished Name validity ⁇ notBefore ⁇ utcTime UTCTime 32 generalTime GeneralizedTime 32 ⁇ notAfter ⁇ utcTime UTCTime 32 generalTime GeneralizedTime 32 ⁇ ⁇ subject Name 132 This is a higher estimate - approximated for 4 names.
  • Name is defined sequence of Relative Distinguished Names subjectPublicKeyInfo ⁇ algorithm ⁇ Algorithm Object Identifier 11 Parameters Defined by 32 Signature algorithm parameters are usually NULL but since parameters are allowed, 32 bytes have been assigned for it ⁇ subjectPublicKey BIT STRING 128 ⁇ issuerUniqueID BIT STRING 132 This is higher estimate.
  • issuerUniqueID should not be used subjectUniqueID BIT STRING 132 This is higher estimate.
  • subject UniqueID should not be used extensions ⁇ extnID Object Identifier 0 Certificate is being estimated without any extensions.
  • extnID would take 11 bytes.
  • critical BOOLEAN 0 BOOLEAN would take 4 bytes extnValue OCTET STRING 0 Will depend upon the extension ⁇ ⁇ signatureAlgorithm ⁇ algorithm Object Identifier 11 parameters Defined by 32 Algorithm ⁇ Signature Value BIT STRING 128 This may vary from signer to signer When signed by root, the sire will be 256 when signed by the root ⁇ Total 985
  • Certificate Extension - with Root Instructions and Extensions Size (in Certificate Extensions/root entry Specific Instructions Bytes) Size Calculation Comments Must not contain Issuer Unique ID ⁇ 132 Must not contain Subject Unique ID ⁇ 132 Contain a Subject DN 0 Already present in certificate Extension subjectAltNames is supported as e-mail 47 Consists of a number of GeneralNames - root entity will support only rfc822 - email address - estimated at 32 bytes + 11 bytes for extnID and 4 bytes for critical flag Extension KeyUsage should appear in all Certificates 17 2 bytes for the bit string + 15 for extension parameters Extended Key usage should appear when appropriate 65 Consists of OID.
  • Valid request and response times for OCSP transactions and warranty transactions and confirmation times for all transactions are preferably specified by root entity 110 .
  • the following section describes preferred performance targets for the transaction coordinator.
  • the response times noted refer specifically to the system response time.
  • lapsed timeframes in which manual processes are completed are also established.
  • the validation request and response time (i.e., OCSP) is ten seconds or less for all response time transactions within the root control infrastructure.
  • Validation outside the root infrastructure (from customer to customer or customer to root) preferably does not exceed sixty seconds.
  • the total round-trip time preferably does not exceed seventy seconds.
  • the response time includes latency on the Internet.
  • the end-to-end response time preferably includes the longest validation path (i.e. subscribing customer to relying customer to relying participant to issuing participant to root entity).
  • An illustrative performance requirement maybe as follows: No more than 6 seconds between the post of a certificate status check to a relying participant's transaction coordinator and receipt of a response and no more than 3 seconds to turn around a response to a certificate status check where the data for the response is locally available in a case where caching is in effect, proof of freshness (i.e., including status of participant certificates in messages transmitted by the participant) is in effect, a certificate chain of two certificates is being validated, the transaction is a four-corner transaction, and the system entities are connected to a 10 Mbps LAN (rather than the Internet).
  • the warranty request response time includes offline transactions. Preferably, these offline transactions do not exceed an eight hour window starting at the end of a business day.
  • the response time for response to notification of lost, compromised, or invalid certificates preferably includes offline transactions. Preferably, these offline transaction do not exceed one hour.
  • the revocation of certificates also preferably includes offline transactions. Preferably, these offline transactions do not exceed one hour.
  • the transaction coordinator also preferably provides confirmation of transactions. Online transaction requests preferably receive status confirmation, including incomplete request or response, within seventy seconds.
  • the transaction coordinator also preferably provides a method of storing for retrieval incomplete transaction requests or responses, a receipt of request status, an incomplete request response, and transaction queuing for incomplete transaction.
  • the transaction coordinator also preferably comprises transaction recovery requirements. Appropriate system resource allocation preferably allows for transaction roll-back.
  • the transaction coordinator also preferably provides system fail-over requirements.
  • the transaction coordinator is provided with system redundancy, system/hot back-up, and redundancy within the public Internet.
  • a performance baseline in the development environment is preferably established. This base-line information is used to improve the performance of the application components on the development machine itself. However, to achieve a preferred target performance, appropriate production hardware capable of supporting the anticipated number of transactions and a network with appropriate band-width are typically put in place.
  • OCSP checks performed as part of the authentication process may be eliminated if the customer database is designed to reflect revoked certificates and if authorization checks are performed against a user's distinguished name and certificate, as opposed to just its distinguished name.
  • the transaction coordinator stores raw transaction data and then parses the data to separately store a subset of the data for billing purposes.
  • this function may be offloaded to an off-line process that monitors the raw transaction database and extracts relevant billing data from the data stored in the database.
  • Using secure socket layer between financial institutions and during communications with root entity 110 typically eliminates the need to digitally sign each request message. However, digitally signed requests provide a higher degree of security. Each participant may preferably assess the risks involved with trading off security for performance.
  • Caching OCSP responses typically improves the turnaround time by reducing the time it takes to send and receive an OCSP request to the root entity.
  • verification of OCSP responses is performed as the data is put into the cache as opposed to performing verification as part of the on-line transaction processing.
  • a transaction coordinator may cache validity responses and use the cached responses to validate credentials.
  • the period for which a response may be cached is preferably set as a policy matter by root entity 110 . This period may preferably be within the 4 to 5 minute range.
  • a transaction coordinator implements the ability to used cached responses it is preferably adapted to log their use for billing and audit as well as non-repudiation purposes.
  • the logged information preferably indicates that a cached response was used to validate a credential rather than a freshly acquired response.
  • a client application may prefer the use of a fresh response rather than a cached response. Accordingly, in a preferred embodiment, transaction coordinators preferably get and use a freshly acquired validity response on explicit request to use a fresh response rather than a cached response.
  • the recipient of a response checks the status of the responder's certificate.
  • the transaction coordinator may automatically include the status of its certificate (as signed by the root) whenever it sends a response to either a relying customer or to another transaction coordinator.
  • the following section discusses testing of the transaction coordinator.
  • the transaction coordinator is tested for the items listed in this section.
  • the transaction coordinator is preferably ported to more than one hardware platform (e.g. Microsoft Windows NT 4.0/2000, Sun Solaris and Hewlett Packard HP-UX). This allows participants to choose their own hardware platform from the list of the supported platforms. Tests are preferably performed to ensure that the transaction coordinator is installed smoothly on each of the supported platforms. To enable such testing appropriate hardware is typically required.
  • Microsoft Windows NT 4.0/2000, Sun Solaris and Hewlett Packard HP-UX e.g. Microsoft Windows NT 4.0/2000, Sun Solaris and Hewlett Packard HP-UX.
  • Tests are preferably performed to ensure that the transaction coordinator may be installed and uninstalled on a clean Windows NT Machine.
  • test are preferably performed to ensure that the executable derived from the same source code can be installed on all of the supported operating systems. Appropriate hardware with appropriate operating systems may be required to perform these tests.
  • the transaction coordinator interfaces with other third party vendors' software tools.
  • the interfaces to these software tools are preferably tested on the development site during development and system test phase.
  • elaborate testing is typically done at the customer site to ensure that the transaction coordinator interface with these tools is stable. This may be done during customer/functionality testing, described below.
  • the functionality of the transaction coordinator is preferably tested during development and system test phases. During these tests, appropriate tools are used to ensure that all of the custom written code is exercised at least once. In a another preferred testing phase, customers test the functionality of the transaction coordinator.
  • Security is a critical piece of the transaction coordinator. Preferably, testing is done to ensure that data is transferred securely from one point to another. Test cases are preferably created to exhaustively test the security aspect of the public key infrastructure.
  • each transaction coordinator supports this messaging protocol definition. Specifically, each transaction coordinator accepts and routes all valid XML messages as defined in the messaging protocol definition, logs and reports ill-formed messages, and is able to generate valid XML messages in response to requests.
  • the system may instead be implemented as an OCSP centric model that does not employ transaction coordinators 202 .
  • This alternative embodiment employs enhanced OCSP responders adapted to provide significantly more functionality than normally provided by a typical OCSP responder.
  • the enhanced OCSP responder is adapted to provide the following additional functionality:
  • This alternative embodiment provides only portions of the certificate status check service without providing the flexibility of adding new services. Also, billing is not implemented in this alternative embodiment. In addition, this alternative embodiment may cause vendor locking. A detailed list of the pros and cons of this alternative embodiment is provided below.
  • FIG. 14 depicts the transaction flows for this alternative embodiment.
  • the message flows in FIG. 14 are summarized in the following table: 1
  • the Subscribing Customer (SC) sends signed data, the signature, the SC and the IP certificates (and optionally CSSD) to the Relying Customer (RC).
  • the RC verifies the signature on the data sent by the SC and validates the SC's certificate chain and then creates an OCSP request containing the SC certificate serial number. This data is sent to the USM for signature.
  • 3 The OCSP request for the SC's certificate, signed by the RC is sent to the Relying Participant (RP) OCSP Responder (OR) along with the RC's certificate chain. The entire certificate chain must be passed with the message.
  • RP Relying Participant
  • OR OCSP Responder
  • the RP OCSP Responder logs the request in its OCSP log.
  • the RP OCSP Responder verifies the signature on the request and validates the RC's certificate chain. All verification if performed is software. The entire chain (including the root) must be passed with the message in order for verification of the signature/certificate chain to be performed. No checks are performed to ensure that the RC's certificate has not been revoked.
  • the RP OCSP Responder creates a new request, containing the single request received from the RC, and signs it using its HSM. Signed requests between financial institutions are not required.
  • the root entity may require SSL client- side authentication in which case the verification/validation/customer look up is based on the certificates associated with the SSL connection.
  • the RP OCSP Responder sends the signed OCSP request to the appropriate Issuing Participant's OCSP Responder based on the value in the Service Locator request extension of the received request.
  • the IP OCSP Responder logs the request in its OCSP log.
  • the IP OCSP Responder verifies the signature on the request and validates the RP OR's certificate chain. All verification if performed in software. The entire chain (including the root) must be passed with the message in order for verification of the signature/certificate chain to be performed.
  • the IP OCSP Responder creates an OCSP request containing the serial number of the PP OCSP Responder's certificate and signs it using its HSM.
  • the IP OCSP Responder then sends the request to the ROOT OCSP Responder based on the authority information access extension in the certificate associated with the signature on the request received in Step 4.
  • the IP OCSP Responder waits for a response from the ROOT regarding the RP OCSP Responder's certificate before issuing a response on the SC's certificate. If the IP only requires SSL client-side authentication and does not require signed OCSP requests, this step may not be necessary.
  • the ROOT OCSP Responder logs the request in its OCSP log.
  • the IP OCSP Responder verifies the signature on the request and validates the Root's OCSP Responder certificate chain. It should be noted, however, that there may not be enough information maintained in the logs to support non-repudiation. The entire certificate chain must be passed with the message. 14 The IP OCSP Responder then checks its local database to determine the status of the SC's certificate. The IP OCSP Responder generates a response and signs it using its HSM. 15 The IP OCSP Responder sends the signed response to the RP OCSP Responder. 16 The RP OCSP Responder logs the OCSP response in the OCSP log. The RP OCSP Responder verifies the signature on the response and validates the IP's OCSP Responder certificate chain.
  • the entire certificate chain must be passed with the message.
  • the RP OCSP Responder creates an OCSP request containing the serial number of the IP OCSP Responder's certificate and signs it using its HSM.
  • the RP OCSP Responder then sends the request to the ROOT OCSP Responder based on the authority information access extension in the certificate associated with the signature on the response received in step 14.
  • the ROOT OCSP Responder logs the raw request in its OCSP log.
  • the ROOT OCSP Responder verifies the signature on the request and validates the entire RP OCSP Responder's certificate chain.
  • the entire certificate chain must be passed with the message.
  • the ROOT OCSP Responder checks its local database to determine the status of the IP OCSP Responder's certificate, then it generates a response and signs it using its HSM. 21 The ROOT OCSP Responder sends the signed response to the OCSP Responder. 22 The RP OCSP Responder logs the response in its OCSP log. The RP OCSP Responder verifies the signature on the response and validates the Root's OCSP Responder certificate chain. The certificate chain may be passed with the message, or parts of the chain may reside either on the HSM or in the Certificate Verification database.
  • the RP OCSP Responder creates a response for the RC that contains information it received in step 2 (e.g., the nonce) and the status information on the SC's certificate it received in step 14 and signs it using its HSM. 24 The RP OCSP Responder returns the response to the RC. 25 The RC uses its HSM to verify the signature on the response and validate the RP's OCSP Responder certificate chain. The certificate chain may be passed with the message, or parts of the chain may reside on the HSM. 26 The RC creates an OCSP request containing the IP's certificate serial number. This data is sent to the HSM for signature.
  • the OCSP request for the IP's certificate, signed by the RC, is sent to the Relying Participant (RP) OCSP Responder (OR) along with the RC's certificate chain.
  • the entire certificate chain needs to be passed with the message.
  • the RP OCSP Responder logs the request in its OCSP log.
  • the RP OCSP Responder verifies the signature on the request and validates the RC's certificate chain. All verification if performed in software.
  • the entire chain (including the root) must be passed with the message in order for verification of the signature/certificate chain to be performed. No checks are performed to ensure that the RC's certificate has not been revoked.
  • the RP OCSP Responder creates a new request, containing the single request received from the RC, and signs it using its HSM. Signed requests between financial institutions are not required. Instead, the ROOT may require SSL client-side authentication in which case the verification/validation/customer look up is based on the certificates associated with the SSL connection. 30 The RP OCSP Responder sends the signed OCSP request to the ROOT OCSP Responder based on the value in the Service Locator request extension of the received request. 31 The ROOT OCSP Responder logs the request in its OCSP log. The ROOT OCSP Responder verifies the signature on the request and validates the RP OR's certificate chain. All verification is performed in software.
  • the entire chain (including the root) must be passed with the message in order for verification of the signature/certificate chain to be performed.
  • the ROOT OCSP Responder checks its local database to determine the status of the RP OCSP Responder's certificate, then it generates a response and signs it using its HSM.
  • the ROOT OCSP Responder then returns the response to the RP OCSP Responder.
  • the RP OCSP Responder logs the response in its OCSP log.
  • the RP OCSP Responder verifies the signature on the response and validates the ROOT's OCSP Responder certificate chain. It should be noted that there may not be enough information maintained in the logs to support non-repudiation.
  • the entire certificate chain must be passed with the message.
  • This OCSP proxy centric model has advantages and disadvantages when compared to the transaction coordinator model described above.
  • the pros and cons of this alternative embodiment are summarized in the table below: Pros Cons Takes away some of the complexity of Two OCSP Responder are required: one implementing the transaction coordinator as that re-signs responses, one that forwards an initial phase by reducing functionality signed responses without re-signing. and pushing code changes to the manufacturer of the OCSP responder. Allows the basic security infrastructure to No authorization checks are performed. be put in place and tested. Signatures are verified by the OCSP Responder but there are no checks performed to determine whether or not the request is from an authorized customer. There are no OCSP checks performed to determine if a requestor's certificate has been revoked.
  • All certificates in a requestor's/responder's chain must be sent with the request/ response in order for the OCSP Responder to verify the signatures. This significantly increases the size of the messages.
  • the RC must send individual requests to the RP - multiple certificate statuses cannot be requested in the same message if they need to be processed by different OCSP responders. Not enough information is maintained in the logs for non-repudiation purposes. It is not clear whether enough information about the requestor is retained for billing purposes. Can only perform certification status checks. Will still require a transaction coordinator to fulfill other services. Will not provide generic reusable core components. The TETF OCSP Responder specification does not require Responder to provide this additional functionality.
  • each OCSP responder 204 operates pursuant to the Online Certificate Status Protocol (OCSP).
  • OCSP Online Certificate Status Protocol
  • an OCSP responder 204 when an OCSP responder 204 receives an OCSP request, it validates the requestor's certificate, authenticates the requestor, and verifies that the requestor is a contracted system user with the participant that received the request by performing a local status check on the requestor's certificate. Authentication of the requestor may be accomplished using the signed OCSP request, in the case of an inter-institution request, or through secure socket layers client authentication, in the case of a customer request. In addition, secure socket layers may be required to ensure the confidentiality of all requests.
  • each OCSP responder 204 selects peer servers when making inter-institution requests based on a locator extension of the requested service and a local table.
  • this information may be obtained by lightweight directory access protocol (LDAP) look up.
  • LDAP lightweight directory access protocol
  • each OCSP responder 204 may cache certificates subject to rules specified by root entity 110 .
  • each OCSP responder 204 verifies that inter-institution responses have been signed by an authorized responder certificate.
  • the OCSP responder of the relying participant 204 preferably re-signs the response from, e.g., issuing participant 102 before transmitting it to the requestor.
  • each OCSP responder supports the following responses: “revoked,” “good,” and “unknown.” If a client OCSP responder receives a “revoked” response regarding a particular certificate produced at a time t, then the client OCSP responder assumes that that certificate, or some certificate in the certificate chain of that certificate was revoked prior to time t. As such, the client OCSP responder does not possess sufficient evidence to transfer liability for documents that have been digitally signed after time t using the private key corresponding to the checked certificate to the server OCSP responder.
  • a client OCSP responder receives a “good” response regarding a particular certificate, produced at a time t, then the client OCSP responder assumes that that certificate and every other certificate in its certificate chain was in good standing at time t. As such, the client OCSP responder has sufficient evidence to transfer liability for documents that have been digitally signed prior to time t to the server OCSP responder.
  • the client OCSP responder receives an “unknown” response regarding a particular certificate produced at time t, then the client OCSP responder assumes that that certificate, or a certificate in the certificate chain of that certificate, is not known to be in good standing. As such, the client OCSP responder does not possess sufficient evidence to transfer liability for documents that have been digitally signed using the private key corresponding to the checked certificate to the server OCSP responder.
  • each OCSP responder 204 stores its private keys in a hardware security module that meets requirements established by root entity 110 .
  • each OCSP responder 204 uses separate keys for server secure socket layers, client secure socket layers, and OCSP responses.
  • each OCSP responder 204 has the ability to operate on institution-hardened platform configurations.
  • An institution-hardened platform is a tried and tested platform that is approved for use within an institution's firewall.
  • each OCSP responder 204 maintains detailed logs of all signed requests and responses, all exceptions or errors, and all administrative and configuration actions.
  • each OCSP responder 204 uses strong authentication, such as secure socket layers client authentication, to authenticate entities for all administrative transactions.
  • each OCSP responder 204 meets minimum security requirements established by root entity 110 .
  • the institution that maintains the OCSP responder may specify additional OCSP responder security rules.
  • each OCSP responder 204 is configured to be highly available and deployable in a replicated mode.
  • each OCSP Responder preferably responds to all requests in less than one second.
  • OCSP responders are not typically required to perform checks on utility certificates. They may, however, be configured to allow a requestor unauthenticated access to the status of a utility certificate.
  • an OCSP responder may be required to serve as an authenticated interface to an institution's repository. Implementation details of this preferred embodiment may be left to the entity that maintains the OCSP responder.
  • each OCSP Responder comprises additional interfaces to support additional functionality.
  • each OCSP responder preferably comprises an additional interface to make information available to support a participant's customer-service requirements.
  • each OCSP responder preferably comprises an institution-defined standard interface for exporting system and event logs.
  • Each OCSP responder may also comprise an interface for export of information for billing applications. Billing data may be exported in any format including logs but preferably enables the requestor to determine the type and volume of the request.
  • participant 102 , 104 shown in FIG. 1 are referred to as level-one participants because they are issued digital certificates directly by root entity 110 . Accordingly, the certificate chain of each participant begins at root entity 110 . Each level one participant relies on root entity 110 to obtain the status of certificates of other level-one participants.
  • the present system may comprise additional participants, called level-two participants.
  • Each level-two participant is preferably issued a digital certificate by a level-one participant with which it is associated. These level-two participants may then serve as certificate authorities for their respective customers and provide system services to those customers.
  • Level one participants preferably provide the highest point of trust for level two participants. As such, level two participants preferably report directly to their sponsoring level one participant. Level two participants must also rely on their sponsoring level one participants to obtain the status of certificates of other participants.
  • a preferred embodiment including level one and level two participants is further described in copending U.S. patent application Ser. No. 09/502,450, filed Feb. 11, 2000, entitled System and Method for Providing Certification-Related and other Services, which is hereby incorporated by reference.
  • each participant collectively implements and maintains a hardware and software configuration baseline that identifies the operating environment of the hardware and software components of each participant.
  • the configuration baseline serves as a configuration reference which facilitates the daily operation and management of the system.
  • the baseline facilitates the integration of configuration changes made by one or more participants on a system-wide level.
  • the baseline facilitates system-wide service recovery in the event of hardware or software failures of one or more certification authorities.
  • a master copy of the configuration baseline for the present system is maintained by root entity 110 .
  • the master copy is kept by an officer of root entity 110 , such as the Vice President of Operations.
  • root entity 110 keeps a true and accurate record of root entity 110 's hardware and software configuration. At least three copies of the root certification authority's configuration baseline are preferably retained by root entity 110 at the following three locations: (1) at the same physical location of the root certification authority thereby allowing operational changes to be recorded as they occur; (2) at a secure location outside the physical location of the root certification authority but in a controlled container; and (3) at an offsite location with root entity 110 's backup and archive records. Other copies of this hardware and software configuration may be provided to level one certification authorities at the discretion of root entity 110 .
  • each level one participant maintains a true and accurate record of the hardware and software configuration of its certification authority architecture.
  • Each level one participant preferably prepares, retains, and maintains at least three copies of its configuration baseline document in the following three locations: (1) at the same physical location of the level one certification authority thereby allowing operational changes to be recorded as they occur; (2) at a secure location outside the physical location of the level one certification authority but in a controlled container; and (3) at an offsite location with the level one certification authority's backup and archive records.
  • each level one participant preferably provides a copy of its configuration baseline to root entity 110 .
  • level two participants also maintain a true and accurate record of the hardware and software configuration of their certification authority architecture.
  • Each level two participant prepares, retains, and maintains at least three copies of its configuration document in the following three locations: (1) at the same physical location as the level two certification authority thereby allowing operational changes to be recorded as they occur; (2) at a secure location outside the physical location of the level two certification authority but in a controlled container; and (3) at an off-site location with the level two certification authority's back up and archive records.
  • each level two participant preferably provides a copy of its configuration baseline to its sponsoring level one certification authority.
  • Forms may be provided to facilitate documentation of hardware and software configurations.
  • the hardware and software configurations of root entity 110 's and each participant's certification authority directory, OCSP responder, and Internet firewall are also documented.
  • root entity 110 has primary responsibility for configuration management on a system-wide level. This responsibility is typically delegated to an officer of root entity 110 , such as the Vice President of Operations.
  • Each certificate authority preferably comprises a technical operations staff which has the operational responsibility for maintaining an accurate record of the certification authority's hardware and software configuration.
  • the initial configuration baseline of each certificate authority is produced by commissioning the configuration baselines of each subordinate certification authority.
  • a configuration change must comply with the following criteria: (1) a configuration change must be required to address a defined system requirement; (2) a configuration change must be recommended by the certification authority's operations staff; (3) a configuration change to the operational platforms must be approved by an officer, such as the Vice President of Operations in the case of the root entity, and a senior manager accountable for the integrity of the certification authority, in the case of a level one or level two certification authority; (4) notice of configuration changes must be given to any affected parties; (5) a configuration change must take into account relevant configuration change criteria imposed by governmental or standards setting bodies; and (6) a configuration change must be recorded by setting out the date of the change and the period of each previous configuration.
  • Each certificate authority typically archives configuration changes with other archived materials such as backup tapes.
  • the configuration baseline is implemented in conjunction with the root entity's system security policy and is an audited component of each certification authority.

Abstract

A system and method for facilitating electronic commerce by securely providing certificate-related and other services including certificate validation and warranty is disclosed. In a preferred embodiment, these services are provided within the context of a four-corner trust model. The four-corner model comprises a buyer, or subscribing customer, and a seller, or relying customer, who engage in an on-line transaction. The buyer is a customer of a first financial institution, or issuing participant. The issuing participant operates a certificate authority and issues the buyer a hardware token including a private key and a digital certificate signed by the issuing participant. The seller is a customer of a second financial institution, or relying participant. The relying participant operates a certificate authority and issues the buyer a hardware token including a private key and a digital certificate signed by the relying participant. The system also includes a root certificate authority that operates a certificate authority that issues digital certificates to the issuing and relying participants. At the time of a transaction, the buyer creates a hash of the transaction data, signs the hash, and transmits the transaction data, the signature, and its digital certificate to the seller. The seller may then request system services via a connection with its financial institution, the relying participant. The system services may include a certificate status check service and a warranty service. The certificate status check service allows the relying customer to validate the subscribing customer's certificate. The warranty service allows the relying customer to receive a collateral-backed warranty that the subscribing customer's certificate is valid. Each participant and the root entity is provided with a transaction coordinator for combining services and operations into a single transaction having the qualities of atomicity, consistency, isolation, and durability. The transaction coordinator provides a single consistent interface for certificate-status messages and requests, as well as messages and requests relating to other services.

Description

  • This application claims priority from U.S. provisional patent application serial No. 60/231,319, filed Sep. 8, 2000, entitled Transaction Coordinator Certificate Status Check (CSC) Protocol Definition, Transaction Coordinator Messaging Protocol Definition, and Transaction Coordinator Requirements, which is hereby incorporated by reference. This application is also a continuation of U.S. patent application Ser. No. 09/657,605, filed Sep. 8, 2000, entitled System and Method for Providing Certificate Validation and Other Services, which claimed priority to U.S. provisional patent application serial No. 60/153,726, filed Sep. 13, 1999, entitled Transaction Coordinator for Certificate Status Checking and Other Services; U.S. provisional patent application serial No. 60/153,724, filed Sep. 13, 1999, entitled Transaction Coordinator Requirements and High Level Design; and U.S. provisional patent application serial No. 60/153,203, filed Sep. 10, 1999, entitled System and Process for Certification in Electronic Commerce, all of which are hereby incorporated by reference.[0001]
  • FIELD OF THE INVENTION
  • This invention relates generally to the field of facilitating electronic commerce by providing services via a public key infrastructure. [0002]
  • BACKGROUND OF THE INVENTION
  • The world of electronic commerce has created new challenges to establishing relationships between contracting parties. One of those challenges springs from the fact that the parties to the transaction cannot see or hear each other, and cannot otherwise easily confirm each other's identity and authority to act. [0003]
  • One remedy for this problem is to provide each contracting party with a private key for signing transmitted messages. The signing party makes available an associated public key that decrypts messages signed with the party's private key, and thus enables a receiving party to confirm the identity of the sender. [0004]
  • But the sender's public key may not be known a priori to the recipient. In that event, the sender may transmit with its signed message a digital certificate issued by a certificate authority. The certificate is itself a signed electronic document (signed with the private key of the certificate authority) certifying that a particular public key is the public key of the sender. [0005]
  • In some cases, the recipient may be unfamiliar with the public key of the certificate authority or may not know whether the certificate is still valid. In that event, the recipient may wish to check the authenticity and validity of the certificate with an entity that it trusts. One known protocol for checking certificate status is the on-line certificate status protocol (OCSP). [0006]
  • SUMMARY OF THE INVENTION
  • A system and method are disclosed for facilitating electronic commerce by securely providing certificate-related and other services including certificate validation and warranty. In a preferred embodiment, these services are provided within the context of a four-corner trust model. The four-corner model comprises a buyer, referred to as the subscribing customer, and a seller, referred to as the relying customer, who engage in an on-line transaction. The buyer is a customer of a first financial institution, referred to as an issuing participant. The issuing participant acts as a certificate authority for the buyer and issues the buyer a hardware token including a private key and a digital certificate signed by the issuing participant. The seller is a customer of a second financial institution, referred to as the relying participant. The relying participant acts as a certificate authority for the seller and issues the buyer a hardware token including a private key and a digital certificate signed by the relying participant. The system also includes a root certificate authority that issues digital certificates to the issuing and relying participants. [0007]
  • At the time of a transaction, the buyer creates a hash of the transaction data, signs the hash, and transmits the transaction data, the signature, and its digital certificate to the seller. The seller may then request system services via a connection with its financial institution, the relying participant. [0008]
  • In a preferred embodiment, these system services may include a certificate status check service and a warranty service. The certificate status check service allows the relying customer to validate the subscribing customer's certificate. The warranty service allows the relying customer to receive a collateral-backed warranty that the subscribing customer's certificate is valid. Detailed message flows for providing these services are provided in the detailed description. [0009]
  • In a preferred embodiment, each participant and the root entity is provided with a transaction coordinator for combining services and operations into a single transaction having the qualities of atomicity, consistency, isolation, and durability. The transaction coordinator provides a single consistent interface for certificate-status messages and requests, as well as messages and requests relating to other services. As a result, the present invention provides the necessary flexibility to permit centralized and consistent capture of transactional information relating to a plurality of offered services for audit and non-repudiation purposes. In addition, the present invention facilitates the integration of additional services and provision of those services to customers. [0010]
  • The disclosed transaction coordinator provides a single interface to facilitate electronic communications amongst banks or other financial institutions or between banks or other financial institutions and their customers. The transaction coordinator also provides a single entry point for customers to obtain certificate-check services and provides the flexibility to add new business application services, such as warranty service, payment guarantee service, or certified mail service, while still providing a single entry point for these additional services. It is preferably designed to be easily extended to support additional services as they are created. [0011]
  • The disclosed transaction coordinator provides parsing, flow control, and error handling for the present messaging infrastructure and acts as a message switch to route message components to an appropriate system service (e.g., to an OCSP responder, warranty engine, etc.). In addition, it collates responses from these services into a consolidated response and dispatches the responses to requesting clients. [0012]
  • The disclosed transaction coordinator also records billing data for the certificate check service or other services in a centralized general fashion. Because all of the banks and other financial institutions have their own requirements for billing, the billing data can be extracted and modified to an individual financial institution's needs by writing simple extraction functions. [0013]
  • The disclosed transaction coordinator also allows banks or other financial institutions to cross-charge each other for different types of transactions as needed. Further, the disclosed transaction coordinator allows for the integration of commercial off-the-shelf software applications and provides a single electronic signing service to electronically sign and verify documents. [0014]
  • In addition, the disclosed transaction coordinator isolates all core services, thereby promoting reuse of components and simplifying the maintenance and enhancements of these services. The disclosed transaction coordinator does not require changing the on-line certification check functionality that would render it non-standard and might result in vendor locking and implementation delays.[0015]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • These and other objects, features, and advantages of the present invention will be better understood when taken in conjunction with the following detailed description and accompanying drawings in which: [0016]
  • FIG. 1 is a block diagram of a preferred embodiment of the four-corner model employed by the present system; [0017]
  • FIG. 2 is a block diagram depicting components preferably provided at entities in the four-corner model; [0018]
  • FIG. 3 is a block diagram of a preferred embodiment of a transaction coordinator; [0019]
  • FIG. 4 is a composite block/flow diagram that demonstrates certain aspects of transaction coordinator operation in a preferred embodiment; [0020]
  • FIG. 5 is a composite block/flow diagram depicting preferred operation of the signing component of a transaction coordinator; [0021]
  • FIG. 6 is a composite block/flow diagram demonstrating a preferred embodiment of the steps performed by a transaction coordinator in performing a certificate status check; [0022]
  • FIG. 7 is a composite block/flow diagram illustrating a preferred embodiment of the transaction flow for validating a certificate; [0023]
  • FIG. 8 is a composite block/flow diagram illustrating the transaction flow for one preferred embodiment of a warranty service; [0024]
  • FIG. 9 is a composite block/flow diagram of a preferred embodiment of server-side authentication; [0025]
  • FIG. 10 is a composite block/flow diagram of a preferred embodiment of client-side authentication; [0026]
  • FIG. 11 is a composite block/flow diagram illustrating a preferred message authentication process; [0027]
  • FIG. 12 is a composite block/flow diagram of a preferred embodiment of the security-relevant flows associated with components of a transaction coordinator; [0028]
  • FIG. 13 is a composite block/flow diagram that depicts the (estimated) sizes of messages that are passed between system entities in a preferred embodiment; [0029]
  • FIG. 14 is a composite block/flow diagram that depicts the transaction flows for an OCSP-proxy centric embodiment of the present system.[0030]
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • The present disclosure relates to a system that allows financial institutions to securely perform electronic certificate status checks and other services for their customers. In a preferred embodiment, the disclosed system employs a four-corner trust model to provide these services. A preferred embodiment of the four-corner model employed by the present system is shown in FIG. 1. [0031]
  • As shown in FIG. 1, the four-corner model comprises a [0032] first institution 102 and a second institution 104. First institution 102 is referred to as the “issuing participant” because it is a participant in the present system and issues smart cards to its customers, as described below. Second institution 104 is referred to as the “relying participant” because it is a participant in the present system and its customers rely on representations made by issuing participant 102 and issuing participant 102's customers, as described below. Participants 102, 104 are typically banks or other financial institutions.
  • Also shown in FIG. 1 are a [0033] first customer 106, and a second customer 108. First customer 106 and second customer 108 are preferably customers of issuing participant 102 and relying participant 104, respectively. First customer 106 is referred to as the “subscribing customer” because it subscribes to services provided by issuing participant 102. Second customer 108 is referred to as the “relying customer” because it relies on representations made by both issuing participant 102 and subscribing customer 106.
  • Also shown in FIG. 1 is a [0034] root entity 110. Root entity 110 is typically an organization that establishes and enforces a common set of operating rules for facilitating electronic commerce and electronic communications. Root entity 110 may be owned jointly by a plurality of banks and/or other financial institutions that have agreed to adhere to these operating rules. One exemplary embodiment of such a root entity is described in copending application Ser. No. 09/502,450, filed Feb. 11, 2000, entitled System and Method for Certification-Related and Other Services, which is hereby incorporated by reference.
  • FIG. 2 is a block diagram depicting components preferably provided at entities in the four-corner model. As shown in FIG. 2, [0035] participants 102, 104 and root entity 110 are each provided with a transaction coordinator 202 that serves as a gateway for transmitting and receiving all inter-entity messages related to services provided by the present system. As described in more detail below, transaction coordinators 202 provide a single interface to issuing participant 102's and relying participant 104's on-line services, and implement safeguards necessary to ensure secure electronic communications between transaction coordinators 202 and other entities in the four-corner model. One preferred embodiment of a transaction coordinator 202 is described below in connection with FIGS. 3-6.
  • [0036] Participants 102, 104 and root entity 110 are each further preferably provided with an OCSP responder 204 and hardware security module (HSM) 206. Exemplary requirements for an OCSP responder 204 are described below. HSM 206 is adapted to sign messages and verify signatures on messages, as described below, in connection with FIG. 6.
  • In addition, each [0037] participant 102, 104 and root entity 110 is further preferably provided with a billing data database 208 (connected to a bank billing application 210 in the case of participants 102, 104), a raw transaction log, 212, a customer data database 214, a risk manager 216 (connected to customer data database 214), and a second hardware security module 218, each of which is connected to transaction coordinator 202.
  • As further shown in FIG. 2, relying [0038] customer 108 is preferably provided with a Web server 220 that is adapted to receive and transmit information via the Internet. Relying customer 108 is further preferably provided with a bank interface 222 for communicating with relying participant 104, as described in more detail below. One preferred embodiment of bank interface 222 (as well as additional components preferably provided at the relying customer) is described in copending U.S. patent application Ser. No. 09/657,604, filed Sep. 8, 2000, entitled System and Method for Facilitating Access By Sellers to Certificate-Related and Other Services, which is hereby incorporated by reference. Relying customer 108 is preferably further provided with a hardware security module 230 for signing and verifying system messages.
  • As further shown in FIG. 2, subscribing [0039] customer 106 is preferably provided with a Web browser 224 for browsing the Internet and a smart card 226 (and associated reader) for signing digital messages, as described below.
  • In a preferred embodiment, each system entity is provided with two digital certificates (and corresponding private keys) to facilitate authentication: An identity certificate (also referred to, in some cases, as a warranty certificate) and a utility certificate. In addition, in a preferred embodiment, each [0040] transaction coordinator 202 is preferably provided with its own identity certificate and utility certificate and associated private keys.
  • The identity private key is used to produce digital signatures that are required by [0041] root entity 110 as evidence of an entity's contractual commitment to the contents of an electronic transaction. A certificate chain is needed to support operations using this key. The status of the identity certificate may be obtained by authorized entities, as described below.
  • The utility private key is used to produce digital signatures that allow additional transactional security. Typically, utility certificates are used to support secure socket layer sessions, to sign S/MIME messages, and for other utility applications. A certificate chain is also needed to support operations using the utility key. The status of the utility certificate, however, may not be available to a requestor. Throughout this document, the term “certificate” refers to an identity certificate unless otherwise stated. [0042]
  • In a preferred embodiment, subscribing [0043] customer 106's digital certificates and associated private keys are provided to it by issuing participant 102. Issuing participant 102 preferably issues smart cards or other suitable instruments to subscribing customer 106 that include at least the private key associated with the subscribing customer's identity certificate. If desired, the smart card may also include the subscribing customer's identity certificate. Preferred specifications for the smart card, its manufacture, and contents are described in U.S. provisional patent application serial No. 60/224,994, filed Aug. 14, 2000, entitled Signing Interface Requirements, Smart Card Compliance Requirements, Warranty Service Functional Requirements, and Additional Disclosure, which is hereby incorporated by reference.
  • FIG. 3 is a block diagram of a preferred embodiment of a [0044] transaction coordinator 202. As shown in FIG. 3, transaction coordinator 202 preferably comprises an interface 302 comprising two components: a TC request manager 304 and a transport services component 306. Interface 302 passes communications to and from a plurality of service modules 308 and core components 310. Service modules 308 preferably include a certificate status check module 312, warranty service module 314, a payment guarantee module 316, and may comprise other service modules 318 for providing additional services. Core components 310 preferably include a logging component 320, a billing component 322, and a signing component 324.
  • [0045] Transport services component 306 provides a single entry point into the transaction coordinator and acts as an isolation layer between a requestor and the transaction coordinator's service modules and core components. Request manager 304 receives service requests from transport services component 306 and forwards them to appropriate service modules and/or core components, as described in more detail below.
  • The function of certificate [0046] status check service 312 is to validate the certificates of entities within system 200 of FIG. 2. The function of warranty service 314 is to guarantee the identity of an entity that signs an electronic communication relating to a particular business transaction. In a preferred embodiment, the participant providing the warranty, typically issuing participant 102, accepts financial responsibility for some or all of the transaction amount if it is later discovered that subscribing customer 106 did not execute a digital signature created with the subscribing customer's private key.
  • The function of [0047] payment guarantee service 316 is to further decrease the risk associated with a transaction by providing relying customer 108 with immediate confirmation of subscribing customer 106's ability to fulfill a financial obligation. In addition, issuing participant 102 may issue a payment guarantee for some or all of the transaction amount if for some reason subscribing customer 106 fails to pay relying customer 108. Payment services may also be established as described in copending U.S. patent application Serial No. 09/657,622, filed Sep. 8, 2000, entitled System and Method for Providing Payment Services in Electronic Commerce, which is hereby incorporated by reference.
  • The function of [0048] certified mail service 318 is to support off-line transactions. Off-line transactions occur when the receiving entity, instead of servicing the request immediately, puts the request in a processing queue. Typically, an acknowledgment of receipt is sent to the requestor. This scenario may preferably be implemented when the transaction volumes are so large that it is not feasible to provide on-line responses to every request. Certified mail service 318 may preferably be used to satisfy requests between relying customer 108 and relying participant 104, relying participant 104 and issuing participant 102, and any request made to root entity 110.
  • The function of [0049] logging component 320 is to log all service requests and OCSP responses in a raw transaction log 58 (see FIG. 5) for non-repudiation and security auditing purposes.
  • The function of [0050] billing component 322 is to create and store a transaction billing history for messages (responses and requests) received by transaction coordinator 202. Preferred operation of these modules and components is further described below.
  • FIG. 4 is a composite block/flow diagram that demonstrates certain aspects of transaction coordinator operation in a preferred embodiment. As shown in FIG. 4, in step [0051] 4002, transport services component 306 of transaction coordinator 202 receives a service request from another system entity and sends the service request to request manager 304. In step 4004, request manager 304 checks to see if the service request format is valid. If the service request format is valid, request manager 304 requests information on the requestor, the billing data, and the service request type by calling a message validation module 404. Message validation module 404 calls a parser component 406 to extract the relevant information from the raw service request.
  • In step [0052] 4006, request manager 304 calls an authentication module 408 to authenticate the requestor. Authentication module 408 is described in more detail below.
  • In step [0053] 4008, authentication module 408 authenticates the requestor by calling signing component 324 of transaction coordinator 202 which, in turn, calls hardware security module 218. A preferred structure and operation for signing component 324 is described in more detail below.
  • In step [0054] 4010, authentication module 408 calls certificate status check component 414 that in turn calls an OCSP responder 204 to perform a certificate status check on the requestor. A preferred structure and operation for certificate status check component 414 is described in more detail below.
  • In step [0055] 4012, authentication module 408 calls a customer authorization check module 418 to verify that the requestor is authorized to place the service request. A preferred structure and operation for customer authorization check module 418 is described in more detail below.
  • In step [0056] 4014, request manager 304 calls logging component 320 to log the raw service request for non-repudiation purposes. In a preferred embodiment, messages stored in the raw transaction log are stored in either ASN.1 or XML format.
  • In step [0057] 4016, request manager 304 forwards any billing data necessary to appropriately bill for services provided to billing component 322 to for logging in the billing log.
  • In step [0058] 4018, request manager 304 forwards the service request to a service request router 426. In step 4020, service request router 426 calls an appropriate service module 308 to fulfill the request.
  • In step [0059] 4022, a service response is received by service request router 426 from the service module that was called in step 4020. Service request router 426 forwards the service response back to request manager 304 which, in turn, sends the service response to transport services components 306. Transport services component 306 forwards the service response to the entity that made the service request.
  • FIG. 5 is a composite block/flow diagram depicting preferred operation of [0060] signing component 324. Signing component 324 preferably provides a single interface to different signing devices, such as smart cards and hardware security modules, and uses cryptographic processing to verify signatures.
  • Turning to FIG. 5, when a request is received by signing [0061] component 324 in step 5002, signing component 324 determines whether it is a request for signature or for verification. If the request is for verification, signing component 324 sends the request to a hardware security module 218 for verification (step 5004). In step 5008, hardware security module 218 responds to this request with a signature verification response to signing component 60.
  • If the request is to sign a document, [0062] signing component 324 sends the request (which should include the document to be signed) to hardware security module 218 for signature (step 5006). In step 5010, hardware security module 218 responds to this request by signing the document and returns the signed document to signing component 324. Finally, in step 5012, signing component 324 returns the signature-verification response or signed document to the component that made the request.
  • FIG. 6 is a composite block/flow diagram demonstrating a preferred embodiment of the steps performed by a [0063] transaction coordinator 202 in performing a certificate status check. In step 6002, certificate check service module 312 receives an unparsed certificate status check request from service router 426 and forwards it to a parser component 406 that extracts the relevant customer information (comprising the certificate to be checked) from the request. In step 6004, certificate check service module 312 obtains any additional service-specific fulfillment information from a customer database 606.
  • In step [0064] 6006, if the certificate to be checked belongs to a customer of the participant whose transaction coordinator 202 received the request, certificate check service module 312 hands the request off to a local-customer handler 602. Otherwise, certificate check service module 312 hands the request off to a non-local-customer handler 610.
  • In those cases where local-[0065] customer handler 602 handles the request, the system proceeds to step 6008, where local customer handler 602 sends a certificate check request to a certificate status check component 312. Certificate status check component 312 then obtains a certificate status for the certificate to be checked from its associated OCSP responder 204 (i.e., the OCSP responder 204 belonging to the same transaction coordinator 202 as certificate status check component 312). Flow in these cases then continues with step 6032 below.
  • In contrast, in those cases where the certificate to be checked does not belong to a customer of the participant who received the request, then, in step [0066] 6010, non-local-customer handler 610 looks up the IP address of the issuing participant that issued the certificate that is the subject of the request in a static DNS table 604. Transaction coordinator 202 RP is preferably adapted to use the AIA extension in a certificate to identify the location of issuing participant 102. In step 6012, non-local-customer handler 610 forwards the subject certificate to an OCSP request formulation module 608. In step 6014, OCSP request formulation module 608 formulates an OCSP request for the certificate and sends the request to signing component 324 for signature. In step 6016, signing component 324 returns the signed request.
  • In step [0067] 6018, OCSP request formulation module 608 sends the signed request to the issuing participant 102 that issued the subject certificate. In step 6020, that issuing participant 102 returns an OCSP response to the request to OCSP request formulation module 608.
  • In step [0068] 6022, OCSP request formulation module 608 forwards the response to non-local-customer handler 610. In step 6024, non-local-customer handler 610 logs the raw response data to raw transaction log 212 for non-repudiation purposes.
  • In step [0069] 6026, non-local-customer handler 610 sends the raw response data to parser component 406 to extract the certificates of issuing participant 102 and its transaction coordinator 202 IP from the response.
  • In step [0070] 6028, non-local-customer handler 610 validates the issuing participant's transaction coordinator certificate by repeating steps 6012-6024 but transmitting the OCSP request created in step 6014 to root entity 110 rather than issuing participant 102.
  • Similarly, in step [0071] 6030, non-local-customer handler 610 validates the issuing participant's certificate by repeating steps 6012-6024 but transmitting the OCSP request created in step 6014 to root entity 110 rather than issuing participant 102.
  • In step [0072] 6032, the certification check response data received by non-local-customer handler 610 or generated by local-customer handler 602 is sent to signing component 324 which signs the response. In step 6034, the signed response is sent back to certificate check service module 312 which, in turn, transmits the response to service request router 426.
  • FIG. 7 is a composite block/flow diagram illustrating a preferred embodiment of transaction flow within [0073] system 200 for validating a certificate. As shown in FIG. 7, in step 7002, subscribing customer 106 creates a hash of data representing a transaction between subscribing customer 106 and relying customer 108 and sends the hash to smart card 226 for signature. In step 7004, smart card 226 signs the data and returns the signed data along with the certificate of subscribing customer 106 and issuing participant 102.
  • In step [0074] 7006, subscribing customer 106 sends the signed data and the two certificates to relying customer 108. In step 7008, relying customer 108 verifies the signature on the data sent by subscribing customer 106. This verification preferably includes checking the validity period of the received certificates. Alternatively, verification may be provided as a service to relying customer 108 by relying participant 104. Relying customer 108 then creates an OSCP request containing the subscribing customer's and issuing participant's certificates and transmits the request to hardware security module 230 for signature. In step 7010, hardware security module 230 returns the signed request.
  • In step [0075] 7012, relying customer 108 transmits the signed OCSP request to relying participant 104, along with its own certificate. In step 7014, transaction coordinator 202 RP of relying participant 104 receives the signed OCSP request and checks customer database 214 RP to make sure that the request was signed by an existing relying customer before processing the request. In a preferred embodiment, a relying participant 104 does not process requests received from a customer of a different participant. In step 7016, transaction coordinator 202 RP stores the raw transaction data (i.e., the unparsed request, signature, and accompanying relying customer certificate) in raw transaction log 212 RP. In step 7018, any billing data necessary to appropriately bill for services provided is stored in billing log 208 RP. Alternatively, billing data may be extracted from the raw-transaction log by an off-line process to increase system performance.
  • In step [0076] 7020, transaction coordinator 202 RP verifies the relying customer's signature on the service request using the relying customer's certificate, the relying participant's certificate, and the root public key. The relying participant's certificate and the root public key may preferably be stored in hardware security module 218 RP.
  • In step [0077] 7022, transaction coordinator 202 RP generates an OCSP request containing the relying customer's certificate, signs it, and sends it to its OSCP responder 204. Alternatively, if the transaction coordinator and OCSP responder are co-located, a signature on the request may not be necessary. In step 7024, OCSP responder 204 verifies the signature of the request, checks its local repository to determine the validity of its relying customer's certificate, and sends a response back concerning that certificate's status to transaction coordinator 202 RP.
  • It should be noted that, as part of system operation, relying [0078] customers 108 will often need to validate the certificate of a subscribing customer 106 that is a customer of a participant other than relying participant 104. Because, in that case, relying participant 104 is not the issuing participant that issued the certificate to be validated, it does not have first hand knowledge of that certificate's status.
  • In a preferred embodiment, the present system addresses this problem by having each participant that receives an OCSP request for a certificate issued by another participant, forward the request to the issuing participant for that certificate. In particular in step [0079] 7026, relying participant 104 determines the subscribing customer's issuing participant. If the subscribing customer is a customer of a different participant, relying participant 104 generates a signed validation request for the subscribing customer's certificate and sends it to the identified issuing participant 102 along with its own certificate. Alternatively, rather than sign the validation request, the relying participant may instead provide client-side authentication to issuing participant 102 as, for example, in the OCSP-proxy centric model described below.
  • If the subscribing customer and the relying customer are both customers of the same participant, validation of the subscribing customer's certificate is handled by local-[0080] handler module 602, as described above.
  • In step [0081] 7028, issuing participant 102 checks its customer database 214 IP to make sure that the request was signed by an entity authorized to make the request. In step 7030, issuing participant 102 stores the received raw transaction (i.e., the unparsed request, signature, and accompanying certificate) in its raw transaction log 212 IP. In step 7032, issuing participant 102 stores relevant billing data for the request in its billing log 208. Alternatively, billing data may be extracted from the raw-transaction log by an off-line process to increase system performance.
  • In step [0082] 7034, issuing participant 102 verifies transaction coordinator 202 RP's signature on the request using the relying participant's transaction coordinator certificate (sent with the request) and the root public key (which may be stored in hardware security module 218 IP). In step 7036, the issuing participant's transaction coordinator 202 IP generates a signed OCSP request for the relying participant's transaction coordinator certificate and sends the request to root entity 110.
  • In step [0083] 7038, transaction coordinator 202 R of root entity 110 receives the request and stores the raw request in its raw transaction log 212 R. In step 7040, transaction coordinator 202 R stores billing data for the request in billing data log 208 R. In step 7042, transaction coordinator 202 R verifies the signature on the request and then sends the request to OCSP responder 204 R. In step 7044, OCSP responder 204 R checks its local repository to determine the status of the subject certificate and sends a response back concerning its status to transaction coordinator 202 R. In step 7046, transaction coordinator 202 R sends a signed response to transaction coordinator 202 IP indicating the status of the relying participant's transaction coordinator certificate.
  • In step [0084] 7048, transaction coordinator 202 IP of issuing participant 102 stores the OCSP response from root entity 110 in raw transaction log 212 IP for non-repudiation purposes. In step 7050, transaction coordinator 202 IP generates an OCSP request for the subscribing customer's certificate, signs it, and sends it to its own local OCSP responder 204 IP along with its own certificate. Alternatively, if transaction coordinator 202 IP and OCSP responder 204 IP are co-located, a signature on the request may not be necessary. Also, if the two are co-located, the transaction coordinator may simply act as a pass through, as opposed to re-signing requests and responses.
  • In step [0085] 7052, OCSP responder 204 IP verifies the signature on the request, generates a response, signs it, and returns the signed response to transaction coordinator 202 IP. In step 7054, transaction coordinator 202 IP verifies the OCSP responder's signature, resigns the response, and returns it to transaction coordinator 202 RP along with its own certificate.
  • In step [0086] 7056, transaction coordinator 202 RP of relying participant 104 stores the raw response data received from issuing participant 102 in raw transaction log 212 RP for non-repudiation purposes. In step 7058, transaction coordinator 202 RP verifies the signature of transaction coordinator 202 IP on the response using the issuing participant's transaction coordinator certificate (sent with the request) and the root public key (which may be stored in hardware security module 218 RP). In step 7060, transaction coordinator 202 RP generates a signed OCSP request for the issuing participant's transaction coordinator certificate and sends it to root entity 110.
  • In step [0087] 7062, transaction coordinator 202 R of root entity 110 stores the raw request data in raw transaction log 212 R. In step 7064, transaction coordinator 202 R stores relevant billing data in billing log 208 R. In step 7066, transaction coordinator 202 R verifies the signature on the request and sends the request to OCSP responder 204 R. In step 7068, OCSP responder 204 R checks its local repository to determine the status of the issuing participant's transaction coordinator certificate and sends a response back concerning its status to transaction coordinator 202 R. In step 7070, transaction coordinator 202 R sends a signed response concerning the status of the subject certificate to transaction coordinator 202 RP.
  • In step [0088] 7072, transaction coordinator 202 RP of relying participant 104 stores the response in raw transaction log 212 RP for non-repudiation purposes. At this point, processing of the subscribing customer's certificate is complete.
  • In step [0089] 7074, transaction coordinator 202 RP now processes the second half of the request: the issuing participant's certificate, by generating a signed OCSP request for the issuing participant's certificate and sending it to root entity 110.
  • In step [0090] 7076, transaction coordinator 202 R of root entity 110 stores the raw request data in raw transaction log 212. In step 7078, transaction coordinator 202 R stores relevant billing data in billing log 208.
  • In step [0091] 7080, transaction coordinator 202 R verifies the signature on the request and sends the request to OCSP responder 204 R. In step 7082, OCSP responder 204 R checks its local repository to determine the status of the subject certificate and sends a response back to transaction coordinator 202 R. In step 7084, transaction coordinator 202 R sends a signed response to transaction coordinator 202 RP.
  • In step [0092] 7086, transaction coordinator 202 RP of relying participant 104 stores the response from root entity 110 in raw transaction log 212 RP for non-repudiation purposes. In step 7088, transaction coordinator 202 RP creates an OCSP response from the responses received from transaction coordinator 202 IP of issuing participant 102 and its local cache, signs it, and sends it to relying customer 108 along with its own certificate.
  • In step [0093] 7090, relying customer 108 verifies the response using the root's public key certificate stored in hardware security module 230. In step 7092, relying customer 108 sends a request to transaction coordinator 202 RP for the relying participant's transaction coordinator certificate in order to determine if that certificate has been revoked. In step 7094, transaction coordinator 202 RP verifies the signature on the request and sends a request to local OCSP responder 204 RP to ensure that the relying customer's transaction coordinator certificate has not been revoked. In step 7096, local OCSP responder 204 RP responds to this request from transaction coordinator 202 RP.
  • In step [0094] 7098, transaction coordinator 202 RP sends an OCSP request for the relying participant's transaction coordinator certificate to transaction coordinator 202 R of root entity 110. In step 7100, transaction coordinator 202 R verifies the signature on the request and checks with local OCSP responder 204 R to determine the status of the relying participant's transaction coordinator certificate. In step 7102, transaction coordinator 202 R forwards the response received from local OCSP responder 204 R to transaction coordinator 202 RP.
  • In step [0095] 7104, transaction coordinator 202 RP forwards the response received from root entity 110 to relying customer 108. In step 7106, relying customer 108 provides acknowledgment to subscribing customer 106.
  • In connection with steps [0096] 7092-7104 above, it should be noted that, as part of system operation, relying customers 108 will typically need to obtain the status of relying participant 104's transaction coordinator certificate. Within the four-corner model, the transaction coordinator and OCSP responder certificates of issuing participant 102 and relying participant 104 are signed by root entity 110. While root entity 110 operates an OCSP responder, this service is accessible only to participants. Consequently, relying customer 108 cannot request validation of its relying participant's certificates directly from root entity 110.
  • In a preferred embodiment, the present system addresses this problem by having each [0097] participant 102, 104 operate a root responder proxy. This proxy accepts requests from customers on behalf of the root, typically through a different uniform resource locator, forwards the request to the root over an authenticated secure sockets layer channel, and returns the response (still signed by the root) to the requesting party.
  • The four-corner model described above may also be used to provide a warranty service that warranties the identity of a particular entity (e.g., the subscribing customer) that signed a transaction. One embodiment for providing such a warranty service is described below. Additional embodiments for providing warranty services are described in U.S. provisional patent application serial No. 60/224,994, filed Aug. 14, 2000, entitled Signing Interface Requirements, Smart Card Compliance Requirements, Warranty Service Functional Requirements, and Additional Disclosure, which is hereby incorporated by reference. [0098]
  • FIG. 8 is a diagram of the transaction flow for one preferred embodiment of a warranty service. As shown in FIG. 8, in step [0099] 8002, subscribing customer 106 creates a hash of date representing a transaction between subscribing customer 106 and relying customer 108 and sends the hash to smart card 226 for signature. In step 8004, smart card 226 signs the data and returns the signature along with the subscribing customer's certificate and the issuing participant's certificate. Optionally, this message may also include card and signature security data (CSSD) to inject additional security such as protection against duplicate messages.
  • In step [0100] 8006, subscribing customer 106 sends the signed data, the signature, the subscribing customer's certificate, and the issuing participant's certificate (and optionally the CSSD) to relying customer 108. In step 8008, relying customer 108 verifies the signature on the data sent by subscribing customer 106. Alternatively, verification may be provided as a service to relying customer 108 by relying participant 104. Relying customer 108 then creates a warranty request and transmits the request to hardware security module 230 for signature. In step 8010, hardware security module 230 returns the signed request along with a copy of the relying customer's certificate.
  • In step [0101] 8012, relying customer 108 sends the signed warranty request and relying customer certificate to relying participant 104.
  • In step [0102] 8014, transaction coordinator 202 RP of relying participant 104 checks customer database 214 RP to make sure that the request was signed by an existing customer before processing the request. In step 8016, transaction coordinator 202 RP stores the raw transaction data relating to the transaction (i.e., the “unparsed” request, signature, and accompanying certificate) in raw transaction log 212 RP. In step 8018, transaction coordinator 202 RP stores relevant billing data in billing log 208 RP. Alternatively, billing data may be extracted from the raw transaction log by an off-line process to increase system performance.
  • In step [0103] 8020, transaction coordinator 202 RP verifies the relying customer's signature on the request using the relying customer's certificate (sent with the request), the relying participant's certificate, and the root public key (both of which may be stored in hardware security module 218 RP). Transaction coordinator 202 RP then generates an OCSP request containing the relying customer's certificate, signs it, and sends it to its local OCSP responder 204 RP. Alternatively, if the transaction coordinator and OCSP responder are co-located, a signature on the request may not be necessary.
  • In step [0104] 8022, OCSP responder 204 RP verifies the signature on the request, check its local repository for the status of the relying customer's certificate, and sends a response concerning that status back to transaction coordinator 202 RP.
  • In step [0105] 8024, transaction coordinator 202 RP calls a risk manager 216 RP to determine if relying customer 108 is financially authorized to make the warranty request. If it is, then, in step 8026, transaction coordinator 202 RP determines the participant responsible for responding to warranty requests concerning subscribing customer 106 (i.e., the participant of which subscribing customer 106 is a customer). In the present example, this entity is issuing participant 102. Transaction coordinator 202 RP then creates a warranty request for subscribing customer 106, signs it, and sends it to issuing participant 102 along with its own certificate. It should be noted that if the relying customer and subscribing customer are both customers of the same participant, the warranty request may instead be processed locally by the participant.
  • In step [0106] 8028, transaction coordinator 202 IP checks customer database 214 IP to make sure that the request was signed by an entity authorized to make the request. In step 8030, transaction coordinator 202 IP stores the raw transaction data (i.e., the “unparsed” request, signature, and accompanying certificate) in raw transaction log 212 IP. In step 8032, transaction coordinator 202 IP stores relevant billing data for the request in the billing log 208 IP. Alternatively, billing data may be extracted from the raw transaction log by an off-line process to increase system efficiency. In step 8034, transaction coordinator 202 IP verifies transaction coordinator 202 RP's signature on the request using transaction coordinator 202 RP's certificate (sent with the request), and the root public key (which may be stored in hardware security module 218 IP). Transaction coordinator 202 IP then generates a signed OCSP request for the relying participant's transaction coordinator certificate and sends it to root entity 110.
  • In step [0107] 8036, transaction coordinator 202 R of root entity 110 stores the raw request in raw transaction log 212 R. In step 8038, transaction coordinator 202 R stores relevant billing data for the request in billing data log 208 R. In step 8040, transaction coordinator 202 R verifies the signature on the request and then sends the request to OCSP responder 204 R. OCSP responder 204 R checks its local repository to determine the status of relying participant's transaction coordinator certificate and sends a response concerning that status back to transaction coordinator 202 R. Transaction coordinator 202 R then sends a signed response back to transaction coordinator 202 IP.
  • In step [0108] 8042, transaction coordinator 202 IP of issuing participant 102 stores the raw response in raw transaction log 212 IP for non-repudiation purposes. In step 8044, transaction coordinator 202 IP then generates an OCSP request from the request it received containing the subscribing customer's certificate, signs it, and sends it to its local OCSP responder 204 IP along with its own certificate. Alternatively, if the transaction coordinator and OCSP responder are co-located, as signature on the request may not be necessary. Also, if the two are co-located, the transaction coordinator may simply act as a pass through as opposed to re-signing requests or responses.
  • In step [0109] 8046, OCSP responder 204 IP verifies the signature on the request, generates a response, signs it, and returns the signed response to transaction coordinator 202 IP. In step 8048, transaction coordinator 202 IP calls risk manager 216 IP to determine whether or not to issue a warranty for subscribing customer 106. In step 8050, risk manager 216 IP returns a signed message to transaction coordinator 202 IP indicating whether a warranty should be issued. In step 8052, transaction coordinator 202 IP stores the signed response in raw transaction log 212 IP.
  • In step [0110] 8054, transaction coordinator 202 IP sends a signed request to transaction coordinator 202 R of root entity 110 to determine if issuing participant 102 has enough collateral to issue the warranty. In step 8056, transaction coordinator 202 R interacts with risk manager 216 R to determine if issuing participant 102 is adequately collateralized and, if so, decreases issuing participant 102's collateral level by an amount appropriate for the warranty being issued and returns a response to issuing participant 102.
  • In step [0111] 8058, transaction coordinator 202 IP verifies transaction coordinator 202 R'S signature, creates a warranty response, and returns it to transaction coordinator 202 RP along with its certificate.
  • In step [0112] 8060, transaction coordinator 202 RP of relying participant 104 stores the raw response in raw transaction log 212 RP for non-repudiation purposes. In step 862, transaction coordinator 202 RP verifies transaction coordinator 202 IP's signature on the response using transaction coordinator 202 IP's certificate (sent with the response), and the root public key (which may be stored in hardware security module 218 RP). Transaction coordinator 202 RP then creates a signed OCSP request for the issuing participant's transaction coordinator certificate and sends it to root entity 110.
  • In step [0113] 8064, transaction coordinator 202 R of root entity 110 stores the raw request in raw transaction log 212 R. In step 8066, transaction coordinator 202 R stores relevant billing data in billing log 208 R. In step 8068, transaction coordinator 202 R verifies the signature on the request. Transaction coordinator 202 R then sends the request to its OCSP responder 204 R. OCSP responder 204 R checks its local repository to determine the status of the subject certificate and sends a response back to transaction coordinator 202 R. Transaction coordinator 202 R then sends a signed response to transaction coordinator 202 RP.
  • In step [0114] 8070, transaction coordinator 202 RP of relying participant 104 stores the raw response data in raw transaction log 212 RP for non-repudiation purposes. In step 8072, transaction coordinator 202 RP checks with transaction coordinator 202 R of root entity 110 to ensure that the issuing participant has sufficient collateral to issue the warranty.
  • In step [0115] 8074, transaction coordinator 202 R stores the raw request in raw transaction log 212 R. In step 8076, transaction coordinator 202 R stores relevant billing data in billing log 208 R. In step 8078, transaction coordinator 202 R sends a yes or no response to transaction coordinator 202 RP of relying participant 104 concerning whether issuing participant 102 has sufficient collateral to issue the warranty.
  • In step [0116] 8080, transaction coordinator 202 RP stores the raw response data in raw transaction log 212 RP for non-repudiation purposes. In step 8082, transaction coordinator 202 RP creates a warranty response from the responses received from transaction coordinator 202 IP, signs it, and sends it to relying customer 108 along with transaction coordinator 202 RP's certificate.
  • In step [0117] 8084, relying customer 108 verifies the response using the root public key stored in hardware security module 230. In step 8086, relying customer 108 sends a request to transaction coordinator 202 RP for transaction coordinator 202 RP's certificate to see if it has been revoked.
  • In step [0118] 8088, transaction coordinator 202 RP verifies the signature on the request and sends a request to its local OCSP responder 204 RP to ensure that relying customer 108's transaction coordinator certificate has not been revoked. In step 8090, local OCSP responder 204 RP sends a response to this request to transaction coordinator 202 RP. In step 8092, transaction coordinator 202 RP sends an OCSP request for its certificate to transaction coordinator 202 R.
  • In step [0119] 8094, transaction coordinator 202 R verifies the signature on the request and checks with its local OCSP responder 204 R to determine the status of transaction coordinator 202 RP's certificate. Transaction coordinator 202 R then forwards the response received from local OCSP responder 204 R to transaction coordinator 202 RP.
  • In step [0120] 8096, transaction coordinator 202 RP forwards the response received from transaction coordinator 202 R to relying customer 108. In step 8098, relying customer 108 sends an acknowledgment to subscribing customer 106.
  • In a preferred embodiment, each [0121] transaction coordinator 202 provides atomicity, consistency, isolation, and durability to transactions coordinated by the transaction coordinator. Atomicity means that all actions required to complete a transaction succeed or all fail; the transaction is an indivisible unit of work. Consistency means that after a transaction is executed, the system is left in a correct, stable state, or returns to the state preceding initiation of the transaction. Isolation means that each transaction is unaffected by other transactions that may execute concurrently. Durability means that the effects of each transaction are permanent after the transaction is committed. The combination of atomicity, consistency, isolation, and durability are sometimes referred to as ACID properties.
  • [0122] Transaction coordinators 202 preferably provide ACID properties in a distributed computing environment by incorporating a transaction processing monitor or component transaction monitor. Suitable transaction processing monitors may include BEA TUXEDO from BEA Systems, Inc., MSMQ from Microsoft, Top End from NCR Corporation, and Encina from IBM Transarc. Suitable component transaction monitors may include Orbix OTM from Iona Technologies Inc. and BEA WebLogic from BEA Systems, Inc.
  • Any combination of steps to be coordinated by a transaction coordinator may be combined to form a transaction having the ACID properties. Preferably, one or more pre-defined transactions are provided for each of the process flows depicted in FIGS. [0123] 5-7. Thus, for example, the steps occurring between the request and response depicted in FIG. 5 may be combined to form a transaction having ACID properties.
  • In a preferred embodiment, transaction coordinator components interact with the transaction processing monitor via a transaction processing library. To facilitate a flexible architecture whereby the implemented transaction processing monitor may be replaced with an alternate transaction processing monitor, libraries may be written to access transaction-processing-monitor functionality regardless of the particular brand of transaction processing monitor used. [0124]
  • Each of the above-listed transaction processing monitors has certain features that relate to its suitability for incorporation in a transaction coordinator of the present system. For example, TUXEDO transaction process monitors are designed to provide: (1) a high-performance message-passing engine (2) distributed transaction management, allowing clients and servers to participate in a distributed transaction and to manage two-phase commit processes transparently to applications (3) an application to transaction manager interface allowing developers to write BEA TUXEDO applications regardless of the hardware hosting program (4) dynamic workload balancing that automatically generates and manages parallel copies of applications and ensures that they are evenly utilized (5) transaction queuing that allows distributed applications to work together in an asynchronous, connectionless fashion and that prioritizes queues based on message context, content, and time of day (6) data dependent routing that enables transactions to be processed where the data can be most efficiently utilized (7) automatic recovery from application failures, transaction failures, network failures, and node failures in which the server manager restarts the failed process and recovers the failed program by rolling back the transaction that was in progress. [0125]
  • MSMQ transaction processing monitors from Microsoft are designed to provide: (1) full COM component support (2) access from a range of programming languages (e.g. Visual C++, Visual J++) (3) five APIs (open, close, receive, send, and locate) providing advanced message queuing benefits (4) sliding-window protocols, recoverable storage, dynamic routing to deliver messages, and on-time, in-order message delivery (5) the ability to be included within transactions that contain other activities, such as database updates (6) the ability to commit or abort operations with other resources to preserve data integrity during transactions (7) built-in message encryption, integrity, and signature support and (8) administrators the ability to specify which MSMQ events should create an audit record in the Windows NT Security Log. [0126]
  • MSMQ is typically included as a feature of both MS Windows NT Server, Standard Edition 4.0 and MS Windows NT Server, and Enterprise Edition 4.0. If support for more than twenty-five clients, cost-based routing, or the MSMQ Connector is needed, MSMQ is preferably run on NT Server and Enterprise Edition 4.0. It should be noted that although MSMQ is a high-performance message-passing engine, it does not have necessary features of a transaction process monitor, and therefore may not be suitable for use in the present system. [0127]
  • IBM Encina is available from Transarc on many hardware platforms including Sun, IBM, Digital Equipment Corp., Hewlett Packard, and Windows. IBM Encina transaction processing monitors are designed to provide: (1) interoperability to allow the development of distributed transaction processing applications that integrate a wide variety of systems (2) concurrent use of multiple XA-compliant databases or resource managers, such as Oracle, Ingres, Informix, or Sybase through an X/Open XA application programming interface and provide mainframe LU6.2 interoperability, including sync-[0128] level 0, 1, and 2 services, without requiring additional software on the mainframe (3) performance and reliability required by transaction processing applications (4) an efficient, fully-distributed two-phase commit mechanism (5) automatic load balancing and replication of application servers to increase performance and to eliminate single points of failure (6) inherited security mechanisms of the underlying DCE thereby allowing both clients and servers to verify the identities and privileges of participants in a transaction (7) additional security mechanisms, including automated authorization checking and facilities to allow the construction of audit trail records (8) enterprise-wide scalability in order to support large numbers of users and large amounts of data and (9) a centralized administration facility to permit effective management.
  • Top End transaction processing monitors are designed to provide: (1) robust middleware (2) distributed transaction management (3) client/server interaction (4) reliable file transfer (5) dynamic workload balancing (6) recoverable transaction queuing (7) application parallelization (8) two-phase commit processing (9) automatic recovery (10) message-sensitive routing (11) multiple database support (Microsoft SQL Server, Oracle, and Sybase) and (12) Internet application scalability and availability. [0129]
  • In a preferred embodiment, each transaction coordinator in the present system is adapted to provide a plurality of security services including: authentication, authorization, session security, message security, non-repudiation, and auditing. [0130]
  • In a preferred embodiment, the transaction coordinator uses PKIX authentication based on a PKI defined by [0131] root entity 110. Other authentication mechanisms for services outside the present system may be supported as determined by the entity operating the transaction coordinator.
  • In a preferred embodiment, authentication is provided through the use of digital signatures. Authentication may take place at the session level, the message level, or both. [0132]
  • In a preferred embodiment, the secure socket layer protocol provides session level authentication. The secure sockets layer protocol consists of two phases: server-side authentication and optional client-side authentication. A given [0133] transaction coordinator 202 acts as a server when it receives requests from a customer or another transaction coordinator and as a client when it transmits a request to another transaction coordinator.
  • FIG. 9 depicts server-side authentication. A [0134] server 90 receives a request from a client 95 (step 9002), and sends its utility certificate to the client (step 9004). In step 9006, client 95 generates a public key, encrypts it with the server's public key and sends it to server 90 (step 9006). In step 9008, server 90 uses its private key to recover the public key sent by client 95, and authenticates itself to client 95 by returning a message authenticated with the public key received from the client. Subsequent data is encrypted and authenticated with keys derived from the client-generated public key.
  • Secure socket layer server-side authentication allows [0135] client 95 to know with whom it is communicating. Server-side authentication is preferably required for all sessions over which network transactions take place. In order to authenticate server 90, client 95 must possess the public key certificate of the root certificate authority in server 90's utility certificate chain.
  • FIG. 10 depicts optional client-side authentication. In [0136] step 10002, server 90 sends a challenge to client 95. Client 95 authenticates itself to server 90 by signing the challenge with its private key and returning the signed challenge, with its public key certificate, to the server (step 10004).
  • Secure socket layer client-side authentication ensures that [0137] client 95 possesses a valid utility certificate and the accompanying private key. As noted, in a preferred embodiment, secure socket layer client-side authentication is optional but is employed if relying and issuing participants 104 and 102 do not require digitally signed requests from clients 95. Transaction coordinators 202 IP, 202 RP, and 202 R must possess the public key certificate of the root certificate authority in the client's utility certificate chain in order to determine that client 95 holds a valid root certificate.
  • In a preferred embodiment, at the session level, [0138] issuing participant 102 and relying participant 104 authenticate themselves to their customer clients. Issuing participant 102 and relying participant 104 may also require customer clients to authenticate themselves to transaction coordinators 202 IP, 202 RP, and 202 R at the time a session is established. Thus, if client 95 is not an authorized customer of the participant with which it is communicating, the transaction coordinator for that participant may terminate the session before processing a message. Participants may also require customer client-side authentication at the session level in lieu of requiring message level authentication.
  • As noted, authentication between [0139] transaction coordinators 202 IP, 202 RP, and 202 R may occur either at the session level or at the message level, or both. In contrast, relying customers are preferably required to provide authentication at the message level by digitally signing all requests sent to transaction coordinator 202 RP. However, as previously mentioned, a participant may also require relying customers to provide client-side authentication at the session level.
  • FIG. 11 is a composite block/flow diagram illustrating a preferred message authentication process. As will be described, this process operates to authenticate messages (responses or requests) sent to [0140] transaction coordinators 202 by applying a digital signature to data contained in the message.
  • In step [0141] 1102, an authentication module 408 calls hardware security module 218 to verify the signature on a received message using the sender's public key certificate typically sent with the message. In step 1104, authentication module 408 calls hardware security module 206 to check that the sender possesses a valid root warranty certificate by validating the sender's certificate chain, beginning with the root's certificate in the sender's chain. Portions of the sender's chain, such as the sender's public key certificate, are sent with the message. Other portions of the chain may be previously stored in HSM 206 and/or customer database 214, such as the root's certificate.
  • In step [0142] 1106, authentication module 408 calls a time source 11 to obtain the current time and verify that none of the certificates comprising the sender's chain have expired. All participants and root entity 110 are preferably provided with synchronized time sources.
  • In step [0143] 1108, authentication module 408 calls OCSP responder 204 to check that the certificates in the signer's chain, other than those stored in hardware security module 218, have not been revoked.
  • Message authentication provides a stronger level of authentication than session authentication. Session authentication uses utility keys. In general, OCSP checks are not performed on utility keys, therefore neither a client nor a server will learn during the authentication process if an SSL certificate has been revoked. In addition, utility keys are stored unprotected so that anyone in possession of the token on which the key is stored can masquerade as the authorized user. Warranty keys, on the other hand, which are used to provide message authentication, are protected so that merely possessing the token is not sufficient to gain access to the key and masquerade as the authorized user. [0144]
  • In a preferred embodiment, customer authorization check module [0145] 418 (see FIG. 5) checks to make sure the requestor of a service is authorized to receive that service. For purposes of determining authorization, the requestor's identity may be determined from session level authentication or message level authentication. Preferably, customer authorization check module 418 performs an authorization check by extracting the user's authenticated identity or distinguished name from its presented utility or warranty certificate, and comparing this against a list of authorized users in customer database 214. In a preferred embodiment, the customer authorization check may be based on a part of the distinguished name, such as any user with a distinguished name subordinate to the financial institution's certificate authority's distinguished name, or it can be based on the entire distinguished name, such that only specific users are authorized.
  • Customer [0146] authorization check module 418 may perform authorization checks at multiple levels. For example, it may have the capability to allow or deny services at the user level, or to allow or deny services based on finer criteria, such as the amount of collateral a user has.
  • In a preferred embodiment, [0147] transaction coordinators 202 provide session security using a secure socket layer (SSL). SSL typically provide three levels of session security: confidentiality, data integrity, and session authentication. Preferably, all communications to and from transaction coordinators 202 are encrypted using SSL.
  • Message security in the present system is preferably provided through the use of digital signatures. Digital signatures provide two levels of message security: authentication and data integrity. Digital signatures typically provide authentication through the use of protected private keys, which are used for signing messages. [0148]
  • As noted above, digital signatures preferably provide data integrity through the use of a hash or message digest that is generated during the signature process. Message digests provide a “fingerprint” of the data such that if any bit of the signed data is modified, a different “fingerprint” will result and the recipient of the data will not be able to verify the signature. [0149]
  • In a preferred embodiment, confidentiality is provided at the session level for all root communications. The transaction coordinator preferably complies with confidentiality rules specified by [0150] root entity 110.
  • In a preferred embodiment, each [0151] transaction coordinator 202 records all data needed to ensure non-repudiation of a performed service in logs and ensures the integrity of those logs. For example, relying participant 104 preferably provides such non-repudiation for all services it performs for relying customer 108. Thus, for each service performed, transaction coordinator 202 RP not only provides a response to relying customer 108 but also retains all data necessary to ensure that none of the parties involved in performing the service can repudiate having provided the service.
  • In a preferred embodiment, digitally signed messages provide the basis for this non-repudiation. As noted, for example, in the context of the validation service described above, [0152] transaction coordinators 202 maintain a log of all received messages for non-repudiation purposes. Preferably, transaction coordinators 202 log messages exactly as received and do not parse, modify, or store messages in any format other than the format in which they were received. Modification of received messages renders the message's digital signature unverifiable and thus makes the message unsuitable for non-repudiation purposes.
  • In a preferred embodiment, each received message is time stamped as part of the non-repudiation service. Responses are associated with authorization checks performed at a certain point in time. Preferably, the time of the authorization check is a signed attribute in the response and is captured in [0153] raw transaction log 212.
  • In a preferred embodiment, [0154] transaction coordinator 202 also logs information for auditing purposes. Security audit logs may be used to detect potential attacks against the system, such as a suspicious number of requests from non-customers or a suspicious number of invalid signatures. Security audit logs may also assist when a key compromise occurs because a key may be compromised before it is reported and its associated certificate is revoked. The security audit logs may preferably be used to determine if transactions occurred using a compromised key.
  • An audit trail is maintained for purposes of dispute resolution, non-repudiation, and billings. In a preferred embodiment, a transaction coordinator logs every message that it sends or receives and logs the entire message. Messages may be logged in “raw” format. Alternatively, the transaction coordinator may break the message into its constituent parts and store it in a schema such that the entire message can be reconstructed in a manner that preserves the signature. In a preferred embodiment, logs are of such a nature that log entries cannot be falsified (added/deleted/altered) without being detected. In addition, if a transaction coordinator logs a message in raw format, it preferably includes the capability to convert the raw data into a format readable by a COTS solution. This may be a loosely coupled utility or a part of the transaction coordinator functionality that runs as a separate and perhaps lower priority I background process. It may also run on an entirely separate system. The logs may contain other data related to the transport and the session. As an example this may include, sender/recipient IP address, the URL of the post, SMTP header etc. [0155]
  • Transport services component [0156] 306 (shown in FIG. 3) preferably comprises a secure communications component that establishes a secure socket layer session between transaction coordinator 202 and the entity with which it is communicating. In a preferred embodiment, the secure communication component performs session authentication, as described above. Thus, when transaction coordinator 202 acts as a server 90, the secure communications component provides server-side session authentication and may request client-side session authentication. In contrast, when transaction coordinator 202 acts as a client 95, the secure communications component is responsible for authenticating server 90.
  • As a client, [0157] transaction coordinator 202 is also preferably responsible for establishing session security by generating a session key and sending the key, which is encrypted with the server's public key, to the transaction coordinator server with which it wants to communicate. Subsequent communications between the two parties are encrypted with that session key.
  • FIG. 12 is a composite block/flow diagram that depicts a preferred embodiment of the security-relevant flows associated with components of [0158] transaction coordinators 202. As shown in FIG. 12, in step 1202, a request is received by transport services component 306. In step 1204, transport services component 306 delivers the request to request manager 304. Preferably, request manager 304 ensures that all security-related functions are performed on incoming messages before the messages are processed.
  • In step [0159] 1206, request manager calls logging component 320 to log the raw request data. Logging component 320 gathers the data required to support non-repudiation and auditing. As noted above, all requests and responses are preferably logged as received.
  • In step [0160] 1208, request manager 304 determines if a signature on the request is required. In step 1210, if request manager 304 determines that the request does not need to be signed, request manager 304 calls customer authorization check module 54 with the client's utility certificate.
  • In step [0161] 1212, if request manager 304 determines that a signature is required, request manager 304 calls customer authentication module 408. In step 1214, customer authentication module 408 verifies the signature on the request and validates the certificate chain by calling signing component 324.
  • Preferably, [0162] signing component 324 provides message security and supports the session and message authentication services. Signing component 324 interfaces with hardware security module 218, which performs all cryptographic functions. Root 110 preferably specifies the digital signature method that will be used to sign all transactions. Signing component 324 preferably interfaces with hardware security module 218 to perform all cryptographic functions involved in the signature verification process.
  • In step [0163] 1216, customer authentication module 408 checks the status of the customer's warranty certificate by sending a request to OCSP responder 204 via certificate status check component 414, as described above.
  • In step [0164] 1218, customer authentication module 110 calls customer authorization check module 418 with the customer's warranty certificate. In step 1220, customer authorization check module 418 checks customer database 214 to make sure the request came from a customer authorized to obtain the requested service. In step 1222, a response regarding authorization is returned to request manager 304 and processing of system provided services continues as described above.
  • Preferred security requirements for network communications between transaction coordinators and the following entities: customers, OCSP responders, and other transaction coordinators will now be described. These preferred requirements are described in the context of an example in which relying [0165] customer 108 submits a request to relying participant 104.
  • When [0166] transaction coordinator 202 RP of relying participant 104 receives a request from a relying customer 108, transaction coordinator 202 RP authenticates the request. Signatures are typically required on all messages sent to transaction coordinator 202 RP by relying customer 108. In addition, transaction coordinator 202 RP may require relying customer 108 to provide secure socket layer client-side session authentication.
  • Preferably, [0167] transaction coordinator 202 RP provides authentication of all messages it sends to relying customer 108. In addition, transaction coordinator 202 RP provides secure socket layer server-side session authentication when any session is established with relying customer 108.
  • In a preferred embodiment, [0168] transaction coordinator 202 RP performs authorization checks to determine if relying customer 108 is an existing customer of relying participant 104. Transaction coordinator 202 RP may also perform authorization checks to determine if relying customer 108 is authorized to receive the type or level of service being requested. Preferably, relying customer 108 has an entry in customer database 214 RP that lists the services to which it is entitled. Preferably, relying customer 108 is identified by a distinguished name as it exists in its warranty certificate and may also be identified by its distinguished name as it exists in its utility certificate if secure socket layer client-side session authentication is employed. This aspect of the transaction coordinator may be integrated with COTS access control/authorization packages.
  • In a preferred embodiment, transmissions between relying [0169] customer 108 and transaction coordinator 202 RP are encrypted in accordance with specifications specified by root entity 100 and server-side authentication is required.
  • Typically, messages exchanged between relying [0170] customer 108 and transaction coordinator 202 RP are digitally signed. Preferably, transaction coordinator 202 RP verifies all signed messages received, validates the certificate chain, and ensures that the certificates within the chain have not been revoked. In addition, transaction coordinator 202 RP signs all messages it sends to relying customer 108.
  • In a preferred embodiment, [0171] transaction coordinator 202 RP provides a non-repudiation service for relying customer 108. Transaction coordinator 202 RP typically logs all responses relating to requests for service received from any root component. This includes other components of transaction coordinator 202 RP as well as components of other participants and root 110. Preferably, relying participant 104 logs all requests for services from relying customer 108 and all acknowledgments received from relying customer 108 indicating the receipt of a response in order to protect itself from repudiation claims from its customers.
  • In a preferred embodiment, [0172] transaction coordinator 202 RP logs all requests for services from relying customer 108 for auditing purposes. Accordingly, a system administrator can detect potential attacks against the system and determine if requests for services were received after a key compromise occurred. Auditing of requests may also be used to support any billing disputes that may arise.
  • In a preferred embodiment, [0173] transaction coordinators 202 IP, 202 RP, and 202 R communicate respectively with OCSP responders 204 IP, 204 RP, and 204 R only, i.e., OCSP responders that are within their financial institution. To request a response from an OCSP responder 204 at another financial institution, communications must preferably go through the other financial institution's transaction coordinator 202.
  • Preferably, [0174] OCSP responders 204 IP, 204 RP, and 204 R know the identity of the entity from which they are receiving a request and transaction coordinators 202 IP, 202 RP, and 202 R know the identity of the entity from which they are receiving an OCSP response. Preferably, co-located transaction coordinators 202 IP, 202 RP, and 202 R and OCSP responders 204 IP, 204 RP, and 204 R know that they are receiving messages from a local process without any explicit authentication. In this case, neither secure socket layer authentication nor signed requests are required. However, OCSP responders 204 IP, 204 RP, and 204 R may typically sign all responses and transaction coordinators 202 IP, 202 RP, and 202 R may typically accept signed responses in accordance with the Internet PKI OCSP specification.
  • If [0175] transaction coordinators 202 IP, 202 RP, and 202 R and OCSP responders 204 IP, 204 RP, and 204 R are not co-located and cannot ascertain unambiguously with whom they are communicating, authentication between the components is preferably required. Authentication of requests may be either at the session level or the message level. Authentication of responses is preferably at the message level and may be at the session level, as well.
  • It should be recognized that [0176] transaction coordinators 202 IP, 202 RP, and 202 R do not typically perform authorization checks on OCSP responders 204 IP, 204 RP, and 204 R since OCSP responders 204 IP, 204 RP, and 204 R do not typically request services from transaction coordinators 202 IP, 202 RP, and 202 R.
  • Because [0177] OCSP responders 204 are preferably co-located with their respective transaction coordinators 202, transmission security mechanisms do not typically have to be provided for communications between them. Because the two components are contained within a physical environment that is completely under the control of one financial institution, protection can preferably be provided through policy as opposed to implementation of security mechanisms.
  • However, if these components are not co-located, the transmissions are preferably protected against network attacks that could compromise the confidentiality or the integrity of the transmissions. Preferably, SSL is used to provide this protection. [0178]
  • In a preferred embodiment, each [0179] OCSP responder 204 is co-located with its respective transaction coordinator 202 and transaction coordinator 202 therefore need not sign OCSP requests. However, OCSP responder 204 may sign responses if required by specifications specified by root entity 110.
  • In cases where OCSP responses are signed, they are preferably logged with the signature of the responder intact, in particular when the response is directly related to the service being provided. However, if [0180] transaction coordinator 202 has requested an OCSP response as part of an authentication check on a request for service, the OCSP response is typically not logged for non-repudiation purposes. This is because the OCSP check is performed to determine whether or not to process the incoming request, not as part of processing the request itself. Only information relating to the processing of the request is necessary to retain for non-repudiation purposes. In a preferred embodiment, local OCSP responses are typically only logged when relying participant 104 is also issuing participant 102 of the certificate in question and the OCSP request is part of the process for providing a service, e.g., checking the subscribing customer's certificate during a validation request for that certificate.
  • In a preferred embodiment, there are no requirements to log OCSP responses for security auditing purposes because [0181] OCSP responders 204 do not request services of transaction coordinators 202. In addition, there are no requirements to log OCSP requests generated by transaction coordinators 202 for security auditing purposes because transaction coordinator 202 cannot audit itself.
  • Preferably, transaction coordinators authenticate all requests from other transaction coordinators. This is typically accomplished either by secure socket layer client-side authentication or by a financial institution configuring its transaction coordinator to require signatures on all requests from other transaction coordinators. [0182]
  • In a preferred embodiment, a first transaction coordinator that receives a request from a second transaction coordinator performs an authorization check to determine if the requesting transaction coordinator is authorized to make the request. This authorization check is facilitated by providing all authorized [0183] transaction coordinators 202 IP, 202 RP, and 202 R with an entry in the customer database of the transaction coordinator from which they desire to obtain service. If transaction coordinator 202 from whom services are being requested requires a signature, the requestor may preferably be identified by its distinguished name as it exists in its warranty certificate. If not, identification from its utility certificate should preferably be permitted only if secure socket layer client-side authentication is required.
  • Preferably, transmissions between relying [0184] customer 108 and transaction coordinator 202 RP are encrypted and server-side session authentication is required.
  • A participant may require that all requests sent to its transaction coordinator from other transaction coordinators be signed. In lieu of this, a participant may require secure socket layer client-side session authentication. Preferably, [0185] transaction coordinators 202 IP, 202 RP, and 202 R sign all responses being sent to other transaction coordinators.
  • Preferably, [0186] transaction coordinators 202 IP, 202 RP, and 202 R provide a non-repudiation service. To this end, transaction coordinators 202 IP, 202 RP, and 202 R log all responses relating to a request for service received from other transaction coordinators.
  • Preferably, all requests for services received by [0187] transaction coordinators 202 IP, 202 RP, and 202 R will be logged for auditing purposes. This enables a system administrator to detect potential attacks against the system and also enables the system administrator to determine if requests for services were received after a key compromise occurred. Auditing of requests may also be used to support any billing disputes that may arise.
  • Preferred architectural components of a transaction coordinator are now discussed in greater detail. [0188]
  • Components of a transaction coordinator are preferably implemented as customized software code although other software products may be used as described herein. In addition to this code, a participant may write and implement its own additional service modules. Thus, participants may implement their own business specific rules for the certificate status check service described above and other services that may be offered via the four-corner model. [0189]
  • In a preferred embodiment, a customer software development kit is used as a tool-set to facilitate the interface between [0190] transaction coordinator 202 and customers or other transaction coordinators. The software development kit is preferably integrated with transport services component 306. The software development kit is preferably adapted to intercept all hyper-text transfer protocol requests destined for an application's original web server at a web site maintained by relying customer 108. The software development kit preferably determines whether the message needs to be signed based on a defined set of rules. The customer software development kit also authenticates signatures and public key certificates with the help of hardware security module 230. A preferred embodiment of one such SDK is described in copending U.S. patent application Ser. No. 09/657,604, filed Sep. 8, 2000, entitled System and Method for Facilitating Access By Sellers to Certificate-Related and Other Services, which is hereby incorporated by reference.
  • Depending upon the breadth of the features provided by the software development kit, its usage may preferably be expanded to other areas of transaction coordinator operation. Certain modifications and additional functionality are typically required in order for the software development kit to be used within the transaction coordinator. [0191]
  • A Microsoft™ SQL server may preferably be used as the database for storing billing data. Preferably, [0192] transaction coordinator 202 is adapted to interact with the server via a database library. Alternatively, interaction with the server may be done using JAVA™ Database Connectivity if the transaction coordinator development is done in JAVA™. In addition, database libraries may be written for other servers thereby permitting the replacement of a Microsoft SQL server by another database without impacting transaction coordinator 202.
  • Preferably, Microsoft's MS SQL Server provides the following features and functionality: (1) Online Analytical Processing (OLAP) Services to efficiently analyze complex information essential to reporting, data analysis, decision support, and data modeling (2) on-disk storage architecture (3) a Multiphase Query Optimizer (4) auto statistics to enable the query optimizer to use the latest information and to increase query efficiency (5) active backup to provide high performance online backup with minimal impact on operational systems (6) merge replication to allow users to work independently, then combine their work later (7) built-in priority-based conflict resolution to resolve merge conflicts (8) ability to publish data on the Web (9) a data transformation service to simplify the process of importing and transforming data from multiple, heterogeneous sources (10) ability to check physical and logical database consistency (11) dynamic row-level locking (17) a query optimizer that manages statistics gathering and guaranteeing an efficient plan (13) an intra-query parallel execution of a single query across multiple processors to improve performance; steps in a single query are executed in parallel thereby delivering an optimum response time (14) a redesigned query processor to better support the large databases and complex queries found in decision support, data warehousing, and Online Analytical Processing applications (15) sort speed (16) multiple triggers per table and direct recursion of triggers (17) dynamic memory to optimize memory allocation and usage and dynamic memory management (18) parallel backup and the ability to restore utilities scale at device speeds (19) smart read-ahead logic to improve performance and to eliminate the need for manual tuning and (20) run-time checks of critical structures. [0193]
  • Preferably, adequate data is captured and stored to allow the entity that maintains a transaction coordinator to generate billing invoices on a per transaction basis. To this end, in a preferred embodiment, each and every incoming and outgoing message generated by a transaction coordinator, in its entirety, is stored in successive records in a database. Such messages include: all requests received, all requests made, all responses generated, and all responses received. This ensures availability of all the necessary data to generate invoices on a per transaction basis. [0194]
  • Preferably, [0195] transaction coordinator 202 records billing data in a centralized general fashion. Participants may obtain records by writing their own routines to extract the billing data relevant to the participant from the centralized billing data. In addition to providing data in the database, data may also be provided in EXCEL™ spreadsheets.
  • In a preferred embodiment, TymeServe Network Time Server (“TYMSYNC”)™ by Datum Inc. is used as the transaction coordinator's time stamping component. TYMSYNC is a time synchronization package that acquires time from the Global Positioning System Navstar satellite constellation with absolute accuracy to the nearest microsecond relative to the Universal Time Coordinator as maintained by the United States Naval Observatory. This product may be adapted to synchronize workstations in TCP/IP (transmission control protocol over internet protocol) and LAN (local area network) networks. Preferably, time is distributed within the network using the Network Time Protocol. TYMSYNC may be configured to continuously synchronize a computer system's clock to the Universal Time Coordinator. The times when requests and responses are generated and when messages are received and sent are preferably stored for non-repudiation and auditing purposes. [0196]
  • In a preferred embodiment, all communications with [0197] transaction coordinator 202 are conducted over secure connections. Preferably, the secure socket layer encryption scheme for synchronous communications is used. Secure socket layers are used in a fashion compatible with commercial/web server implementations and provide security and privacy over electronic networks such as the Internet. Secure socket layers are application independent, thereby allowing protocols to be layered transparently on top of them.
  • Secure socket layers provide confidentiality, data integrity, and authentication for all network communications. Secure socket layers typically ensure confidentiality by encrypting all data being passed between the communicating entities. When a secure socket layer-enabled [0198] client 95 and server 90 first communicate, they agree on a protocol version and select encryption algorithms. Preferably, network endorsed encryption algorithms and key lengths are specified by root entity 110.
  • Secure socket layers also typically ensure data integrity through the use of encryption. If a message does not decrypt correctly, the recipient can tell that someone has tampered with the message. [0199]
  • Secure sockets layers also support server and client authentication, negotiate encryption keys, and authenticate the server before data is exchanged by the higher-level application. Authentication is preferably provided through the use of digital signatures and public key certificates, which are exchanged at the time an electronic communication session is first established. [0200]
  • In a preferred embodiment, each transaction coordinator is capable of accepting and sending messages over the public Internet using SMTP to send S/MIME messages and communicating via the HTTP protocol over an SSLv3 connection (HTTPS). In other words, each transaction coordinator is preferably adapted to support the following two modes of communication: [0201]
  • HTTP over Secure Sockets Layer (SSLv3) - For synchronous communications (i.e. HTTPS). HTTPS is a hypertext transfer protocol that incorporates secure sockets layer between Web servers and Web browsers in order to transfer Web pages securely. Use of HTTP keep alive is recommended. [0202]
  • S/MIME v2 - For asynchronous communication using SMTP. [0203]
  • In a preferred embodiment, each transaction coordinator acts as an HTTPS server during communications with the relying customer and as an HTTPS client when it makes a request to a transaction coordinator at another financial institution. In either mode, all SSL communication for credential status checking may employ only server authentication. [0204]
  • In a preferred embodiment, each transaction coordinator may accept messages delivered via other transport protocols (e.g., IIOP) approved by [0205] root entity 110. In addition, participants may implement other transport protocols locally by arrangement. In the absence of prior agreement, however, only HTTPS support should be assumed.
  • In a preferred embodiment, Valicert's™ OCSP responder is used for certificate [0206] status check service 312. However, access to OCSP responder 204 may be achieved using libraries. Thus, by writing new libraries, new OCSP responder vendors may be implemented.
  • Preferably, [0207] OCSP responder 204 determines certificate status without using a certificate revocation list. OCSP responder 204 may move most of the processing involved to a certificate authority, a component that issues, verifies, and revokes certificates, and eliminate the need to download potentially large certificate revocation lists. Alternatively, these functionalities may be divided among different components which may be provided with separate signing keys. For example, the function of issuing certificates may be separated from the revocation function, and components for performing these functions may be provided with separate signing keys.
  • In a preferred embodiment, a hardware security module is used as a signing component. The hardware security module is preferably a high-speed device for signing and verifying signatures. The hardware security module is typically a networked hardware device that provides cryptographic services to authenticated entities. A suitable hardware security module is manufactured by NCipher. [0208]
  • In a preferred embodiment, [0209] transaction coordinator 202 is always available to process requests during its normal operating times, which may be twenty-four hours a day seven days a week. To make sure the system meets availability requirements, a detailed requirement analysis of system-availability should be conducted. Because different participants may have different requirements, many different types of failures may occur. As is known, many different hardware and software vendors offer different options for high-availability systems. However, these options may or may not be available for the hardware and software that is chosen by a given financial institution.
  • There are a number of known potential hardware failures that may affect a transaction coordinator. For example, the power supply to the server may fail. Preferably, a multiple redundant hot-swap power supply automatically swaps to a redundant power supply. If the server fails or crashes, the transaction coordinator preferably provides for high availability clustering for automatic fail over. In addition, the transaction coordinator preferably comprises a self re-start capability for automatically rebooting the server in the event of a network operating system (NOS) hang. [0210]
  • The transaction coordinator also preferably comprises multiple redundant hot-swap disk drives and a disk array controller to handle disk failure or crashes. The transaction coordinator also comprises a network interface to provide support for redundant network interface cards (NICs) in the event of NIC failure. In the event of cooling system failure, the transaction coordinator preferably uses redundant hot-swap cooling systems comprising hot swappable redundant fans which are individually removable. The transaction coordinator also preferably comprises an Intelligent Platform Management Interface to detect hardware and software failures. The Intelligent Platform Management Interface is an open specification which simplifies and standardizes communications for device management. In the event of memory corruption, the transaction preferably uses self-correcting memory. The self-correcting memory is preferably a managed error checking and correcting system memory and cache memory. [0211]
  • In the event of application crashes, [0212] transaction coordinator 202 preferably uses transaction processing monitoring to restart the application. The transaction coordinator may also run redundant copies of an application and the transaction process monitor may transfer transactions to the redundant copies. Certain application availability features may require that the application to be coded in a specific way which may also help address application crashes.
  • In the event of an operating system crash, transactions are preferably transferred to a standby machine that is supported by the network. Directory services, including middleware like CORBA, may also be used to re-direct any new transaction requests to the new machine. [0213]
  • In addition to the hardware and the software availability products, a monitoring infrastructure is preferably used to monitor the applications and the network. [0214]
  • In a preferred embodiment, a software monitoring tool (such as Trivoli) is used to monitor applications. This tool is preferably configured to page the administrator in the event of application failure. A network monitoring system (such as that made by NetView) may also be used to allow administrators to monitor the network. [0215]
  • Preferably, custom written application daemons are used to simulate transactions. If these transactions fail, system administrators may be informed. Also, database vendor tools may be used for database monitoring. Most databases provide database-monitoring tools that detect deadlocks and other databases problems. [0216]
  • A distribution approach for the transaction coordinator may preferably be defined that is a function of what [0217] root entity 110 wishes to distribute to participants. Application distribution may typically be performed via Web-download from root entity 110. The Web-download mechanism may provide for selective download, authentication, and tracking.
  • In a preferred embodiment, the transaction coordinator may be adapted to support integration with existing operational systems such as CICS, IMS and other legacy systems. [0218]
  • Participants may choose to use the entire transaction coordinator architecture and functionality described above, or may instead choose to use components of the transaction coordinator and add their own implementations to those components. The Web-download approach is preferably configured to fulfill the varying requirements of participants. The download mechanism preferably provides at least three download options: (1) a download transaction coordinator executable option (2) a source code or binaries of the transaction coordinator option and (3) a source code of transaction coordinator classes option. [0219]
  • The first option preferably accommodates participants that choose to use the transaction coordinator in its entirety. This option provides options for different platforms. The second option preferably accommodates participants that choose to plug components of the transaction coordinator described above into their own implementations. This download mechanism also provides options for different platforms. The third option preferably accommodates financial institutions that opt for heavy-duty development and choose only to use certain pieces of implementation of the transaction coordinator described above. [0220]
  • Preferably, the download mechanism allows financial institutions to not only download the executable, but also the source code. Because the downloaded executable may be used on its own and the source code may be used to develop other custom applications, [0221] root entity 110 preferably provides download access only to those institutions that are trusted partners with root entity 110 and hence are authorized to use the transaction coordinator. Preferably, this is achieved via an authentication/authorization process.
  • [0222] Root entity 110 may preferably track which participants download particular components of the transaction coordinator. This way root entity 110 may determine the versions of the transaction coordinator and/or its components that are being used at any given time. Root entity 110 may use this information to (1) charge a fee from the financial institutions for the downloaded component(s) and to (2) track versions of the transaction coordinator for maintenance purposes.
  • Preferably, the transaction coordinator is adapted to be scalable to accommodate a growing user base without significant performance degradation. One step in fulfilling the scalability requirements for an application is to forecast the potential growth in the user base. In general, an application with a distributed architecture facilitates higher scalability by allowing distributed multiple instances of heavily loaded components to be running at a given time. The transaction coordinator architecture is preferably a distributed one and, therefore, supports scalability. In addition, the load-capacity of the transaction coordinator is preferably base-lined on a chosen development machine. This information is used to select appropriate hardware to support the anticipated number of transactions. Preferably, the transaction coordinator (and OCSP responder) are adapted to reliably handle up to 1000 validation transactions per minute. [0223]
  • As noted above, OCSP checks are typically not performed on utility certificates. If signatures are not required on requests, there is no mechanism in place to ensure that the secure socket layer client-side certificates have not been revoked. Preferably, if a secure socket layer certificate has been revoked, financial institutions are informed out of band (e.g., a broadcast message) and the affected users are removed from the participant's customer database. [0224]
  • Each transaction coordinator typically trusts some set of certificates that are stored on its hardware security module. No OCSP checks are performed on these certificates. If a revoked certificate exists on a hardware security module, it will not be detected during on-line processing. Preferably, financial institutions are notified if a certificate stored on a hardware security module has been revoked so that they can remove the certificate from the hardware security module. [0225]
  • Transaction coordinators, when acting as clients, authenticate servers with whom they are communicating. But this check typically only guarantees that the server has a certificate that was issued by a certificate authority that the transaction coordinator trusts. There are no checks regarding the identity or status of the server itself. In a preferred embodiment, the transaction coordinator checks servers against a list of trusted servers and performs OCSP checks of the server's certificate. However, since there is little to be gained by a server intercepting requests, the degradation of performance resulting from these additional checks is typically not warranted. [0226]
  • Typically, the transaction coordinator does not have automated processes for detecting potential attacks. Preferably, system and security administrators inspect audit logs periodically in order to identify such potential attacks. [0227]
  • Typically, requests that do not pass a secure socket layer client-side authentication check are not logged. If an attack (e.g., a denial of service attack) occurs at this level, there are no logs to reference. [0228]
  • In a preferred embodiment, the transaction coordinator is protected by a firewall. Preferably, the firewall component maintains logs of incoming requests. [0229]
  • The transaction coordinator is preferably provided with automated intrusion detection mechanisms. These processes typically watch incoming traffic or scan audit logs looking for suspicious activity, and take appropriate actions if necessary. [0230]
  • The transaction coordinator preferably maintains logs for non-repudiation purposes. Often, however, the system will not include functions to assist a user in retrieving the data necessary to support non-repudiation. The user manually searches through the logs to find all the supporting data. In other embodiments, automated non-repudiation tools may be used to assist the user in this process. [0231]
  • In a preferred embodiment, transaction coordinators and OCSP responders employ normal Internet time out values for certificate status check requests. For other services, the time out value may be set as appropriate for the service. In a preferred embodiment, timeout values are configurable in the transaction coordinator. [0232]
  • The following discussion outlines a possible hardware and software implementation for a transaction coordinator. [0233]
  • The main server used for the transaction coordinator may be a Hewlett Packard Netserver LH4. Preferably, the server has the following specifications: 4 P2-450 MHZ processors, 512-768MB RAM, 40-60 GB HD with Raid 5 Array, UPS, and an external DLT 40E DLT 4000 tape drive for tape backup. Preferably, at least five workstations are used each having the following specifications: P2400 MHz processors, 128 MB RAM, and 6 GB HD. [0234]
  • The transaction coordinator is preferably platform independent so that it can be supported on servers based on Microsoft Windows NT 4.0/2000, Sun Solaris, and Hewlett Packard HP-UX. Implementation is preferably done in JAVA however some coding may be done in C/C++ as well. [0235]
  • A Windows NT Server w/Service Pack 3 may be used as the operating system. Microsoft Visual SourceSafe 6.0 may be used for source control. Visual Café Professional Edition 3.0 from Symantec (Java Version 1.2) may be used for development. SSL/J SDK from RSA Security Systems may be used for secure socket layer implementation and is also required by XETI's JKIX. [0236]
  • For signature verification, nCipher's hardware security module may be used. For signatures from subscribing customers, Datakey smart cards may be used. Preferably, OCSP responders are provided with a toolkit that provides an interface to cryptographic functions and for ASN.1 Communication. In a preferred embodiment, XETI's JKIX may be used for this purpose. [0237]
  • For digital time stamping, Datum's TYMSYNC or other trusted time source may be used. An MS SQL Server may be used for the databases described above. Code Warrier from Metro Works may be used for the development of portable C/C++ development. CodeIntegrity may be used to perform code integrity checks to verify code portability. [0238]
  • Typically, the size of the data that is passed between different entities is instrumental in the performance of a public key infrastructure system. Messages submitted between entities are therefore preferably analyzed to estimate the size of the data that is transmitted. The analysis may be done on the basis of the certificate fields defined in RFC2459 along with specific root extensions. [0239]
  • The exact data lengths of the certificate fields, which have a fixed length, are preferably taken into account during the estimation. However, there are many fields for which the length varies. For these fields, a liberal estimate on the size is preferably made (i.e., larger rather than smaller). Also, estimates of overall message size preferably include the sizes for all extensions, i.e., if a message allows five different extensions, the size is preferably calculated on an assumption that all five extensions are being sent with the request. [0240]
  • FIG. 13 depicts the different message (estimated) sizes passed between system entities in a preferred embodiment. As shown in FIG. 13, the total estimated message size of messages passed from subscribing [0241] customer 106 to relying customer 108 is 2610 bytes. The message typically comprises two certificates, each 1146 bytes, the issuing participant's certificate signed by root entity 110, 128 bytes, the issuing participant's signature, 128 bytes, and an HTTP header, 62 bytes.
  • The total estimated message size of messages passed from relying [0242] customer 108 to relying participant 104 is 2022 bytes. The message typically comprises two requests, one concerning the subscribing customer's certificate and one concerning the issuing participant's certificate, each 55 bytes, a message extension, 210 bytes, a version number, 4 bytes, the relying participant's name, 132 bytes, the relying participant's signature, 128 bytes, the relying customer's certificate, 1146 bytes, and an HTTP header, 62 bytes.
  • The total estimated message size of messages passed from relying [0243] participant 104 to issuing participant 102 is 1601 bytes. The message typically comprises a request concerning the subscribing customer's certificate or the issuing participant's certificate, 55 bytes, a message extension, 210 bytes, the root entity's signature on the relying participant's transaction coordinator certificate, 128 bytes, the relying participant's transaction coordinator certificate, 1146 bytes, and an HTTP header, 62 bytes.
  • The total estimated message size of messages passed from issuing [0244] participant 102 to relying participant 104 is 2086 bytes. The message typically comprises a response concerning either the subscribing customer's certificate or the issuing participant's certificate, 456 bytes, a message extension, 294 bytes, the issuing participant's certificate, 1146 bytes, the root entity's signature, 128 bytes, and an HTTP header, 62 bytes.
  • The total estimated message size of messages passed from relying [0245] participant 104 to relying customer 108 is 2213 bytes. The message typically comprises a response concerning the subscribing customer's certificate or the issuing participant's certificate, 55 bytes, a message extension, 210 bytes, the response from the relying participant's transaction coordinator, 127 bytes, the relying participant's transaction coordinator certificate, 1146 bytes, the root entity's signature on the relying participant transaction coordinator's certificate, 128 bytes, and an HTTP header 62 bytes.
  • The detail on message size estimation of different fields is depicted in the table below. Typically, the size of message being passed between the entities is between 2K and 3K. Once the transaction volume has been projected, this information is preferably used to estimate the network load. [0246]
    Certificate Size - No Extensions or Root Specific instructions
    Size (in
    Certificate { Bytes) Size Calculation Comment
    TbsCertificate {
    Version Integer 4
    Serial Number 4
    Integer
    signature {
    Algorithm Object Identifier 11
    Parameters Defined by 32 Signature algorithm parameters are usually NULL but since
    Algorithm parameters are allowed, 32 bytes have been assigned for it
    }
    issuer Name 132 This is a higher estimate -- approximated for 4 names.
    Name is defined as sequence of Relative Distinguished
    Name
    validity {
    notBefore {
    utcTime UTCTime 32
    generalTime GeneralizedTime 32
    }
    notAfter {
    utcTime UTCTime 32
    generalTime GeneralizedTime 32
    }
    }
    subject Name 132 This is a higher estimate - approximated for 4 names. Name
    is defined sequence of Relative Distinguished Names
    subjectPublicKeyInfo {
    algorithm {
    Algorithm Object Identifier 11
    Parameters Defined by 32 Signature algorithm parameters are usually NULL but since
    parameters are allowed, 32 bytes have been assigned for it
    }
    subjectPublicKey BIT STRING 128
    }
    issuerUniqueID BIT STRING 132 This is higher estimate. Usually if Issuer is defined,
    issuerUniqueID should not be used
    subjectUniqueID BIT STRING 132 This is higher estimate. Usually if Subject is defined,
    subject UniqueID should not be used
    extensions {
    extnID Object Identifier 0 Certificate is being estimated without any extensions.
    extnID would take 11 bytes.
    critical BOOLEAN 0 BOOLEAN would take 4 bytes
    extnValue OCTET STRING 0 Will depend upon the extension
    }
    }
    signatureAlgorithm {
    algorithm Object Identifier 11
    parameters Defined by 32
    Algorithm
    }
    Signature Value BIT STRING 128 This may vary from signer to signer When signed by root,
    the sire will be 256 when signed by the root
    }
    Total 985
  • Certificate Extension - with Root Instructions and Extensions [0247]
    Size (in
    Certificate Extensions/root entry Specific Instructions Bytes) Size Calculation Comments
    Must not contain Issuer Unique ID −132
    Must not contain Subject Unique ID −132
    Contain a Subject DN 0 Already present in certificate
    Extension subjectAltNames is supported as e-mail 47 Consists of a number of GeneralNames - root entity will
    support only rfc822 - email address - estimated at 32 bytes
    + 11 bytes for extnID and 4 bytes for critical flag
    Extension KeyUsage should appear in all Certificates 17 2 bytes for the bit string + 15 for extension parameters
    Extended Key usage should appear when appropriate 65 Consists of OID. Estimated at 5 OID = 55 Bytes + 15 for
    extension parameters
    Certificate Policies should be present with OID 26 11 bytes for root entity OID + 15 for extension parameters
    Basic Constraints should be present 19 4 bytes for the Boolean + 0 bytes for the path since path is
    not being used + 15 bytes for extension parameters
    Subject Key ID should be present 35 20 bytes based on 160-bit SHA-1 hash + 15 bytes for
    extension parameters
    Authority Key ID should be present 103 20 bytes for the hash + 64 for the General Name-
    assumption that it could be URI + 52 + 4 for serial + 15 for
    extension parameters
    Must not contain Name Constraint 0 0
    Must not contain Policy Constraint 0 0
    AlA must be used for OCSP and RM 90 64 bytes for general name + 11 bytes for OID + 15 for
    extension parameters
    Extension - Subscriber Information 55 20 bytes for warranty account + 20 bytes for
    device id + 15 bytes for extension parameters
    Total 193
  • OCSP Request - with Root Instructions & Extensions [0248]
    Size (in
    OCSPRequest{ Bytes) Size Calculation Comments
    TbsRequest {
    Version Integer 4
    RequestorName Name 132
    Request { The Request structure repeats for each request in a
    particular OCSP request.
    ReqCert {
    CertID {
    HastAlgorithm {
    Algorithm OID 11
    Parameters Defined by 0 Estimated as 0 since no parameters passed on the
    Algorithm implementation.
    }
    }
    IssuerNameHash 20
    IssuerKeyHash 20
    SerialNumber 4
    }  }  }  }
    Total (Without Extensions) 191
    RequestExtensions {
    Nonce {
    OID 11
    Nonce Value 24 No requirements have been imposed on Nonce Value.
    Estimated at 24 bytes
    }
    ServiceLocator {
    IssuerName 132
    AIA 32
    OID 11
    }    }
    Total (With Extensions) 401
  • OCSP Response - with Root Instructions & Extensions [0249]
    Size (in
    OCSPResponse{ Bytes) Size Calculation Comments
    ResponseStatus {
    ResponseBytes
    ResponseType OID
    11
    Response 32
    }
    BasicOCSPResponse {
    TbsResponseData {
    Version Integer 4
    ResponderID Name 132
    ProucedAT GeneralizedTime 32
    }
    Responses   { Repeated for each response
    CertID {
    Algorithm {
    algorithm OID 22
    parameters Defined by 0
    Algorithm
    }
    issuerNameHash 20
    issuerKeyHash 20
    serialNumber 4
    }
    CertStatus 8
    ThisUpdate 32
    NextUpdate 0 Not to be used in root entity Responses
    }
    SignatureAlgorithm {
    Algorithm {
    algorithm 11
    Parameters 0
    }
    } 0
    Signature Value 128
    }
    Total (Without Extensions) 456
    ResponseExtensions {
    Nonce {
    OID 11
    Nonce Value 24
    }
    CRLEntryExtension {
    Reason OID 11
    ReasonCd Enum 4
    HoldInstructsonCd OID 11
    HoldInstruction OID 11
    InvalidityDate GeneralizedTime 32
    CertificateIssuer OID 11
    CertificateIssuerName Name 132
    }
    CRLReason {
    Reason OID 11
    ReasonCd Enum 4
    Time GeneralizedTime 32
    }
    Total (With Extensions) 750
  • Valid request and response times for OCSP transactions and warranty transactions and confirmation times for all transactions are preferably specified by [0250] root entity 110. The following section describes preferred performance targets for the transaction coordinator. The response times noted refer specifically to the system response time. Preferably, lapsed timeframes in which manual processes are completed (noting the need for verification and requesting it, filing claims, etc.) are also established.
  • Preferably, the validation request and response time (i.e., OCSP) is ten seconds or less for all response time transactions within the root control infrastructure. Validation outside the root infrastructure (from customer to customer or customer to root) preferably does not exceed sixty seconds. The total round-trip time preferably does not exceed seventy seconds. Preferably the response time includes latency on the Internet. The end-to-end response time preferably includes the longest validation path (i.e. subscribing customer to relying customer to relying participant to issuing participant to root entity). [0251]
  • An illustrative performance requirement maybe as follows: No more than 6 seconds between the post of a certificate status check to a relying participant's transaction coordinator and receipt of a response and no more than 3 seconds to turn around a response to a certificate status check where the data for the response is locally available in a case where caching is in effect, proof of freshness (i.e., including status of participant certificates in messages transmitted by the participant) is in effect, a certificate chain of two certificates is being validated, the transaction is a four-corner transaction, and the system entities are connected to a 10 Mbps LAN (rather than the Internet). [0252]
  • The warranty request response time includes offline transactions. Preferably, these offline transactions do not exceed an eight hour window starting at the end of a business day. [0253]
  • The response time for response to notification of lost, compromised, or invalid certificates preferably includes offline transactions. Preferably, these offline transaction do not exceed one hour. [0254]
  • The revocation of certificates also preferably includes offline transactions. Preferably, these offline transactions do not exceed one hour. [0255]
  • The transaction coordinator also preferably provides confirmation of transactions. Online transaction requests preferably receive status confirmation, including incomplete request or response, within seventy seconds. The transaction coordinator also preferably provides a method of storing for retrieval incomplete transaction requests or responses, a receipt of request status, an incomplete request response, and transaction queuing for incomplete transaction. [0256]
  • The transaction coordinator also preferably comprises transaction recovery requirements. Appropriate system resource allocation preferably allows for transaction roll-back. [0257]
  • The transaction coordinator also preferably provides system fail-over requirements. In a preferred embodiment, the transaction coordinator is provided with system redundancy, system/hot back-up, and redundancy within the public Internet. [0258]
  • During the development of the transaction coordinator, a performance baseline in the development environment is preferably established. This base-line information is used to improve the performance of the application components on the development machine itself. However, to achieve a preferred target performance, appropriate production hardware capable of supporting the anticipated number of transactions and a network with appropriate band-width are typically put in place. [0259]
  • The following sections discuss preferred tuning strategies for higher performance of the transaction coordinator. [0260]
  • It may be possible to reduce the size of messages being passed between entities by eliminating some or all of the certificates sent with each message. Typically the recipient of a message knows the identity of the sender (i.e., his distinguished name as it appears in his warranty certificate) and has access to his full certification path. Many of the needed certificates are also available from local repositories. [0261]
  • OCSP checks performed as part of the authentication process may be eliminated if the customer database is designed to reflect revoked certificates and if authorization checks are performed against a user's distinguished name and certificate, as opposed to just its distinguished name. [0262]
  • In a preferred embodiment described above, the transaction coordinator stores raw transaction data and then parses the data to separately store a subset of the data for billing purposes. Alternatively, however, this function may be offloaded to an off-line process that monitors the raw transaction database and extracts relevant billing data from the data stored in the database. [0263]
  • Co-locating the transaction coordinator and OCSP responder eliminates the need to sign and verify requests and to establish secure socket layer connections between these components. [0264]
  • Using secure socket layer between financial institutions and during communications with [0265] root entity 110 typically eliminates the need to digitally sign each request message. However, digitally signed requests provide a higher degree of security. Each participant may preferably assess the risks involved with trading off security for performance.
  • Caching OCSP responses typically improves the turnaround time by reducing the time it takes to send and receive an OCSP request to the root entity. In a preferred embodiment, verification of OCSP responses is performed as the data is put into the cache as opposed to performing verification as part of the on-line transaction processing. [0266]
  • In a preferred embodiment, a transaction coordinator may cache validity responses and use the cached responses to validate credentials. The period for which a response may be cached is preferably set as a policy matter by [0267] root entity 110. This period may preferably be within the 4 to 5 minute range.
  • If a transaction coordinator implements the ability to used cached responses it is preferably adapted to log their use for billing and audit as well as non-repudiation purposes. The logged information preferably indicates that a cached response was used to validate a credential rather than a freshly acquired response. [0268]
  • For high value transactions, a client application may prefer the use of a fresh response rather than a cached response. Accordingly, in a preferred embodiment, transaction coordinators preferably get and use a freshly acquired validity response on explicit request to use a fresh response rather than a cached response. [0269]
  • In a preferred embodiment, the recipient of a response checks the status of the responder's certificate. Alternatively, to eliminate this second request, the transaction coordinator may automatically include the status of its certificate (as signed by the root) whenever it sends a response to either a relying customer or to another transaction coordinator. [0270]
  • The following section discusses testing of the transaction coordinator. Preferably, the transaction coordinator is tested for the items listed in this section. [0271]
  • In order to provide architectural flexibility, the transaction coordinator is preferably ported to more than one hardware platform (e.g. Microsoft Windows NT 4.0/2000, Sun Solaris and Hewlett Packard HP-UX). This allows participants to choose their own hardware platform from the list of the supported platforms. Tests are preferably performed to ensure that the transaction coordinator is installed smoothly on each of the supported platforms. To enable such testing appropriate hardware is typically required. [0272]
  • Tests are preferably performed to ensure that the transaction coordinator may be installed and uninstalled on a clean Windows NT Machine. [0273]
  • If the transaction coordinator is extended to support other operating systems, tests are preferably performed to ensure that the executable derived from the same source code can be installed on all of the supported operating systems. Appropriate hardware with appropriate operating systems may be required to perform these tests. [0274]
  • Preferably, the transaction coordinator interfaces with other third party vendors' software tools. The interfaces to these software tools are preferably tested on the development site during development and system test phase. In addition, elaborate testing is typically done at the customer site to ensure that the transaction coordinator interface with these tools is stable. This may be done during customer/functionality testing, described below. [0275]
  • The functionality of the transaction coordinator is preferably tested during development and system test phases. During these tests, appropriate tools are used to ensure that all of the custom written code is exercised at least once. In a another preferred testing phase, customers test the functionality of the transaction coordinator. [0276]
  • Security is a critical piece of the transaction coordinator. Preferably, testing is done to ensure that data is transferred securely from one point to another. Test cases are preferably created to exhaustively test the security aspect of the public key infrastructure. [0277]
  • A messaging protocol definition for messages transmitted within [0278] system 200 and a certificate status protocol definition for system 200 are described in copending U.S. provisional patent application serial No. 60/231,319, filed Sep. 8, 2000, entitled Transaction Coordinator Certificate Status Check (CSC) Protocol Definition, Transaction Coordinator Messaging Protocol Definition, and Transaction Coordinator Requirements, which is hereby incorporated by reference. In a preferred embodiment, each transaction coordinator supports this messaging protocol definition. Specifically, each transaction coordinator accepts and routes all valid XML messages as defined in the messaging protocol definition, logs and reports ill-formed messages, and is able to generate valid XML messages in response to requests.
  • In an alternative embodiment, the system may instead be implemented as an OCSP centric model that does not employ [0279] transaction coordinators 202. This alternative embodiment employs enhanced OCSP responders adapted to provide significantly more functionality than normally provided by a typical OCSP responder. In particular, the enhanced OCSP responder is adapted to provide the following additional functionality:
  • Encrypted communication using SSL. [0280]
  • Logging of raw transactions for both requests and responses. [0281]
  • Providing of certificate chains with responses. [0282]
  • Verification of signatures on requests preferably using an HSM. [0283]
  • Validation of certificate chains accompanying requests (parts of which may be stored in a local database or on an HSM). [0284]
  • Creation of new requests based on: [0285]
  • A value in a service locator request extension of a received request. [0286]
  • An authority information-access extension in the certificate accompanying a response. [0287]
  • Suspension of processing on a request until responses are received on these other newly created requests, i.e., ability to synchronize responses to requests. [0288]
  • Forwarding of responses, when appropriate. [0289]
  • This alternative embodiment provides only portions of the certificate status check service without providing the flexibility of adding new services. Also, billing is not implemented in this alternative embodiment. In addition, this alternative embodiment may cause vendor locking. A detailed list of the pros and cons of this alternative embodiment is provided below. [0290]
  • FIG. 14 depicts the transaction flows for this alternative embodiment. The message flows in FIG. 14 are summarized in the following table: [0291]
     1 The Subscribing Customer (SC) sends signed data, the signature, the SC and the IP
    certificates (and optionally CSSD) to the Relying Customer (RC).
     2 The RC verifies the signature on the data sent by the SC and validates the SC's
    certificate chain and then creates an OCSP request containing the SC certificate serial
    number. This data is sent to the USM for signature.
     3 The OCSP request for the SC's certificate, signed by the RC is sent to the Relying
    Participant (RP) OCSP Responder (OR) along with the RC's certificate chain. The
    entire certificate chain must be passed with the message.
     4 The RP OCSP Responder logs the request in its OCSP log. The RP OCSP
    Responder verifies the signature on the request and validates the RC's certificate
    chain. All verification if performed is software. The entire chain (including the root)
    must be passed with the message in order for verification of the signature/certificate
    chain to be performed. No checks are performed to ensure that the RC's certificate
    has not been revoked.
     5 The RP OCSP Responder creates a new request, containing the single request
    received from the RC, and signs it using its HSM. Signed requests between financial
    institutions are not required. Instead, the root entity (ROOT) may require SSL client-
    side authentication in which case the verification/validation/customer look up is
    based on the certificates associated with the SSL connection.
     6 The RP OCSP Responder sends the signed OCSP request to the appropriate Issuing
    Participant's OCSP Responder based on the value in the Service Locator request
    extension of the received request.
     7 The IP OCSP Responder logs the request in its OCSP log. The IP OCSP Responder
    verifies the signature on the request and validates the RP OR's certificate chain. All
    verification if performed in software. The entire chain (including the root) must be
    passed with the message in order for verification of the signature/certificate chain to
    be performed.
     8 The IP OCSP Responder creates an OCSP request containing the serial number of the
    PP OCSP Responder's certificate and signs it using its HSM.
     9 The IP OCSP Responder then sends the request to the ROOT OCSP Responder based
    on the authority information access extension in the certificate associated with the
    signature on the request received in Step 4. The IP OCSP Responder waits for a
    response from the ROOT regarding the RP OCSP Responder's certificate before
    issuing a response on the SC's certificate. If the IP only requires SSL client-side
    authentication and does not require signed OCSP requests, this step may not be
    necessary.
    10 The ROOT OCSP Responder logs the request in its OCSP log. The ROOT OCSP
    Responder verifies the signature on the request and validates the IP OCSP
    Responder's certificate chain. Signed requests between financial institutions are not
    required. Instead, the ROOT may require SSL client-side authentication in which
    case the verification/validation/customer look up is based on the certificates
    associated with the SSL connection.
    11 The ROOT OCSP Responder checks its local database to determine the status of the
    RP OCSP Responder's certificate, then it generates a response and signs it using its
    HSM.
    12 The ROOT OCSP Responder then returns the response to the IP OCSP Responder.
    13 The IP OCSP Responder logs the response in its OCSP log. The IP OCSP Responder
    verifies the signature on the request and validates the Root's OCSP Responder
    certificate chain. It should be noted, however, that there may not be enough
    information maintained in the logs to support non-repudiation. The entire certificate
    chain must be passed with the message.
    14 The IP OCSP Responder then checks its local database to determine the status of the
    SC's certificate. The IP OCSP Responder generates a response and signs it using its
    HSM.
    15 The IP OCSP Responder sends the signed response to the RP OCSP Responder.
    16 The RP OCSP Responder logs the OCSP response in the OCSP log. The RP OCSP
    Responder verifies the signature on the response and validates the IP's OCSP
    Responder certificate chain. The entire certificate chain must be passed with the
    message.
    17 The RP OCSP Responder creates an OCSP request containing the serial number of
    the IP OCSP Responder's certificate and signs it using its HSM.
    18 The RP OCSP Responder then sends the request to the ROOT OCSP Responder
    based on the authority information access extension in the certificate associated with
    the signature on the response received in step 14.
    19 The ROOT OCSP Responder logs the raw request in its OCSP log. The ROOT
    OCSP Responder verifies the signature on the request and validates the entire RP
    OCSP Responder's certificate chain. The entire certificate chain must be passed with
    the message.
    20 The ROOT OCSP Responder checks its local database to determine the status of the
    IP OCSP Responder's certificate, then it generates a response and signs it using its
    HSM.
    21 The ROOT OCSP Responder sends the signed response to the OCSP Responder.
    22 The RP OCSP Responder logs the response in its OCSP log. The RP OCSP
    Responder verifies the signature on the response and validates the Root's OCSP
    Responder certificate chain. The certificate chain may be passed with the message, or
    parts of the chain may reside either on the HSM or in the Certificate Verification
    database.
    23 The RP OCSP Responder creates a response for the RC that contains information it
    received in step 2 (e.g., the nonce) and the status information on the SC's certificate it
    received in step 14 and signs it using its HSM.
    24 The RP OCSP Responder returns the response to the RC.
    25 The RC uses its HSM to verify the signature on the response and validate the RP's
    OCSP Responder certificate chain. The certificate chain may be passed with the
    message, or parts of the chain may reside on the HSM.
    26 The RC creates an OCSP request containing the IP's certificate serial number. This
    data is sent to the HSM for signature.
    27 The OCSP request for the IP's certificate, signed by the RC, is sent to the Relying
    Participant (RP) OCSP Responder (OR) along with the RC's certificate chain. The
    entire certificate chain needs to be passed with the message.
    28 The RP OCSP Responder logs the request in its OCSP log. The RP OCSP
    Responder verifies the signature on the request and validates the RC's certificate
    chain. All verification if performed in software. The entire chain (including the root)
    must be passed with the message in order for verification of the signature/certificate
    chain to be performed. No checks are performed to ensure that the RC's certificate
    has not been revoked.
    29 The RP OCSP Responder creates a new request, containing the single request
    received from the RC, and signs it using its HSM. Signed requests between financial
    institutions are not required. Instead, the ROOT may require SSL client-side
    authentication in which case the verification/validation/customer look up is based on
    the certificates associated with the SSL connection.
    30 The RP OCSP Responder sends the signed OCSP request to the ROOT OCSP
    Responder based on the value in the Service Locator request extension of the
    received request.
    31 The ROOT OCSP Responder logs the request in its OCSP log. The ROOT OCSP
    Responder verifies the signature on the request and validates the RP OR's certificate
    chain. All verification is performed in software. The entire chain (including the root)
    must be passed with the message in order for verification of the signature/certificate
    chain to be performed.
    32 The ROOT OCSP Responder checks its local database to determine the status of the
    RP OCSP Responder's certificate, then it generates a response and signs it using its
    HSM.
    33 The ROOT OCSP Responder then returns the response to the RP OCSP Responder.
    34 The RP OCSP Responder logs the response in its OCSP log. The RP OCSP
    Responder verifies the signature on the response and validates the ROOT's OCSP
    Responder certificate chain. It should be noted that there may not be enough
    information maintained in the logs to support non-repudiation. The entire certificate
    chain must be passed with the message.
  • This OCSP proxy centric model has advantages and disadvantages when compared to the transaction coordinator model described above. The pros and cons of this alternative embodiment are summarized in the table below: [0292]
    Pros Cons
    Takes away some of the complexity of Two OCSP Responder are required: one
    implementing the transaction coordinator as that re-signs responses, one that forwards
    an initial phase by reducing functionality signed responses without re-signing.
    and pushing code changes to the
    manufacturer of the OCSP responder.
    Allows the basic security infrastructure to No authorization checks are performed.
    be put in place and tested. Signatures are verified by the OCSP
    Responder but there are no checks
    performed to determine whether or not the
    request is from an authorized customer.
    There are no OCSP checks performed to
    determine if a requestor's certificate has
    been revoked.
    All certificates in a requestor's/responder's
    chain must be sent with the request/
    response in order for the OCSP Responder
    to verify the signatures. This significantly
    increases the size of the messages.
    The RC must send individual requests to the
    RP - multiple certificate statuses cannot be
    requested in the same message if they need
    to be processed by different OCSP
    responders.
    Not enough information is maintained in the
    logs for non-repudiation purposes. It is not
    clear whether enough information about the
    requestor is retained for billing purposes.
    Can only perform certification status
    checks. Will still require a transaction
    coordinator to fulfill other services.
    Will not provide generic reusable core
    components.
    The TETF OCSP Responder specification
    does not require Responder to provide this
    additional functionality.
  • Technical and security requirements for [0293] OCSP responder 204 are preferably specified by root entity 110. An exemplary set of requirements is described below.
  • Technical Requirements [0294]
  • In a preferred embodiment, each [0295] OCSP responder 204 operates pursuant to the Online Certificate Status Protocol (OCSP).
  • In a preferred embodiment, when an [0296] OCSP responder 204 receives an OCSP request, it validates the requestor's certificate, authenticates the requestor, and verifies that the requestor is a contracted system user with the participant that received the request by performing a local status check on the requestor's certificate. Authentication of the requestor may be accomplished using the signed OCSP request, in the case of an inter-institution request, or through secure socket layers client authentication, in the case of a customer request. In addition, secure socket layers may be required to ensure the confidentiality of all requests.
  • In a preferred embodiment, each [0297] OCSP responder 204 selects peer servers when making inter-institution requests based on a locator extension of the requested service and a local table. In an alternative embodiment, this information may be obtained by lightweight directory access protocol (LDAP) look up.
  • In a preferred embodiment, each [0298] OCSP responder 204 may cache certificates subject to rules specified by root entity 110.
  • In a preferred embodiment, each [0299] OCSP responder 204 verifies that inter-institution responses have been signed by an authorized responder certificate. For inter-institution OCSP requests, the OCSP responder of the relying participant 204 preferably re-signs the response from, e.g., issuing participant 102 before transmitting it to the requestor.
  • In a preferred embodiment, each OCSP responder supports the following responses: “revoked,” “good,” and “unknown.” If a client OCSP responder receives a “revoked” response regarding a particular certificate produced at a time t, then the client OCSP responder assumes that that certificate, or some certificate in the certificate chain of that certificate was revoked prior to time t. As such, the client OCSP responder does not possess sufficient evidence to transfer liability for documents that have been digitally signed after time t using the private key corresponding to the checked certificate to the server OCSP responder. [0300]
  • If a client OCSP responder receives a “good” response regarding a particular certificate, produced at a time t, then the client OCSP responder assumes that that certificate and every other certificate in its certificate chain was in good standing at time t. As such, the client OCSP responder has sufficient evidence to transfer liability for documents that have been digitally signed prior to time t to the server OCSP responder. [0301]
  • If the client OCSP responder receives an “unknown” response regarding a particular certificate produced at time t, then the client OCSP responder assumes that that certificate, or a certificate in the certificate chain of that certificate, is not known to be in good standing. As such, the client OCSP responder does not possess sufficient evidence to transfer liability for documents that have been digitally signed using the private key corresponding to the checked certificate to the server OCSP responder. [0302]
  • Security Requirements [0303]
  • In a preferred embodiment, each [0304] OCSP responder 204 stores its private keys in a hardware security module that meets requirements established by root entity 110.
  • In a preferred embodiment, each [0305] OCSP responder 204 uses separate keys for server secure socket layers, client secure socket layers, and OCSP responses.
  • In a preferred embodiment, each [0306] OCSP responder 204 has the ability to operate on institution-hardened platform configurations. An institution-hardened platform is a tried and tested platform that is approved for use within an institution's firewall.
  • In a preferred embodiment, each [0307] OCSP responder 204 maintains detailed logs of all signed requests and responses, all exceptions or errors, and all administrative and configuration actions.
  • In a preferred embodiment, each [0308] OCSP responder 204 uses strong authentication, such as secure socket layers client authentication, to authenticate entities for all administrative transactions.
  • In a preferred embodiment, each [0309] OCSP responder 204 meets minimum security requirements established by root entity 110. In addition, the institution that maintains the OCSP responder may specify additional OCSP responder security rules.
  • In a preferred embodiment, each [0310] OCSP responder 204 is configured to be highly available and deployable in a replicated mode. In addition, each OCSP Responder preferably responds to all requests in less than one second.
  • OCSP responders are not typically required to perform checks on utility certificates. They may, however, be configured to allow a requestor unauthenticated access to the status of a utility certificate. [0311]
  • In a preferred embodiment, an OCSP responder may be required to serve as an authenticated interface to an institution's repository. Implementation details of this preferred embodiment may be left to the entity that maintains the OCSP responder. [0312]
  • In a preferred embodiment, each OCSP Responder comprises additional interfaces to support additional functionality. In particular, each OCSP responder preferably comprises an additional interface to make information available to support a participant's customer-service requirements. In addition, each OCSP responder preferably comprises an institution-defined standard interface for exporting system and event logs. Each OCSP responder may also comprise an interface for export of information for billing applications. Billing data may be exported in any format including logs but preferably enables the requestor to determine the type and volume of the request. [0313]
  • In a preferred embodiment, [0314] participants 102, 104 shown in FIG. 1 are referred to as level-one participants because they are issued digital certificates directly by root entity 110. Accordingly, the certificate chain of each participant begins at root entity 110. Each level one participant relies on root entity 110 to obtain the status of certificates of other level-one participants.
  • In a further preferred embodiment, the present system may comprise additional participants, called level-two participants. Each level-two participant is preferably issued a digital certificate by a level-one participant with which it is associated. These level-two participants may then serve as certificate authorities for their respective customers and provide system services to those customers. [0315]
  • Level one participants preferably provide the highest point of trust for level two participants. As such, level two participants preferably report directly to their sponsoring level one participant. Level two participants must also rely on their sponsoring level one participants to obtain the status of certificates of other participants. A preferred embodiment including level one and level two participants is further described in copending U.S. patent application Ser. No. 09/502,450, filed Feb. 11, 2000, entitled System and Method for Providing Certification-Related and other Services, which is hereby incorporated by reference. [0316]
  • In a preferred embodiment, each participant collectively implements and maintains a hardware and software configuration baseline that identifies the operating environment of the hardware and software components of each participant. As such, the configuration baseline serves as a configuration reference which facilitates the daily operation and management of the system. The baseline facilitates the integration of configuration changes made by one or more participants on a system-wide level. In addition, the baseline facilitates system-wide service recovery in the event of hardware or software failures of one or more certification authorities. [0317]
  • In a preferred embodiment, a master copy of the configuration baseline for the present system is maintained by [0318] root entity 110. Typically, the master copy is kept by an officer of root entity 110, such as the Vice President of Operations.
  • In a preferred embodiment, [0319] root entity 110 keeps a true and accurate record of root entity 110's hardware and software configuration. At least three copies of the root certification authority's configuration baseline are preferably retained by root entity 110 at the following three locations: (1) at the same physical location of the root certification authority thereby allowing operational changes to be recorded as they occur; (2) at a secure location outside the physical location of the root certification authority but in a controlled container; and (3) at an offsite location with root entity 110's backup and archive records. Other copies of this hardware and software configuration may be provided to level one certification authorities at the discretion of root entity 110.
  • In a preferred embodiment, each level one participant maintains a true and accurate record of the hardware and software configuration of its certification authority architecture. Each level one participant preferably prepares, retains, and maintains at least three copies of its configuration baseline document in the following three locations: (1) at the same physical location of the level one certification authority thereby allowing operational changes to be recorded as they occur; (2) at a secure location outside the physical location of the level one certification authority but in a controlled container; and (3) at an offsite location with the level one certification authority's backup and archive records. In addition, each level one participant preferably provides a copy of its configuration baseline to root [0320] entity 110.
  • In a preferred embodiment, level two participants also maintain a true and accurate record of the hardware and software configuration of their certification authority architecture. Each level two participant prepares, retains, and maintains at least three copies of its configuration document in the following three locations: (1) at the same physical location as the level two certification authority thereby allowing operational changes to be recorded as they occur; (2) at a secure location outside the physical location of the level two certification authority but in a controlled container; and (3) at an off-site location with the level two certification authority's back up and archive records. In addition, each level two participant preferably provides a copy of its configuration baseline to its sponsoring level one certification authority. [0321]
  • Forms may be provided to facilitate documentation of hardware and software configurations. In a preferred embodiment, the hardware and software configurations of [0322] root entity 110's and each participant's certification authority directory, OCSP responder, and Internet firewall are also documented.
  • In a preferred embodiment, [0323] root entity 110 has primary responsibility for configuration management on a system-wide level. This responsibility is typically delegated to an officer of root entity 110, such as the Vice President of Operations. Each certificate authority preferably comprises a technical operations staff which has the operational responsibility for maintaining an accurate record of the certification authority's hardware and software configuration.
  • In a preferred embodiment, the initial configuration baseline of each certificate authority is produced by commissioning the configuration baselines of each subordinate certification authority. [0324]
  • In a preferred embodiment, a configuration change must comply with the following criteria: (1) a configuration change must be required to address a defined system requirement; (2) a configuration change must be recommended by the certification authority's operations staff; (3) a configuration change to the operational platforms must be approved by an officer, such as the Vice President of Operations in the case of the root entity, and a senior manager accountable for the integrity of the certification authority, in the case of a level one or level two certification authority; (4) notice of configuration changes must be given to any affected parties; (5) a configuration change must take into account relevant configuration change criteria imposed by governmental or standards setting bodies; and (6) a configuration change must be recorded by setting out the date of the change and the period of each previous configuration. Each certificate authority typically archives configuration changes with other archived materials such as backup tapes. [0325]
  • In a preferred embodiment, the configuration baseline is implemented in conjunction with the root entity's system security policy and is an audited component of each certification authority. [0326]
  • While the invention has been described in conjunction with specific embodiments, it is evident that numerous alternatives, modifications, and variations will be apparent to those skilled in the art in light of the foregoing description. [0327]

Claims (21)

What is claimed is:
1. A system for providing one or more services via a network, comprising:
a root entity, the root entity operating a root entity certification authority, the root entity maintaining a root entity configuration baseline for the root entity certification authority, the root entity configuration baseline comprising the operating environment of the root entity certification authority;
at least one level-one participant, the level-one participant operating a level-one certification authority, the level-one participant maintaining a configuration baseline for the level-one certification authority, the configuration baseline for the level-one certification authority comprising the operating environment of the level-one certification authority;
at least one level-two participant, the level-two participant operating a level-two certification authority, the level-two participant maintaining a configuration baseline for the level-two certification authority, the configuration baseline for the level-two certification authority comprising the operating environment of the level-two certification authority.
2. The system of claim 1, wherein the configuration baseline of each entity's certification authority is recorded on a form.
3. The system of claim 1, wherein a copy of each entity's configuration baseline is maintained by the root entity.
4. The system of claim 1, further comprising a configuration manager, the configuration manager being an officer of the root entity, the configuration manager further having primary responsibility for configuration management within the system.
5. The system of claim 1, wherein each certification authority comprises a technical operations staff, the technical operations staff having primary responsibility for maintaining record of an entity certification authority's configuration.
6. The system of claim 1, wherein the configuration baseline for each entity's certification authority is maintained at the same physical location of the entity's certification authority.
7. The system of claim 1, wherein the configuration baseline for each entity's certification authority is maintained at a secure location outside the physical location of the entity's certification authority.
8. The system of claim 1, wherein the configuration baseline for each entity's certification authority is maintained at an offsite location.
9. The system of claim 1, wherein changes to the configuration baseline of an entity's certification authority are made to address a system requirement.
10. The system of claim 1, wherein an affected party is notified of a change to the configuration baseline of an entity's certification authority.
11. The system of claim 1, wherein a change to the configuration baseline of an entity's certification authority takes into account configuration change criteria imposed by government bodies.
12. The system of claim 1, wherein a change to the configuration baseline of an entity's certification authority takes into account configuration change criteria imposed by standards-setting bodies.
13. A system for providing a certificate status check service via a network comprising a plurality of entities including at least one root entity, at least one issuing participant, and at least one relying participant, each entity comprising:
a transaction coordinator;
an online certificate status protocol responder, the online certificate status protocol responder checking status of a certificate, the online certificate status protocol responder receiving online certificate status requests from the transaction coordinator, the online certificate status protocol responder sending online certificate status responses to the transaction coordinator; and
at least one hardware security module.
14. The system of claim 13, wherein the online certificate status protocol responder sends a revoked response regarding a checked certificate, the revoked response indicating that the certificate, or a certificate in a certificate chain of the certificate, has been revoked prior to a particular time.
15. The system of claim 14, wherein the issuing participant does not accept liability for documents that have been signed after the particular time using a private key corresponding to the checked certificate.
16. The system of claim 13, wherein the online certificate status protocol responder sends a good response regarding a checked certificate, the good response indicating that the certificate and every other certificate in the certificate chain of the certificate is in good standing at a particular time.
17. The system of claim 16, wherein the issuing participant accepts liability for documents that have been signed prior to the particular time using a private key corresponding to the checked certificate.
18. The system of claim 13, wherein the online certificate status protocol responder sends an unknown response regarding a certificate, the unknown response indicating that the certificate, or a certificate in the certificate chain of the certificate, is not known to be in good standing at a particular time.
19. The system of claim 18, wherein the issuing participant does not accept liability for documents that have been signed prior to the particular time using a private key corresponding to the checked certificate.
20. The system of claim 13, wherein the online certificate status protocol responder stores its private keys in a hardware security module.
21. The system of claim 13, wherein the online certificate status protocol responder meets a set of minimum security requirements established by the root entity.
US09/950,440 1999-09-10 2001-09-10 System and method for providing certificate validation and other services Abandoned US20020029200A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US09/950,440 US20020029200A1 (en) 1999-09-10 2001-09-10 System and method for providing certificate validation and other services
US11/603,755 US8818903B2 (en) 1999-09-10 2006-11-22 Transaction coordinator for digital certificate validation and other services
US14/467,926 US20150278808A1 (en) 1999-09-10 2014-08-25 Transaction coordinator for digital certificate validation and other services

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US15320399P 1999-09-10 1999-09-10
US15372499P 1999-09-13 1999-09-13
US15372699P 1999-09-13 1999-09-13
US65760500A 2000-09-08 2000-09-08
US23131900P 2000-09-08 2000-09-08
US09/950,440 US20020029200A1 (en) 1999-09-10 2001-09-10 System and method for providing certificate validation and other services

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US65760500A Continuation 1999-09-10 2000-09-08

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/603,755 Continuation US8818903B2 (en) 1999-09-10 2006-11-22 Transaction coordinator for digital certificate validation and other services

Publications (1)

Publication Number Publication Date
US20020029200A1 true US20020029200A1 (en) 2002-03-07

Family

ID=27538450

Family Applications (3)

Application Number Title Priority Date Filing Date
US09/950,440 Abandoned US20020029200A1 (en) 1999-09-10 2001-09-10 System and method for providing certificate validation and other services
US11/603,755 Expired - Fee Related US8818903B2 (en) 1999-09-10 2006-11-22 Transaction coordinator for digital certificate validation and other services
US14/467,926 Abandoned US20150278808A1 (en) 1999-09-10 2014-08-25 Transaction coordinator for digital certificate validation and other services

Family Applications After (2)

Application Number Title Priority Date Filing Date
US11/603,755 Expired - Fee Related US8818903B2 (en) 1999-09-10 2006-11-22 Transaction coordinator for digital certificate validation and other services
US14/467,926 Abandoned US20150278808A1 (en) 1999-09-10 2014-08-25 Transaction coordinator for digital certificate validation and other services

Country Status (1)

Country Link
US (3) US20020029200A1 (en)

Cited By (137)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020107795A1 (en) * 2001-02-02 2002-08-08 Brian Minear Application distribution and billing system in a wireless network
US20020144122A1 (en) * 2001-04-03 2002-10-03 S.W.I.F.T. System and method for facilitating trusted transactions between businesses
US20020165824A1 (en) * 1995-10-02 2002-11-07 Silvio Micali Scalable certificate validation and simplified PKI management
US20020184182A1 (en) * 2001-05-31 2002-12-05 Nang Kon Kwan Method and system for answering online certificate status protocol (OCSP) requests without certificate revocation lists (CRL)
US20030018585A1 (en) * 2001-07-21 2003-01-23 International Business Machines Corporation Method and system for the communication of assured reputation information
US20030051047A1 (en) * 2001-08-15 2003-03-13 Gerald Horel Data synchronization interface
US20030055873A1 (en) * 2001-08-17 2003-03-20 Fernando Pedone Method and system for performing fault-tolerant online validation of service requests
US20030065920A1 (en) * 2001-10-01 2003-04-03 International Business Machines Corporation Method and apparatus for using host authentication for automated public key certification
US20030074313A1 (en) * 2000-02-03 2003-04-17 Mcconnell Richard Network-based billing method and system
US20030140226A1 (en) * 2000-12-12 2003-07-24 Masaaki Yamamoto Authentication method, communication apparatus, and relay apparatus
US20030212632A1 (en) * 2002-01-07 2003-11-13 S.W.I.F.T.S.C.; Electronic payment initiation and assurance system
US20030221101A1 (en) * 1995-10-02 2003-11-27 Silvio Micali Efficient certificate revocation
US6665672B2 (en) * 1998-10-30 2003-12-16 Xerox Corporation Transaction/object accounting method and system
US20040043753A1 (en) * 2002-08-30 2004-03-04 Wake Susan L. System and method for third party application sales and services to wireless devices
WO2004036443A1 (en) * 2002-09-09 2004-04-29 Atitania Ltd. Code generator for a distributed processing system
US20040093493A1 (en) * 1995-01-17 2004-05-13 Bisbee Stephen F. System and method for electronic transmission, storage and retrieval of authenticated documents
WO2004054152A1 (en) * 2002-12-09 2004-06-24 Bea Systems, Inc. System and method for single security administration
US20040153528A1 (en) * 2002-12-17 2004-08-05 Akira Suzuki Digital contents distributing system and distributing method
US20040230891A1 (en) * 2003-05-16 2004-11-18 Pravetz James D. Document modification detection and prevention
US20040237031A1 (en) * 2003-05-13 2004-11-25 Silvio Micali Efficient and secure data currentness systems
US20050010783A1 (en) * 1995-10-24 2005-01-13 Phil Libin Access control
US20050039016A1 (en) * 2003-08-12 2005-02-17 Selim Aissi Method for using trusted, hardware-based identity credentials in runtime package signature to secure mobile communications and high-value transaction execution
US20050044386A1 (en) * 1995-10-02 2005-02-24 Phil Libin Controlling access using additional data
US20050055548A1 (en) * 1995-10-24 2005-03-10 Silvio Micali Certificate revocation system
US20050055567A1 (en) * 1995-10-02 2005-03-10 Phil Libin Controlling access to an area
US20050102326A1 (en) * 2003-10-22 2005-05-12 Nitzan Peleg Method and apparatus for performing conflict resolution in database logging
US20050154879A1 (en) * 2004-01-09 2005-07-14 David Engberg Batch OCSP and batch distributed OCSP
US20050154878A1 (en) * 2004-01-09 2005-07-14 David Engberg Signature-efficient real time credentials for OCSP and distributed OCSP
US20050154918A1 (en) * 2003-11-19 2005-07-14 David Engberg Distributed delegated path discovery and validation
US20050192878A1 (en) * 2004-01-21 2005-09-01 Brian Minear Application-based value billing in a wireless subscriber network
US6948060B1 (en) * 2000-08-11 2005-09-20 Intel Corporation Method and apparatus for monitoring encrypted communication in a network
US20050257265A1 (en) * 2003-06-11 2005-11-17 Cook Randall R Intrustion protection system utilizing layers
US20050278534A1 (en) * 2004-05-27 2005-12-15 International Business Machines Corporation Method and system for certification path processing
US20050289047A1 (en) * 2004-06-28 2005-12-29 Oliver Mitchell B Virtual marketplace for wireless device applications and services with integrated multi-party settlement
US20060004670A1 (en) * 1999-09-24 2006-01-05 Mckenney Mary K System and method for providing payment services in electronic commerce
US20060006222A1 (en) * 2004-07-09 2006-01-12 U.S. Bank Corporation System and method for managing requests to document archives, routing requests and delivering requests to a variety of channels or delivery mechanisms
US20060036546A1 (en) * 2004-06-30 2006-02-16 Franco Arcieri System and method for improving reliability of distributed electronic transactions
US20060089970A1 (en) * 2004-09-30 2006-04-27 Microsoft Corporation Enforcing rights mangement through edge email servers
US20060101062A1 (en) * 2004-10-29 2006-05-11 Godman Peter J Distributed system with asynchronous execution systems and methods
US20060097843A1 (en) * 2004-11-10 2006-05-11 Phil Libin Actuating a security system using a wireless device
US20060123227A1 (en) * 2000-09-08 2006-06-08 Miller Lawrence R System and method for transparently providing certificate validation and other services within an electronic transaction
US20060156063A1 (en) * 2004-12-20 2006-07-13 Travel Sciences, Inc. Instant messaging transaction integration
US20060173758A1 (en) * 2001-08-13 2006-08-03 Brian Minear System and method for providing subscribed applications on wireless devices over a wireless network
US20060179008A1 (en) * 2000-09-08 2006-08-10 Tallent Guy S Jr Provision of authorization and other services
US20060270386A1 (en) * 2005-05-31 2006-11-30 Julie Yu Wireless subscriber billing and distribution
US20060271449A1 (en) * 2005-05-31 2006-11-30 Oliver Mitchell B Wireless subscriber application and content distribution and differentiated pricing
US20070067238A1 (en) * 2005-09-21 2007-03-22 Capital One Financial Corporation System and method for transferring information between financial accounts
US20070101401A1 (en) * 2005-10-27 2007-05-03 Genty Denise M Method and apparatus for super secure network authentication
US20070150964A1 (en) * 2002-02-21 2007-06-28 Adobe Systems Incorporated Application Rights Enabling
US20070168351A1 (en) * 2004-10-29 2007-07-19 Fachan Neal T Non-blocking commit protocol systems and methods
US20080046745A1 (en) * 2002-05-17 2008-02-21 Microsoft Corporation End-to-end authentication of session initiation protocol messages using certificates
US20080046443A1 (en) * 2006-08-18 2008-02-21 Fachan Neal T Systems and methods for providing nonlinear journaling
US20080109653A1 (en) * 2006-11-06 2008-05-08 Fuji Xerox Co., Ltd. Information-processing apparatus, information-processing method, and communication control program recording medium
WO2008058172A2 (en) * 2006-11-08 2008-05-15 Managed Inventions, Llc System and method for reducing click fraud
US20080243773A1 (en) * 2001-08-03 2008-10-02 Isilon Systems, Inc. Systems and methods for a distributed file system with data recovery
US20090055604A1 (en) * 2007-08-21 2009-02-26 Lemar Eric M Systems and methods for portals into snapshot data
US20090210880A1 (en) * 2007-01-05 2009-08-20 Isilon Systems, Inc. Systems and methods for managing semantic locks
US20090210703A1 (en) * 2008-01-18 2009-08-20 Epstein William C Binding a digital certificate to multiple trust domains
US20090248765A1 (en) * 2008-03-27 2009-10-01 Akidau Tyler A Systems and methods for a read only mode for a portion of a storage system
US20090248975A1 (en) * 2008-03-27 2009-10-01 Asif Daud Systems and methods for managing stalled storage devices
US20090252066A1 (en) * 2005-10-21 2009-10-08 Isilon Systems, Inc. Systems and methods for providing variable protection
EP2129077A1 (en) * 2008-05-30 2009-12-02 Hitachi Ltd. Validation server, validation method and program
US20090327218A1 (en) * 2006-08-18 2009-12-31 Passey Aaron J Systems and Methods of Reverse Lookup
US20100017413A1 (en) * 2008-07-17 2010-01-21 Ian Edward James Systems and methods for transferring value
US20100058070A1 (en) * 2008-08-28 2010-03-04 Garay Juan A Message authentication code pre-computation with applications to secure memory
US7698559B1 (en) 2002-11-27 2010-04-13 Adobe Systems Incorporated Dynamic enabling of functionality in electronic document readers
US7716486B2 (en) 1995-10-02 2010-05-11 Corestreet, Ltd. Controlling group access to doors
US20100161557A1 (en) * 2006-08-18 2010-06-24 Anderson Robert J Systems and methods for a snapshot of data
US20100161556A1 (en) * 2006-08-18 2010-06-24 Anderson Robert J Systems and methods for a snapshot of data
US20100235413A1 (en) * 2001-08-03 2010-09-16 Isilon Systems, Inc. Systems and methods for providing a distributed file system utilizing metadata to track information about data stored throughout the system
US20100306786A1 (en) * 2006-03-31 2010-12-02 Isilon Systems, Inc. Systems and methods for notifying listeners of events
US20100318791A1 (en) * 2009-06-12 2010-12-16 General Instrument Corporation Certificate status information protocol (csip) proxy and responder
US20110022790A1 (en) * 2006-08-18 2011-01-27 Isilon Systems, Inc. Systems and methods for providing nonlinear journaling
US7882068B2 (en) 2007-08-21 2011-02-01 Isilon Systems, Inc. Systems and methods for adaptive copy on write
US20110044209A1 (en) * 2006-02-17 2011-02-24 Isilon Systems, Inc. Systems and methods for providing a quiescing protocol
US7900015B2 (en) 2007-04-13 2011-03-01 Isilon Systems, Inc. Systems and methods of quota accounting
US20110060779A1 (en) * 2006-12-22 2011-03-10 Isilon Systems, Inc. Systems and methods of directory entry encodings
US7917474B2 (en) 2005-10-21 2011-03-29 Isilon Systems, Inc. Systems and methods for accessing and updating distributed data
US20110087635A1 (en) * 2006-08-18 2011-04-14 Isilon Systems, Inc. Systems and methods for a snapshot of data
US7937421B2 (en) 2002-11-14 2011-05-03 Emc Corporation Systems and methods for restriping files in a distributed file system
US7949636B2 (en) 2008-03-27 2011-05-24 Emc Corporation Systems and methods for a read only mode for a portion of a storage system
US7953704B2 (en) 2006-08-18 2011-05-31 Emc Corporation Systems and methods for a snapshot of data
US7966289B2 (en) 2007-08-21 2011-06-21 Emc Corporation Systems and methods for reading objects in a file system
US20110154026A1 (en) * 2009-12-23 2011-06-23 Christofer Edstrom Systems and methods for parallel processing of ocsp requests during ssl handshake
US20110154017A1 (en) * 2009-12-23 2011-06-23 Christofer Edstrom Systems and methods for evaluating and prioritizing responses from multiple ocsp responders
US20110154018A1 (en) * 2009-12-23 2011-06-23 Christofer Edstrom Systems and methods for flash crowd control and batching ocsp requests via online certificate status protocol
US7971021B2 (en) 2008-03-27 2011-06-28 Emc Corporation Systems and methods for managing stalled storage devices
US20110161663A1 (en) * 2009-12-29 2011-06-30 General Instrument Corporation Intelligent caching for ocsp service optimization
US20110183748A1 (en) * 2005-07-20 2011-07-28 Wms Gaming Inc. Wagering game with encryption and authentication
US8015216B2 (en) 2007-04-13 2011-09-06 Emc Corporation Systems and methods of providing possible value ranges
US8015597B2 (en) 1995-10-02 2011-09-06 Corestreet, Ltd. Disseminating additional data used for controlling access
US8185945B1 (en) * 2005-03-02 2012-05-22 Crimson Corporation Systems and methods for selectively requesting certificates during initiation of secure communication sessions
US20120167212A1 (en) * 2009-01-20 2012-06-28 Check Point Software Technologies, Ltd. Methods for inspecting security certificates by network security devices to detect and prevent the use of invalid certificates
US8214400B2 (en) 2005-10-21 2012-07-03 Emc Corporation Systems and methods for maintaining distributed data
US8214334B2 (en) 2005-10-21 2012-07-03 Emc Corporation Systems and methods for distributed system scanning
US8238350B2 (en) 2004-10-29 2012-08-07 Emc Corporation Message batching with checkpoints systems and methods
US8261319B2 (en) 1995-10-24 2012-09-04 Corestreet, Ltd. Logging access attempts to an area
US8286029B2 (en) 2006-12-21 2012-10-09 Emc Corporation Systems and methods for managing unavailable storage devices
CN102956000A (en) * 2011-08-18 2013-03-06 招商银行股份有限公司 Method and device for payment intermediation transaction data processing and payment intermediation network system
US8458064B1 (en) 2006-01-30 2013-06-04 Capital One Financial Corporation System and method for transferring electronic account information
US8660960B2 (en) 2002-11-27 2014-02-25 Adobe Systems Incorporated Document digest allowing selective changes to a document
US8818903B2 (en) 1999-09-10 2014-08-26 Charles Dulin Transaction coordinator for digital certificate validation and other services
US20140278541A1 (en) * 2013-03-14 2014-09-18 Skyscape.Com, Inc. Toolkit system and method for managing delivery of services and content for health care professionals via an electronic health record system
US20140304348A1 (en) * 2001-08-30 2014-10-09 Telecommunication Systems, Inc. Method and Apparatus for Storing Real-Time Text Messages
US8930694B2 (en) 2012-08-02 2015-01-06 Banco Bilbao Vizcaya Argentaria, S.A. Method for the generation of a code, and method and system for the authorization of an operation
US8966080B2 (en) 2007-04-13 2015-02-24 Emc Corporation Systems and methods of managing resource utilization on a threaded computer system
US20150100779A1 (en) * 2013-10-09 2015-04-09 Symantec Corporation Reducing latency for certificate validity messages using private content delivery networks
US9143622B2 (en) 2006-02-17 2015-09-22 Qualcomm Incorporated Prepay accounts for applications, services and content for communication devices
US9185234B2 (en) 2006-02-22 2015-11-10 Qualcomm Incorporated Automated account mapping in a wireless subscriber billing system
EP3155753A2 (en) * 2014-06-10 2017-04-19 Qualcomm Incorporated Common modulus rsa key pairs for signature generation and encryption/decryption
US20170171314A1 (en) * 2015-12-14 2017-06-15 Afero, Inc. Internet of things (iot) apparatus and method for coin operated devices
US20170171313A1 (en) * 2015-12-14 2017-06-15 Afero, Inc. Apparatus and method for modifying packet interval timing to identify a data transfer condition
US20170169264A1 (en) * 2015-12-14 2017-06-15 Afero, Inc. Internet of things (iot) apparatus and method for electronic shelf tags
US9684889B2 (en) 1999-02-12 2017-06-20 Identrust, Inc. System and method for providing certification-related and other services
CN107229541A (en) * 2017-06-20 2017-10-03 携程旅游信息技术(上海)有限公司 Backup method, standby system and the server of Transaction Information
US20170351542A1 (en) * 2016-06-01 2017-12-07 Red Hat, Inc. Non-repudiable transaction protocol
US9843929B2 (en) 2015-08-21 2017-12-12 Afero, Inc. Apparatus and method for sharing WiFi security data in an internet of things (IoT) system
US9942837B2 (en) 2015-08-25 2018-04-10 Afero, Inc. Apparatus and method for a dynamic scan interval for a wireless device
US20180218366A1 (en) * 2017-01-30 2018-08-02 Ncr Corporation User-controlled transaction authorization
US20180219689A1 (en) * 2015-09-30 2018-08-02 Hewlett-Packard Development Company, L.P. Certificate analysis
US10091242B2 (en) 2015-12-14 2018-10-02 Afero, Inc. System and method for establishing a secondary communication channel to control an internet of things (IOT) device
WO2018236401A1 (en) 2017-06-23 2018-12-27 Visa International Service Association Verification and encryption scheme in data storage
US10404681B2 (en) 2013-10-09 2019-09-03 Digicert, Inc. Accelerating OCSP responses via content delivery network collaboration
US20190281067A1 (en) * 2013-07-08 2019-09-12 Ssh Communications Security Oyj Trust Relationships in a Computerized System
US10438182B2 (en) * 2012-07-18 2019-10-08 Swoop Ip Holdings Llc Email-based e-commerce
CN110912693A (en) * 2019-11-22 2020-03-24 福建金密网络安全测评技术有限公司 Digital certificate format compliance detection system
TWI695614B (en) * 2019-03-13 2020-06-01 開曼群島商庫幣科技有限公司 Method for digital currency transaction with authorization of multiple private key
CN111262683A (en) * 2020-01-15 2020-06-09 中南大学 Method for detecting abnormal allocation of certification authority resources in RPKI
US10742419B2 (en) * 2016-03-15 2020-08-11 Visa International Service Association Validation cryptogram for transaction
US10805344B2 (en) 2015-12-14 2020-10-13 Afero, Inc. Apparatus and method for obscuring wireless communication patterns
US10966091B1 (en) * 2017-05-24 2021-03-30 Jonathan Grier Agile node isolation using packet level non-repudiation for mobile networks
US10992746B2 (en) * 2015-12-15 2021-04-27 Microsoft Technology Licensing, Llc Automatic system response to external field-replaceable unit (FRU) process
US20210126798A1 (en) * 2019-10-28 2021-04-29 Robert Bosch Gmbh System, Machine, Method for Configuring a System and Method for Operating a Machine
US20210241270A1 (en) * 2017-12-28 2021-08-05 Acronis International Gmbh System and method of blockchain transaction verification
US11133942B1 (en) * 2019-05-15 2021-09-28 Wells Fargo Bank, N.A. Systems and methods of ring usage certificate extension
SE2150228A1 (en) * 2021-02-12 2022-03-08 Crunchfish Digital Cash Ab Payment service provider interoperability for offline digital payments
WO2022173360A1 (en) * 2021-02-12 2022-08-18 Crunchfish Digital Cash Ab Payment service provider interoperability for digital payments

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
MY133933A (en) * 2000-05-24 2007-11-30 Ericsson Telefon Ab L M Method and apparatus for buyer identification
US7444676B1 (en) * 2001-08-29 2008-10-28 Nader Asghari-Kamrani Direct authentication and authorization system and method for trusted network of financial institutions
US8281129B1 (en) 2001-08-29 2012-10-02 Nader Asghari-Kamrani Direct authentication system and method via trusted authenticators
GB0206552D0 (en) * 2002-03-20 2002-05-01 Koninkl Philips Electronics Nv Computer systems and a related method for enabling a prospective buyer to browse a vendor's webside to purchase goods or services
US20050144189A1 (en) * 2002-07-19 2005-06-30 Keay Edwards Electronic item management and archival system and method of operating the same
US7379978B2 (en) 2002-07-19 2008-05-27 Fiserv Incorporated Electronic item management and archival system and method of operating the same
US8271448B2 (en) * 2005-01-28 2012-09-18 Oracle International Corporation Method for strategizing protocol presumptions in two phase commit coordinator
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US7818811B2 (en) * 2005-12-05 2010-10-19 Microsoft Corporation Off-line economies for digital media
US7840525B2 (en) * 2006-10-11 2010-11-23 Ruby Jonathan P Extended transactions
US8296563B2 (en) 2008-10-22 2012-10-23 Research In Motion Limited Method of handling a certification request
US8255685B2 (en) * 2009-03-17 2012-08-28 Research In Motion Limited System and method for validating certificate issuance notification messages
FR2946445B1 (en) * 2009-06-05 2015-10-30 Jade I METHOD OF ACQUIRING DATA FROM A USER DURING CARD PAYMENT WITH A PAYMENT TERMINAL
US9479509B2 (en) * 2009-11-06 2016-10-25 Red Hat, Inc. Unified system for authentication and authorization
US9118485B2 (en) * 2010-02-26 2015-08-25 Red Hat, Inc. Using an OCSP responder as a CRL distribution point
US8880431B2 (en) * 2012-03-16 2014-11-04 Visa International Service Association Systems and methods to generate a receipt for a transaction
US8694784B1 (en) * 2012-10-09 2014-04-08 Sap Ag Secure client-side key storage for web applications
US8880885B2 (en) * 2012-10-09 2014-11-04 Sap Se Mutual authentication schemes
WO2015117226A1 (en) * 2014-02-05 2015-08-13 Self Care Catalysts Inc. Systems, devices, and methods for analyzing and enhancing patient health
US20150235221A1 (en) * 2014-02-19 2015-08-20 Bank Of America Corporation Proof-of-verification network for third party issuers
WO2016024986A1 (en) * 2014-08-15 2016-02-18 Hewlett-Packard Development Company, L.P. Three phase commit for a distributed file system
US10693638B1 (en) * 2016-12-01 2020-06-23 Amazon Technologies, Inc. Protected cryptographic environment
US11356427B1 (en) 2017-02-15 2022-06-07 Wells Fargo Bank, N.A. Signcrypted envelope message
US11354660B1 (en) 2017-04-27 2022-06-07 Wells Fargo Bank, N.A. Encapsulation of payment information
US10439825B1 (en) * 2018-11-13 2019-10-08 INTEGRITY Security Services, Inc. Providing quality of service for certificate management systems
CN111106940B (en) 2019-11-25 2022-11-04 广州大学 Certificate transaction verification method of resource public key infrastructure based on block chain
CN110852887B (en) * 2020-01-14 2020-06-12 支付宝(杭州)信息技术有限公司 Method and device for acquiring transaction processing state in decentralized application cluster
WO2022261762A1 (en) * 2021-06-14 2022-12-22 Royal Bank Of Canada System and method for multi-user session for coordinated electronic transactions

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5610982A (en) * 1996-05-15 1997-03-11 Micali; Silvio Compact certification with threshold signatures
US20010011255A1 (en) * 1996-12-13 2001-08-02 Alan Asay Reliance management for electronic transaction system
US6285991B1 (en) * 1996-12-13 2001-09-04 Visa International Service Association Secure interactive electronic account statement delivery system
US20040111379A1 (en) * 1999-02-12 2004-06-10 Mack Hicks System and method for providing certification-related and other services

Family Cites Families (161)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4304990A (en) 1979-12-11 1981-12-08 Atalla Technovations Multilevel security apparatus and method
JPH05502956A (en) 1989-10-03 1993-05-20 ユニバーシティ オブ テクノロジィ,シドニー Electronically actuated cradle circuit for access or intrusion detection
US5048085A (en) 1989-10-06 1991-09-10 International Business Machines Corporation Transaction system security method and apparatus
FR2653248B1 (en) 1989-10-13 1991-12-20 Gemolus Card International PAYMENT OR INFORMATION TRANSFER SYSTEM BY ELECTRONIC MEMORY CARD.
US5453601A (en) 1991-11-15 1995-09-26 Citibank, N.A. Electronic-monetary system
US5557518A (en) 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
WO1993017388A1 (en) 1992-02-26 1993-09-02 Clark Paul C System for protecting computers via intelligent tokens or smart cards
CA2133200C (en) 1992-03-30 1998-08-11 Edward Andrew Zuk A cryptographic communications method and system
US5389738A (en) 1992-05-04 1995-02-14 Motorola, Inc. Tamperproof arrangement for an integrated circuit device
US5920847A (en) 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system
WO1995016238A1 (en) 1993-12-06 1995-06-15 Telequip Corporation Secure computer memory card
US5825880A (en) 1994-01-13 1998-10-20 Sudia; Frank W. Multi-step digital signature method and system
SE502424C2 (en) 1994-02-17 1995-10-16 Telia Ab Method and device for certificate management systems
US5511121A (en) 1994-02-23 1996-04-23 Bell Communications Research, Inc. Efficient electronic money
US5668878A (en) 1994-02-28 1997-09-16 Brands; Stefanus Alfonsus Secure cryptographic methods for electronic transfer of information
US5799087A (en) 1994-04-28 1998-08-25 Citibank, N.A. Electronic-monetary system
US6182052B1 (en) 1994-06-06 2001-01-30 Huntington Bancshares Incorporated Communications network interface for user friendly interactive access to online services
US7904722B2 (en) 1994-07-19 2011-03-08 Certco, Llc Method for securely using digital signatures in a commercial cryptographic system
DE69534490T2 (en) 1994-07-19 2006-06-29 Certco, Llc METHOD FOR THE SAFE APPLICATION OF DIGITAL SIGNATURES IN A COMMERCIAL ENCRYPTION SYSTEM
US5694471A (en) 1994-08-03 1997-12-02 V-One Corporation Counterfeit-proof identification card
US5598473A (en) 1994-08-17 1997-01-28 Ibm Corporation Digital signature generator/verifier/recorder (DS-GVR) for analog transmissions
US5841866A (en) 1994-09-30 1998-11-24 Microchip Technology Incorporated Secure token integrated circuit and method of performing a secure authentication function or transaction
US5717989A (en) 1994-10-13 1998-02-10 Full Service Trade System Ltd. Full service trade system
US5715314A (en) 1994-10-24 1998-02-03 Open Market, Inc. Network sales system
US5604801A (en) 1995-02-03 1997-02-18 International Business Machines Corporation Public key data communications system under control of a portable security device
JPH08214281A (en) 1995-02-06 1996-08-20 Sony Corp Charging method and system
DE69637799D1 (en) 1995-02-13 2009-02-12 Intertrust Tech Corp Systems and procedures for secure transaction management and electronic legal protection
US5892900A (en) 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US6658568B1 (en) 1995-02-13 2003-12-02 Intertrust Technologies Corporation Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management
US6157721A (en) 1996-08-12 2000-12-05 Intertrust Technologies Corp. Systems and methods using cryptography to protect secure computing environments
US5677955A (en) 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
FR2733615B1 (en) 1995-04-26 1997-06-06 France Telecom MEMORY CARD AND METHOD FOR IMPLEMENTING SUCH A CARD
US5784612A (en) 1995-05-03 1998-07-21 International Business Machines Corporation Configuration and unconfiguration of distributed computing environment components
FR2735261B1 (en) 1995-06-08 1997-07-11 France Telecom METHOD OF MAKING A PAYMENT USING AN ACCOUNT MANAGER
US5790677A (en) 1995-06-29 1998-08-04 Microsoft Corporation System and method for secure electronic commerce transactions
US5689565A (en) 1995-06-29 1997-11-18 Microsoft Corporation Cryptography system and method for providing cryptographic services for a computer application
US5809144A (en) 1995-08-24 1998-09-15 Carnegie Mellon University Method and apparatus for purchasing and delivering digital goods over a network
US5638446A (en) 1995-08-28 1997-06-10 Bell Communications Research, Inc. Method for the secure distribution of electronic files in a distributed environment
JPH0981519A (en) 1995-09-08 1997-03-28 Kiyadeitsukusu:Kk Authentication method on network
US5721781A (en) 1995-09-13 1998-02-24 Microsoft Corporation Authentication system and method for smart card transactions
US5671279A (en) 1995-11-13 1997-09-23 Netscape Communications Corporation Electronic commerce using a secure courier system
US5870473A (en) 1995-12-14 1999-02-09 Cybercash, Inc. Electronic transfer system and method
US5745574A (en) 1995-12-15 1998-04-28 Entegrity Solutions Corporation Security infrastructure for electronic transactions
US5615269A (en) 1996-02-22 1997-03-25 Micali; Silvio Ideal electronic negotiations
US6138107A (en) 1996-01-04 2000-10-24 Netscape Communications Corporation Method and apparatus for providing electronic accounts over a public network
US6038551A (en) 1996-03-11 2000-03-14 Microsoft Corporation System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer
US5842211A (en) 1996-03-15 1998-11-24 Microsoft Corporation Method and system for transferring a bank file to an application program
US5937068A (en) 1996-03-22 1999-08-10 Activcard System and method for user authentication employing dynamic encryption variables
US5754772A (en) 1996-03-26 1998-05-19 Unisys Corporation Transaction service independent HTTP server-to-transaction gateway
US5850442A (en) 1996-03-26 1998-12-15 Entegrity Solutions Corporation Secure world wide electronic commerce over an open network
US6003007A (en) 1996-03-28 1999-12-14 Dirienzo; Andrew L. Attachment integrated claims system and operating method therefor
US5815657A (en) 1996-04-26 1998-09-29 Verifone, Inc. System, method and article of manufacture for network electronic authorization utilizing an authorization instrument
EP0807910B1 (en) 1996-05-16 2008-06-04 Nippon Telegraph And Telephone Corporation Electronic cash implementing method with a surveillance institution, and user apparatus and surveillance institution apparatus for implementing the same
US5889863A (en) 1996-06-17 1999-03-30 Verifone, Inc. System, method and article of manufacture for remote virtual point of sale processing utilizing a multichannel, extensible, flexible architecture
US5943424A (en) 1996-06-17 1999-08-24 Hewlett-Packard Company System, method and article of manufacture for processing a plurality of transactions from a single initiation point on a multichannel, extensible, flexible architecture
US6373950B1 (en) 1996-06-17 2002-04-16 Hewlett-Packard Company System, method and article of manufacture for transmitting messages within messages utilizing an extensible, flexible architecture
US6072870A (en) 1996-06-17 2000-06-06 Verifone Inc. System, method and article of manufacture for a gateway payment architecture utilizing a multichannel, extensible, flexible architecture
US6324525B1 (en) 1996-06-17 2001-11-27 Hewlett-Packard Company Settlement of aggregated electronic transactions over a network
IL128099A (en) 1996-07-22 2004-05-12 Cyva Res Corp Personal information security and exchange tool
US5944789A (en) 1996-08-14 1999-08-31 Emc Corporation Network file server maintaining local caches of file directory information in data mover computers
US6356878B1 (en) 1996-09-04 2002-03-12 Priceline.Com Incorporated Conditional purchase offer buyer agency system
US5956404A (en) 1996-09-30 1999-09-21 Schneier; Bruce Digital signature with auditing bits
US6029150A (en) 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
KR100213188B1 (en) 1996-10-05 1999-08-02 윤종용 Apparatus and method for user authentication
JP3440763B2 (en) 1996-10-25 2003-08-25 富士ゼロックス株式会社 Encryption device, decryption device, confidential data processing device, and information processing device
US6154844A (en) 1996-11-08 2000-11-28 Finjan Software, Ltd. System and method for attaching a downloadable security profile to a downloadable
US6212634B1 (en) 1996-11-15 2001-04-03 Open Market, Inc. Certifying authorization in computer networks
US5958051A (en) 1996-11-27 1999-09-28 Sun Microsystems, Inc. Implementing digital signatures for data streams and data archives
US6353812B2 (en) 1998-02-19 2002-03-05 Certco, Inc. Computer-based method and system for aiding transactions
US7177839B1 (en) 1996-12-13 2007-02-13 Certco, Inc. Reliance manager for electronic transaction system
US6035402A (en) 1996-12-20 2000-03-07 Gte Cybertrust Solutions Incorporated Virtual certificate authority
US5923552A (en) 1996-12-31 1999-07-13 Buildnet, Inc. Systems and methods for facilitating the exchange of information between separate business entities
US6085168A (en) 1997-02-06 2000-07-04 Fujitsu Limited Electronic commerce settlement system
US5861662A (en) 1997-02-24 1999-01-19 General Instrument Corporation Anti-tamper bond wire shield for an integrated circuit
US6044462A (en) 1997-04-02 2000-03-28 Arcanvs Method and apparatus for managing key revocation
US6477513B1 (en) 1997-04-03 2002-11-05 Walker Digital, Llc Method and apparatus for executing cryptographically-enabled letters of credit
US6766454B1 (en) 1997-04-08 2004-07-20 Visto Corporation System and method for using an authentication applet to identify and authenticate a user in a computer network
US6341353B1 (en) 1997-04-11 2002-01-22 The Brodia Group Smart electronic receipt system
US6105012A (en) 1997-04-22 2000-08-15 Sun Microsystems, Inc. Security system and method for financial institution server and client web browser
US6131162A (en) 1997-06-05 2000-10-10 Hitachi Ltd. Digital data authentication method
US6157917A (en) 1997-07-11 2000-12-05 Barber; Timothy P. Bandwidth-preserving method of charging for pay-per-access information on a network
US6073172A (en) 1997-07-14 2000-06-06 Freegate Corporation Initializing and reconfiguring a secure network interface
US6370249B1 (en) 1997-07-25 2002-04-09 Entrust Technologies, Ltd. Method and apparatus for public key management
US6125349A (en) 1997-10-01 2000-09-26 At&T Corp. Method and apparatus using digital credentials and other electronic certificates for electronic transactions
US5970475A (en) 1997-10-10 1999-10-19 Intelisys Electronic Commerce, Llc Electronic procurement system and method for trading partners
US6134327A (en) 1997-10-24 2000-10-17 Entrust Technologies Ltd. Method and apparatus for creating communities of trust in a secure communication system
US5991750A (en) 1997-10-24 1999-11-23 Ge Capital System and method for pre-authorization of individual account transactions
US6092201A (en) 1997-10-24 2000-07-18 Entrust Technologies Method and apparatus for extending secure communication operations via a shared list
KR100241350B1 (en) 1997-10-27 2000-02-01 정선종 Electronic certificate paper generation method
US7076784B1 (en) * 1997-10-28 2006-07-11 Microsoft Corporation Software component execution management using context objects for tracking externally-defined intrinsic properties of executing software components within an execution environment
US6157920A (en) 1997-11-19 2000-12-05 Lucent Technologies Inc. Executable digital cash for electronic commerce
US6052785A (en) 1997-11-21 2000-04-18 International Business Machines Corporation Multiple remote data access security mechanism for multitiered internet computer networks
US6092196A (en) 1997-11-25 2000-07-18 Nortel Networks Limited HTTP distributed remote user authentication system
US6170058B1 (en) 1997-12-23 2001-01-02 Arcot Systems, Inc. Method and apparatus for cryptographically camouflaged cryptographic key storage, certification and use
EP1050133B2 (en) 1998-01-02 2009-05-27 Cryptography Research Inc. Leak-resistant cryptographic method and apparatus
US6141679A (en) * 1998-02-06 2000-10-31 Unisys Corporation High performance distributed transaction processing methods and apparatus
US6134550A (en) 1998-03-18 2000-10-17 Entrust Technologies Limited Method and apparatus for use in determining validity of a certificate in a communication system employing trusted paths
US6081790A (en) 1998-03-20 2000-06-27 Citibank, N.A. System and method for secure presentment and payment over open networks
US5913210A (en) 1998-03-27 1999-06-15 Call; Charles G. Methods and apparatus for disseminating product information via the internet
US6314517B1 (en) 1998-04-02 2001-11-06 Entrust Technologies Limited Method and system for notarizing digital signature data in a system employing cryptography based security
US6157927A (en) * 1998-04-22 2000-12-05 Unisys Corporation Methods and apparatus for enabling a component in a first transaction processing environment to access a resource in another environment that is under the control of an Xatmi complaint transaction manager
US6385651B2 (en) 1998-05-05 2002-05-07 Liberate Technologies Internet service provider preliminary user registration mechanism provided by centralized authority
US6363365B1 (en) 1998-05-12 2002-03-26 International Business Machines Corp. Mechanism for secure tendering in an open electronic network
ATE548819T1 (en) 1998-06-03 2012-03-15 Cryptography Res Inc SYMMETRIC CRYPTOGRAPHIC COMPUTING METHOD AND DEVICE FOR MINIMIZING LOSS IN CHIP CARDS AND OTHER ENCRYPTION SYSTEMS
US6718470B1 (en) 1998-06-05 2004-04-06 Entrust Technologies Limited System and method for granting security privilege in a communication system
US6363479B1 (en) 1998-07-22 2002-03-26 Entrust Technologies Limited System and method for signing markup language data
US6330551B1 (en) 1998-08-06 2001-12-11 Cybersettle.Com, Inc. Computerized dispute resolution system and method
US6085321A (en) 1998-08-14 2000-07-04 Omnipoint Corporation Unique digital signature
US6301658B1 (en) 1998-09-09 2001-10-09 Secure Computing Corporation Method and system for authenticating digital certificates issued by an authentication hierarchy
US6272675B1 (en) * 1998-10-01 2001-08-07 Unisys Corporation Development system for automatically enabling a server application to execute with an XATMI-compliant transaction manager managing transactions within multiple environments
US6715080B1 (en) 1998-10-01 2004-03-30 Unisys Corporation Making CGI variables and cookie information available to an OLTP system
US7047416B2 (en) 1998-11-09 2006-05-16 First Data Corporation Account-based digital signature (ABDS) system
US7080409B2 (en) 1998-11-10 2006-07-18 Dan Eigeles Method for deployment of a workable public key infrastructure
US6260024B1 (en) 1998-12-02 2001-07-10 Gary Shkedy Method and apparatus for facilitating buyer-driven purchase orders on a commercial network system
US6044350A (en) 1998-12-24 2000-03-28 Pitney Bowes Inc. Certificate meter with selectable indemnification provisions
US6327578B1 (en) 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US6510513B1 (en) 1999-01-13 2003-01-21 Microsoft Corporation Security services and policy enforcement for electronic data
CA2361053A1 (en) 1999-01-29 2000-08-03 Richard Ankney Reliance manager for electronic transaction system
US6223291B1 (en) 1999-03-26 2001-04-24 Motorola, Inc. Secure wireless electronic-commerce system with digital product certificates and digital license certificates
US6711679B1 (en) 1999-03-31 2004-03-23 International Business Machines Corporation Public key infrastructure delegation
US6889325B1 (en) 1999-04-28 2005-05-03 Unicate Bv Transaction method and system for data networks, like internet
US6865674B1 (en) 1999-06-02 2005-03-08 Entrust Technologies Limited Dynamic trust anchor system and method
US6675153B1 (en) 1999-07-06 2004-01-06 Zix Corporation Transaction authorization system
US20010020228A1 (en) 1999-07-09 2001-09-06 International Business Machines Corporation Umethod, system and program for managing relationships among entities to exchange encryption keys for use in providing access and authorization to resources
US6609128B1 (en) * 1999-07-30 2003-08-19 Accenture Llp Codes table framework design in an E-commerce architecture
US6718535B1 (en) * 1999-07-30 2004-04-06 Accenture Llp System, method and article of manufacture for an activity framework design in an e-commerce based environment
US6704873B1 (en) * 1999-07-30 2004-03-09 Accenture Llp Secure gateway interconnection in an e-commerce based environment
US7100195B1 (en) * 1999-07-30 2006-08-29 Accenture Llp Managing user information on an e-commerce system
US6523027B1 (en) * 1999-07-30 2003-02-18 Accenture Llp Interfacing servers in a Java based e-commerce architecture
US6633878B1 (en) * 1999-07-30 2003-10-14 Accenture Llp Initializing an ecommerce database framework
US6601233B1 (en) * 1999-07-30 2003-07-29 Accenture Llp Business components framework
WO2001011843A1 (en) 1999-08-06 2001-02-15 Sudia Frank W Blocked tree authorization and status systems
US6449598B1 (en) 1999-09-02 2002-09-10 Xware Compliance, Inc. Health care policy on-line maintenance dissemination and compliance testing system
US7206805B1 (en) * 1999-09-09 2007-04-17 Oracle International Corporation Asynchronous transcription object management system
AU7357200A (en) 1999-09-10 2001-04-10 Mack Hicks System and method for providing certificate-related and other services
US20020029200A1 (en) 1999-09-10 2002-03-07 Charles Dulin System and method for providing certificate validation and other services
AU7123900A (en) 1999-09-10 2001-04-10 Jackson Brandenburg System and method for facilitating access by sellers to certificate-related and other services
US6853988B1 (en) 1999-09-20 2005-02-08 Security First Corporation Cryptographic server with provisions for interoperability between cryptographic systems
DE60040926D1 (en) 1999-09-24 2009-01-08 Identrust Inc SYSTEM AND METHOD FOR PROVIDING PAYMENT SERVICES IN E-COMMERCE
US6598027B1 (en) 1999-11-16 2003-07-22 Xs, Inc. Systems, methods and computer program products for conducting regulation-compliant commercial transactions of regulated goods via a computer network
US6643701B1 (en) 1999-11-17 2003-11-04 Sun Microsystems, Inc. Method and apparatus for providing secure communication with a relay in a network
US6763459B1 (en) 2000-01-14 2004-07-13 Hewlett-Packard Company, L.P. Lightweight public key infrastructure employing disposable certificates
WO2001054038A1 (en) 2000-01-20 2001-07-26 David Thieme System and method for facilitating secure payment with privacy over a computer network including the internet
AU2001257573A1 (en) 2000-02-11 2001-08-20 Verimatrix, Inc. Web based human services conferencing network
GB0014414D0 (en) 2000-06-12 2000-08-09 Business Information Publicati Electronic deposit box system
AU2001286464A1 (en) 2000-08-14 2002-02-25 Peter H. Gien System and method for secure smartcard issuance
AU2001284881A1 (en) 2000-08-14 2002-02-25 Peter H. Gien System and method for providing warranties in electronic commerce
JP3588042B2 (en) 2000-08-30 2004-11-10 株式会社日立製作所 Certificate validity checking method and device
WO2002021405A1 (en) 2000-09-07 2002-03-14 Closingguard.Com, Inc. System and method of managing financial transactions over an electronic network
WO2002032064A1 (en) 2000-09-08 2002-04-18 Tallent Guy S System and method for providing authorization and other services
WO2002021409A1 (en) 2000-09-08 2002-03-14 Tallent Guy S System and method for transparently providing certificate validation and other services within an electronic transaction
WO2002029702A1 (en) 2000-10-04 2002-04-11 American Express Travel Related Services Company, Inc. System and method for providing feedback in an interactive payment system
US20020065695A1 (en) 2000-10-10 2002-05-30 Francoeur Jacques R. Digital chain of trust method for electronic commerce
CA2436143A1 (en) 2001-01-26 2002-08-01 Shearman & Sterling Methods and systems for electronically representing records of obligations
US20020124172A1 (en) 2001-03-05 2002-09-05 Brian Manahan Method and apparatus for signing and validating web pages
US7167985B2 (en) 2001-04-30 2007-01-23 Identrus, Llc System and method for providing trusted browser verification
US6973571B2 (en) 2001-07-03 2005-12-06 Bank Of America Corporation System, apparatus, and method for performing cryptographic validity services
GB0117429D0 (en) 2001-07-17 2001-09-12 Trustis Ltd Trust management
US20050132229A1 (en) 2003-11-12 2005-06-16 Nokia Corporation Virtual private network based on root-trust module computing platforms
US7130998B2 (en) 2004-10-14 2006-10-31 Palo Alto Research Center, Inc. Using a portable security token to facilitate cross-certification between certification authorities
US8151317B2 (en) 2006-07-07 2012-04-03 International Business Machines Corporation Method and system for policy-based initiation of federation management

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5610982A (en) * 1996-05-15 1997-03-11 Micali; Silvio Compact certification with threshold signatures
US20010011255A1 (en) * 1996-12-13 2001-08-02 Alan Asay Reliance management for electronic transaction system
US6285991B1 (en) * 1996-12-13 2001-09-04 Visa International Service Association Secure interactive electronic account statement delivery system
US20040111379A1 (en) * 1999-02-12 2004-06-10 Mack Hicks System and method for providing certification-related and other services

Cited By (245)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7743248B2 (en) * 1995-01-17 2010-06-22 Eoriginal, Inc. System and method for a remote access service enabling trust and interoperability when retrieving certificate status from multiple certification authority reporting components
US20040093493A1 (en) * 1995-01-17 2004-05-13 Bisbee Stephen F. System and method for electronic transmission, storage and retrieval of authenticated documents
US20050055567A1 (en) * 1995-10-02 2005-03-10 Phil Libin Controlling access to an area
US7716486B2 (en) 1995-10-02 2010-05-11 Corestreet, Ltd. Controlling group access to doors
US20020165824A1 (en) * 1995-10-02 2002-11-07 Silvio Micali Scalable certificate validation and simplified PKI management
US7822989B2 (en) 1995-10-02 2010-10-26 Corestreet, Ltd. Controlling access to an area
US20050044386A1 (en) * 1995-10-02 2005-02-24 Phil Libin Controlling access using additional data
US8732457B2 (en) 1995-10-02 2014-05-20 Assa Abloy Ab Scalable certificate validation and simplified PKI management
US8015597B2 (en) 1995-10-02 2011-09-06 Corestreet, Ltd. Disseminating additional data used for controlling access
US20030221101A1 (en) * 1995-10-02 2003-11-27 Silvio Micali Efficient certificate revocation
US7660994B2 (en) 1995-10-24 2010-02-09 Corestreet, Ltd. Access control
US20050055548A1 (en) * 1995-10-24 2005-03-10 Silvio Micali Certificate revocation system
US20050010783A1 (en) * 1995-10-24 2005-01-13 Phil Libin Access control
US8261319B2 (en) 1995-10-24 2012-09-04 Corestreet, Ltd. Logging access attempts to an area
US6665672B2 (en) * 1998-10-30 2003-12-16 Xerox Corporation Transaction/object accounting method and system
US9684889B2 (en) 1999-02-12 2017-06-20 Identrust, Inc. System and method for providing certification-related and other services
US8818903B2 (en) 1999-09-10 2014-08-26 Charles Dulin Transaction coordinator for digital certificate validation and other services
US20060004670A1 (en) * 1999-09-24 2006-01-05 Mckenney Mary K System and method for providing payment services in electronic commerce
US7765161B2 (en) 1999-09-24 2010-07-27 Identrust, Inc. System and method for providing payment services in electronic commerce
US20030074313A1 (en) * 2000-02-03 2003-04-17 Mcconnell Richard Network-based billing method and system
US6948060B1 (en) * 2000-08-11 2005-09-20 Intel Corporation Method and apparatus for monitoring encrypted communication in a network
US20060179008A1 (en) * 2000-09-08 2006-08-10 Tallent Guy S Jr Provision of authorization and other services
US20060123227A1 (en) * 2000-09-08 2006-06-08 Miller Lawrence R System and method for transparently providing certificate validation and other services within an electronic transaction
US7734924B2 (en) 2000-09-08 2010-06-08 Identrust, Inc. System and method for transparently providing certificate validation and other services within an electronic transaction
US8892475B2 (en) * 2000-09-08 2014-11-18 Identrust, Inc. Provision of authorization and other services
US7707403B2 (en) * 2000-12-12 2010-04-27 Ntt Docomo, Inc. Authentication method, communication apparatus, and relay apparatus
US20030140226A1 (en) * 2000-12-12 2003-07-24 Masaaki Yamamoto Authentication method, communication apparatus, and relay apparatus
US20020107795A1 (en) * 2001-02-02 2002-08-08 Brian Minear Application distribution and billing system in a wireless network
US20020144122A1 (en) * 2001-04-03 2002-10-03 S.W.I.F.T. System and method for facilitating trusted transactions between businesses
US20020184182A1 (en) * 2001-05-31 2002-12-05 Nang Kon Kwan Method and system for answering online certificate status protocol (OCSP) requests without certificate revocation lists (CRL)
US6970862B2 (en) * 2001-05-31 2005-11-29 Sun Microsystems, Inc. Method and system for answering online certificate status protocol (OCSP) requests without certificate revocation lists (CRL)
US20030018585A1 (en) * 2001-07-21 2003-01-23 International Business Machines Corporation Method and system for the communication of assured reputation information
US7962779B2 (en) 2001-08-03 2011-06-14 Emc Corporation Systems and methods for a distributed file system with data recovery
US20080243773A1 (en) * 2001-08-03 2008-10-02 Isilon Systems, Inc. Systems and methods for a distributed file system with data recovery
US20100235413A1 (en) * 2001-08-03 2010-09-16 Isilon Systems, Inc. Systems and methods for providing a distributed file system utilizing metadata to track information about data stored throughout the system
US8112395B2 (en) 2001-08-03 2012-02-07 Emc Corporation Systems and methods for providing a distributed file system utilizing metadata to track information about data stored throughout the system
US20060173758A1 (en) * 2001-08-13 2006-08-03 Brian Minear System and method for providing subscribed applications on wireless devices over a wireless network
US10009743B2 (en) 2001-08-13 2018-06-26 Qualcomm Incorporated System and method for providing subscribed applications on wireless devices over a wireless network
US20030051047A1 (en) * 2001-08-15 2003-03-13 Gerald Horel Data synchronization interface
US9203923B2 (en) 2001-08-15 2015-12-01 Qualcomm Incorporated Data synchronization interface
US20030078886A1 (en) * 2001-08-15 2003-04-24 Brian Minear Application distribution and billing system in a wireless network
US7051065B2 (en) * 2001-08-17 2006-05-23 Hewlett-Packard Development Company, L.P. Method and system for performing fault-tolerant online validation of service requests
US20030055873A1 (en) * 2001-08-17 2003-03-20 Fernando Pedone Method and system for performing fault-tolerant online validation of service requests
US20140304348A1 (en) * 2001-08-30 2014-10-09 Telecommunication Systems, Inc. Method and Apparatus for Storing Real-Time Text Messages
US20030065920A1 (en) * 2001-10-01 2003-04-03 International Business Machines Corporation Method and apparatus for using host authentication for automated public key certification
US20030212632A1 (en) * 2002-01-07 2003-11-13 S.W.I.F.T.S.C.; Electronic payment initiation and assurance system
US7913314B2 (en) 2002-02-21 2011-03-22 Adobe Systems Incorporated Application rights enabling
US8256016B2 (en) 2002-02-21 2012-08-28 Adobe Systems Incorporated Application rights enabling
US20070150964A1 (en) * 2002-02-21 2007-06-28 Adobe Systems Incorporated Application Rights Enabling
US8307421B2 (en) * 2002-05-17 2012-11-06 Microsoft Corporation End-to-end authentication of session initiation protocol messages using certificates
US8732818B2 (en) 2002-05-17 2014-05-20 Microsoft Corporation End-to-end authentication of session initiation protocol messages using certificates
US20080046745A1 (en) * 2002-05-17 2008-02-21 Microsoft Corporation End-to-end authentication of session initiation protocol messages using certificates
US20040043753A1 (en) * 2002-08-30 2004-03-04 Wake Susan L. System and method for third party application sales and services to wireless devices
WO2004036443A1 (en) * 2002-09-09 2004-04-29 Atitania Ltd. Code generator for a distributed processing system
US7937421B2 (en) 2002-11-14 2011-05-03 Emc Corporation Systems and methods for restriping files in a distributed file system
US8660960B2 (en) 2002-11-27 2014-02-25 Adobe Systems Incorporated Document digest allowing selective changes to a document
US8151114B2 (en) 2002-11-27 2012-04-03 Adobe Systems Incorporated Dynamic enabling of functionality in electronic document readers
US7698559B1 (en) 2002-11-27 2010-04-13 Adobe Systems Incorporated Dynamic enabling of functionality in electronic document readers
US9253173B2 (en) 2002-12-09 2016-02-02 Oracle International Corporation System and method for supporting security administration
US20040158737A1 (en) * 2002-12-09 2004-08-12 Hong-Hsi Lo System and method for single security administration
WO2004054152A1 (en) * 2002-12-09 2004-06-24 Bea Systems, Inc. System and method for single security administration
US7831999B2 (en) 2002-12-09 2010-11-09 Bea Systems, Inc. System and method for single security administration
US20110023095A1 (en) * 2002-12-09 2011-01-27 Bea Systems, Inc. System and method for supporting security administration
US7490136B2 (en) * 2002-12-17 2009-02-10 Ricoh Company, Ltd. Digital contents distributing system and distributing method
US20040153528A1 (en) * 2002-12-17 2004-08-05 Akira Suzuki Digital contents distributing system and distributing method
US7657751B2 (en) 2003-05-13 2010-02-02 Corestreet, Ltd. Efficient and secure data currentness systems
US20040237031A1 (en) * 2003-05-13 2004-11-25 Silvio Micali Efficient and secure data currentness systems
US20040230891A1 (en) * 2003-05-16 2004-11-18 Pravetz James D. Document modification detection and prevention
US8533480B2 (en) 2003-05-16 2013-09-10 Adobe Systems Incorporated Document modification detection and prevention
US9338011B2 (en) 2003-05-16 2016-05-10 Adobe Systems Incorporated Document modification detection and prevention
US9705917B2 (en) 2003-05-16 2017-07-11 Adobe Systems Incorporated Document modification detection and prevention
US7735144B2 (en) 2003-05-16 2010-06-08 Adobe Systems Incorporated Document modification detection and prevention
US7512977B2 (en) * 2003-06-11 2009-03-31 Symantec Corporation Intrustion protection system utilizing layers
US20050257265A1 (en) * 2003-06-11 2005-11-17 Cook Randall R Intrustion protection system utilizing layers
GB2422077A (en) * 2003-08-12 2006-07-12 Intel Corp Method for using trusted,hardware-based identity credentials in runtime package signature to secure mobile communication and high-value transaction execution
GB2422077B (en) * 2003-08-12 2007-10-10 Intel Corp Method for using trusted,hardware-based identity credentials in runtime package signature to secure mobile communication and high-value trans action execution
WO2005020542A1 (en) * 2003-08-12 2005-03-03 Intel Corporation Method for using trusted, hardware-based identity credentials in runtime package signature to secure mobile communications and high-value transaction execution
US20050039016A1 (en) * 2003-08-12 2005-02-17 Selim Aissi Method for using trusted, hardware-based identity credentials in runtime package signature to secure mobile communications and high-value transaction execution
US20050102326A1 (en) * 2003-10-22 2005-05-12 Nitzan Peleg Method and apparatus for performing conflict resolution in database logging
US20050154918A1 (en) * 2003-11-19 2005-07-14 David Engberg Distributed delegated path discovery and validation
US8707030B2 (en) 2003-11-19 2014-04-22 Corestreet, Ltd. Distributed delegated path discovery and validation
US20050193204A1 (en) * 2004-01-09 2005-09-01 David Engberg Communication-efficient real time credentials for OCSP and distributed OCSP
US9461828B2 (en) 2004-01-09 2016-10-04 Assa Abloy Ab Signature-efficient real time credentials for OCSP and distributed OCSP
US20050154878A1 (en) * 2004-01-09 2005-07-14 David Engberg Signature-efficient real time credentials for OCSP and distributed OCSP
US7966487B2 (en) 2004-01-09 2011-06-21 Corestreet, Ltd. Communication-efficient real time credentials for OCSP and distributed OCSP
WO2005071877A1 (en) * 2004-01-09 2005-08-04 Corestreet, Ltd. Signature-efficient real time credentials for ocsp and distributed ocsp
EP1706954B1 (en) * 2004-01-09 2018-07-25 Assa Abloy Ab Signature-efficient real time credentials for ocsp and distributed ocsp
US20050154879A1 (en) * 2004-01-09 2005-07-14 David Engberg Batch OCSP and batch distributed OCSP
US10043170B2 (en) 2004-01-21 2018-08-07 Qualcomm Incorporated Application-based value billing in a wireless subscriber network
US20050192878A1 (en) * 2004-01-21 2005-09-01 Brian Minear Application-based value billing in a wireless subscriber network
US20050278534A1 (en) * 2004-05-27 2005-12-15 International Business Machines Corporation Method and system for certification path processing
US7444509B2 (en) * 2004-05-27 2008-10-28 International Business Machines Corporation Method and system for certification path processing
US20050289047A1 (en) * 2004-06-28 2005-12-29 Oliver Mitchell B Virtual marketplace for wireless device applications and services with integrated multi-party settlement
US7593901B2 (en) * 2004-06-30 2009-09-22 Ats S.R.L. System and method for improving reliability of distributed electronic transactions
US20100070597A1 (en) * 2004-06-30 2010-03-18 ATS s.r.I. System and method for improving reliability of distributed electronic transactions
US8024199B2 (en) 2004-06-30 2011-09-20 A.T.S. R&L S.R.L., I.S System and method for improving reliability of distributed electronic transactions
US20060036546A1 (en) * 2004-06-30 2006-02-16 Franco Arcieri System and method for improving reliability of distributed electronic transactions
US9361621B2 (en) 2004-06-30 2016-06-07 Konvax Corporation System and method for improving reliability of distributed electronic transactions
US20060006222A1 (en) * 2004-07-09 2006-01-12 U.S. Bank Corporation System and method for managing requests to document archives, routing requests and delivering requests to a variety of channels or delivery mechanisms
US7431201B2 (en) * 2004-07-09 2008-10-07 U. S. Bank Corporation System and method for managing requests to document archives, routing requests and delivering requests to a variety of channels or delivery mechanisms
US20060089970A1 (en) * 2004-09-30 2006-04-27 Microsoft Corporation Enforcing rights mangement through edge email servers
US20060101062A1 (en) * 2004-10-29 2006-05-11 Godman Peter J Distributed system with asynchronous execution systems and methods
US8140623B2 (en) 2004-10-29 2012-03-20 Emc Corporation Non-blocking commit protocol systems and methods
US8051425B2 (en) * 2004-10-29 2011-11-01 Emc Corporation Distributed system with asynchronous execution systems and methods
US20070168351A1 (en) * 2004-10-29 2007-07-19 Fachan Neal T Non-blocking commit protocol systems and methods
US8238350B2 (en) 2004-10-29 2012-08-07 Emc Corporation Message batching with checkpoints systems and methods
US8055711B2 (en) 2004-10-29 2011-11-08 Emc Corporation Non-blocking commit protocol systems and methods
US20060097843A1 (en) * 2004-11-10 2006-05-11 Phil Libin Actuating a security system using a wireless device
US20060156063A1 (en) * 2004-12-20 2006-07-13 Travel Sciences, Inc. Instant messaging transaction integration
US8185945B1 (en) * 2005-03-02 2012-05-22 Crimson Corporation Systems and methods for selectively requesting certificates during initiation of secure communication sessions
US9185538B2 (en) 2005-05-31 2015-11-10 Qualcomm Incorporated Wireless subscriber application and content distribution and differentiated pricing
US20060271449A1 (en) * 2005-05-31 2006-11-30 Oliver Mitchell B Wireless subscriber application and content distribution and differentiated pricing
US9350875B2 (en) * 2005-05-31 2016-05-24 Qualcomm Incorporated Wireless subscriber billing and distribution
US20060270386A1 (en) * 2005-05-31 2006-11-30 Julie Yu Wireless subscriber billing and distribution
US8775316B2 (en) * 2005-07-20 2014-07-08 Wms Gaming Inc. Wagering game with encryption and authentication
US20110183748A1 (en) * 2005-07-20 2011-07-28 Wms Gaming Inc. Wagering game with encryption and authentication
US20070067238A1 (en) * 2005-09-21 2007-03-22 Capital One Financial Corporation System and method for transferring information between financial accounts
US8176013B2 (en) 2005-10-21 2012-05-08 Emc Corporation Systems and methods for accessing and updating distributed data
US8214334B2 (en) 2005-10-21 2012-07-03 Emc Corporation Systems and methods for distributed system scanning
US8054765B2 (en) 2005-10-21 2011-11-08 Emc Corporation Systems and methods for providing variable protection
US8214400B2 (en) 2005-10-21 2012-07-03 Emc Corporation Systems and methods for maintaining distributed data
US20090252066A1 (en) * 2005-10-21 2009-10-08 Isilon Systems, Inc. Systems and methods for providing variable protection
US20110145195A1 (en) * 2005-10-21 2011-06-16 Isilon Systems, Inc. Systems and methods for accessing and updating distributed data
US7917474B2 (en) 2005-10-21 2011-03-29 Isilon Systems, Inc. Systems and methods for accessing and updating distributed data
US20070101401A1 (en) * 2005-10-27 2007-05-03 Genty Denise M Method and apparatus for super secure network authentication
US8458064B1 (en) 2006-01-30 2013-06-04 Capital One Financial Corporation System and method for transferring electronic account information
US9143622B2 (en) 2006-02-17 2015-09-22 Qualcomm Incorporated Prepay accounts for applications, services and content for communication devices
US8625464B2 (en) 2006-02-17 2014-01-07 Emc Corporation Systems and methods for providing a quiescing protocol
US20110044209A1 (en) * 2006-02-17 2011-02-24 Isilon Systems, Inc. Systems and methods for providing a quiescing protocol
US9185234B2 (en) 2006-02-22 2015-11-10 Qualcomm Incorporated Automated account mapping in a wireless subscriber billing system
US8005865B2 (en) 2006-03-31 2011-08-23 Emc Corporation Systems and methods for notifying listeners of events
US20100306786A1 (en) * 2006-03-31 2010-12-02 Isilon Systems, Inc. Systems and methods for notifying listeners of events
US8356150B2 (en) 2006-08-18 2013-01-15 Emc Corporation Systems and methods for providing nonlinear journaling
US8027984B2 (en) 2006-08-18 2011-09-27 Emc Corporation Systems and methods of reverse lookup
US20100161556A1 (en) * 2006-08-18 2010-06-24 Anderson Robert J Systems and methods for a snapshot of data
US8356013B2 (en) 2006-08-18 2013-01-15 Emc Corporation Systems and methods for a snapshot of data
US20100161557A1 (en) * 2006-08-18 2010-06-24 Anderson Robert J Systems and methods for a snapshot of data
US20090327218A1 (en) * 2006-08-18 2009-12-31 Passey Aaron J Systems and Methods of Reverse Lookup
US20110022790A1 (en) * 2006-08-18 2011-01-27 Isilon Systems, Inc. Systems and methods for providing nonlinear journaling
US8015156B2 (en) 2006-08-18 2011-09-06 Emc Corporation Systems and methods for a snapshot of data
US8010493B2 (en) 2006-08-18 2011-08-30 Emc Corporation Systems and methods for a snapshot of data
US8380689B2 (en) 2006-08-18 2013-02-19 Emc Corporation Systems and methods for providing nonlinear journaling
US20080046443A1 (en) * 2006-08-18 2008-02-21 Fachan Neal T Systems and methods for providing nonlinear journaling
US7899800B2 (en) 2006-08-18 2011-03-01 Isilon Systems, Inc. Systems and methods for providing nonlinear journaling
US20110087635A1 (en) * 2006-08-18 2011-04-14 Isilon Systems, Inc. Systems and methods for a snapshot of data
US7953704B2 (en) 2006-08-18 2011-05-31 Emc Corporation Systems and methods for a snapshot of data
US20080109653A1 (en) * 2006-11-06 2008-05-08 Fuji Xerox Co., Ltd. Information-processing apparatus, information-processing method, and communication control program recording medium
WO2008058172A3 (en) * 2006-11-08 2008-08-21 Managed Inv S Llc System and method for reducing click fraud
WO2008058172A2 (en) * 2006-11-08 2008-05-15 Managed Inventions, Llc System and method for reducing click fraud
US8286029B2 (en) 2006-12-21 2012-10-09 Emc Corporation Systems and methods for managing unavailable storage devices
US20110060779A1 (en) * 2006-12-22 2011-03-10 Isilon Systems, Inc. Systems and methods of directory entry encodings
US8060521B2 (en) 2006-12-22 2011-11-15 Emc Corporation Systems and methods of directory entry encodings
US20090210880A1 (en) * 2007-01-05 2009-08-20 Isilon Systems, Inc. Systems and methods for managing semantic locks
US8082379B2 (en) 2007-01-05 2011-12-20 Emc Corporation Systems and methods for managing semantic locks
US8966080B2 (en) 2007-04-13 2015-02-24 Emc Corporation Systems and methods of managing resource utilization on a threaded computer system
US8015216B2 (en) 2007-04-13 2011-09-06 Emc Corporation Systems and methods of providing possible value ranges
US8195905B2 (en) 2007-04-13 2012-06-05 Emc Corporation Systems and methods of quota accounting
US20110113211A1 (en) * 2007-04-13 2011-05-12 Isilon Systems, Inc. Systems and methods of quota accounting
US7900015B2 (en) 2007-04-13 2011-03-01 Isilon Systems, Inc. Systems and methods of quota accounting
US7966289B2 (en) 2007-08-21 2011-06-21 Emc Corporation Systems and methods for reading objects in a file system
US20090055604A1 (en) * 2007-08-21 2009-02-26 Lemar Eric M Systems and methods for portals into snapshot data
US8200632B2 (en) 2007-08-21 2012-06-12 Emc Corporation Systems and methods for adaptive copy on write
US7882068B2 (en) 2007-08-21 2011-02-01 Isilon Systems, Inc. Systems and methods for adaptive copy on write
US7949692B2 (en) 2007-08-21 2011-05-24 Emc Corporation Systems and methods for portals into snapshot data
US20090210703A1 (en) * 2008-01-18 2009-08-20 Epstein William C Binding a digital certificate to multiple trust domains
US8793487B2 (en) 2008-01-18 2014-07-29 Identrust, Inc. Binding a digital certificate to multiple trust domains
US7971021B2 (en) 2008-03-27 2011-06-28 Emc Corporation Systems and methods for managing stalled storage devices
US7953709B2 (en) 2008-03-27 2011-05-31 Emc Corporation Systems and methods for a read only mode for a portion of a storage system
US7949636B2 (en) 2008-03-27 2011-05-24 Emc Corporation Systems and methods for a read only mode for a portion of a storage system
US20090248975A1 (en) * 2008-03-27 2009-10-01 Asif Daud Systems and methods for managing stalled storage devices
US20090248765A1 (en) * 2008-03-27 2009-10-01 Akidau Tyler A Systems and methods for a read only mode for a portion of a storage system
US7984324B2 (en) 2008-03-27 2011-07-19 Emc Corporation Systems and methods for managing stalled storage devices
US8819417B2 (en) 2008-05-30 2014-08-26 Hitachi, Ltd. Validation server, validation method, and program
US8176316B2 (en) 2008-05-30 2012-05-08 Hitachi, Ltd. Validation server, validation method, and program
EP2129077A1 (en) * 2008-05-30 2009-12-02 Hitachi Ltd. Validation server, validation method and program
US20090300349A1 (en) * 2008-05-30 2009-12-03 Yoko Hashimoto Validation server, validation method, and program
US20100017413A1 (en) * 2008-07-17 2010-01-21 Ian Edward James Systems and methods for transferring value
US20100058070A1 (en) * 2008-08-28 2010-03-04 Garay Juan A Message authentication code pre-computation with applications to secure memory
US8799679B2 (en) * 2008-08-28 2014-08-05 Alcatel Lucent Message authentication code pre-computation with applications to secure memory
US8452984B2 (en) * 2008-08-28 2013-05-28 Alcatel Lucent Message authentication code pre-computation with applications to secure memory
US20130254557A1 (en) * 2008-08-28 2013-09-26 Alcatel Lucent Message authentication code pre-computation with applications to secure memory
US8850576B2 (en) * 2009-01-20 2014-09-30 Check Point Software Technologies Ltd. Methods for inspecting security certificates by network security devices to detect and prevent the use of invalid certificates
US20120167212A1 (en) * 2009-01-20 2012-06-28 Check Point Software Technologies, Ltd. Methods for inspecting security certificates by network security devices to detect and prevent the use of invalid certificates
US20100318791A1 (en) * 2009-06-12 2010-12-16 General Instrument Corporation Certificate status information protocol (csip) proxy and responder
US8627063B2 (en) * 2009-12-23 2014-01-07 Citrix Systems, Inc. Systems and methods for flash crowd control and batching OCSP requests via online certificate status protocol
US20110154026A1 (en) * 2009-12-23 2011-06-23 Christofer Edstrom Systems and methods for parallel processing of ocsp requests during ssl handshake
US20110154018A1 (en) * 2009-12-23 2011-06-23 Christofer Edstrom Systems and methods for flash crowd control and batching ocsp requests via online certificate status protocol
US9172545B2 (en) 2009-12-23 2015-10-27 Citrix Systems, Inc. Systems and methods for evaluating and prioritizing responses from multiple OCSP responders
US20110154017A1 (en) * 2009-12-23 2011-06-23 Christofer Edstrom Systems and methods for evaluating and prioritizing responses from multiple ocsp responders
US9203627B2 (en) 2009-12-23 2015-12-01 Citrix Systems, Inc. Systems and methods for flash crowd control and batching OCSP requests via online certificate status protocol
US8621204B2 (en) * 2009-12-23 2013-12-31 Citrix Systems, Inc. Systems and methods for evaluating and prioritizing responses from multiple OCSP responders
US20110161663A1 (en) * 2009-12-29 2011-06-30 General Instrument Corporation Intelligent caching for ocsp service optimization
CN102956000A (en) * 2011-08-18 2013-03-06 招商银行股份有限公司 Method and device for payment intermediation transaction data processing and payment intermediation network system
US11410143B2 (en) 2012-07-18 2022-08-09 Swoop Ip Holdings Llc Email-based e-commerce
US10438182B2 (en) * 2012-07-18 2019-10-08 Swoop Ip Holdings Llc Email-based e-commerce
US8930694B2 (en) 2012-08-02 2015-01-06 Banco Bilbao Vizcaya Argentaria, S.A. Method for the generation of a code, and method and system for the authorization of an operation
US20140278541A1 (en) * 2013-03-14 2014-09-18 Skyscape.Com, Inc. Toolkit system and method for managing delivery of services and content for health care professionals via an electronic health record system
US11277414B2 (en) 2013-07-08 2022-03-15 Ssh Communications Security Oyj Trust relationships in a computerized system
US10880314B2 (en) * 2013-07-08 2020-12-29 Ssh Communications Security Oyj Trust relationships in a computerized system
US20190281067A1 (en) * 2013-07-08 2019-09-12 Ssh Communications Security Oyj Trust Relationships in a Computerized System
US11212274B2 (en) * 2013-10-09 2021-12-28 Digicert, Inc. Accelerating OCSP responses via content delivery network collaboration
US10404681B2 (en) 2013-10-09 2019-09-03 Digicert, Inc. Accelerating OCSP responses via content delivery network collaboration
US20150100779A1 (en) * 2013-10-09 2015-04-09 Symantec Corporation Reducing latency for certificate validity messages using private content delivery networks
US10110592B2 (en) * 2013-10-09 2018-10-23 Digicert, Inc. Reducing latency for certificate validity messages using private content delivery networks
US9949115B2 (en) 2014-06-10 2018-04-17 Qualcomm Incorporated Common modulus RSA key pairs for signature generation and encryption/decryption
EP3155753A2 (en) * 2014-06-10 2017-04-19 Qualcomm Incorporated Common modulus rsa key pairs for signature generation and encryption/decryption
US10149154B2 (en) 2015-08-21 2018-12-04 Afero, Inc. Apparatus and method for sharing WiFi security data in an internet of things (IoT) system
US10659961B2 (en) 2015-08-21 2020-05-19 Afero, Inc. Apparatus and method for sharing WiFi security data in an internet of things (IoT) system
US9843929B2 (en) 2015-08-21 2017-12-12 Afero, Inc. Apparatus and method for sharing WiFi security data in an internet of things (IoT) system
US9942837B2 (en) 2015-08-25 2018-04-10 Afero, Inc. Apparatus and method for a dynamic scan interval for a wireless device
US20180219689A1 (en) * 2015-09-30 2018-08-02 Hewlett-Packard Development Company, L.P. Certificate analysis
US11032087B2 (en) * 2015-09-30 2021-06-08 Hewlett-Packard Development Company, L.P. Certificate analysis
US10805344B2 (en) 2015-12-14 2020-10-13 Afero, Inc. Apparatus and method for obscuring wireless communication patterns
US20170171314A1 (en) * 2015-12-14 2017-06-15 Afero, Inc. Internet of things (iot) apparatus and method for coin operated devices
US10362114B2 (en) * 2015-12-14 2019-07-23 Afero, Inc. Internet of things (IoT) apparatus and method for coin operated devices
US20170169264A1 (en) * 2015-12-14 2017-06-15 Afero, Inc. Internet of things (iot) apparatus and method for electronic shelf tags
US10169626B2 (en) * 2015-12-14 2019-01-01 Afero, Inc. Internet of things (IOT) apparatus and method for electronic shelf tags
US10447784B2 (en) * 2015-12-14 2019-10-15 Afero, Inc. Apparatus and method for modifying packet interval timing to identify a data transfer condition
US10091242B2 (en) 2015-12-14 2018-10-02 Afero, Inc. System and method for establishing a secondary communication channel to control an internet of things (IOT) device
US20170171313A1 (en) * 2015-12-14 2017-06-15 Afero, Inc. Apparatus and method for modifying packet interval timing to identify a data transfer condition
US10992746B2 (en) * 2015-12-15 2021-04-27 Microsoft Technology Licensing, Llc Automatic system response to external field-replaceable unit (FRU) process
US10742419B2 (en) * 2016-03-15 2020-08-11 Visa International Service Association Validation cryptogram for transaction
US20170351542A1 (en) * 2016-06-01 2017-12-07 Red Hat, Inc. Non-repudiable transaction protocol
US20190188029A1 (en) * 2016-06-01 2019-06-20 Red Hat, Inc. Non-repudiable transaction protocol
US11150938B2 (en) * 2016-06-01 2021-10-19 Red Hat, Inc. Non-repudiable transaction protocol
US10228967B2 (en) * 2016-06-01 2019-03-12 Red Hat, Inc. Non-repudiable transaction protocol
US10977635B2 (en) * 2017-01-30 2021-04-13 Ncr Corporation User-controlled transaction authorization
US20180218366A1 (en) * 2017-01-30 2018-08-02 Ncr Corporation User-controlled transaction authorization
US11659394B1 (en) * 2017-05-24 2023-05-23 Jonathan Grier Agile node isolation using packet level non-repudiation for mobile networks
US11706624B1 (en) * 2017-05-24 2023-07-18 Jonathan Grier Agile node isolation through using packet level non-repudiation for mobile networks
US10966091B1 (en) * 2017-05-24 2021-03-30 Jonathan Grier Agile node isolation using packet level non-repudiation for mobile networks
CN107229541A (en) * 2017-06-20 2017-10-03 携程旅游信息技术(上海)有限公司 Backup method, standby system and the server of Transaction Information
WO2018236401A1 (en) 2017-06-23 2018-12-27 Visa International Service Association Verification and encryption scheme in data storage
EP3642998A4 (en) * 2017-06-23 2020-05-06 Visa International Service Association Verification and encryption scheme in data storage
US20210241270A1 (en) * 2017-12-28 2021-08-05 Acronis International Gmbh System and method of blockchain transaction verification
TWI695614B (en) * 2019-03-13 2020-06-01 開曼群島商庫幣科技有限公司 Method for digital currency transaction with authorization of multiple private key
US11133942B1 (en) * 2019-05-15 2021-09-28 Wells Fargo Bank, N.A. Systems and methods of ring usage certificate extension
US11849050B1 (en) 2019-05-15 2023-12-19 Wells Fargo Bank, N.A. Systems and methods of ring usage certificate extension
US20210126798A1 (en) * 2019-10-28 2021-04-29 Robert Bosch Gmbh System, Machine, Method for Configuring a System and Method for Operating a Machine
US11641284B2 (en) * 2019-10-28 2023-05-02 Robert Bosch Gmbh System, machine, method for configuring a system and method for operating a machine
CN110912693A (en) * 2019-11-22 2020-03-24 福建金密网络安全测评技术有限公司 Digital certificate format compliance detection system
CN111262683A (en) * 2020-01-15 2020-06-09 中南大学 Method for detecting abnormal allocation of certification authority resources in RPKI
SE2150228A1 (en) * 2021-02-12 2022-03-08 Crunchfish Digital Cash Ab Payment service provider interoperability for offline digital payments
SE544227C2 (en) * 2021-02-12 2022-03-08 Crunchfish Digital Cash Ab Payment service provider interoperability for offline digital payments
WO2022173360A1 (en) * 2021-02-12 2022-08-18 Crunchfish Digital Cash Ab Payment service provider interoperability for digital payments

Also Published As

Publication number Publication date
US8818903B2 (en) 2014-08-26
US20070073621A1 (en) 2007-03-29
US20150278808A1 (en) 2015-10-01

Similar Documents

Publication Publication Date Title
US8818903B2 (en) Transaction coordinator for digital certificate validation and other services
JP5670295B2 (en) Methods for providing certificate verification and other services
US20200145223A1 (en) System and method for blockchain-based notification
US9876779B2 (en) Document verification with distributed calendar infrastructure
US7047415B2 (en) System and method for widely witnessed proof of time
EP1540881B1 (en) System and method for the transmission, storage and retrieval of authenticated documents
CN110569675A (en) Multi-Agent transaction information protection method based on block chain technology
US20030028495A1 (en) Trusted third party services system and method
US8095972B1 (en) Secure authentication for web-based applications
US20140089156A1 (en) Addresses in financial systems
Moser et al. Building dependable and secure Web services.
Saeed et al. Performance evaluation of E-voting based on hyperledger fabric blockchain platform
WO2001020513A1 (en) System and method for providing certificate validation and other services
Ehikioya et al. A formal model of distributed security for electronic commerce transactions systems
Torres et al. An implementation of a trusted and secure DRM architecture
AU2019203761A1 (en) Addresses in financial systems
Bessani et al. Spin One’s Wheels? Byzantine Fault Tolerance with a Spinning Primary
AU2011369348A1 (en) Addresses in financial systems

Legal Events

Date Code Title Description
AS Assignment

Owner name: IDENTRUS LLC, NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:VASANTHAKUMAR, NAVIN;REEL/FRAME:012918/0257

Effective date: 20011107

AS Assignment

Owner name: ZIONS BANCORPORATION, UTAH

Free format text: SECUIRTY AGREEMENT;ASSIGNOR:IDENTRUS, LLC;REEL/FRAME:015932/0591

Effective date: 20050314

AS Assignment

Owner name: IDENTRUS, LLC, NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BARCLAYS BANK PLC;REEL/FRAME:016525/0730

Effective date: 20020311

Owner name: BANK OF AMERICA, NORTH CAROLINA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NEPOMUCENO, LARRY;REEL/FRAME:016525/0591

Effective date: 20020128

Owner name: BARCLAYS BANK PLC, UNITED KINGDOM

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:STIRLAND, MARK;REEL/FRAME:016525/0646

Effective date: 20020803

AS Assignment

Owner name: IDENTRUS, LLC, NEW YORK

Free format text: CHANGE OF NAME;ASSIGNOR:IDENTRUS, LLC;REEL/FRAME:016542/0732

Effective date: 20050708

AS Assignment

Owner name: IDENTRUS, INC. (SUCCESSOR-IN-INTEREST TO INDENTRUS

Free format text: RELEASE OF SECURITY AGREEMENT;ASSIGNOR:ZIONS BANCORPORATION;REEL/FRAME:016890/0162

Effective date: 20050921

AS Assignment

Owner name: IDENTRUST, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:IDENTRUS, INC.;REEL/FRAME:018782/0321

Effective date: 20060403

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION