Electrical computers and digital processing systems: support – Multiple computer communication using cryptography – Particular communication authentication technique
Reexamination Certificate
2001-06-26
2002-05-07
Peeso, Thomas R. (Department: 2132)
Electrical computers and digital processing systems: support
Multiple computer communication using cryptography
Particular communication authentication technique
C713S182000
Reexamination Certificate
active
06385725
ABSTRACT:
FIELD OF THE INVENTION
The invention relates generally to systems and methods employing digital signature techniques, and more particularly to systems and methods for facilitating electronic commerce or other transactions.
BACKGROUND OF THE INVENTION
Digital signatures are currently not established to be used as equivalents to “handwritten” signatures for mainly two reasons: (a) a uniform legal framework has not been established which accepts digital signatures in the same manner as handwritten signatures, and (in spite of sufficiently secure existing signing algorithms) (b) the technical possibility of obtaining signatures in an underhanded way aided by such mechanisms as Trojan horses, cannot be ignored. Even when using secure hardware, the possibility for extortion by forcing a person to make a digital signature might be higher than in the non-electronic environment due, for example, to a reduced potential of witnesses.
Also, in electronic commerce, it is possible for a buyer to deny having made a digital signature after receiving goods from a merchant in some cases. This is generally not acceptable. A merchant that obtains a digitally signed order from a buyer should not later have the buyer be able to repudiate its signature without suitable liability. Similarly, it is not acceptable for parties to a contract, if properly signed using a contract signing protocol, to repudiate signatures because a signor claims that his original signature was somehow compromised at the time of signing.
As known in the art, many signing protocols exist. For example, a public/private key signing technique may be used wherein a public verifying key is used to verify a signor's signature, which indirectly confirms his possession of a certain private (e.g., secret) signing key.
Some attempts have been made to overcome the above-mentioned problems. For example, some systems attempt to limit liability of a purchaser or limit a contract by requiring payment authorization at the time the specific transaction is taking place, although this is not typically sufficient to provide an acceptable limit for the payer in case his key is compromised. For example, Secure Electronic Transaction (SET) protocol is typically used in credit card payment systems. In these instances, a buyer typically authorizes payment in the context of a specific transaction by using a digital signature. Prior to performing a purchase order, a merchant typically requests authorization from the guaranteeing institution. Typically the seller has the sole discretion of the amount requested as guaranteed by the financial institution.
For example, the seller typically enters via a keypad, the dollar amount of the transaction or a higher amount such as in the case of hotel stays and the like. The buyer typically has no way of limiting the authorization request. A financial institution upon receiving an authorization request typically sends back a guarantee of payment reply. A payment gateway generates and digitally signs an authorization response message which includes a copy of a payment gateway signature certificate. The response or reply is intended to give a guarantee to the seller that the seller will be paid as expected. However, the buyer has no control of the amount claimed in the authorization request. When the authorization amount exceeds an amount desired by the buyer, the buyer can be liable for excessive amounts in the event of a compromised signing key.
Another mechanism of payment and payment authorization includes electronic checks. With such systems, a written agreement between the holder of the account and the bank can limit liability in case of forgery or other problem. However, the electronic checks are typically issued by the bank before the bank knows the context of a given transaction. Generally, no commitment made by the holder of the account is confirmed by the bank in this context. Typically, there is only the commitment of the bank to fulfil at most the guaranteed payment to the seller. As such, the system cannot limit the account holder's liability for the compromised case to a lower level than corresponds to the bank guarantees for all issued checks (the same holds for pre-paid bank checks) which might be much too high to be acceptable for the holder for the account in case it is not possible to prove that his key was compromised (which might be very difficult or even impossible in the case of a Trojan Horse program which might destroy itself after the attack).
Moreover, none of the approaches so far enables the user to limit his commitments for, e.g., the case of a compromised key, and at the same time enables the user to present a commitment (e.g., prior of and independently from performing a payment) the merchant can trust, since the merchant knows that the user is bound to this commitment even in case the signing key is claimed to having been compromised. Also, known systems generally do not allow a user to a priori define on his own the (e.g., monthly) totals of such commitments, as well as on a per transaction basis by selecting, for example, after negotiation with the merchant, a specific commitment which is prevented to exceed the total.
Consequently, a need exists for a networked communication system and method for providing commitment security among users that facilitates user selected commitment limits on a per track transaction basis and which utilizes a trusted authority unit to confirm that each level of commitment, such as a dollar limit in a financial transaction, can be met before the commitment is due. It would be desirable if such a system and method facilitated use of per transaction user selected commitment condition data to narrowly restrict the validity of a commitment.
It would also be desirable to provide a system and method that included commitment certificate issue condition data which facilitated a commitment certificate authority's check so that the user's specified conditions are met prior to issuance a commitment certificate.
It would also be desirable if such a system included per transaction user selected commitment conditions to restrict the validity of the commitment. It would also be desirable if such a system could issue commitment certificates issued by a trusted authority so that all members of the transaction can trust in the commitment. It would be desirable if such a system, also allowed a written agreement between user and commitment certificate issuer to regulate the user's binding to his digital signature and to issued commitment certificates, even in case that the user later claims that its key was compromised. This would allow, for example, all members of a transaction to be confident that if a repudiation occurs, liability (an example for a type of commitment) is at least that which was confirmed by the authority and cannot exceed a user specified limit.
REFERENCES:
Blaze, Matt; Feigenbaum, Joan and Lacy, Jack: “Decentralized Trust Management,” AT&T Research, Murray Hill, NJ 07974 (1999 IEEE).
Eastlake, D. etl.: CyberCash Credit Card Protocol Version 0.8; Network Working Group, Request for Comments: 1898, Internet RFC/STD/FY/BCP Archives, Jul. 8, 1995.
Entrust Technologies Limited
Peeso Thomas R.
Vedder Price Kaufman & Kammholz
LandOfFree
System and method for providing commitment security among... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for providing commitment security among..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for providing commitment security among... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2886814