WO2001052473A1

WO2001052473A1 - Secure management of electronic documents in a networked environment

Info

Publication number: WO2001052473A1
Application number: PCT/US2000/010405
Authority: WO
Inventors: M. Michael Serbinis; Sumit Oberai; Daniel Leibu
Original assignee: Critical Path, Inc.
Priority date: 2000-01-14
Filing date: 2000-04-18
Publication date: 2001-07-19
Also published as: AR023579A1; AU2000243591A1; TW474080B

Abstract

A system and method are provided that permit electronic documents to be securely transferred, stored, and shared. When an electronic document (60) is to be managed by the system, a document key pair (62), comprising a document public key (62a) and a document private key (62b) are generated. The document key pair (62) is used to encrypt the document, and a public key associated with a recipient is used to encrypt the document key pair (62). To share the document with an entire team, a team public key (70a) is used to encrypt the document key pair (62). Each member of the team is provided a copy of a team key pair (70) comprising a team public key (70a) and a team private key (70b), encrypted using his public key. The team private key (70b) may be used to decrypt the document. The document and all keys are generated, encrypted, and decrypted on a user's computer, so that the document management system has no access to decrypted versions of the document or the keys. The system is illustratively described in the context of an Internet-accessible document management system.

Description

SECURE MANAGEMENT OF ELECTRONIC DOCUMENTS IN A NETWORKED ENVIRONMENT

Field Of The Invention

This invention relates to apparatus and methods for securely transferring, sharing, and storing electronic documents over insecure electronic networks, such as the Internet. More specifically, the present invention provides apparatus and methods for securely- handling electronic documents in a networked document management system.

Background Of The Invention

Document management systems are known that permit multiple users to store and retrieve electronic documents on a closed client/server architecture network, such as a local area network or secure wide area network. These previously known document management systems, such as DOCSFusion, available from PCDOCS, Inc., Toronto, Ontario, Canada and EDMS 98, available from Documentum, Inc., Pleasanton, California, require the presence of a client application on each node of the network that is to access and manipulate files, and provide limited security features . With the recent rapid expansion of the Internet, the opportunity for collaborative efforts has increased many fold, as colleagues scattered around the world can rapidly transmit files for review and revision using electronic mail facilities. While electronic mail systems are useful for transmitting relatively small files on the Internet, however, large documents often are too large to be handled by typical message transfer systems, and can overburden a network. Large documents also may exceed the available storage at a recipient's site, thus preventing a recipient from storing a received document . Electronic mail systems used on open systems, such as the Internet, also do not generally address security concerns, or permit a transmission to be tracked, as is possible with a physical document delivery service (e.g., courier). Some or all of these difficulties may be addressed by using a centralized, Internet-accessible document management service that permits documents to be uploaded to the service for. storage, transfer, collaboration, or other document management services . This centralized service also provides an ability to limit access to documents, and to track when documents are uploaded, viewed, changed, downloaded, or otherwise accessed. Additionally, unlike e-mail, where each recipient of a document receives his or her own copy of the document, a centralized document management service may store a single copy of a lengthy document, while sending "recipients" a short notice, allowing them to access the document on the service, saving storage space and communications bandwidth. These services may be made accessible over the Internet, using a standard Web browser as the interface through these services are accessed.

Numerous services are known that provide a few of the aforementioned benefits associated with an Internet document management service. For example,

Smith, U.S. Patent No. 5,790,790, describes an Internet electronic document delivery system, wherein an e-mail message sent to a recipient contains a direct reference to an electronic document stored on a server. The system described in the Smith patent does not provide a full set of document management services, such as document sharing or storage, and does not provide security services. An additional drawback of the system described in that patent, is that the sending computer must include a specialized client application for interacting with the server. The system described in the Smith patent also lacks the transaction logging and accounting functions needed to provide a useful document management system. The IME system, offered by Tumbleweed

Communications Corporation, of Redwood City, California, overcomes some of the drawbacks of the system described in the Smith patent. For example, the IME system eliminates the need for specialized client software for basic document delivery operations, and permits the use of a previously known web browser, such as Internet Explorer^®, available from Microsoft Corp., Redmond, Washington, or Netscape Navigator^®, Netscape Corporation, Mountain View, California. However, the system provides none of the capabilities normally associated with a document management system.

Higley, U.S. Patent No. 5,790,793, like the aforementioned Smith patent, also describes an Internet electronic document delivery system wherein an e-mail message includes a URL reference to a document stored in a server. This system described in this patent also requires the use of a specialized client application, and is limited to an electronic document delivery service.

All of these services focus almost exclusively on document delivery, rather than on other document management services, such as storage and collaboration. Additionally, previously-known systems have had limited document tracking and accounting capabilities, and limited security.

While it is known in the art to use an Internet web browser to download an electronic document from a website, using, for example, Hyper Text Transfer Protocol ("HTTP") or File Transfer Protocol ("FTP"), there currently do not exist secure network document management systems that use encryption and digital signatures to permit a file to be modified by a user, and uploaded to the system for further' collaborative retrieval and modification by others, so that neither unauthorized users, nor the document management system can view protected documents . Although presently known systems may use a secure transfer method, such as Secure Sockets Layer (SSL) to transfer documents between a server and a client computer, this is not sufficient to provide confidentiality or authentication for an electronic document after it has been transferred. Systems that rely exclusively on SSL and other secure transfer methods do not prevent unauthorized access to electronic documents by the service provider (i.e. the company that runs the server to which the documents are transferred) , or against any intruders who may gain access to the server on which documents are stored.

Recently, electronic mail systems have been developed that provide an ability to send encrypted e- mail. These systems typically offer only e-mail service, and do not provide a centralized server on which documents or messages are stored, or any other document management services . Such systems are often implemented by combining a known e-mail client program with known encryption products and standards, such as OpenPGP or S/MIME. Both OpenPGP and S/MIME use public- key cryptography, and provide encryption, authentication, and nonrepudiation capabilities.

Public-key cryptography uses a key pair for encryption and decryption. This key pair comprises a private key, known only to the owner of the key pair, and a public key, accessible to the public. A message that is encrypted using the private key may only be decrypted using the public key, and a message encrypted using the public key may only be decrypted using the private key. Thus, to securely send a message to a particular recipient, the message may be encrypted using the recipient's public key, which is known to the public. The message may then be sent to the recipient, and decrypted using the recipient's private key. Since only the recipient knows his private key, only the recipient is able to decrypt the message .

Public-key cryptography may also be used to provide authentication and nonrepudiation. Typically, this is done by applying a "digital ' signature" to a message, using the private key of the sender. In a typical digital signature protocol, the sender applies a "message digest" algorithm, such as MD2 or MD5 (described in RFCs (Request for Comments) 1319 and 1321, maintained by the Internet Society (ISOC) , in Reston, Virginia) to the message to generate a short digest that would change if anything in the message changed. This digest is then encrypted using the sender's private key. A recipient receives both the message, and the encrypted digest, and decrypts the digest using the sender's public key. The recipient then independently applies the message digest algorithm to the message, and compares the result with the digest that was sent with the message. If the two digests match, then the message has not been altered, and there is evidence that the sender whose public key was used to decrypt the digest sent the message. There are numerous public-key algorithms available, including RSA (covered in U.S. Patent Number 4,405,829, to Rivest et al . ) , and various algorithms based on elliptic curves. Any of these public-key algorithms may be used according to a wide variety of protocols to accomplish a variety of security-related tasks .

It should be noted that public-key cryptography (also known as asymmetric cryptography) methods are typically implemented using a combination of public-key algorithms and secret-key cryptography algorithms (also known as symmetric cryptography) , in which a single secret key is used both to encrypt and to decrypt a message. Such "hybrid" algorithms typically work by using a randomly generated secret key to encrypt a message using secret-key cryptography methods, and a public-key algorithm to encrypt the secret key. When the message is decrypted, a public- key algorithm is used to decrypt the secret key, which is then used to decrypt the message. Since it is typically much faster and easier to encrypt large messages using a secret-key algorithm than using a public-key algorithm, hybrid algorithms advantageously combine the speed of secret-key algorithms with the flexibility of public-key algorithms.

As used herein, use of a public or private key to encrypt or decrypt data indicates that either a hybrid algorithm is to be used for the encryption or decryption, or that a public-key algorithm is to be used. Similarly, public-key cryptography indicates use of either a hybrid algorithm, or a "pure" public-key algorithm. Although hybrid algorithms, such as described above, and "pure" public-key algorithms may be used interchangeably, at present, a hybrid algorithm will typically be preferable, due to the speed advantages of hybrid algorithms .

Public-key cryptography products (using both public-key algorithms and hybrid algorithms) that may be incorporated into other products and systems are offered commercially by RSA Security, Inc., of Bedford, Massachusetts. RSA Security has promulgated a series of standards for public-key cryptography known collectively as PKCS. The PKCS standards describe a variety of security-related technologies, including syntax for digital certificates, cryptographic messages, private key information, and certificate requests. The PKCS standards are typically referred to by a number, such as PKCS #5, which provides a password-based encryption standard. The various PKCS standards are summarized in Burton S. Kaliski Jr., "An Overview of the PKCS Standards," RSA Laboratories Technical Note, RSA Security, Inc. Public-Key Cryptography Standards (PKCS) , Revised November 1, 1993.

Public-key cryptography relies on being able to obtain a public key for an intended recipient of encrypted messages, or for the sender of a digital signature. A person's public key almost serves as his or her "digital identity", in that anyone who wishes to send a private message, or verify the source and authenticity of a signed digital document identifies a person by his or her public key. It is therefore necessary to have a trusted way of accessing public keys . One method that has been used to provide such a level of trust uses "digital certificates."

Digital certificates are issued by certification authorities to provide a trusted source for public key information. A digital certificate typically comprises a public key and other identifying information that has been digitally signed by a certification authority. A digital certificate is created when a user sends a certification request containing a public key and identifying information to a certificate authority. The certificate authority may then attempt to verify the information, and adds its digital signature to the public key and identifying information, which is then sent back to the person who made the request . The digital certificate may then be sent to those who wish to communicate securely with the owner of the certificate, or stored in a database, where it will be available to others. The digital signature of the certification authority is used to authenticate the certificate. A standard syntax for sending certification requests is given in PKCS #10, and a standard format for digital certificates is provided in PKCS #6, and in ITU Recommendation X.509, promulgated by the International Telecommunication Union, headquartered in Geneva, Switzerland. For sending secure e-mail, and other communications, many e-mail clients use the S/MIME specification, maintained by the S/MIME working group of the Internet Engineering Task Force, and available through the Internet Society (ISOC) of Reston, Virginia. S/MIME packages messages that are to be securely sent into a "digital envelope" , that provides encryption and digital signatures. The digital signature portion of S/MIME essentially works in the manner described above. The encryption for S/MIME uses a hybrid algorithm, as explained below.

In a first step of encrypting a message using S/MIME, the sender's system generates a random "session key", which is used in a symmetric (or secret-key) encryption algorithm, such as DES, Triple-DES, or RC2 , to encrypt the message. A symmetric encryption algorithm is used because symmetric encryption algorithms are typically computationally less expensive than public-key encryption algorithms, and are better suited for use on long messages . Next, the random session key is encrypted with the intended recipient's public key, obtained from an X.509 digital certificate. Encryption of the session key is performed using a public-key encryption algorithm, such as RSA. The encrypted message, and encrypted session key are then sent to the intended recipient .

To unpack an S/MIME digital envelope, the recipient first uses his private key to decrypt the session key. The session key is then used with a symmetric algorithm to decrypt the message. Additionally, the message may be authenticated using a digital signature, as described above, and an X.509 digital certificate containing the sender's public key. Verisign, Inc., of Mountain View, California, has established a certificate hierarchy to support S/MIME. For a fee, Verisign can provide digital certificates for use with S/MIME, and store the digital certificates in a database that can be used to find a person's public key, given identifying information, such as an e-mail address, a name, or a serial number for the digital certificate.

All of these protocols and encryption methods are directed at ensuring the security of messages or other data that is sent across insecure communication channels. Use of similar security methods to protect electronic documents as they are managed by a centralized Internet document management service is more complex and cumbersome. For example, to forward an S/MIME encoded message to a new recipient using such a centralized document management service, it is necessary to download the message from the document management service, decrypt the message using the original recipient's private key, re-encrypt the entire message using the public key of the new recipient, and upload the re-encrypted message back to the document management service, with instructions to notify the new recipient that the document may be retrieved. Sharing S/MIME messages with multiple users on a team typically requires that the message be downloaded, and re- encrypted and uploaded for each member of the team, and for each new member of the team. If many large messages are being sent to every member of a large team, this can be very expensive in terms of computation time, storage requirements, and communication bandwidth. Although there is a great need for secure management of documents in an Internet-accessible document management system, use of standard "digital- envelope" protocols, such as S/MIME, can reduce the storage and communication benefits associated with centralized document management services. Because documents must be repackaged (i.e. re-encrypted and signed, or placed in a new "digital envelope") for each recipient or team member, it is necessary to upload and store many separate copies of a document . This makes collaboration and sharing of documents more difficult. In view of the foregoing, it would be desirable to provide a system and methods for performing a variety of secure electronic document management services, including transferring, storing, and sharing electronic documents.

It would further be desirable to provide a document management service and methods that permit secure storage, transfer, and sharing of documents without requiring that the entire document be re- encrypted in order to be forwarded or shared with each member of a team or other group.

It also would be desirable to provide a document management service and methods that permit electronic documents to be securely transferred, stored, and shared, without permitting the document management service or any unintended recipients to access unencrypted electronic documents . Summary Of The Invention

It is an object of the present invention to provide a system and methods for performing a variety of secure electronic document management services, including transferring, storing, and sharing electronic documents .

It is a further object of the present invention to provide a document management service and methods that permit secure storage, transfer, and sharing of documents without requiring that the entire document be re-encrypted in order to be forwarded or shared with each member of a team or other group .

It also is an object of the present invention to provide a document management service and methods that permit electronic documents to be securely transferred, stored, and shared, without permitting the document management service or any unintended recipients to access unencrypted electronic documents.

These and other objects of the present invention are accomplished by adding additional levels of key management onto existing encryption techniques. In a preferred embodiment of the invention, for use with a document management system, each document is provided with a document key pair comprising a document public key and a document private key, which may be used to encrypt or decrypt the document, but not to digitally sign or authenticate the document. This document key pair may then be encrypted using the public key of an intended recipient, while the document itself is encrypted using the document public key. The document, and the document key pair, encrypted using the recipient's public key, and optionally digitally signed using the originator's private key, are uploaded to the document management service, which may notify the intended recipient that the document is available. In a preferred embodiment, generation of key pairs, encryption, and decryption are all performed on a computer separate from the system that provides the document management service, so that the document management service never has access to an unencrypted version of the document .

To view the document, the recipient first downloads the document and the document key pair from the document management service, and uses his private key to decrypt the document key pair. The recipient then uses the document private key to decrypt the document. To forward the document to a new recipient, it is necessary only to. download and decrypt the document key pair, re-encrypt the document key pair with the new recipient's public key, and upload the re- encrypted document key pair. It is not necessary to download, decrypt, re-encrypt, and upload the entire document to forward the document. For large documents, this can be a considerable savings in time, storage space, and communications bandwidth.

In accordance with the principles of the present invention, an additional level of key management may be added to permit documents to be shared by all the members of a team without re- encrypting the document for each team member. When a new member is added to a team, that member receives a copy of a team key pair, comprising a team public key and a team private key, encrypted using that member's public key. The document key pair of documents that are to be shared with the team are encrypted using the team public key. Each member of the team may access the documents by using their private key to decrypt the team key pair, using the team private key to decrypt the document key pair, and using the document private key to decrypt the document . The document and the document key pair each need be encrypted only once to be shared by all the members of a team.

The steps of generating document (or team) keys, encrypting the document, encrypting the document (or team) key pair, decrypting the key pairs, and decrypting the document preferably are all carried out on a user's computer, rather than on a system associated with the centralized Internet-accessible document management service. Thus, the document management service that stores the encrypted key pairs and encrypted documents never has access to unencrypted versions of key pairs or documents, and cannot compromise the security of the documents that are stored, transferred, or shared using the document management service.

Brief Description Of The Drawings

The above and other objects and advantages of the invention will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like references refer to like parts throughout, and in which:

FIGS. 1A and IB are block diagrams illustrating the architecture of a document management service (DMS) system for use with the system and methods of the present invention; FIG. 2 is a flowchart of a method for securely handling a document in accordance with the principles of the present invention;

FIG. 3 is a flowchart of a method for securely transferring an electronic document in accordance with the principles of the present invention;

FIGS 4A and 4B show additional levels of encryption and key management in accordance with the principles of the present invention;

FIG. 5 is a flowchart of a method of adding a new member to a team in accordance with the principles of the present invention; and

FIG. 6 shows the structure of a digital certificate storing a document public key in accordance with the principles of the present invention.

Detailed Description Of The Invention

The present invention is directed to apparatus and methods for securely managing electronic documents over the Internet. Specifically, the present invention provides methods for securely transferring and sharing documents in a networked environment using a centralized document management service. The methods of the present invention are illustratively presented in the context of an Internet-accessible server programmed to provide a plurality of document management services, including document storage and retrieval, collaborative document sharing, and electronic document delivery and distribution. In accordance with the principles of the present invention, these services may be performed securely without requiring that the user trust the provider of the service with valuable information such as keys or messages, and without requiring that large documents be downloaded, and re-encrypted each time they are transferred, shared, forwarded, or distributed.

The document management system supports these service and security features through a common database system or data repository that permits interfaces to the multiple services to be accessed using previously known web browsers, and without a specialized client application aside from downloadable applets or other "mobile code" that may execute within the context of the browser. Other networked systems, such as operating systems and file systems, that require secure transfer and sharing of information also may advantageously use the methods of the present invention.

It should be noted that as used herein, an electronic document comprises any collection of electronic data that may be stored, transferred, shared, or otherwise managed. Typically, an electronic document will comprise a file or collection of files.

System Architecture

Referring to FIGS. 1A and IB, an illustrative architecture suitable for implementing the system and methods of the present invention in the context of a network document management service is described. In FIGS. 1A and IB, this architecture comprises personal computers 10 and 11 coupled through an open network, such as Internet 15, to document management services ("DMS") system 17. DMS system 17 comprises server computer 20, which in turn, comprises or is coupled to DMS database 25, store 30, notification server 35 and public key infrastructure server 40. Personal computers 10 and 11 are connected to an open network, such as Internet 15, using wireless connections, dedicated lines, or dial-up connections to the public standard telephone network ("PSTN") . While Internet 15 is depicted as a single entity, it will of course be understood that Internet 15 comprises a myriad of computer networks connected by bridges, routers, etc., and is constantly evolving. As defined herein, the term "Internet" refers not only to the Internet in its present form, but also encompasses changes, additions and future embodiments of the Internet. Each of personal computers 10 and 11 preferably is connected to Internet 15 through an Internet Service Provider ("ISP"), and includes a web browser, such as the aforementioned Internet Explorer^® or Netscape Navigator^®, which is preferably used to interact with DMS system 17. Personal computers may be standalone computers, or may be connected to the Internet through a local area network (not shown) . Personal computers 10 and 11 may be IBM-compatible personal computers (or any other type of computer) , or take the form of other devices capable of establishing a connection to the Internet, including TV set-top boxes, handheld devices, Personal Digital Assistants (PDAs), cellular telephones, or other wireless devices. Server computer 20 is coupled to, and communicates asynchronously with, Internet 15, and includes a domain-specific digital certificate to enable secure communications between client computers and server computer 20. Server computer 20 preferably is programmed as a web server, e.g., to run Hyper Text Transfer Protocol ("HTTP") and with Document Management Services ("DMS") system software that provides a variety of document management services, including document storage and retrieval, collaborative document" sharing, and electronic document delivery and distribution. Server 20 also is programmed to handle the document security methods of the present invention, and is preferably capable of downloading to personal computers 10 and 11 applets or other "mobile code" capable of executing on personal computers 10 and 11, permitting personal computers 10 and 11 to handle the methods of the present invention. In a preferred embodiment, the DMS software runs on the web server through a Common Gateway Interface (CGI) , through Java servlets, or through Enterprise Java Beans (EJB) services . This enables DMS system 17 to interact with users through a web browser, rather than requiring specialized client software. Using CGI, a user enters information into a form displayed in a web browser. The information is transferred to server computer 20 using HTTP, and is made available to the programmed routines executing on server computer 20 through the CGI. Use of servlets (i.e. routines, typically written in the Java programming language, that run on a web server) or EJB services also permit users to interact with DMS system 17 through a web browser.

While the present invention is described in the context of web browsers running on personal computers to access the DMS system, other devices and software may be used. In general, any software capable of communications with the DMS system, and of displaying web pages may be used to access the DMS system. Additionally, as used herein, the term "web browser" includes previously known browsing software, as well as "applets", such as Java applets, that may be downloaded from the DMS system, and temporarily executed within the context of the web browser.

Database 25, which may be a relational or object database, stores: data concerning documents controlled by server computer 20 and stored in store 30 (hereinafter, referred to as "meta-data" ) , such as annotations, instructions, characteristics, etc.; user and account data; transaction data; notification data; and authorization data. Database 25 may be implemented on server computer 20 or on a separate computer connected to server computer 20.

Store 30 is connected to server computer 20 and stores electronic documents (or "files") . Store 30 provides a storage mechanism for storing electronic documents, and may comprise one or more hard drives, optical drives, RAIDS, etc., and further may comprise one or more stores supporting different types of storage media. Store 30 also may comprise remote storage, in which the file is stored on a remote DMS server. If multiple stores are used, DMS system 17 preferably includes a configurable algorithm to decide in which store a document will be placed, thereby evenly distributing document storage among all stores . Store 30 preferably comprises either a relational database, where the electronic documents and information about the document is stored in the relational database, or a file system. If store 30 comprises a relational database, a unique key to the document is generated and indexed, as may be appropriate for storage of smaller files (e.g., < 1KB). If store 30 comprises a relational database, then entries in the relational database may include a storage type, a storage path (i.e., a description of location), a name, a maximum size and a state value. When store 30 comprises more than one store, the state value for each store may be set to "active" or "inactive" and documents cannot be stored in an

"inactive" store. If store 30 comprises file system storage, the file system may assign a unique name to each document and the document is stored directly on the hard drive, optical drive, etc., as may be appropriate for large files.

Notification server 35, which may comprise software running on server computer 20 or on one or more separate computers connected to server computer 20, dispatches notifications, e.g., via voice message, e-mail, pager, etc., to users of DMS system 17 concerning the status of documents stored in the DMS system.

Public key infrastructure server 40 ("PKI"), which also may comprise software running on server computer 20 or on one or more separate computers connected to server computer 20, handles digital certificates of users of the DMS system. PKI server 40 may issue certificates for users, track certificates, store certificates, and import or otherwise acquire certificates from other certificate authorities. Thus, digital certificates used in DMS system 17 may be issued by sources other than DMS system 17, or may be issued directly by DMS system 17. To acquire certificates from other sources, DMS system 17 may communicate with other certificate authorities, or may rely on a user to provide access to copy of his or her digital certificate. The digital certificates may be used by the users to digitally sign documents for the purpose of non-repudiation, and may be used to securely send documents between users of the DMS system, or to securely share documents among members of a team, as described hereinbelow. DMS system 17 of FIG. 1A illustratively is depicted as having a single server computer 20, but also may comprise multiple server computers for use in high load scenarios. As shown in FIG. IB, when more than one server computer is used, load balance appliance 45 may be employed to balance traffic between server computers 20A and 2OB. Load balance appliance 45 may comprise software running on the server computers 20A and 2OB. Alternatively, load balance appliance 45 may comprise software running on a separate computer (not shown) , which' is in turn connected to server computers 20A and 2OB.

Secure Document Management

In any networked environment it is important to address security issues. These issues are particularly important in a networked environment in which important confidential business documents are transferred, stored, and shared across a wide area network, such as the Internet. No single entity controls all of the communication links through which important documents may be sent. Additionally, many businesses may be hesitant to trust their secret documents to an Internet document management service, such as DMS system 17, that they do not control, and that transfers documents over insecure communication channels.

Securely sending documents and other information across insecure communication channels has been addressed in the past through use of cryptographic techniques. For example, Secure Sockets Layer (SSL) provides a standard way of providing secure communications channels. For a document management system, however, merely securing the communication channels is not enough. Documents that are managed by the document management system must be securely "packaged" , so that they cannot be viewed by unauthorized parties at either end of the communication channel.

In accordance with the principles of the present invention, secure packaging or digital envelope techniques that have been used for secure e-mail and other secure transfers of electronic documents may be modified and adapted for use in other aspects of an Internet document management service, such as DMS system 17. By applying the methods of the present invention, documents may be securely transferred, shared, and stored on an Internet document management service, without permitting unintended entities, including the provider of the document management service, to view the documents. Additionally, the methods of the present invention obviate the need to take cumbersome steps such as downloading a securely packaged document from the document management service, unpackaging it (i.e. decrypting the document), repackaging it (i.e. re-encrypting the document) for a new recipient or team member, and uploading the repackaged document to the document management service, when a document is transferred or shared. In a preferred embodiment of the present invention, this is achieved in a manner consistent with established encryption standards and infrastructure, such as S/MIME and X.509.

The methods of the present invention include numerous steps that should be performed on a user's computer, such as personal computers 10 and 11 of FIG. 1. In a preferred embodiment, this may be achieved by sending mobile code (such as applets) from DMS system 17 to the user's computer, and executing the mobile code on the user's computer. The mobile code that is sent to the user's computer may comprise Java applets, or may be coded in any other form that may be executed or interpreted by the user's computer. The mobile code may be executed on the user's computer in the context of a web browser, as standalone applications, or in the context of any other application that may execute on the user's computer.

Preferably the mobile code is sent to the user's computer when the user registers with DMS system 17, and may be updated by DMS system 17 as necessary. The mobile code is preferably sent to the user's computer over secure channels, and is preferably digitally signed by DMS system 17, so that the user may be assured of the mobile code's authenticity.

The methods of the present invention make use of numerous preexisting encryption technologies and standards, including S/MIME, which is detailed hereinabove, and digital certificates. Users of an Internet document management service built in accordance with the present invention may either import a digital certificate, or may request that the document management system issue them a digital certificate. Private keys are not provided to the system for security reasons. The portion of the system of the present invention that executes on the user's computer, ■ however, may be provided with information on where to obtain a user's private keys (e.g. from a file, from a smartcard, etc.). Referring now to FIG. 2, an overview of the method of the present invention is described. At step 101, a user prepares a document that is to be managed (i.e. stored, shared, transferred, etc.) by DMS system 17. This step is preferably performed on the user's computer, using whatever application software the user prefers to use for document preparation.

In step 102, the user generates a document key pair, comprising a document public key, and a document private key. The document key pair will be used, either by a public-key algorithm or a hybrid algorithm, to encrypt the document. Specifically, the document key pair will be a special "recipient" of the document on the document management system. The document key pair is not used to digitally sign or otherwise authenticate the document.

The document key pair may be generated using . a standard key generation algorithm corresponding to the public-key encryption algorithm used by the system. The length of the key to be generated will depend on the desired encryption strength. For documents having little value or need for security, a relatively weak key (e.g. a 40 bit key) may suffice to provide a degree of privacy, or to comply with applicable export restrictions on encryption. For valuable documents whose value may depend on their secrecy, a longer key should be used. Generally, keys should be made as strong as they need to be to protect the document to an appropriate degree for the time that the document needs to be protected.

In a preferred embodiment, the document key pair is generated by mobile code, that is sent to the user's computer by DMS system 17, and that executes on the user's computer, so that DMS system 17 does not have access to the document key pair. It should also be noted that when a document key pair is created, the originator of the document keeps a copy of the document key pair encrypted for himself. The originator's copy of the document key pair is preferably packaged for the originator and uploaded to the document management system, as described hereinbelow, but may alternatively be stored locally on the originator's computer. At step 103, the document public key is packaged as a digital certificate, digitally signed by the originator of the document . The structure of the digital certificate preferably conforms to the X.509 standard, and will be described in greater detail hereinbelow. In a preferred embodiment, this step is performed by mobile code executing on the user's computer .

Packaging the document public key as a certificate is not required, but is preferred, because it puts the document public key in a standard format. This standard format is recognized by a variety of existing software, which may be able to properly handle document public keys packaged as certificates.

At step 104, the document private key is packaged in a format preferably conforming to the

PKCS#8 standard for private key information syntax. The private key may be encrypted using the private key of the originator of the key, encrypted using a password or other symmetric encryption, or may be encoded using any standard encoding to protect the document private key. This step is preferably carried out by mobile code executing on the user's computer, so that DMS system 17 does not have access to the document private key. As with the document public key, packaging the document private key in a standard format, such as PKCS#8 is preferred, but not required. The certificate containing the document public key, and the package containing the document private key are then packaged together in a encrypted key block in step 105. The encrypted key block is preferably S/MIME encoded for each "recipient" of the document using the recipient's public key. Alternatively, other encoding or encryption methods could be used to encode the encrypted key block. Preferably, the encoding method used for encrypting the encrypted key block also adds a digital signature to the encrypted code block. This encoding is preferably performed by mobile code executing on the user's computer.

The "recipient" will vary according to the document management service being performed. For a delivery, the "recipient" will be the person to whom the document is to be delivered. For storing a document so that it may be retrieved later, the "recipient" of the document will be the same as the originator of the document . For sharing with a team, the recipients are the members of the team, or a special team public key that can be accessed by all members of the team.

Public keys for the recipients may typically be obtained by requesting a certificate for each of the recipients from a certificate authority, or from DMS system 17, through PKI server 40. If no certificate can be found for a recipient, the user has several options. For documents for which security is critical, the user may be unable to send the document to the recipient if a trusted certificate cannot be found. As another option, the user may request that the system send the intended recipients for whom no certificate can be found a message instructing them to acquire a certificate. A third option is to use a symmetric encryption scheme based on a password known to both the user and the intended recipient to encrypt the document and send it to the intended recipient . In another option, the user may opt to create a public key pair for use in sending the document to the recipient . This temporary, one-time public key pair, including a temporary, one-time certificate, may be encrypted using a prearranged symmetric key, and may be sent to the intended recipient. Finally, if no security is needed, the sender may optionally digitally sign the document, and send it without encrypting it .

At step 106, the certificate generated at step 103 from the document public key is used to S/MIME encode (i.e. encrypt and/or digitally sign) the document. S/MIME encoding, or "packaging" the document may comprise encrypting and digitally signing the document, encrypting the document, digitally signing the document, or (if no security or authentication is needed) leaving the document unencrypted and unsigned. Note that when the document is digitally signed, the private key of the user is used for the signature . The document private key should generally not be used to sign the document, since the document private key does not provide any degree of authentication. The S/MIME encoding of the document is preferably performed by , mobile code executing on the user's computer, so that DMS system 17 is not given access to the unencrypted version of the document .

At step 107, the user uploads the S/MIME encoded document to DMS system, which preferably logs the transaction. The document is then stored in store 30, and information about the document is stored in database 25.

At step 108, the encrypted key block containing the document key pair is uploaded to the document management service for each recipient of the document for which the encrypted key block has been S/MIME encoded in step 105. The document management service may then notify the recipients of the availability of the document. Additionally, the encrypted key block may optionally be directly sent to each recipient of the document for which the encrypted key block has been S/MIME encoded in step 105. The recipients typically may view the document by downloading the S/MIME encoded document, using their personal private key to decrypt the encrypted key block, and then using the document private key to decrypt, or "unpack" the S/MIME encoded document.

Encrypted key blocks for the recipients are preferably stored on the document management service in database 25 or store 30, where they may be referenced using a document identifier unique to each document, and a recipient identifier, unique to each recipient.

In an alternative preferred embodiment, the document may be S/MIME encoded with the public keys (found in certificates) of each of the recipients, as well as with the document public key, and may be uploaded to the document management service and sent to each of the original recipients through the document management service. This permits recipients who have software for handling S/MIME messages to handle the documents when they are offline, or otherwise not connected to the document management service . Additionally, by maintaining a degree of compatibility, software for handling S/MIME messages may be used to handle documents without requiring use of any custom software or mobile code, while maintaining many of the benefits of the methods of the present invention, such as the ease of document forwarding and sharing described hereinbelow. The process for forwarding or transferring a document to a new recipient is shown in FIG. 3. At step 201, the original recipient obtains a copy of the encrypted key block containing the document key pair from the document management service. In a preferred embodiment, this may be accomplished by requesting the encrypted key block from database 25 or store 30 using the document identifier and the recipient identifier for the original recipient.

At step 202, the original recipient uses his or her private key to unpack the S/MIME encoded encrypted key block containing the document key pair. This is preferably done by mobile code executing on the original recipient's computer, so the document management service never has access to the decrypted document key pair.

At step 203, the document key pair is S/MIME encoded, or "repackaged", using the certificate for a new recipient. This new encrypted key block is uploaded to the document management service and optionally sent to the new recipient through the document management service at step 204. The new encrypted key block is preferably stored by the document management service in database 25 or store 30 so it may be referenced by the document identifier, and by an identifier for the new recipient. The new recipient can use his or her private key to decrypt the document key pair, which may be used to decrypt the document .

It should be noted that when the document key pair is repackaged, the history of the key pair may be lost, since the repackaging will typically remove any digital signature of the sender that was part of the original package. If the user desires that a history of the transfer of a document be kept, then the original packaged document key pair, with a digital signature of the sender, may be kept as part of the new document key pair. The unencrypted document key pair may be added to the original packaged document key pair with the digital signature of the sender, and this entire block may be repackaged with the public key of the new recipient. Using such a technique, it is possible to trace back through the digital signatures to determine the chain of senders of a document key pair. Alternatively, a history may be kept by logging the transactions on the document management service.

Since the new "recipient" in the above-described method can be a group or the original recipient, this same method may be used to move a received document into storage, or to move a document into a team. Thus, numerous services, including transferring, storing, and sharing access to a document are supported by the above-described methods.

Advantageously, the above-described methods permit documents to be stored, shared, and transferred through a document management system without having to continuously re-encrypt documents when additional recipients are added, or when users are added to the group that may access a document. Because each document is encoded using a document key pair, all that is needed to add a recipient is to encrypt the document key pair for that recipient . It is not necessary to download and decrypt the entire document and re-encrypt the entire document using the public key of the new recipient, as was necessary in previously known systems. For large documents, this can represent a large savings of time and communications bandwidth because the documents are stored by the document management service, and only the relatively small key blocks need to be downloaded and repackaged. Additionally, since the entire process of generating the document key pair, encoding the document key pair, and encoding the document is handled by the user's computer, rather than by the document management service, the document management service is never given access to an unencrypted version of the document or the document key pair. Thus, the user need not place much trust in the document management service, since the document management service is incapable of viewing the documents that it stores. In accordance with the principles of the present invention, these advantages result from adding an additional level of key management to standard encryption methods. Rather than simply S/MIME encoding the document with the recipient's public key, as seen in FIG. 4A, document 60 is S/MIME encoded using document public key 62a of document key pair 62, which is generated for document 60. Document key pair 62, including document public key 62a and document private key 62b is then S/MIME encoded using recipient public key 64. Access to document 60 may be granted simply be granting access to document key pair 62, without requiring that document 60 be downloaded, decrypted, re-encrypted, and resent.

Additional levels of key management also may be used in accordance with the present invention. As shown in FIG. 4B, a team key level may be added. Document 60 is S/MIME encoded using document public key 62a, as before. Document key pair 62 is S/MIME encoded using team public key 70a of team key pair 70. Team key pair 70 is generated when a team is created by the originator or leader of the team, and comprises team public key 70a and team private key 70b. Team key pair 70 may then be S/MIME encoded using public keys 72 for each member of the team.

To unpack the document, a team member uses his or her private key to decrypt team key pair 70. Team private key 70b is then used to decrypt document key pair 62, so that document private key 62b may be used to decrypt document 60.

By adding this additional level to key management, documents may be shared with entire teams without having to repackage the document for each team member. Each team member will have a copy of team key pair 70, which will give them access to any documents with document key pairs that are encoded for the team. For compatibility, as described above with reference to document key pairs, it may be desirable to package the document key pairs using the certificates of all of the team members, rather than just with the team key pair. Additionally, to maintain compatibility with other software and standards, it may be desirable to package the documents themselves using the certificates of the team members, as well as with the document key pair. FIG. 5 shows a method in accordance with the methods of the present invention for adding a new member to a team. At step 301, the team originator downloads his or her copy of the team key pair from the document management service . In a preferred embodiment, encrypted team key pairs may be stored in store 30 or database 25, and may be accessed using a team identifier and a team member identifier.

At step 302, the team originator unpacks his or her copy of the team key pair using his or her private key. This step is preferably performed on the team originator's computer, so that the document management system never has access to a decrypted team key pair.

At step 303, the team originator repackages the team key pair by S/MIME encoding the team key pair using the public key of the new team member. Additionally, the team originator digitally signs the team key pair with his or her private key, for authentication. The encoded team key pair is then uploaded to the document management system and sent via the document management system to the new team member at step 304. The repackaged team key pair is preferably stored in database 25 or store 30 of the document management service, where in is accessible using the team identifier and a team member identifier for the new team member.

Once the new team member has access to the team key pair, he or she may access any documents having a document key pair that is encoded using the team key pair. Advantageously, this permits documents to be securely shared with other team members without requiring that the documents be re-encrypted for each team member.

It will be evident to one skilled in the art that the procedure for adding a team member described with reference to FIG. 5 is essentially identical to the method of forwarding a message described with reference to FIG. 3. Similarly, the method for generating team keys and packing document key pairs using team keys, and for sending team keys to team members is essentially identical to the method described with reference to FIG. 2 for generating document keys and packing documents.

It is expected that additional levels of key management could be advantageously used by reapplying the same methods to add and manage the additional levels. For example, team keys could be packaged with additional levels of key pairs, permitting teams within teams, or teams within larger access groups, or other nested structures of keys. In this manner, for example, documents could be made available to teams in a particular division of an organization, or to divisions in a particular region.

It will further be evident to one skilled in the relevant arts that a document may comprise numerous files that are all to be stored together, sent to the same recipient, shared by the same team, etc. Thus a document may comprise any collection of files or other data that are all packaged together. If there are multiple files to be managed, they may each be packaged separately, or they may be combined and packaged together, if they will be managed (i.e. stored, transferred, shared) together.

It will also be understood that although the description of the methods of the present invention refers to S/MIME and to other known encryption and certificate standards, such as X.509, PKCS#6 and PKCS#8, there is no requirement that these standards be used. Any similar encryption and packaging methods may be used in accordance with the present invention with minimal modification. Use of standards is preferred, however, because it may permit currently existing software and public key infrastructure to be used with a system that implements the methods of the present invention. As described above, for example, standard certificate formats may be used for packaging a document public key (or team public key, etc) . FIG. 6 shows the parts of a standard certificate used for packaging a document public key in a preferred embodiment of the present invention.

Digital certificate 80 includes serial number field 82, which contains a unique serial number for the certificate. In addition to serial number field 82, certificate 80 may be uniquely identified through use of distinguished name field 84.

Distinguished name field 84 contains a globally unique identifier, or distinguished name, for the certificate. The distinguished name may be a large random number or a combination of a random number with other information identifying the certificate. In a preferred embodiment of the present invention, distinguished name field 84 in a certificate for a document public key contains a distinguished name comprising a random number combined with the name of the document, and an optional reference to the certificate of the originator of the document, an optional reference to the server or service that created the originator's certificate, and any other descriptors and identifying information.

Duration field 86 gives the period of time during which certificate 80 is valid. This may comprise a fixed expiration time, or some arbitrarily long period specified by the user. In a preferred embodiment of the present invention, duration field 86 is set according to terms of the document management service. For example, a user of a basic plan may be able to create certificates for document public keys . that have a duration of three days, while a user of a premium plan may create certificates that last for ten years. An alternative preferred embodiment uses a duration related to the reasonable survival time of a document, and may be set on a document by document (or team by team, etc.) basis.

Issuer field 88 contains the distinguished name of the issuer of the certificate. For a certificate containing a document public key, issuer field 88 contains the distinguished name of the public key certificate of the document originator or sender.

For a team public key, issuer field 88 contains the distinguished name of a certificate for the team originator. Public key field 90 contains the public key that is packaged in certificate 80. If certificate 80 is for a document, public key field 90 contains the document public key. If certificate 80 is for a team, public key field 90 contains the team public key.

Signed public key field 92 contains a copy of the public key packaged in certificate 80 that has been digitally signed by the issuer of the certificate. For a document public key the key will be signed by the document originator or sender. For a team public key, the key will be signed by the team originator.

Date field 94 contains the date of issue of the certificate, and may contain the time at which the certificate was issued. Typically, this will be the date and time at which the document or team public key was created and packaged as a digital certificate.

Policy field 96 is an optional field that may contain information relating to the use, rights, or attributes of the certificate. Certificate practice field 98 also is an optional field, that contains a reference (typically as a URL) to a certificate practice statement .

In addition to the above-described fields, it will be evident to one skilled in the art that other fields, such as fields required by X.509 or other standards, may be added to certificate 80 without departing from the invention. Although the present invention does not require use of a certificate having all of the fields described above, these fields may be necessary to conform with established standards, and should be included to derive the benefits of using established standards such as X.509 or PKCS. Although preferred illustrative embodiments of the invention are described above, it will be obvious to one skilled in the art that various changes and modifications may be made therein without departing from the invention. For example, although the methods of the present invention are described as part of an Internet-accessible document management service, the methods may be advantageously applied with minimal modification to many applications that require transferring or sharing information. It is intended that the appended claims cover all such changes and modifications that fall within the true spirit and scope of the invention.

Claims

What Is Claimed Is:

1. A method of securely managing an electronic document comprising: generating a document key pair for the electronic document, the document key pair comprising a document public key and a document private key; packaging the document using the document public key to produce a packaged document; determining a recipient for the document ; encrypting the document key pair using a recipient public key associated with the recipient to produce an encrypted key block; providing the recipient with access to the packaged document and to the encrypted key block;

2. The method of claim 1, wherein packaging the document using the document public key comprises S/MIME encoding the document using the document public key.

3. The method of claim 1, wherein packaging the document using the document public key comprises encrypting the document using the document public key.

4. The method of claim 3, wherein encrypting the document using the document public key comprises using a hybrid encryption algorithm to encrypt the document .

5. The method of claim 1, wherein packaging the document using the document public key comprises digitally signing the document.

6. The method of claim 1, wherein providing the recipient with access to the packaged document and to the encrypted key pair comprises storing the packaged document in a document management system and storing the encrypted key pair in a database .

7. The method of claim 6 , wherein storing the_. encrypted key pair in a database further comprises: providing a document identifier; providing a recipient identifier; and storing the encrypted key pair so it is referenced by the document identifier and the recipient identifier.

8. The method of claim 7, wherein providing a document identifier comprises providing a unique document identifier.

9. The method of claim 7, wherein providing a recipient identifier comprises providing a unique recipient identifier.

10. The method of claim 1, wherein the recipient is an originator of the electronic document, and wherein the method further comprises storing the electronic document in a document management system.

11. The method of claim 1 further comprising forwarding or transferring the electronic document from the recipient to a new recipient.

12. The method of claim 11, wherein forwarding the electronic document further comprises: decrypting the encrypted key block using a private key associated with the recipient to produce the document key pair; encrypting the document key pair using a public key associated with the new recipient to produce a new encrypted key block; and providing the new recipient with access to the new encrypted key block and the packaged document .

13. The method of claim 1, wherein the recipient is a team, the method further comprising: generating a team key pair for the team, the team key pair comprising a team public key and a team private key; for each member of the team, encrypting the team key pair for that member of the team using a public key associated with that member of the team to produce an individual encrypted copy of the team key pair for that member of the team; and for each member of the team, providing access to the individual encrypted copy of the team key pair for that member of the team; wherein encrypting the document key pair comprises encrypting the document key pair using the team public key.

14. The method of claim 13, wherein encrypting the team key pair further comprises digitally signing the team key pair.

15. The method of claim 13, further comprising adding a new member to the team.

16. The method of claim 15, wherein adding a new member to the team comprises : decrypting the individual encrypted copy of the team key pair for a team member to produce the team key pair; encrypting the team key pair with the public key of the new member to produce a new individual encrypted copy of the team key pair for the new member; and providing the new member with access to the new individual encrypted copy of the team key pair.

17. The method of claim 13, further comprising using additional levels of key management.

18. The method of claim 1, wherein generating a document key pair further comprises packaging the document public key as a certificate.

19. The method of claim 18, wherein the certificate conforms to a standard format.

20. The method of claim 19, wherein the standard format comprises X.509.

21. The method of claim 18, wherein packaging the document public key as a certificate further comprises providing a unique distinguished name for the certificate.

22. A server that provides secure document management services across a network, the server comprising a memory containing one or more downloadable routines, each of the one or more downloadable routines causing a remote computer to perform a function when downloaded to the remote computer and executed on the remote computer, the one or more downloadable routines comprising: a document key generation routine that causes the remote computer to generate a document key pair for an electronic document, the document key pair comprising a document public key and a document private key; a document packaging routine that causes the remote computer to package the electronic document using the document public key to produce a packaged document ; a key encryption routine that causes the remote computer to encrypt the document key pair using a recipient public key associated with a recipient, producing an encrypted key block; and an upload routine that causes the remote computer to upload the encrypted document and the encrypted key block to the server.

23. The server of claim 21, wherein the one or more downloadable routines further comprise a certificate routine that causes the remote computer to retrieve a recipient certificate from a document management service or from a certificate authority.

24. The server of claim 22, wherein the document packaging routine comprises a document encryption routine, that encrypts the document using the document public key.

25. The server of claim 24, wherein the document encryption routine comprises a hybrid encryption algorithm.

26. The server of claim 22, wherein the document packaging routine comprises a document digital signature routine, that digitally signs the document.

27. The server of claim 22, wherein the memory further comprises a programmed routine that causes the server to store the packaged document and the encrypted key block, and to provide the recipient with access to the packaged document and the encrypted key block.

28. The server of claim 22, wherein the one or more downloadable routines comprise applets that execute on the remote computer within a web browser.

29. The server of claim 22, wherein the one or more downloadable routines further comprise a forwarding routine that permits the recipient to forward the electronic document to a new recipient by causing the remote computer to: download the encrypted key block from the server; decrypt the encrypted key block using a private key associated with the recipient to produce the document key pair; encrypt the document key pair using a public key associated with the new recipient to produce a new encrypted key block; and upload the new encrypted key block to the server .

30. The server of claim 22, wherein the recipient is a team, and the one or more downloadable routines further comprise a team routine that shares the electronic document with members of the team by causing the remote computer to: generate a team key pair for the team, the team key pair comprising a team public key and a team private key; encrypt the team key pair for each member of the team using a public key associated with that member of the team to produce an individual encrypted copy of the team key pair for that member of the team; and upload the individual encrypted copy of the team key pair for each member of the team to the server; wherein the key encryption routine causes the remote computer to encrypt the document key pair using the team public key.

31. The server of claim 30, wherein the team routine further causes the remote computer to digitally sign the team key pair.

32. The server of claim 30, wherein the one or more downloadable routines further comprise a nested key management routine that causes the remote computer to use additional levels of key management.

33. The server of claim 30, wherein the one or more downloadable routines further comprise a new member routine that adds a new member to a team by causing the remote computer to: download the individual encrypted copy of the team key pair for a team originator from the server; decrypt the individual encrypted copy of the team key pair using the private key of the team originator to produce the team key pair; encrypt the team key pair using the public key of the new member to produce a new individual encrypted copy of the team key pair for the new member; and upload the new individual encrypted copy of the team key pair to the server.

34. The server of claim 33, wherein the new member routine further causes the remote computer to digitally sign the new individual encrypted copy of the team key pair.

35. A computer that provides secure document management services, the computer comprising a memory containing one or more routines, the one or more routines comprising: a document key generation routine that causes the computer to generate a document key pair for an electronic document, the document key pair comprising a document public key and a document private key; a document packaging routine that causes the computer to package the electronic document using the document public key to produce a packaged document; a key encryption routine that causes the computer to encrypt the document key pair using a recipient public key associated with a recipient, producing an encrypted key block; and an upload routine that causes the computer to upload the packaged document and the encrypted key block to a document management system.

36. The computer of claim 35, wherein the one or more routines comprise mobile code that are downloaded to the computer by the document management system.

37. The computer of claim 35, wherein the document packaging routine comprises a document encryption routine that encrypts the electronic document using the document public key.

38. The computer of claim 37, wherein the document encryption routine comprises a hybrid encryption algorithm.

39. The computer of claim 35, wherein the document packaging routine comprises a document digital signature routine that digitally signs the electronic document .

40. The computer of claim 35, wherein the one or more routines further comprise a forwarding routine that permits the recipient to forward the electronic document to a new recipient by causing the computer to: download the encrypted key block from the document management system; decrypt the encrypted key block using a private key associated with the recipient to produce the document key pair; encrypt the document key pair using a public key associated with the new recipient to produce a new encrypted key block; and upload the new encrypted key block to the document management system.

41. The computer of claim 35, wherein the recipient is a team, and the one or more routines further comprise a team routine that shares the electronic document with members of the team by causing the computer to: generate a team key pair for the team, the team key pair comprising a team public key and a team private key; encrypt the team key pair for each member of the team using a public key associated with that member of the team to produce an individual encrypted copy of the team key pair for that member of the team; and upload the individual encrypted copy of the team key pair for each member of the team to the document management system; wherein the key encryption routine causes the computer to encrypt the document key pair using the team public key.

42. The computer of claim 41, wherein the team routine further causes the computer to digitally sign the team key pair.

43. The computer of claim 41, wherein the one or more routines further comprise a new member routine that adds a new member to a team by causing the computer to: download the individual encrypted copy of the team key pair for a team originator from the document management system; decrypt the individual encrypted copy of the team key pair using the private key of the team originator to produce the team key pair; encrypt the team key pair using the public key of the new member to produce a new individual encrypted copy of the team key pair for the new member; and upload the new individual encrypted copy of the team key pair to the document management system.

44. The computer of claim 43, wherein the new member routine further causes the computer to digitally sign the new individual encrypted copy of the team key pair.