CA2194475A1 - Method for securely using digital signatures in a commercial cryptographic system - Google Patents

Abstract

A system for securely using digital signatures in a commercial cryptographic system that allows industry-wide security policy and authorization information to be encoded into the signatures and certificates by employing attribute certificates to enforce policy and authorization requirements. Verification of policy and authorization requirements is enforced in the system by restricting acess to public keys to users who have digitally signed and agreed to follow rules of the system. These rules can also ensure that payment is made for public and private key usage. Additionally, users can impose their own rules and policy requirements on transactions in the system.

Description

~ W096/02993 2 1 9 ~ 4 7 5 P~ /6 METHOD FOR SECURELY USING DIGITAL SIGNATURES
IN A C~MMT~TAT CKY~ ~APHIC SYSTEM

R~ K( )U..~ OF T~ INVENTION
This invention relates to digital signatures.
More particularly, this invention relates to the use of digital siy--atuLe3 and certificates for digital signatures in a commercial cryptographic system for enforcing security policies and authorization requirements in a manner that reduces risks to the use~s.
Public-key cryptography is a modern computer security technology that can 5upport the creation of paperless electronic ds t systems, providing that the user's digital signature on an electronic dc_ ~, that i8, the user's electronic authentication and verification of the electronic d~ L, can be given suf~icient practical and legal meaning. Such paperless electronic ~c ~ systems, or "~d_ archite_LuL_ ," will ar - not only trading paL~ L~ operating under ~tandard bilateral c~,.L.__~
but also global multilateral systems in which any entity can, in theory, co~ v..d with any other entity in ~ legally provable manner, A - i nq that proper security controls are obs~L~_d ~--vugl-~u~.
These systems will have : commercial significance because, in many cases, cost reduc~i~n~ on the order o~ 10-to-1 can be realized over current paper .~..s cLion ~-~celu-.G. This i ~.. L is surficiently dramatic such that many organizations would, for e i~ and competitive reasons, be W096l02993 .~ /6 ~
21 944~5 compelled to use them once their practicality had been LL c~ted .
No one disputes that paper is a bothersome anachronism in the electronic world or that verifying pen-and-ink signatures is costly and error-prone. At least with paper, however, the signer retains the basic "contextual controls" Or d~ t preparation and physical delivery. On a digitally signed electronic ~ t, on the other hand, a signer controls only the encoded signature. All time, place and manner controls are absent, and nothing distin~ich~c a valid user signature from one fraudulently ~-uduued by another user who soDehow obtained the first user's smart card and PIN. It would not take too many multi-million or multi-billion dollar losses to erase all the savings produced by this "newfangled" office-automation techn~logy. Therefore, digital signatures will see early use only in c: _ ~ "electronic coin purse"
applications, where ~A~ODuL~ is low, and in wholesale fin-nriAl transfers, as to which e~LL~ -ly tight security ~O~C-1UL-3 are already the norm. However, these uses will have little general commercial impact.
Thus far, major cuL~uL~tions and banks have ~--11n~ to invest in these technologies due to lack Or w~ll-defined risk models and auditing standards and due to unc~rtainties regarding legal and liability issues.
Serious i..~__i to commercialize digital si~ Lu,~s will occur only after leading national auditing and legal experts have ruled that these systems contain adeguate security controls to warrant reliance in mainstream intra- and inter-_u-~ul~te bl~innCC
trAn---tionC~ typically in the $10,000 to $10 million range. In order for this goal to be achieved, security controls must be formulated to reduce the ri~kc Or WO 96/02993 r~ lfi 1~ 2194475 participants in digital signature d~_ ~ systems to the absolute lowest level tPrhnic~lly achievable.
There are two types of cryptographic systems in which digital signature5 have been used: symmetric and asymmetric cryptographic systems. FIGURES l(a~ and l(b) illustrate the use Or symmetric and nOy LL ic algorithms for encryption. In Oy LLic (conventional) cryptography, as shown in FIGURE l(a), the sender and recipient of a _ ication share a secret key 11.
This key is used by the sender, the originator of a iC~tion, to encrypt the message 12 and by the recipient of the communication to decrypt the message 13. It may also be used by the recipient to authenticate a message by having the sender use the secret key to compute some function such as a Message Authentication Code (MAC) based upon the message; the recipient thus can be assured of the identity of the originator, because only the sender and the reclpiPnt know the secret key used to compute the MAC. DES is an example o~ a Oy ic ~y~LO~L~phic system.
In aOy ic (public key) cryptogrAphy, shown in FIGURE l(b), different keys are used to encrypt and decrypt a meOssage. Each user i8 associated with a pair of keyO. One Rey 15 (the public key) is publicly known and i~ used to encrypt ~ 17 destined for that u8er, and the other key 1~ (the private key) is known only to that user and is used to decrypt 1- in7 r~ 18. Since the public key need not be kept secret, it is no longer ~~~~~ ~ y to secretly convey a shared encryption Rey between irating partie~
prior to exchanging confidPntiAl traffic or authenticating ~~- 57, ~ . RSA is the most well-known asymmetric algorithm.

W096/0~993 2 1 9 ~ 4 7 ~ P~ l.vl6 A digital signature, however, i5 a block of data ~ a~d to a message data unit, and allows the recipient to prove the origin of the message data unit and to protect it against forgery. Some asymmetric algorithms (for example, RSA) can also provide auth~ntiration and non-repudiation through use of digital si~--a-u-es. In order to sign data, the sender sncrypts the data under hi5 own private key. In order to validate the data, the recipient de~ Ls it with the sender's public key. If the message i5 curc~fully decrypted using the sender's public key, the message must originally have been encrypted by the sender, because the sender is the only entity that knows the ~ULL- ~ -lin~ private key. Using this method of signing d~ Ls, the encrypted message i8 bound to the signature, because the re~1pi~nt cannot read the message without decrypting the signature data block.
The siul-aLu,, ~ -y~-ed message can then be encrypted to the recipient using the recipient's public key, as usual.
Digital 8i~llaLUL~S may also be formed using asymmetric encryption algorithms as described below and as illustrated in FIGURE 2. To sign a mesfiage, the me~sage 20 is first digested (hashed) into a single bloe~ 22 using a one-way hash function 21. A one-way hA~h function has the PLUY_LLY that, given the digest, it i~ _ Lionally infeasible to ~u~L~u~L any message that hashes to that value or to find two --97, - that hash to the same digest. The digest 22 is then encrypted with the user's private key 23, and the result 24 is ~nY ~d to the encrypted or u..~ yLed message as its signature 25. The recipient uses the sender's public key 26 to decrypt the signature 25 into the hash digest 22. The I~ ipiPrt ~ W096/02993 2 1 9 4 ~ 7 5 rc~ ~Ds~/6 al~o digests (hashes) the message 20, which has been received either unencrypted or encrypted and then decrypted by the recipient, into a block 27 using the sane one-way hash function 21 used by the sender. The recipient then verifies 28 the sender's signature by rh~r~ing that the decrypted hash digest 22 is the same as the hashed message digest 27.
Separating the signature from the message in this way, that is, not requiring the 5ender and recipient to encrypt and decrypt the entire message in order to verify the signature, greatly reduces the amount of data to be encrypted. This is important because public key algorithms are generally subst~ntiAlly slower than conv~nt1-n-l algorithms, and proce-s;ng the entire message in order to verify a signature would require a significant amount of time. The signature process also ill~L~dU''e8 L ~ r- y into the message, which, because the message must hash to the ~p~cif;e~ digest, allows the r~cipi~n~ to detect unauthorized changes to the message.
A digital signature provides the security service~
Or (a) integrity, because any modification of the data being signed will result in a different digest and thus a different signature; (b) origin authentication, becau-e only the holder of the private key C~L~, ';nJ' to the public key used for validation of the signature could have signed the message; and (c) r.~n ra~diation, as irrevocable proof to a third party that only the signer, and not the recipient or its employees, could have created the signature. A
symmetric secret key authenticator, for example the Xg.g ~AC, does not provide these services, since either of the two parties can create the authenticator using their shared key.

W096/02993 P~l/u~ l ,6 ~
21 ~4~75 v Several of the ~ ni~ ~icn-lc~Pd herein as6ume the ability to attach multiple signatures or cosignatures to a ~- ~. A useful format for this purpose, as i8 well known in the art, i5 defined in "PKCS ~7: Cryptographic ~essage Syntax," RSA Data Security, Inc., 1993, which is hereby incv~.ated by reference. Each signature structure on a do t will contain an indication of the certificate needed to validate the signature along with a bit string containing the actual signature. Additionally, other information relevant to the particular signer may be in~ A~ in an individual signature computation. This per-signer information may be included in the signature computation as "signature attributes."
In order for one user to identify another user for ~L - ic~ion of a message in a way that ensures the second user'~ pos~6ion of a private key, the fir~t user must be able to obtain the other user's public key from a trusted source. A~ i8 well-known in the art, a f ~_ ~ for the use of public key certificates was dsfined in "X.509: The Directory: Authentication F~ CCITT, April, 1993 ("X.509n), which i5 hereby in~ ~uLated by reference. These basic public key certificates bind a user's name to a public key and ar~ ~igned by a trusted issuer called a certiricatiOn Authority (CA). Besides cnntA;ning the user's name and public key, the certificate also contains the issuing CA's name, a serial number and a validity period.
Although X.509 doeD not imposQ any particular ~LLU~LULe on the CAs, many i 1- L~tions find it r~on~hle to impose a hierarchical D-Lu~LuL~ in which each CA (in general) certifies only entities that are subordinate to it. ~ence, we can C~ LU~ A hierarchy of C~s, as ~hown in FIGURE 3, in which the higher level ~ W096/02993 2 1 ~ 4 4 7 5 P~ll. Sh ~/6 CAs 31 (perhaps banks) sign the certificates 34 of the CAs 32 beneath them (for example, ni~), and the lowest level of CAs 32 sign user 33 certiricates 35.
At the top of thi5 hierarchy (not shown) are a relatively few other root CAs, perhaps one per country, that may "cross-certify" each other's public keys (root keys) .
Various security architectures define ~ n i I
to cùl-aLLu~- a certification path through the hierarchy to obtain a given user's certificate and all CA
certificates n~c~ss~ry to validate it. These architectures share the common characteristic that a user need trust only one other public key in order to obtain and validate any other certificate. The trusted key may be that of the top-level CA (in a centralized trust model) or of the local CA that issued the user's certificate (in a de~en~Lalised model).
Certificates also contain an expiration date. If it is ne~s-~y to cancel a certificate prior to its expiration date, such as if the name association becomes invalid or the CULL ,~r~0~1;ng private key is 108t or _ . i f ~, the certificate may be added to the CA's certificate revocation list (CRL) or "hot li~t.~ mi~ list is signed by the CA and widely di~tributed, possibly as part of the CA's directory entry. The certificate remains on the CRL until the certificate's expiration date.
Often certain information concerning an entity or CA need6 to be made available in a trusted manner. In a secure X.500 Directory, this information would be retrieved via standard Directory operations and the result would be signed by the Directory. In the absence of such a secure ~.500 implementation, this information is placed in an attribute certlficate, W096/02993 ~ 6 o 21 9447~

which is signed by a CA in the same manner as the public key certificate. Attribute certificates would be created on presentation of the proper credentials by the user. For example, the user would present his public key certificate and prove he pOqE~ the uuLL~ u~ nJ private key, as one form of identification. Attribute certificates are linked to the user's basic public key certificate by referencing the basic certificate's serial number and are revoked by an identical parallel CRL -- -n~r~. Attribute certificates are dic~ cFo~ further in "X9.30 Part 3:
Certificate M~nA~ L for DSA," ANSI X9Fl, June, 1994, and U.S. Patents Nos. 4,868,877, S,005,200 and 5,214,702, which are all well-known in the art and are all hereby inuuLuuL~ted by reference.
An attribute certificate is a ~LLU~LULe separate from a public key certificate because proper separation of duties may often re~uire that the CA that issues the attribute certificate be different than the CA that issues the public key certificate. A central CA might rarely of itself posse5s the required securlty or authority to "sign for" all of a user's authorizations.
Having s_~aLaL~ CAs ~ L-te various types of attribute c-rtificates distributes risks more appropriately. In addition, the defined attributes may not be re~uired for all domains, neL~-LkD or applications. The need for these attributes and for additional domain-specific attributes is deto~minDd by each domain.
The user's basic public key certificate remains X.509 compatlble, allowing its use with other applications and allowing use of commercial ~Lu~uuLD
for certificate generation.
Tt is desirable to be able to uun~LLuuL a trusted organization that utilizes digital signature and ~ W096/02993 2i 94475 r l" /6 certificate ~ ni~ to enforce a security policy defined by rules within this organizational structure.
It is also desirable to use digital signature and certificate -h~nil to encode industry-wide security policy and authorization information into the signatures and certificates in order to permit the verifier of a signature to decide whether to accept the signature or certificate as valid, thus ac~ ting and easing electronic ce business transactions.
It is further desirable to reduce the risks associated with digital signature systems, particularly with end-user smart cards, by b~ i ng on this use Or public key certificates and attribute certificates.
It is further desirable to prevent the use of such a digital signature 5ystem by any party that might purport to "accept" a transaction in c~ La~6..~ion of the applicable authorization certiricates when that party had not signed the applicable "system rules~
~ . ~ pertaining to that system of _ icating signer authorization.

STTMMARY OF I~T~ INV~UTION
These and other objects Or the invention are ~" li~h~d in accordanc¢ with the principles of the i.... 1 ~n by providing a system for securely using dig$tal Si~--a-u~-3 in a commercial cryptographic system that. allows industry-wide security policy and authorization information to be encoded into the si~..aLu~ and certificates by employing attribute certificates to enforce policy and authorization requirements. In addition to value limits, cosignature requirements and d- ~ type restrictions that can oe placed on transactions, an organization can enforce with respect to any transaction gaa~L~pl,ical and W096l02993 P~ C~v~6 21 ~4475 temporal controls, age-of-signature limitations, pre-ay~Lvv~d counterparty limitations and confirm-to reguirements by using attribute certificates for the tran~acting u~er. Restrictions on distribution of certificates can be set using attribute certificates.
Certificates can be used also to ensure key confinement and non-decryption reguirements of smartcards in this system.

R~T~ DESCRIPTION OF THE DR~WINGS
The above and other objects and advantages of the invention will be apparent upon concidoration of the following iot~i led description, taken in conjunction with the a~ nying drawings, in which the reference characters refer to like parts th~uu~llu~L and in which:
FIGURES l(a) and l(b) show the prior art use of symmetric and asymmetric algorithms for encry-ption;
FIGURE 2 is a flow chart illustrating the prior Art process of a digital signature using an a~y ic encryption algorithm;
FIGURE 3 ~hows a hierarchy Or signature certification authorities;
FIGURE 4 shows a directory information tree (DIT);
FIGURE 5 shows an example of an authorization c~rtificate;
FIGURE 6 is a flow chart illustrating the prior art process of verifier enfo1~ ' of a transaction y value restriction;
FIGUR~ 7 is a flow chart illustrating the prior art process of verifier enfu~-_ of a tr~~ "-ti n~
cosignature reguirement;
FIGURE 8 i_ a flow chart illustrating the procass of verifier enfuL, L of a trAr~~ nn l. L-type restriction;

~ W096~2993 A ~ i / ~ ~ v 16 ~ 21 94475 FIGURE 9 is a flow chart illustrating the process of verifier enfor ~ of a transaction geographical and temporal control;
FIGURE 10 iB a flow chart illustrating the process of verifier enfoL. ~ of a maximum age of sender's signature restriction;
FIGURE 11 is a flow chart illustrating the process of verifier and sponsor enfo~o ~~ of a pre-a~Lo~cd counterparty restriction;
FIGURE 12 is a flow chart illustrating the process of verifier enfo~- ~ ~ of a transaction "confirm-ton reguirement;
FIGURE 13 i6 a flow chart illustrating the process of a device's certification of key confinement and non-decryption;
FIGURE 14 is a flow chart illustrating the processof keeping public keys secret and enforcing signing of system rules; and FIGURF 15 i8 a flow chart illustrating the process of verifying user rules of a transaction.

nT~ATTT~n D~ T~LlON QF T~ l~v~
The following general prinrir~q and rhil~a~rhi~c are reflected in the signature verification model defined in this invention. First, CA and user certificates can contain attributes that ' ~ the conditions and assumptions under which they were created. Verifiers may simply reject all certificates and tr~nq~ct;~n~ that do not meet their minimum standards.
Also, attribute certificates may be signed by a UDer~8 1~D~ 5J n to signify that the sponsor's signature will be honored for official b~q;n~qq if the tra~ n meets the requirements stated or implied by WO 96/02993 1 ~,1 /L.................................. _. ,V /6 ~

the attributes. Although typically the user's sponsor will be the user's employer, the model can be extended to include the user's bank, credit card issuer, voting bureau, video rental store, public library or any other entity that might accept the user's signature. This sponsor (authorization) certificate is thus the electronic equivalent of an "affidavit of legal mark,"
as ufied in the context of a traditional signature stamp. See Robert Jueneman, "Limiting the Liability of CAs and Individuals Regarding the Use of Digital Signatures," presented to the ABA Section of Science and Technology Certification Authority Work Group, July 2, 1993.
FUrth~ e, industries may develop "industry policy" statements that establish minimum requirements for signature verification. All particir~nt~ would sign these multilateral &gL~ ~ in order to ensure that all ~uul.LeL~aLLies would be bound by the encoded restrictions. Normally, sponsor certificate6 should be reguired in all cases, and digital signatures would be deemed otherwise null and void in their absence.
Industry-wide pol;ci~c would also define (1) relevant d~ L types and classes, (2) signer roles and titles, and (3) coded symbols for in~uL~uLating by Ler..~ standard uul.LL~_Lual terms and conditions.
IIOLe~._L~ there must be strict a~leLenCe to the principle that all restrictions can be enfoL~ed in an entirely automated manner (that is, verification "on siqht~), without reference to paper a~ or human int~L~L~LaLion, ~ Li--- also termed "fully - ;n~hl~ straight-through pro~ inq." In complex and/or high-volume envL, La, this is required in order to give these security controls credibility in the eyes of audit and legal experts. Reference to -~ W096/02993 2 1 9 4 4 7 5 r~l" /6 trusted third parties should also be minimized to reduce verification latency times.
While these restrictions seem complex, they merely reflect ordinary business procedures made explicit for S ~u~yoses of machine verification. Formerly, such controls were enforced inside the sponsor's computer systems before sending out the transaction. However, with the advent of multilateral distributed transactions, the verifying user is typically off-line from the sender's sponsor's system, and so the verifier must enforce the sponsor's authorization model, as reflected in the attribute certificates. Once this methodology is specified, office software vendors will develop menu-driven systems to create and manage user attributes, and the cost to user organizations will be relatively low.

Or~Ani 7~ti~nAl SLr U~ l "' e in Cer~ificates The certificates themselves may reflect the 20 SLL~LU ~ Of a sponsor organization. ~ecause many authorization decisions are based on the user's position in an organization, the organizational ~L~Lu-- and the user's position therein may be ,~ 'fied as part of a user's name. Names in certificates are specified in terms Or the X.500 Diroctory model, as follo~s.
The X.500 Directory ~L~u~Lu~ is hierarchical; the resulting distributed database comprises the Directory Information Tree (DIT~, as shown in FIGURE 4. Each entLy 41 is of a specific object class and consists of a set of properties called attributes 42. An attribute 42 consists of a type 43 and one or more values 44.
Thus, in an entry of class organization, one attribute is the organizationName; in an entry of class W096/02993 Y~ 6 ~h~
21 9447~ v organizationalPers0n, attributes might include title and tel. l~h~u~n~ ~ .
Each entry also has one or more special attribute values used to UUI~D ~L U~ ' ~ the object's name; this S attribute value is the relative distinguished name (RDN) o~ the entry. An object's distinguished name lDN) 45, which is created by concatenating the relative dlstinguished name5 46 of all entries from the DIT root to the entry, uniquely identiries the object in the global DIT.
Several of the attributes defined in X.500 may be usefully in~ iD~ in the user's attribute certificate.
For example, the object class can be used to distin~-i~h between entities (for example users and roles) whose distinguished names are of the same ~orm.
Also, the title may be used in making authorization rl ~Dr i c i C~n ~: .
In addition to the use of the DIT to group entities along organizational lines, X.500 define8 several object classes that can be used to oullOLL~L
arbitrary groups of entities. These object classes include the organizational role, whose "role o ~
attribute lists the name5 of the users who occupy the role, and ths group 0r names, whose " ~ attribute li-ts the names of group members. To convey this infor ation in a trusted way, one could define role and group certificates that convey the names of the role 1 a or group members, respectively, and that are signed by a CA, thus ~n-hl ing use 0r this feature outside the context of an X.500 directory system.
Group and role certificates may be used in cv,,Ju..~Lion with a cosignature - -nl ~~ to ~impli~y the ~u-.OLLu~-ion of cosignature reguirements. For example, a transaction might require the si~..aLu..- of ~ W096/02993 P~~ .l6 -- 21,q4475 three oC~u~lL5 of the "purchasing agent" role. A ufier may also indicate the role in which he i8 acting by inrluSing the role in the signature computation as a tper-signer~ signature attribute. The asserted role may then be matched against a role certificate (or the user's attribute certificate) during verification.

Policy Information i n Certiricates It is another P~ho~ of this invention to encode information regarding a CA's security policy into the attribute certificates of the CA and its subscribers, so that the verifier of a signature can use the information in ~etDrmining whether to accept a signature afi valid. In general, the CA's certificate will convey the rules that a CA uses when making certification ~oci~i~n~ while the user's certificate will convey the information used by the CA when applying these rules.
Attributes in CA certificates can indicate security policy and aDDuLGncc information for a particular CA. This policy information can also be inherited by subordinate CAs, allowing easy C~ LL U~ Lion of security domains sharing a common policy. Policy attributes in a CA's certificate might, among others, include:
(1) Liability Limitations: the extent to which a CA i~ liable in the event of various problems (for example, CA key ~ i~e, defective binding); this might be no liability, full liability or a ~pPcific -~ amount.
t2) Trust Specification: a description of which users and CAfi a given CA can certify, ex~.c3~cd relative to the CA itself (for example, "all WO96~v2s93 F~~ 6 21 94~75 subordinates"), or to the DIT in general (for example, "the subtree below Organization ABC"), or to others.

(3) Required Attributes: a list of those attributes in the user's attribute certiflcates that must be verified against a transaction and/or its context in order for the transaction to be c~n~i~A~red authorized. These attributes would be found in the certificate(s) of the sponsor and allow a single authorization certificate to con~ain authorization attributes for use with multiple applications. Some suggested user authorization attributes are defined later.

(4) ~ hl~ Name Forms: a specification of the ~1l, hl~ name forms that the CA may certify. This information is held as (a) a set of name ~inAin7~, which defines the attributes that may be used to name entries of a given object class (that is, the ~11 hle RDN formats rOr entries of that class), and (b) a set of ~L,~ LULC rules, which defines which object classes may be adjacent (that is superior or subordinate) to each other in the DIT, that is, the order in which object classes may be chained together to form a complete DN. This policy attribute may be used to restrict the type of entities that may sign L, Lions. For example, for wire transfer applications, it might be desirable to restrict siq~-t~lre cAr~hility to the organization itself, rather than to users within the organization, since this is similar to the current mode of operation using DES
MACs.

(5) Cross-Certificates: it may be desirable from an erficiency point Or view to allow certi~ying entities and as organizations to cross-certify each other in order to constrain the length of certification ~ W096l02993 1~ 6 21 9'4475 paths. On the other hand, it is not desirable to allow certification paths to contain arbitrary number~ of cross certificates, as it i5 difficult to determine the level of trust in the entity at the other end. Nany certification architectures re5trict certification paths to contain only one cross-certificate. To A -'-te a wider range of policies, an attribute may be added to the attribute certificate associated with the ~LOSS ceLLificate indicating that the cross-certifier explicitly allows the use ofcross-certifiCate5 i55ued by the CA being cro5s-certified.
Attributes in a user's or entity's attribute certificate may represent the information verified by the CA when creating ~he certificate for the entity.
Policy attribute5 in a user's certificate might, among others, include:
(1) Binding Information: the criteria used to bind the public key to the identity of the entity being certified. This ;n~ '3e (a) the method of delivery, auch as being presented in person, by authorized agent, by mail or by another method; (b) the method of ;S~nt1fication, such as by La - -hle - ~u ial ~ a~ verified by trusted third party, dual 25 con~rol, finqerprint check, full ba~h~Luud inv~stigation or another method; (c) the identification presented to the CA; and (d) the subject's entity type, that is, individual, cu~uL~tion, device or other.
(2) Trusted Third Parties: the names of any trusted third parties or agenta involved in the binding process.
(3) Roles: it may be useful for authorization ~UL~05~S to indicate which roles (both internal and W096/02993 ~ v,6 ~

external to the organization) a user may exercise.
This i_ in contrast to a role certificate, which would be issued to the role and contain the names of all oc~O ~ya--t~. .
(4) Relative Identity: a CA may wish to certi~y only a portion of the DN of an individual. In particular, the CA might ~ic~l~im liability for CULL~ Lness of an individual'5 personal name, since, under legal Agency principles, the individual's signature is binding on their organizational sponsor in any event. rnnci~r the name:
C~US; O-Bankers Trust; OU=Global Electronic C ~; CN~Frank Sudia; TI~VP
The CA might certify only the validity of the organization, organizational unit and title portions of the individual's dis~inT~ichod name, all of which are easy to verlfy, while the personal name would only be "ro~cnnAhly believed accurate." In view of the relative ease of obtaining false identity papers, this 20 avoid_ the need for prohibitively expensive ba~y~ud investigations. Such an identification can be relied on in an ordinary co_mercial setting but not in a proc~e~inq concerning a will or inheritance, for exampl-.
l5) Absolute Identity: we define relative identity as the user's identity "relative" to his organizational sponsor. Put another way, we certify all ~1- of the user's n~--ci- card identity, n except his personal name. As a special case, some CAs might undertake to certify the absolute identity of a~l~cto~ users, say the children of wealthy clients, diplomats or national security operatives, almost certainly bolstered with biometric techniques. This would be rare and is presented here only for ~ W096l02993 P~ 6 completeness in order to round out the "relative identity" concept.

AuthQrization TnfQrr~tion in Certificates Attributes may convey restrictions that control the conditions under which a signature i8 valid.
~ithout such restrictions, the ris~c of forgery would be considered excessive, since an electronic signature can be affixed to almost any digital ~ L by anyone poceeSsing the user's smart card and personal identification number (PIN~. In the electronic environment, the normal contextual controls of do.
creation and physical delivery are either weak or nonexistent.
Even authentic users are hardly ~,a~; _ Lhy to undertake free-form offline commitments, and organizations will thus welcome the ~p~hi1ity to positively restrict the scope of express signature authorization. Such authorization attributes might, in addition to standard X.500 attributes, include Transaction Limits, Cosignature Requirements, Dc Types, fiubject matter restrictions, Authorized Signatories, Geographical and Temporal Controls, Age of Signature, Pre-a~ l Counterparties, Delegation Controls, and Confirm-To Requirement. These attributes can be encoded in one or more authorization certiricates signed by the signer's organizational sponsor or by an external CA acting on behalf of the organization. An example of an authorization certificate and an associated Lr~ns~cLion is shown in EIGURE 5.
When a recipient user (verifier) receives a t, .ction 51 from a sending user, the recipient first uses the sender's basic key certificate 55 to verify W096/02993 rc~ 6 A~
21 94~75 '~

the sender's signature 52 on the transaction Sl. As will be described in greater detail below, the recipient also uses the sender's authorization certificate 56, signed by the sender's fiponsor 59, to verify the cosignatures 53 and ti~- t _ notarization 54 A~ n~r~ to the LL~ cLion 51 and to verify that the attribute values 57 of the trAncaotinn 51 fall within the authorized attribute values 58 as specified in the authorization certificate 56.
The user may be subject to transaction limits that control the value of transactions or other ~c- --Ls that the user may initiate. The user's signature will be valid only on transactions originated either up to a certain monetary limit or between two monetary value boundaries. Accordingly, as shown in FIGURF 6, the aending user sends a trAncac~ion 601 signed 603 by the sender (actually by the user's smart card 600 containing his private key) and appends thereto an authorization certificate 604. The verifier uses the authorization certificate 604 to verify 607 the user's signature 603 and to verify that the ~ t 1~n - ~ value 602 falls within the trAn~Actinn limit attribute value 605 in the authorization certificate 604. The verifier also verifiefi 609 the sponsor signature 606 on the authorization certificate 604 using the ~ponsor's public key 610. If any of tho-9e Cj~ 8 and attribute values does not verify, the trAn-a~ti~n i~ rejected 611. If verification is complete, the transaction is accepted 612.
With regnrd to cosignature requirements, additional si~..atuL~s may be required in order for a given signAture to be cnnci~ ed valid. Quorum and weighting -- sni - can be used to vvl.~LLuvL fairly elaborate checkfi and bAlAnc~ for explicitly governing ~ W096/02993 P~ ,6 ~, 21 9~475 the level of trust in each user. The particular sequence or order of required signatures may also be specified. Referring to FIGURE 7, sending user A sends a trAn~acti~n 702 signed 703 by his own smartcard 700 and, if user B's cosignature is required on the transaction 702, signed 704 by the smartcard of user B
701. Sending user A also appends his own authorization cert.ificate 705 to the transaction 702. The verifier uses the authorization certificate 705 to verify 711 user A's signature 703, and uses the sponsor's public key 713 to verify 712 the sponsor's signature 707 on the authorization certificate 705; if either signature does not verify, the transaction is rejected 720. If a cosignature value 706 is required 714 by the authorization certificate 705, the recipient enforces the requirement by verifying 715 cnCignDr user B's signature 704 on the ~-~n~a~Li~n 702, and then checks cosignDr user B's public lcey certificate 708 by verifying 716 the signature 709 of the certificate issuer, using the issuer's public key 717. If the signature of either user ~ or his certificate's issuer does not verify, the trAn~-sLion is rejected 722.
The uae of cosignatures allows an organization to effectively define checks and hAlAnr~, and to explicitly specify the level of trust in a user. The U8- of cosi~..atuL~s also greatly reduces the risks that result from inadvertent , ice of a private key due to theft, misuse or mispla ~ of a ~aLLc~Ld or PIN.
In particular, it is believed that the ability to require cosignatures, value limits and related controls will enable organizations to carefully manage and fine-tune all signature authorizations, thereby giving them all the tools needed to manage and limit their risks.
Use of cosignatures further allows distribution of the WO96102993 I._11L~_.___/6 21 94475 ~

authorization function over multiple locations and hardware platforms, with the resultant minim; z-tion Or risks that might result from access control failures on one of those platforms. See U.S. Patents Nos.
4,868,877, 5,005,200 and 5,214,702.
Authorization signatures, which must meet the restrictions 5pecified in the signer's certificate, can also be distin~iQh~ from other cosignatures by ;nr~ nq the signature purpose as a signature attribute and by requiring that an indication of the signature purpose be included in the data being signed.
This signatuL~ ~uL~ose attribute might require the values of: (a) an authorization signature appropriate to the dc ~, tb) an authorization cosignature appropriate to the dc L, where the cosigner' 5 certificate has sufficient authority to authorize the ' t, and (c) a witness cnaiqnAt~re, where the rosiqn~r's certificate does not by itself have sufficient authority to authorize the ~~ t.
Signature purpose Dnro~in7a ~;ac~c~ed in draft ANSI
~L~r.dald X12.58 Version 2 (~pr~n~iY) issued by the Data Interchange SLanla~ds Association (DISA), which is well-known in the art and is hereby inc~L~L~ted by ref-rRnce .
The user can also be restricted to signing only particular dc L types, such as ordinary C~LL~ , '~ e, purchase orders, specified FDI
LL ~ ;On types, b~Q;n aQ ~IlLL~L~, speciried finAnriAl i~ Ls, etc., as defined by industry-wide policies. It ~ay also be desirable for efficiency to exclude certain large classes of LL ~~ Lions and d- . Referring to FIGURE 8, the recipient enforces the dc --~-type restriction in the ~ender~8 trAn~Arl ;~n 801 by first verifying 807 the ~ W096/02993 21 94475 . ~ l vl6 sender's signature 803 on the transaction and by then verifying 808 the ~oc - t type attribute value 802 within the transaction 801 to enforce the do t type restriction 805 within the sender's authorization certificate 804. The recipient then verifies the authorization certificate 804 by using the sponsor's public key 811 to verify 809 the sponsor's signature 806. If either a signature or the attribute restriction doe5 not verify, the transaction i8 rejected 810.
It is also de5irable to add po5itive or negative restrictions pertaining to transaction subject matter or context clas6. For example, to restrict an agent to signing purchase orders for some class of goods (such as, for example, office supplies), or to deny authority as, for example, in the case of denying an agent the ability to purchase pvL..v~Laphic materials. Subject matter restrictions are ~nfuL~ed by the transaction rec;ri~nt in the same manner as dr ~ type restrictions, and may be implicit in many d t typos, yet requiring separate specification for the more generic dc t types.
An organization can indicate that there are ~~ 'f~c authorized signatories, that i8, that only , 'fic individuals can Hsign for" the organization, si~il~r to a ~tal-da d "cv~uLate 1 -clut;n~" to this effnct. This might 1~ the lc L-type concept, as an additional control on signing of nC~,~VLate" 1- t-type~. This restriction can be ~ d by specifying that a cosignature i8 recuired in which the cosigner~s title (in its disti~ h~d name) must be egual to one on a specified list contained in a authorization certificate. This is W096~v2993 I~ l/U~ 6 21 94475 v in lieu of naming a list of one or more required cosigners.
Geographical and temporal controls include locations and time periods from which transactions are considered valid. Use of a local trusted "timestamp notary" is assumed. Such a notary would append a trusted timestamp to the originator's signature on a dc L and would then sign the result. Thus, time-of-day and day-of-week restrictions would normally roin~iSo with the work-week of the user's locale.
Also, location information would be associated with the notary 80 as to restrict access to a specific network segment, typically the user's Acciqn~d work area. The "granularity" of location controls would depend on the network architecture. The signer or the signer's computer system must attach a certiried ~ from a ~pecified local server to the transaction, or else the verifier cannot accept the transaction and the signer's sponsor will not be bound by it. As shown in FIGURE 9, the sending user attaches to the LL~r.aa~Llon 901 an authorization certificate 902, as usual, an authorized ti- L 903 and a time server certificate 904. The recipient verifies 92~ the sender's signature 905 on the transaction 901 and verifies 922 the spon or's signature 908 on the authorization certificate 902. The recipient then (1) verifies 923 that the t1 t trAncac~ion text hash 909 matches the result of the text of the LL-nC~ n 901 hashed with a known hash function, ~2) verifies 924 that the time and date 910 on the transaction ti-- i 903 fall within the authorized time and date 906 attribute valu-s as specified in the authorization certificate 902, (3) verifies 925 the time server signature 911 on the li ; 903, and (4) verifies 926 the sponsor's ~ W096/02993 ~ /6 sigllature 912 on the time server certificate. If all these conditions are satisfied, the transaction is accepted 931; if not, the transaction is rejected 930.

Furthermore, a document may not be valid unless the signature is verified within some specified time period. For high-value transactions this age-of-signature attribute period would be quite short, while for more normal transactions, esreciAlly those sent via store-and-forward systems such as X.400, a longer interval (such as two days) would be appropriate.
FIGURE 10 shows enf OL ~ L by a recipient of the age-of-signature attribute value. The time of verification would be provided using a receipt 103 signed by a trusted timestamp service 104 containing, at a minimum, the recipient's name and the signature from the original tr~nC~I ion. The verifier must submit a timestamped copy of the original signature that is dated promptly after the time and date Or the original transaction, or else the sponsor will reject it. As shown in FIGURE 10, the recipient (verifier) verifies 121 the sender's signature 107 on the trAn~A~ti~n 101 and verifics the sponsor~s signature 115 on the authorization certificate 102. The recipient then v~if~e~ 122 that the difference between the date 105 and time 106 on the transaction 101 and the date 111 and time 112 on the t i-- ~ 103 is within the age-of-signature attribute restriction 108 in the authorization certificate 102. The rec;~iPnt also verifies 123 that the hash 110 of the tr~n~A~t;~n 101 within the trusted ~;-~ L 103 matches the text of the trAn~acti~n 101. If all these conditions are satisfied, the LL~I13a_LiOn is accepted 130; if not, the L- -t;~n is rejected 131.

W096/02993 r~ 6 ~
21 94~75 v A similar concept is that of a minimum age of a signature. In this case the signature would not be valid until some minimum time after it had been signed.
This allows for a smartcard to be reported lost and for a revocation notice to be broadcast to the recipient.
The control attribute can specify a maximum and/or minimum age for the signature . . .
A "pre-~yyL~._d counterparties" attribute value restricts an entity to dealing only with some specified set Or known L.u~ Llry partners. This is a common reguirement in dial-up home banking systems, which typically reguire that all authorized payees be specified in advance. Another way of stating this is that "free-form transfers" are forbidden. SY~I8GL~
realize that, in case of an error, they stand a better chance of ~ c~-rully reversing the error when dealing with a large, solvent and creditworthy party than when dealing with a small, unknown and unauthorized one.
Separate certificates can be issued for each ~u~L~LyaLLy in order to prevent a competitor from nht~;ning the user's customer list (other than himself) in a single certi~icate. The a~L~._d ~uu~L~Lyd~Ly can be coded either as a common name, a dist;n~i~h~A name, a certificate number, or the hash value of either the Ai~tin~li~h~d name or the counterparty's public key.
In order to claim the benefit of the L.~n~--Linn, the v-rifier must submit a certificate that matches the encoded counterparty value.
FIGURE 11 shows verification by the user's sponsor of the user's transaction after receipt by a rqcipi~t.
The recipient (c~u--L~ry~LLy) verifies 1110 the user'~
signature 1103 on the L,u--_ cLion 1101 and verifies 1111 the sponsor's signature 1105 on the user authorization certificate 1102. If either of these ~ W096/02993 2 ~ 9 4 ~ 7 5 , signatures does not verify, the transaction 1101 is rejected 1112. If the signatures verify and the transaction is accepted 1113 by the recipient, the recipient endorses the transaction 1101 by issuing his S verified transaction 1114 counter-signing 1116 the text 1106 of the original user transaction 1101 and the sending user's signature 1103, with the recipient's certificate 1115 attached. In enforcing the pre-~ru~_d counterparty restriction in the sending user's authorization certi~icate 1102, the sending user's sponsor veriries 1121 the sending user's signature 1103, as inrlllA~d in the recipient's veri~ied LLal.a~Liûn 1114, and verifies 1122 the recipient's signature 1116 thereon. If these signatures are verified, the sponsor next verifies 1123 the counterparty public key hash value by hashing the recipient's public key 1117 and ~h~inq the result against one of the authorized counterparty public key hash values 1104 as specified in the user's authorization certificate 1102 (the reciri~nt's public key 1117 that the sponsor hashes for verification is itself verified 1124 when the sponsor verifies the recipient's certificate). If these conditions are met, the Lr~ i~n is accepted 1125.
me attribute values o~ delegation controls can limit the types and value ranges o~ authorizations that a CA may specify when issuing an attribute certificate.
They can also serve to limit the scope and depth to which a user may delegate his signing authority to others. For example, a root CA might limit an organizational CA to issuing authorizations only to allow its end users to sign dc t S whose ds L
types fall into a range of ~c ts related to state tax administration. Or a CA might grant some authority w096/02993 rc~ ,,6 to a user with the provision that it can be delegated only to another person with the rank of assistant treasurer or higher, for a time not to exceed thirty days, and without the right to further sllhdPlegAte.
Another authorization attribute, called a "confirm-to requirement~ value, prevents the signature from being valid unless the verifier sends a copy of the verified trAnRAr~ion to a third party, typically the user's organizational sponsor or work supervisor, at a specified mail or network address, and either (a) receives an accept/reject message, or (b) a specified time elapses. This re~uirement is similar to a cosignature but occurs after the trAnR~ctinn is sent rather than before. Such after-the-fact confirmation could be acceptable in lower risk situations in which few transactions would be rejected and in which nhtAining the cosignature of the third party in advance may be unduly bUL;~_ . Or it might be preferred in high-value cAAses where positive on-line nhPn~ing is ' -'. In that case, the flow pattern reverts back to an on-line rather than an off-line system. As shown in FIGURE 12, the recipient first, as usual, verifies 1211 the sender's signature 1203 on the ~ I in~
1201 and verifies 1212 the sponsor's signature 1205 on the u~er authorization certificate 1202; if either of th ~ ,e8 does not verify the trA -1;on 1201 is rejected 1213. If ths si~..aLuL~s are verified, the reAiriPnt sends 1214 a confirmation message consisting of the original L. -Lion 1201 (the L. inn text 1202 and the sending user's signature 1203) to the user's sponsor 1215, as specified 1204 in the sender's authorization certificate 1202. The recipient should receive from the sponsor 1215 the same message in return as confirmation 1216, but signed 1205 by the ~ W09~02993 2 I q 4 4 7 5 r~ . l6 sponsor. The recipient then verifies 1217 the sponsor's signature 1220 and the confirmation message 1216, and accepts 1219 the transaction 1201.
In order to create complex combinations of restrictions, a filter expression, which is a Boolean or logical expression involving one or more attributes, can allow ~onDLLuvLion of restrictions involving multiple attributes. The attribute assertions are linked with the usual Boolean ~n~nPctives "and", "or"
and "not". For example, the sponsor might restrict a user to submitting transaction with a type equal to "purchase order" ~n~ a value less than $100,000.
Assertionfi may involve either a single attribute value (equality, less than, greater than, etc.), multiple values of an attribute (subset, DUy_LD~t, etc.), or the p~eF or absence of an attribute in the dc Of course it will be appreciated that any or any of the described restrictions, as well as others, can be in effect at the same time for the same dc ~ ~ or trAnsaction. These reDtrictions have been di~ e~l and illustrated -!~ ately for clarity.
The use of authorization attributes allows a f -ipi~nt to verify authorization as well as iration. In such a scenario, the sponsor c~rtificatQs, an~l.o-ad by the D~VIIDV ing organization~s certiiicate, would be interpreted as authorizing "on sight~ the Ll~n ~ n to which they are applied, ~- ;nq all specified restrictions are met.
A set of basic pol1ciP~ must be defined for use 30 Ll~v~l.ouL the fln~n~i~l services industry and other industries in order to provide a well-defined, predictable level of service for the verification process. These policies would be agreed to on a multilateral ba5is by every participating firm and WO 96102993 1~ , /b could stipulate that certain of the restrictions and authorizations ~;~r~c~ed in this section would always be deemed to be in effect unless expressly provided otherwise. One of the more important elements of these industry a~L. c would be the definition and coding of dc t types. This must be done on a per-industry basis, since the rules will obviously be much different, f or instance, for customs inspectors, aircraft inspector5, auditor5, tax officials, etc.
Certain authorization attributes may pertain to the specific content of the ~n . L itself. This can pose problems for automated machine verification, because the verifier's computer may not always be able to determine the value5 of such attributes for a given d- L or transaction. Examples include -y transaction limits, dn. types, and security or confiA~ntiA11ty labels. Therefore, it is desirable to provide a ~LandaLd data block, preferably at the start of the l: L or the LL~n-~ l1nn, clearly ~roAin7 the attribute, for example the stated monetary LL_ -Lion value, ~._ type or security sensitivity label. This ~c tag will be ~P~ A
by the signer's computer for the convenience of the verifier and as an aid to the verification process.
How v r, in the event of a cnnflict between the tag and th- actual content of the d~ L, the ] A , -- ~ of the ~c would be controlling. In the case of ~LL~LuLed transactions, such as EDI tran---L;o~, in which the ~ L types and monetary values are already completely machine readable, dc~ L tags would not be needed.
As a pOc~; hl e convenience in proce~inq simple authorizations, ~peciAlly where a given user sign~
many similar transactions, it may often be helpful to WO 96/02993 ~ 1 q ~ 4 7 5 ~ 16 copy the user's public key out of his baOic - authentication certificate and include it as another attribute in an authorization certificate. This permits the authorization certificate to serve both purposes (authentication and authorization) and allows the sender to omit the basic authentication certificate from each transaction. In addition, where a device is being relied upon to fulfill a given condition, it may likewise be advantageous to copy the user's device public key into the authentication or authorization certificate as well, further eliminating the need to send the device certificate with each transaction.

Th 1 rd P~rtY Tnt~ract i onll:
Additional, useful features of digital si~lla~ures~
beyond those that can be provided using attribute certificates, involve interaction between a signer and third parties of various types.
One such use for digital si~llaLuL~s is electronic notarization. As ~;CC~9~1 above, there will be a need to cosign dc ~ using a third party that is trusted to provide an accurate 1i i and/or location information. Simply relying upon signature originators to provide this information in an accurate fashion leavQs si~laLuL_3 wlnerable to fraud based on, for example, pre- or post-dating of A:_ ta. An electronic ~nvL~Ly~ would be trusted by virtue of its CA's pol i~iDC to provide this information correctly.
The multiple signature ~r~hilities already assumed can 3 0 be oYr~nAAd to provide a EL _L k for this ~ervice.
For notarization ~UL~ es, ti-- ; - and location information will be in~l--ADd as signature attributes.
Individual signature oLLuv-u ~O may either be dDt~hDA

WO 96/02993 . ~,111 5 ,~ /6 and stored or, if desired, ~u~v~yed separately from the Multiple siy..aLuLds or joint signatures on the d~ ~ itself can also be distinguished from "countersiy--aLuLas," which are signatures on the slgnature ~LLu~LuLe in which they are found and not on the d~ L itself. A countersignature thus provides proof of the order in which siy-~aLuLes were applied.
Because a countersignature is itself a signature ~LLuuLuL~, it may itself contain countersiy..atuLes;
this allows ~u..~LLuuLion of arbitrarily long chains of countersignatures. Electronic notarization would then consist of countersigning the originator's signature and including a ti-- ; within the information being signed. For very high-risk applications it may also be desirable to reguire multiple siy~laLuLas on each certificate by one or more CAs, with the siu~a~uL~
being peLrl -I in ~nA~r~n~nt cryptographic facilities and with different private keys.
Various levels of service can be defined for electronic notaries based on the level of data verification performed prior to signing (ranging from mere existence of the ~c L, in which case notarization may be o letely automatic, to human verification of ~ L content) and based on data retention and audit oAr~hilities.
Another use for digital siyll~LuLes is for delegation or "power of attorney" certificates.
Because users are often tempted to entrust their devices or smartcards to others, for example, secretaries or co ~ Jl k~ when the users go on vacation, the freguent situation, in which one user obtains another user's smartcard and PIN, exposes the smartcard to possible misuse. The system therefore ~ W096/02993 2 1 9 4 4 7 ~ J76 facllitates the iAs~nre of power of attorney certificates that allow a delegate to associate the signature of his own smartcard with the authority of the delegating user. The power of attorney certificate would include at a minimum the name of the delegator, identification of the delegate's public key certificate and a short validity period, and would be signed by the delegator. Another poA~ihjlity is for the delegate to create a new key pair exclusively for use with the delegator's fiignature, with the new public key in~ d in the power of attorney certificate. This would eliminate any potential confusion between use of the delegate's private key on behalf of the delegator and on his own behalf.
The problem of handing over smart cards can be greatly reduced by providLng a workable alternative that preserves the principle of individual accountability. Wide i 1- Lion of this feature will make practical the di ~ of smartcard loans, a highly defiirable goal.
The use of delegation certificates d i r ~ ~ 1 above implies that the user is acting as a CA. In some cases, particularly those in which the transaction cro-~es organizationsl boundaries, there may be concern that the level of controls and auditing available with the individual user's ~L~Lu~ hic device (for exa~ple, a smart card) i~ not sufficient. In such cases, delegation certificates could be issued by a CA
upon request of the delegator as normal authorization certificates. Thifi also allows the delegation certificates to be revoked using the ~LAUdaLd CRL
'-ni~. Users' certificates might then indicate a list of poAsihle delegates, and the delegation W096/02993 1~~ ,o ~
21 ~4475 ~

certificate itself would contain an attribute naming the delegator.
In exercising the power of attorney, a user may indicate that he is signing for another user by ~n~ln~ing in the dc_ t or transaction a ~signing-for" signature attribute, that is, the name of the user being signed for. There must be ~ valid delegation certificate authorizing the signer to act for the user being signed for. Delegation is also useful in connection with a cryptographic module in a user's personal computer. Hashing and signing a ~ L should ideally be a unitary operation in order to prevent substitution of a false hash via software hacking. However, the typical s~artcard lacks the computing power to hash a very long A- t. One solution is to let the smartcard delegate this function to the cryptographic module using a very short-lived delegation certificate valid for only a few minutes.
This certificate is signed by the user's smart card and indicates that the user of the smart card has allowed the delegation. See, for example: Gasser, M., A.
Gol~t~in, C. Kaufman and B. Lampson, "The Digital Distributed System Security Architecture," Procee~ing~
of the 12th National C ~r Security Con~erence, 1989; Gasser, M. and E. M~n ~L, "An Architecture for PL ~ jr~l Delegation in a Distributed System,"
PLI ~~~'1ng~ of the 1990 IEEE Sy ~ on Security and Privacy.

Non-~lhlic ~lhli~ Kev A more basic problem, however, is ensuring that all po~cihle recipients will actually employ the certificate- and attribute-verification methods described above. Although these methods allow . ~

~ W096/02993 2 1 94475 ~ /6 sponsoring organizations to protect themselves, their users and those with whom they transact from liability based upon falsified transactions by allowing them to verify the identity and qualifications of those with whom they LL~naacL and the characteristics of the transactions prior to transacting, there is no guarantee that all recipients will actually 80 verify.
If a recipient acts upon a transaction without flrst verifying the attributes of both the sender and the transaction, and if the sender is later found to have sent a fraudulent or unauthorized transaction, the recipient could then claim liability from the sender or its sponsor by cl~;ming that the recipient was unaware of any require~ent for authorization verification of the user'5 basic signature. One way to ensure that ~UI~UL~ and other entities are protected from liability in such a situation is to require that the signer include the hash value of each of his identity and authority certificates AS attributes within hiB
signature. This can prevent a verifier from cl~i that he was unaware of such certificates and of the restrictions they impo~e. However, the signer might (intAntinnAlly or unintentionally) omit to do this.
Another more emphatic way to ensure verifier liAnre i~ to prevent the root key, the public key of the ulti~ate authority, that is, the highest-level certifying authority, which key would-be verifiers will need in order to verify any part of a LL ' ;nn, from being distributed to a user (or to the user's device or smartcard) unless the user contracts with the ~y~LO~L~yhic system and agrees to verify all parties and all trAn~tinn~ in ~O~uLl~nce with the preestAhli~h~d rules. In this way, the users are not te~hniCAlly forced to verify all parts of their W096/02993 P~llu~ v/6 ~
~1 94475 transactions. However, not verifying their trAnCA~tionQ in full would violate the C~ILL~_L between the users and the cryptographic system and would thereby absolve all other parties to the cryptographic system, for example a gponsor whose employee acted without authority, from liability. The non-verifying recipient would then bear all the ri5ks of such an unverified transaction himself. FULLII_L e, because the root key of the system authority is considered a trade secret, no one who has not signed the system rules ~ ~ L may possess a copy of it, and no one could claim to have verified any part of the transaction. This would make it far more difficult for the "outside" verifier to claim that he had incurred a 15 1058 by "L~s~ bly relylng" on the LL Lion, even if it was in fact valid. This art of keeping the system root key as a trade secret lends particular force and effectiveness to all the restriction and authorization methods described herein. It i8 belleved that the possibility of incurring the potentially-large liability for valuable LLa~n~A~- I ionC will p_L~uade users to employ the methods of attribute verification of thls invention.

Re~t~ictions on Certificate Distrih~tion U~ers and orgAnizations must be able to restrict the distribution of all types of certificates for a number of reasons. First, the certlficate3 o~ten contain confld~ti~l b~lQin~~Q information that the user or organization prefers not be shared with others and that is nevertheles5 being shared with the verifier through the certificnte, albeit only for the limited purpose of signature verification. Also, users' basic privacy rights may be violated if their public keys and ~ W096/02993 2 ~ ~4475 r ~ 6 network aldLe6ses are published. For example, they may - be flooded with unsolicited bu6iness proposals and advert~. Ls once their public keys are di~s~in~ted.
Furthermore, the organization may have a general policy S against giving out User identification numbers and public keys, because they may be used as starting points for various types of security attacks.
This functionality may be implemented as an attribute in user's certificate. If the "distribution-restriction" attribute is TRUE, the user/issuer grantspermission to use the certificate (which could be an authority or a public key certificate) only for signature verification; di5tribution or further publication is prohibited. Other ways to specify this restriction might include placing the attribute in the organization's certificate, puhlichinq the restriction as part of the industry-specific policy, or tin a true X.500 impl~ tion) using the X.SOO access control list -ni r~ to restrict access to the certificate.
Although some existing general legal basis for enforcing this restriction might be found under copyright law, that i8, if the certificate is declared as an ~lnr~hli~h~d work for which a license is granted only to the named verifier, a firmer legal basis will ~till be dosirable.

S--r~rd Re~i There are some additional reguirements on ~L L~a~d5 when used with commercial digital signature systems.
The first requirement is private key confinement and self-certification. That is, the user's private signature key must never be allowed to leave the smart card. only in this way can it be assured that theft of W096/02993 - r~ 6 ~1~
21 9~475 ~.

the key cannot be accomplished through purely electronic means without leaving any evidence. This principle of private key confinement is vital to the concept of non-repudiation.
Thus, as illustrated in FIGURE 13, when providing a public key 1303 to be certified, the card 1301 must attest that the card 1301 is t ~.uof and pOFC~cceF
a key confining design. Proof can be provided via a "device certificate" 1302 stating that the card originates from the specific manufacturer or product line. The public key 1308 of the device 1301 must then be certified by the manufacturer or by a CA designated by the manufacturer. One likely a~Lu~_l, to creating this device certificate would be to generate the device key pair during fabrication of the smartcard so that the CULL~ ;nq device certificate 1302 could also be in~ A~ on the card. The device certificate 1302 certifies the propertiss 1304 of the card, and the card generates a key pair 1303,1309 which is to be used by the user of the card and which the user can have certified as his own by any appropriate desired CA.
Then, when submitting a newly generated public key 1303 for certi~ication, the device private signature key 130S would be used to countorsign 1306 the certificate reguc~t data 1307, which is already signed by the newly ~ Led user private key 1309.
Also, in a case in which the ~u~. ~ requires that all decryption keys be e~ ', the card should be able to certify that it is ;n~ApAhle of decryption.
This ~signature only" certirication can bo i through the same -nil described above, thus allowing the user's signature key to remain exempt rrOm escrow requirements. Because it is doubtful whether an ~- . ' key retains any value for non-ropudiation ~ W096/02993 2~194~75 ~l6 services, this certification is vital in order to prevent the signature key's disclosure through possible mi ~h~n~l i ng during an escrow process.
Smartcards should also be required to guard against unauthorized use of personal identification numbers [PINs). Normally, a smartcard is protected against unauthorized use by a PIN, the equivalent of a pA _ld. Typically, a PIN is rh~nqe~hl e only by the user and must be a specified lenqth, but typically nothing prevents the user from setting the PIN to a trivial number, for example all 1~5 or 121212.
Smartcard vendors should be requested to implement PIN-change routines that insure non-trivial PINs without repeating digits or obvious patterns. Naking the PIN
relatively long tat least 6 digits) and non-trivial reduces the chance that the card can be operated by someone finding or stealing it. Support for a 6-digit PIN requirement can be found in ~X9.26: Fin~nr;
Institution Sign-On Authentication for Wholesale FinAn~;Al Transactions", ANSI, 1990, which is well-known in the art and is hereby incoL~uLaLed by reference and which sets forth the "one-in-a-million"
standard that states that a log-in ~n; ~ may be cnn~id~red sQCUre if, among other things, an attacker ha~ no more than a one-in-a-million chance of gU~ccinq the correct pA ,,~Ld and if the system takes evasive action to prevent repeated , - ; nq. Fur~ h~ e, smartcards should be required to take "evasive action~, for example, ch~lt~;n7 down for a period of time or even erasing private keys, if too many inc~-Le_L PINs are entered by an unauthorized user.
It could also be made ~ requirement that smartcard manufa_LuL~I6 use bi~ Lrics as more secure methods of identification. Extensive work is currently being done W096/02993 r~ 6 in the areas of voiceprint and fingerprint identification, as a supplement to PINs. However, while the rates of false positive and negative still must be reduced, the main problem lies in securing the biometric input device and its data channel 80 that they are immune to capture and replay of the biometric data. This is not a problem when the biometric device is . '-''~d in a concrete wall, for example in an AT~
or door nccess system, but it remains a serious problem in typical commercial office settings. Ideally, the card and biometric input device will each be t ~L oof cryptographic modules that can certify themselves and establish secure ~h~nn~l ~ with each other.
Smartcards should also be able to maintain an Haudit trail,H or an internal log of recent actions, containing at a minimum, a timestamp, transaction amount, type code and message digest. This information can be _6sed into 40 or so bytes so that a 400-record circular log would consume sround 16K bytes.
This log would be ~plc~-' and checked only on receipt of a signed request from the card issuer over a secure channel. Al30, the card would not delete the old log until it received a signed confirmation from the issuer stating that the l~ploA~D~ log had been received intact.
Thia control r- '~ni~ will deter forgery, reduce the damage that can be caused by a forger, and allow nnAIlthnrized or guestioned trAn~A~t;on~ to be investigated more quickly and easily. Since most or all transactions occur off-line from the issuer, the card is the best witnes6 of its own actions.

W096~2993 r~ ~,6 21 ~4475 Controlling Access to the Pl~hliC Kev of the Root tifyin~ Authoritv ~n~ Csst R~CU~LY
A~ shown in FIGURE 3, in a particular cryptographic system, there may be a hierarchy of certifying authorities (31-33) issuing certificates 34, 35. In a larger system the number of certifying authorities and the depth of the hierarchy would be much greater. In the structure shown in FIGURE 3 the certifying authority A (31) is the root certifying authority, with all other certifying authorities being below it. As noted in the description of FIGURE 3, the public key of certifying authority A is well known. In a system where certifying authority A accepts liability for any tr~ncac~ion~ in the system based on information in certificateS issued by A, it would be useful and desirable for certifying authority A (the root certifying authority) to control access to its public key. By doing so, certifying authority A could enforce rules on the system which would ensure the well-being of the ~LLU~-UL~ of the system. Various methods for controlling access to the public key of a certifying authority are now described.
With reference to FIGURE 14, in a cryptographic sy~tom, a certifying authority (CA) 1402 issues user identity certificates 1404 to users (for example, user 1438) of the cryptographic system. Certifying authority 1402 has a private key 1406 and a public key 1408. me private key 1406 is used to digitally sign the certificates 1404 with certifying authority's digital signature 1410. Certirying authority 1402 may be any certifying authority in a hierarchy of certi~ying authorities, such as, for example, that shown in FIGURE 3.
Certifying authority 1402 determines information about users of the system, and, based on that W096l02993 ~ 5 ,6 ~
2t 94475 information, issues the certificates 1404 to thosQ
users. A certificate 1404 issued by certifying authority 1402 to a u6er 1438 contains user information 1410 including the user's public key 1412 and certifying authority's policy information 1414 regarding that user. In order for the information contained in the certi~icates 1404 to be verified by other users of the system, these other users must have access to the public Xey 1408 of the certifying authority 1402.
Effectively, certificates 1404 issued by certifying authorities are used by users of the system to identify themselves to other users of the system so as to facilitate transactions within the sy6tem. A
r~c;rient (a system user~ receiving a tr~n~a~ti~n 1440 from another system user 1438, where the ~ r -Lion is ~ nied by a certificate 1404 issued by certifying authority 1402 can rely on Lnformation in the certificate 1404, essentially becaus~ the certifying authority 1402 which issued the certificate 1404 vouches for the information in the certificate and accepts liability for certain trAn~rt;~n~ which rely on information in the certificate. If the certificate 1404 in~ A~ policy information 1414 of the certifying authority, this liability is only accepted by the c~rtliying authority 1402 if the recipient hnd a valid copy of the certifying authority's public key 1406 and if the recipient followed the policy 1414 described in the certificate 1404.
Thus, for example, suppose that after verifying to its sat~f~rt~on the identity of user A (1438), certifying authority 1402 issued a certificat~ 1404 to user A (1438). The certificate inrlnt3~ the public key 1416 of user A (1438), a policy 1414 of certifying ~ W096/02993 1~ 6 21 9~475 .~

authority 1402 with respect to user A and i8 digitally signed by certifying authority 1402. Suppose, for example, that the policy 1414 in the certificate specified that user A can only enter into transactions on weekdays from nine in the morning to five in the afternoon. A recipient 1424 of a transaction 1440 by user A 1438 and the certificate 1404, can perform the transaction with the knowledge that certifying authority 1402 would accept liability for the transaction if (a) the recipient verified the policy 1414 for the transaction, that is, if the recipient verifies that the transaction is taking place within the allowed time bounds, and (b~ the recipient had a valid copy of the public key 1408 of the certifying authority 1402. In other words, if the recipient does not check the transaction with respect to the policy then the LLan~L_Lion is invalid. Further, even if a recipient checks the tr~n~ n from user A and the LL_ ~~ Lion i5 allowed by the policy of the certifying authority with respect to user A (as specified in the certiflcate), the certifying authority 1402 is not liable for the tr~r~~ if the recipient was not in p~sr- inn of a valid copy of the certifying authority' 8 public key 1408.
The ~L~Lo~L~I.ic system also in~ various ~ ~ 1418 who also issue certificates to users.
The~e , -~ -issued certificates are also known as authorization certificates 1420. These certificates 1420 function, inter alia, to specify the rule~ or policies 1422 of the sponsor issuing them. These authorization certificates 1420 can be separate and different from the identity certificates 1404 issued by the certifying authorities (even though the identity certificates may contain policy reguirements of the W096/02993 .~l/- ,v,6 2 ~ 94475 certifying authorities). A user may have only one identity certificate 1404 issued by a certifying authority 1402. However, a user may have numerous authorization certificates 1420 issued by one or more a~ul~S~. D 1418.
When a recipient receives a transaction from another user of the system, the recipient should also verify all sponsor policies included in authorization certificates inrlll~ed with the transaction from that user. Thus, in this cryptographic system, users are reguired to enforce the rules (policies) of the certifying authorities and D~l.SUrS in the system.
As noted above, in order for the information contained in the various certificates to be verii'ied by users of the system, these users must have accesD to the public key 1408 of the certifying authority 1402 or sponsor 1418 that issued the various certificates. In order to enforce the rules of each certifying authority and sponsor in the system it is ne~-C ~y to limit the access to the public key 1408 of some of the certifying authorities. In particular, it is "~ y to limit acces~ to the public key of the topmost (root~
certifying authority 1402.
Accordingly, the root certifying authority 1402 ke ps its public key a trade secret, and in order to obtain the public key of the root certifying authority 1402, a user (potential recipient) 1424 wishing to undertake trAnaa~ti~n in the system must obtain the certifying authority rules 1426 is~ued by the root certifying authority. r -;pi~nt 1424 must hash thoae rules to form hashed rules 1428 which it must then digitally sign to produce a signed copy of the hashnd rules 1430. This digitally signed copy of the hashed rules must be IeLuL..sd to the root certifying authority ~ W096/02993 r~ 6 ~ 21 94475 1402. /3y these actions, the recipient 1424 agrees to abide by the rule5 of the certifying authority 1402 which it has just signed. The root certifying authority 1402 may also require that the recipient 1424 ~15O obtain, sign and return rules from other certifying authorities in the system as well as from ~..svr~ in the system. For example, recipient 1424 may al60 be required to obtain sponsor rules 1432 from sponsor 1418 and return a signed copy of these rules 1434 to the sponsor 1418.
Once the root certifying authority 1402 is satisfied that it ha5 received a valid copy of the system rules signed by the recipient 1424, the root certifying authority issues its public key 1408 to the 15 recipient 1424.
The root certifying authority public key 1424 may be issued to a recipient in a number of ways. In preferred ~ the recipient is provided with a secure device 1436, for example, a ~LLV~Ld. In one 20 preferred ~ the certifying authority public key 1408 is immediately available in the secure device, so that once the rDciri~nt 1424 obtains the device, he has the root certifying authority public key 1408. In another preferred . ';- , the certifying authority 25 publlc key 1408 i6 in the device 1436 in A ~i r'hle~
form, and the root certifying authority 1402 enables the key 1408 in the device upon receipt and verification of the signed rules 1430.
In some cases it i5 useful for the root certifying 30 authority public key 1406 in device 1436 to expire or to become in~cre~6ible after a certain time period. In these cases, in order for the root certifying authority to reactivate the key 1406, the recipient 1424 must again obtain, sign and return the rules of the root WO96/02993 rc~,~ 16 21 q4475 certifying authority 1402. These rules may be different from the rules previously signed.
Different certifying authorities, including the root, may also reguire that other conditions be met by potential recipients before they are given access to the public keys of those certifying authorities.
However, in~ A~d in the sy5tem rules is an &yL~ t by anyone 5igning the rule5 to keep them a secret.

Cost ~_u~_~Y
The rules can also include a~ to pay for use of the system. Thus, when a user obtains a valid key ~by agreeing to follow the rules of the root CA of the system), the5e rule5 can enforce a~L~ L to comply with the payment scheme of the system.
A cryptographic system can link the operation of the system with associated payment by users of the system for the tran5action5 they perform and accept.
The payment for a tr~n~actinn is made, for example, in the form of a pre-paid account, an a~-. to be billed, or a cnnt~ aneuus payment of digital cash to various parties in the system. For example, a particular operations such as digitally signing a LL -t i nn may cost a user a certain amount to be paid 2S to th~ certifying authority which issued the certlficate which guarantees that user's identity.
Some digital payment fllnnti nn~ can be built into the devices cnntAining the public keys. Since user'~
private keys are typically kept in secure devices (for example, smartcards), the secure devices can be used to r-in~ Ain a current digital balance for each user. This digital balance can be a debit or a credit amount.
Every time a user digitally signs a trAn~nct i on using his secure device, a certain amount is deducted from W096/02993 r~ 6 ~ 21 94475 that user's digital balance. If the secure device is a debit device, then when the user's digital balance reaches zero the device would become disabled and no longer able to sign for the user. The user would then have to obtain further digital credit from a certifying authority or some other sponsor in the sDystem. If, on the other hand, the secUre device is a credit device, then the user might be required to perform a payment transaction to the certifying authority at certain regular intervals, for example, daily, weekly or monthly. Since the digital credit amount is available from the secure device, the certifying authority could be Assured that the transaction is for the correct amount. A user who does not perform the required payment LL~na~Lion would be listed in a CRL as being sn~p~n~d or revoked and would no longer be able to perform transactions in the system.
Digital payment on a per transaction basis is also achieved using a confirm-to transaction. The user's authorization certificate would list the confirm-to address of the payee. once the tr~ncacti~ occurs the payee is notified and can deduct payment from the uDer's account.

Price Inforr~tion Since a user has agreed to pay fees and royalties a~sociated with the system, the user can alDo be provided with flexible pricing and billing information.
U~ c_ific pricing policies can be i l~ Lud using certificates. Certificates issued by D~vn~~.D
and certifying authorities can include payment and pricing policies for particular users. For example, a certificate might include a list of prices for certain LL ~:Lions (in~ ing, for example, signing using a w096/02993 2 1 9 4 4 7 5 P~ o o particular private key, verifying using a particular public key, or ~hD~ing the revocation status of a particular certificate), a discount rate for particular users, a discount rate for transactions with certain recipients, and rates for bulk transactions. Some of the billing is performed by the secure devices of the users whereas other hjllAhle events can arise from actions performed by recipients of tr~n~ot;on~.
In order to implement certaLn pricing policies, a certificate may contain various digital fields. For some policies, these fields include a revocation service address, a revocation service fee, and a transaction confirmation fee. The revocation service address is similar to the confirm-to address, but is used only to confirm the validity of the certificates.
That is, the revocation service screens for attempted trAn~n~ion~ based on certificates that have been withdrawn. The Revocation service Fee is the fee charged for this service.
Examples of these fields are:
(a) Private Key_Signing_Fee s $0.50 (b) Public_Xey Verify_Fee = $0.50 (c) Revocation_Service_Address =
1 e ~ _I.e_~@btec.com ~d) Revocation_Service_Fee ~ 50.50 (e) Confirm_Service_Fee = $0.50 All fees can be stated as flat fees or a~ a fee per some amount of base L.~r.~:a~l ion amount. For example, a fee can be specified as "$0.50~ or as "$0.50 per $1,000 of base LL~rnacLion amount".
Given the above examples, a recipient receiving a LL ~~ Lion could send the associated certLficates to the revocation service address and would be billed at the rate specified by the service fee.

~ W096/02993 2 1 9 4 4 7 5 P~ 6 In order to charge for a confirm-to tran6action, a certificate can also contain a transaction confirmation fee, for example, Transaction_Confirmation Fee =
tS0-50 per $1000 transaction amount) In this case each confirmed transaction would cost the recipient the appropriate fee.
In some instances a recipient may receive a transaction that is too expensive and which it would therefore reject. Accordingly, a digital field indicating p~ inn to bill the sender, the field being signed by the sender, is also inr,lllA~A. This field could include the sender's account number and other information inrl~lAing a maximum acceptable billing rate etc. This "bill-5ender" field would appear as an attribute in the sender's signature block.
Intellectn~l PLO~LLY L1rrnR;n~
The rules may also include agL. to pay for all int~ll~ct~l pL~ -y u5ed by a user. For example, a ~ystem may offer a user patented tr~nQ~rtinnQ, _ervices or algorithms, copyrighted materials, and the like. In order to a user to obtain a public key that would enable access to this intellectual p~y_LLy~ the user must sign the user rules agreeing to pay for use of the ~L ~L LY .
For example, in one ~ , the secure device contains many un-activated services (for which payment is reguired). Each use of one of these services requires payment in the foro, for example, of digital cash, either by an internal transaction in the device W096/02993 P~ v,6 or by some transaction with another user of the system.
In order to obtain the device, the user must digitally sign a set of rules (using a private key in the device and unique to the device and therefore the user). By S signing these rules, the user agrees to make the paymentc as reguired.

Sinnr~r T ~ ~ Policies A~ Rlll es A user of a cryptographic system may have an identification certificate tissued by a CA) and one or more authorization certificates (issued by CAs or ~y~ L~ of that user). Each of these certificates has pol1ci~ of the issuing party, and a recipient of a transaction including any of these certificates iB
~Ypect~ to verify that the transaction obeys all the rules specified in the certificates. It may be the case, however, that for a particular trAn~AVcti nn~ a user wishes to have more restrictive rules applied than are allowed by the certificates. For example, a user may be allowed to approve all tr~n~acti onc of $1 million or le~s, but may wish to approve a certain ~L -~ion only if its value is less than $1,000.
Alternatively, a user may be allowed to approve certain LL ~ ;~n~ alone, but for a ~pec;fic trAn-v i~n the u~~ may wish to require one or more co-signers. In support oS this feature, the ~lyyLc~L~phic system of the present invention provides users with the ability to add user rules, attributes and restrictions to trAn-VA,c~irnc.
The user rules cannot permit t~ - L;~nQ to be ~y,~._d that would not otherwise be allowed.
Therefore a recipient must alway~ apply the most restrictive rules to every transaction. For example, if a user's certificate allows transactions up to ~ w096/02993 2 1 9 4 4 7 5 r~ C /6 51,000 and the user rules specified transaction values of up to $1 million, clearly the Sl,oOo limit should apply. This can be achieved, for example, by the recipient applying all of the certificate rules first and then, if the transaction i5 still valid, applying all of the user rules. Applying the user rules first and then the certificate rules will also produce a correct result. ~owever, since boolean combinations of rules and restrictions are supported, interleaving the user and certificate rules may produce an inc~LL~L
result if not carefully performed.
FIGURE 15 shows verification of a user trAn~ n which includes user-supplied rules. A user LL~I-f ~ cLion 1502 ;n~ln~o~ transaction text 1506 describing the transaction to be performed by a recipient. The user appends to the transaction text 1506 a set of user-supplied rules 1504 which the user wants verified by any recipient of the transaction 150Z. Then the user digitally signs the combination of the LL .cti~n text 1506 and the rules 1504 to form the transaction 1502, forming a user signature 1510 which is -~p n~l~d to the transaction.
The transaction 1506 is then sent, along with any required sponsor and/or CA certificates, for example, with CA certificate 1508 and sponsor certificate 1509, to a recipient who must then verify the transaction.
To do this, the recipient verifies 1512 the user'a signature 1510 using the user's public key 1514 from the CA certificate 1508. If the user's signature is accepted, verification c~ntir 35, otherwise the transaction is rejected 1514. If verification continues, the recipient verifies 1516 the CA's signature 1518 using the CA's public key 1520. If the CA's ~ignature is accepted, verification continues 1522 W096/02993 ~ v16 with the rh~r~ing of the rules in all certificates and those supplied by the user, inrln~ing sponsor certificate 1509. Otherwise, the transaction is rejected 1514. If verification continues, the recipient verifies 1522 the trAncactinn against the rules in the CA certificate 1508, sponsor certificate 1509 (and in any other certificates associated with this transaction). If any of these rules are not satisfied the trAnaartion is rejected 1514, otherwise verification of the transaction continues with the verification of the transaction with respect to the user-supplied rules 1504. Only if the transaction satisfies the user provided rules 1504 is it accepted 1526, otherwise it is rejected 1514.
The us~ ~lied rules 1504 can be any combinations of the rules known to the system, inr~ ing, but not limited to co-signature reguirements, temporal limits, trAnaactinn amount limits, confirm-to requirements and the like.
In some envi~ users may create sets of rules or default rules for themselves for use with particular types of users or tr~nalc~inne. These sets of rules or defaults may be automatically attached to all trA- ~tnna from those types of users or L- ;~na. For example, a user who is b_n]c manager may ' ine (from experience) that for all LL ~1 nna by new tellers that she countersigns, she is going to apply more restrictive rules than the bank requires. She would then store these rules in her system as a default for those kinds of trAna~rti that she signs or cvu..~r~igns.
One skilled in the art will appreciate that the present invention is typically practiced using electronic devices such as digital electronic computers ~ W096/02993 2194475 r~ vl6 and the like, and that the certificates, transactions, ~ r~ s, signatures and the like are digital electronic signals generated by the electronic devices ~ and transmitted between the electronic devices.
Thus, a method for securely using digital signatures in a commercial cryptographic system is provided. One skilled in the art will appreciate that the present invention can be practiced by other than the deficribed - '~ ';~~ Ls, which are presented for y~,yoses of illustration and not limitation, and the present invention is limited only by the claims that follow.

Claims (17)

What is claimed is:

1. In a cryptographic system wherein a certifying authority issues digital certificates identifying users of said system, said digital certificates being digitally signed with a private key of said certifying authority to form a digital signature and requiring a public key of said certifying authority in order to verify said digital signature, and wherein a user transaction in said cryptographic system requires verification by a recipient of said user transaction, said verification based on information in said digital certificates and requiring said public key, a method of controlling access to said public key comprising the steps of:
denying access to said public key;
providing said recipient with at least one message containing rules of said system, said rules including maintaining secrecy of said public key;
by said recipient, digitally signing said at least one document, by which said recipient agrees to said rules; and in response to said digital signing, permitting said recipient to utilize said public key.

2. A method as in claim 1 wherein said step of providing includes the step of providing said recipient with a secure device containing said public key, wherein said public key cannot be obtained from said secure device.

3. A method of enforcing a security policy in a cryptographic system, said policy requiring controlling access to a public key, said method comprising the steps of:
denying access to said public key;
providing a recipient with a message containing rules of said cryptographic system, said rules including maintaining secrecy of said public key;
by said recipient, digitally signing said document, by which said recipient agrees to said rules;
in response to said digitally signing, permitting said recipient to utilize public key.

4. A method of enforcing a security policy in a cryptographic system, said policy requiring controlling access to a public key, said method comprising the steps of:
providing a recipient with a document containing rules of said system and with a secure device containing an inactive form of said public key, wherein said public key cannot be obtained from said device;
by said recipient, digitally signing said document;
in response to said digital signing, activating said public key in said secure device.

5. A method of enforcing a security policy in a crytographic system, said policy requiring controlling access to a public key of a certifying authority, said method comprising the steps of:
by said certifying authority, providing a user with a message containing rules of said system and with a secure device containing an inactive form of said public key, wherein said public key cannot be obtained from said device;

by said user, indicating an intent to follow said rules, said indicating including the steps of:
hashing said message to obtain a hashed document;
digitally signing said hashed document to form a digital agreement; and returning said digital agreement to said certifying authority;
in response to said indicating by said user, by said certifying authority, activating said public key in said secure device.

6. A method as in any one of claims 1-5 wherein each user of the system has a private key, and wherein said rules include at least one of rules requiring payment to a third party upon:
each use of said public key;
each use of a user's private key;
each certification of a certificate's status; and each confirm-to transaction by a user.

7. A method as in any one of claims 1-5 wherein said rules include rules to pay for use by said recipient of intellectual property used in creating or operating the system.

8. A method as in claim 1 wherein said user transaction is invalid until said step of digital signing is performed.

9. A method as in claim 1 further comprising the steps of:

in response to said signing by said recipient, said certifying authority accepting a transaction from said recipient, said transaction based on said user transaction.

10. In a cryptographic system wherein a certifying authority issues digital certificates identifying users of said system, said digital certificates being digitally signed with a private key of said certifying authority to form a digital signature and requiring a public key of said certifying authority in order to verify said digital signature, and wherein a user transaction in said cryptographic system requires verification by a recipient of said user transaction, said verification based on information in said digital certificates and requiring said public key, a method of controlling access to said public key comprising the steps of:
providing said recipient with a secure device containing an inactive form of said public key, wherein said public key cannot be obtained from said secure device;
in response to a predetermined transaction with said secure device, activating said inactive public key is said secure device, said predetermined transaction including information from the secure device identifying operational capabilities of the secure device and uniquely identifying said secure device and further including information uniquely binding said recipient to said predetermined transaction.

11. In a cryptographic system wherein a certifying authority issues digital certificates identifying users of said system, said digital certificates being digitally signed with a private key of said certifying authority to form a digital signature and requiring a public key of said certifying authority in order to verify said digital signature, and wherein a user transaction in said cryptographic system requires verification by a recipient of said user transaction, said verification based on information in said digital certificates and requiring said public key, a method of controlling access to said public key comprising the steps of:
providing said recipient with a secure device;
in response to a predetermined transaction with said secure device, transferring said public key to said secure device, said predetermined transaction including information from the secure device identifying operational capabilities of the secure device and uniquely identifying said secure device and further including information uniquely binding said recipient to said predetermined transaction, wherein said public key cannot be obtained from said secure device.

12. A method as in one of claims 10 and 11 wherein said public key in said secure device becomes inactive after a predetermined time period, said method further comprising the steps of:
after said public key in said device becomes inactive, in response to another predetermined transaction with said secure device, activating said inactive public key is said secure device, said other predetermined transaction including information from the secure device identifying operational capabilities of the secure device and further including information uniquely binding said recipient to said other predetermined transaction.

13. A method of enforcing a policy in a cryptographic communication system comprising the steps of:
forming a digital message by a user;
combining with said message at least one user rule;
forming a digital user signature based on said digital message, said at least one user rule and a private key of said user;
combining said digital message, said at least one user rule and said digital user signature to form a digital user transaction; and combining with said digital user transaction a digital identifying certificate issued by a certifying authority, said identifying certificate having a plurality of digital fields, at least one of said fields identifying said user, wherein said at least one user rule specifying conditions under which said digital message transaction is valid.

14. A method as in claim 13, further comprising the step of:
combining with said digital transaction a digital authorizing certificate, separate from said identifying certificate and issued by a sponsor of said user for authorizing transactions by said user.

15. A method of enforcing a policy in a cryptographic communication system comprising the steps of:

receiving a digital user transaction including a digital message, at least one user rule specifying conditions under which said transaction is valid and a digital user signature based on said digital message, said at least one user rule and on a private key of a user;
receiving a digital identifying certificate issued by a certifying authority and having a plurality of digital fields, at least one of said fields identifying said user;
verifying said transaction based on information in said certificate and in said at least one user rule;
and accepting said transaction based on said outcome of said verifying.

16. A method as in claim 15, further comprising the step of:
receiving a digital authorizing certificate, separate from said identifying certificate and issued by a sponsor of said user and authorizing transactions by said user; and wherein said step of verifying includes step of:
verifying said transaction based on information in said authorizing certificate.

17. A method as in any one of claims 13-16 wherein said at least one user rule includes at least one of:
(a) allowed document types of said transaction;
(b) allowed locations at which transactions can be formed;
(c) allowed times at which transactions may be formed;

(d) a time period within which said signature is valid;
(e) a monetary limit for said transaction; and (f) co-signer requirements for said transaction.