CA2357016A1

CA2357016A1 - Web-based delivery of secure e-mail messages

Info

Publication number: CA2357016A1
Application number: CA002357016A
Authority: CA
Inventors: Dmitry Dolinsky; Jean-Christophe Bandini
Original assignee: Individual
Current assignee: Tumbleweed Communications Corp
Priority date: 1999-01-14
Filing date: 2000-01-14
Publication date: 2000-07-20
Also published as: JP2002535884A; NO20013481D0; WO2000042748A1; AU2728100A; NO20013481L; EP1145507A1

Abstract

An electronic document delivery system that enables exchange of digitally signed and public key encrypted packages without requiring pre-installed specialized public key security software applications on recipient's computer.
A URL identifying such a package is sent to the recipient by e-mail. Upon submission of the URL through the World Wide Web, computer instructions in the form of an applet, for example, are sent to the recipient to effect retrieval and processing of the package. Such processing can include decrypting one or more parts of the package and verification of a signature of the package.

Description

WO 00!42748 PCT/US00101011 SPECIFICATION
FIELD OF THE INVE ,~T'I N
The invention relates generally to the secure delivery of data f les through a computer network and, in particular, to delivery of data files which are cryptographically encrypted andlor signed in such a manner that the data files can be decrypted and the signatures can be verified.
BACKGROUND OF THE INVE TI N
As electronic mail (e-mail} has become a widely available and widely used form of communication, security of such e-mail communication has become an important issue. An important development in secure e;-mail communication is the S/MIME (Secure Multipurpose Internet Mail Extension) protocol. S/MIME is a security protocol designed by RSA Data Security, Inc. and other software companies in 1995 to provide message integrity, authentication, non-repudiation and privacy to electronic message exchange through the use of digital signatures and encryption.
SlMIME relies on MIME (Multipurpose Internet Mail Extensions) for specifying content and structure of S/MIME messages .and PKCS (Public-Key Cryptography Standards) fox cryptographic functionaliity. Certificates conforming to the known ITU-T X.509 standard, i.e., X.509 certificates, are used to identify communicating parties.
Currently, there are three versions of S/MIME standard. The most popular is version 2. Version 3 of SIN11ME became a standard in July 1999 and introduces a number of enhancements to S/MIME. S/1VIIME version 3 also introduces a new Cryptographic Message Syntax that is an extension and! replacement of PKCS #7 v1.5 used in S/MIME version 2.
More information regarding S/MIME and RSA Data Security, Inc. can be found on the RSA Data Security, Inc. web site (http:/lwww.r;;a.com). The current status of S/MIME standardization and other S/MIME related documents can be found on IMC
{Internet Mail Consortium) web site (http:///www.imc.~org) and IETF S/MIME
Working group web sites (http://www.imc.org/ietf smime/, http://www.ietf.org/
html.charters/smime-charter.html).
The S/NJZME version 2 standard is published in two RFC documents:
S/MIME Version 2 Message Specif cation (RFC 23 I 1 ) S/MIME Version 2 Certificate Handling {RFC 2312) SIMIME Version 3 is currently specified in the following collection of the Internet Draft documents:
Cryptographic Message Syntax (draft-ietf smime-cms) S/MIME Version 3 Message Specification (draft-ietf smime-msg) ~ S/MIME Version 3 Certif cate Handling (draft-ietf smime-cert) ~ Certificate Request Syntax {draft-ietf smiime-crs) ~ Enhanced Security Services for S/MIMF; (draft-ietf ietf ess) ~ Signing Certif Gate Attribute Specification (draft-ietf smime-sigattr) ~ Certificate Distribution Specification (draft-ietf smime-certdist) Diffie-Hellman Key Agreement Method (draft-ietf smime-x942) ~ Domain Security Services using S/MIMI(draft-ietf smime-domsec) These documents are available from the web sites listed above or from many other web sites such as the web site for RFC Editor (htip://www.rfc-editor.org).
The current practice of exchanging S/MIME measages calls for preparing an S/MIME file according to the SIMIME specifications and sending the SIMIME file as an attachment to an e-mail message. When the message reaches the recipient, it is expected that the recipient has an S/MIME-capable e-mail reader to process the message. Alternatively, the recipient can use a stand alone SIMIME processing helper application to process the message.
There are many obstacles to successful exchange of the S/MIME messages using the scheme described above. First, the recipient may simply lack SIMIME
capability such that the S/MIME message is unusable and is simply stored in the recipient's computer without further handling. There a~.re many circumstances that may lead to this situation. The recipient's e-mail reading program of choice may be a simple e-mail reader or an early version without the ab~iiity to properly authenticate and decrypt messages in S/MIME format. Alternatively, the e-mail reader of the recipient can rely on plug-ins or helper programs that are not in;>talled on the recipient computer.
In any case, a message in S/MIME format is just unreadable to the recipient and the recipient would probably not understand why this partiicular email message is unreadable without additional communication with the; sender.
S/1VBME messaging generally requires that both the sender and recipient are aware of infrastructure required for public key cryptography, i.e., public key infrastructure (PKIj. Such infrastructure includes publiic/private key pairs required for encryption, decryption, and signing and certificates required for authentication. The recipient may be unaware of such public key infrastructure in general and S/MIME in particular. However, to receive encrypted secure e-maul, the recipient must have a digital certif cate which includes the pubic key of the recipient. If the recipient has a certificate, some familiarity with public key infrastructure by the recipient can be assumed. However, in case of signed message no publlic or private key of the recipient is required and, accordingly, no such assumption can be made with respect to the recipient's familiarity with public key infrastructure.
A second obstacle to successful delivery and processing of a message in the S/MIME format is inter-version incompatibility. Even if the recipient's e-mail reader does have some level of S/MIME capability, S/MIME processing may fail due to a difference in S/MIME implementation by different vendors. S/MIME is an evolving standard; there are three different versions in use currently. If the sender uses an S/MIME program implementing a later version than the one implemented by the recipient's e-mail program, the recipient's e-mail reader could be unable to properly decrypt the message and verify the signature. As in the case described above, the message may simply appear to be unreadable and the recipient may not be able to WO 0014274$ PCT/US00/01011 determine the course of action needed to remedy the siituation.
The ordinary solution for such problems is to have recipients upgrade or obtain their e-mail reader or helper applications to properly implement the most recent standardized version of the S/MIME protocol. Installing additional software to a computer system, even simply to upgrade an existing application, can have adverse effects on the computer system by occupying addition<~I system resources.
Accordingly, the recipient can choose not to install new S/MIME software. In addition, the appropriate S/MIME software may not bf; available for the recipient's computing environment. Even if the recipient chooses. to upgrade or obtain the S/MIME software, such installation can take considerable time and significantly delay viewing of the message by the recipient.
S/MTME e-mail messages have another shortcoming. S/MIME messages are transferred as attachments to Internet e-mail. Some-Internet e=mail gateways limit the size of the message and therefore the size of such attachments. Accordingly, the SIIVIIME message can be truncated. If the message is l;runcated, a portion of the data needed to properly decrypt the message and verify the signature is lost and the message becomes useless.
What is needed is a mechanism by which e-mail can be sent to a recipient using a standardized, wide-supported secure e-mail protocol and by which the recipient can receive the e-mail notwithstanding failure of the recipient's e-mail reader to properly implement the secure e-mail protocol.
SUMMARY OF THE INVE1~1TION
In accordance with the present invention, messages which comport with a secure e-mail standard, such as S/MIME, are delivered through a document delivery protocol such as the HTTP protocol of the World Wide Web rather than a conventional e-mail protocol such as SMTP/POP. Web-based secure e-mail delivery increases the likelihood of successful delivery by removing the burden of obtaining and maintaining secure e-mail processing software from the recipient and by having the recipient download the secure message from a Web server instead of receiving it as Internet mail attachment.

WO 00/42748 PCTlUS00/01011 The secure e-mail delivery system uses a notification message sent to the recipient by regular e-mail and a web server for delivery of the secure message through the World Wide Web according to HTTP. As a result, secure e-mail can be sent to virtually any recipient with an e-mail account, regardless of the capabilities of the recipient's computer system beyond a commonly available web browser and e-mail reader.
The secure e-mail delivery system exploits the ai'~ility of commonly available web browsers to automatically install and run software from a web server.
Particularly useful is ability of such a browser to invoke JavaTM applets located on the server such that the software can be brought to the widest range of computing environments. Some web browsers currently have the ability to automatically download and install other types of software including plug-in applications and known ActiveX controls. In particular, the recipient responds to the notification message by submitting a URL through the World _ . . . _ _ _ _ . . _ Wide Web to a web server which controls access to theaecure e-mail message. In. .
response, the web server sends, in addition to the secure e-mail message itself, software which processes the secure message to thereby render the message readable to the recipient. Such processing includes, for example, decrypting the message and one or more attached data f les and verifying a signature of the securE; e-mail message.
There are two main components to the secure e-mail delivery system. The first component is the web server that accepts secure messages for delivery. The second component is the secure message processing software. 'lf he sender is assumed to have software capable of generating secure e-mail messages according to a secure e-mail message standard such as S/MIME, PGP/MIME, or OpenPGP. It is also assumed that the recipient has access to Internet e-mail with the ability to read short text messages -attachment capabilities are not required - and has a web browser capable of running an applet, and/or downloading and installing software, such as the secure message processing software.
To send the secure message, the sender generates a secure message and submits the secure message to the web server of the secure e-mail delivery system along with the e-maii address of the intended recipient. Such submission can happen in many different ways: for example, through a web form hosted by the we;b server, using secure e-mail authoring software which is aware of the secure e-mail delivery system and the web server, or through the use of an Internet e-mail relay which is av~rare of the secure e-mail delivery system and the web server. Specif cally, the e-mail relay can detect e-mail which comports with a secure e-mail protocol supported by the secure e-mail delivery system and redirect such e-mail to the secure e-mail delivery system and allow other e-mail to continue transit according to a conventional e-mail protocol such as SMTP.
Upon such submission, the secure e-mail delivery system generates an e-mail message to the recipient informing the recipient about the secure message and including the Uniform Resource Locator (URL) to be used to retrieve the secure message.
This URL
points to the web server of the secure e-mail delivery system and contains enough information so that web server can locate the secure message.
The recipient uses the web browser to access the URL on the web server. The web server generates the web page that instructs the web brov~rser to invoke secure e-mail processing software. The recipient's web browser cause: execution of the secure e-mail processing software which retrieves the secure message firom the web server, processes the secure message, and presents the result to the recipient. i'rocessing of the secure message can include decrypting the message and one or more attached data f les and verifying any signature of the message.
The secure e-mail delivery system according to th.e present invention enables the recipient to properly process secure messages without hawing installed secure message processing software prior to receiving the message. In adldition, since the secure message processing software is stored on the web server, the secure e-mail delivery system can ensure that the recipient has the latest available version o:f the secure message processing software.
BRIEF DESCRIPTION OF THE I)RAWINrS
Figure 1 is a block diagram which depicts a secure e-mail delivery system including a delivery server which delivers secure e-mail i:n accordance with the present invention.
Figure 2 is a block diagram showing the sender of Figure 1 in greater detail.
Figure 3 is a logic flow diagram illustrating generation of a secure e-mail message _7_ according to one secure e-mail protocol.
Figure 4 is a block diagram of the delivery server of Figure 1 in greater detail.
Figures 5 and 6 are logic flow diagrams of delivery of a secure e-mail message according to the present invention.
Figure 7 is a block diagram of the recipient of Figure 1 in greater detail.
Figure 8 is a block diagram showing the secure e-mail receiver of Figure 7 in greater detail.
Figure 9 is a logic flaw diagram of the receipt of a secure e-mail message in accordance with the present invention.
Figure 10 is a logic flow diagram of the processing of a secure e-mail message in accordance with one secure e-mail protocol.
DETAILED DES RIPTION
In accordance with the present invention, a delivery server 104 (Figure 1 ) effects delivery of an e-mail message according to a secure e-rn<~il protocol by (i) notifying a recipient 106 of the e-mail message, (ii} receiving data from the recipient identifying the message, and (iii) supplying, in response to the data, computer instructions which effect receipt and proper handling of the e-mail message according to the secure protocol.
In particular, a sender 102 uses a secure e-mail protocol to send a secure e-mail message through computer network 108, which can be the Internet for example.
The secure e-mail message is addressed to recipient 106. However, in a manner described more completely below, the secure message is routed to delivery server 104.
While delivery server 104 is shown as a single computer system in Figure 1, it is appreciated that delivery server 104 can include multiple computer systems.
Delivery server 104 assumes that recipient 106 does not have the appropriate software to properly handle the secure message according to the secure protocol.
Accordingly, delivery server 104 assumes responsibility :for proper implementation of the secure e-mail protocol within recipient 106. One such secure e-mail protocol is the S/MIME protocol, version 3. Other versions of the S/MIME protocol can also be the secure e-mail protocol. In alternative embodiments, other secure e-mail protocols such as _g_ PGP/MIME and OpenPGP can be implemented.
As described more completely below, delivery server 104 sends a notification e-mail message using ordinary techniques to recipient 106. The notification e-mail message contains sufficient identification information to identify the specific secure message addressed to recipient 106 within delivery server 104.
When recipient 106 receives and reads the notification e-mail message, recipient 106 submits the identification information to delivery server I04 to thereby request delivery of the secure message. In this embodiment, the identification information is a universal resource locator (URL) which includes data identifying the secure message and recipient 106 sends the URL to delivery server 104 using the hypertext transfer protocol (HTTP), for example, through a web browser 704 (Figure; 7) such as Netscape Navigator available from Netscape Corporation of Mountain View, California or Internet Explorer available from Microsoft Corporation of Redmond, Washington.
In response to the URL, delivery server 104 sends computer instructions which are to be executed by recipient 106 and which implement the secure e-mail protocol with which the secure message comports. As described below in greater detail, the computer instructions comport with the JavaTM computer instruction language implemented by most currently available web browsers in an illustrative embodiiment. Such web browsers, in response to receipt of such computer instructions, begin interpretation of such computer instructions, i.e., execution of the computer instructions ass they arrive. In an alternative embodiment, the computer instructions define a computer program which is installed in the computer system of recipient 106 in persistent storage such that subsequent secure e-mail messages can be pracessed without requiring a second delivery of the computer instructions. In this illustrative embodiment, delivery server 104 verifies that the program installed for recipient 106 is the most current program avaulable and re-delivers and re-installs the computer instructions if the program is not the most current.
As described more completely below, execution o~Fthe received computer instructions causes recipient 106 to retrieve the secure message from delivery server 104 and to process the retrieved secure e-mail message according to the secure e-mail protocol implemented by the received computer instructions.
Thus, recipient 106 can securely receive e-mail according to an established secure _9_ e-mail protocol without f rst separately acquiring and properly installing software specifically designed to implement the secure e-mail protocol.
Sender 102 As described above, sender 102 prepares and senda a message according to a secure e-mail protocol such as S/MIME. In addition, the .message is addressed to recipient 104. Sender 102 is shown to be a computer system. Hov~rever, it is understood that e-mail addresses generally to not specify a computer system but :instead specify a human user or, alternatively, a computer process. For simplicity, sender 102 is therefore a human user of the computer system or a computer process executing within the computer system.
Similarly, recipient 106 is a human user of the computer system shown in the figures as recipient 106 or a computer process executing within the yomputer system.
To prepare the message according to the secure e-mail protocol, sender 102 includes an e-mail authoring process 202 (Figure 2) which in turn includes a secure protocol module 204. E-mail authoring process 202 can be commercially available S/MIME-capable e-mail software, i.e., software which has the ability to produce S/MIME
message given an initial set of documents and one or more recipient e-mail addresses. An example of such software is the WorldSecure/Mail e-mail client available from Worldta.lk Corporation of Santa Clam, California {http://www.worldtalk.com). While secure protocol module 204 is shown to be an integral component of e-mail authoring process 202, it is appreciated that secure protocol module 204 can be a plug-in or a helper application which adds functionality to e-mail authoring process 202.
Logic flow diagram 300 (Figure 3) illustrates one possible example of the packaging of a message by e-mail authoring process 202 and secure protocol module 204.
Various secure e-mail protocols use various cryptographic; protocols in addition to the sign-encrypt protocol illustrated in Iogic flow diagram 30(l. For example, some secure e-mail protocols do not permit signing and/or can support such cryptographic protocols as encrypt-sign and sign-encrypt-sign. In addition, logic flovv diagram 300 is simplified for clarity and involves steps which are known and conventional such as key management, certificate look-up and retrieval, and certificate validations, for example.

WO 00/42748 PCTIUSfl0101011 In step 302, e-mail authoring process 202 (FigurE: 2) collects the information elements of the message; namely, one or more data files to include with the message and e-mail addresses of one or more recipients. In step 304 (F:igure 3), secure protocol module 204 (Figure 2) packages the one or more data files into a. multipart MIME
entity. In test step 306 (Figure 3), secure protocol module 204 determines whether the secure e-mail message is to be signed as specified by sender 102 through e-mail authoring process 202.
Sender 102 can specify whether the message is to be signed using conventional user interface techniques or, alternatively, can use logic to automatically determine whether signing the message is desired.
If the message is to be signed, processing transfers to step 308. Conversely, if the message is not to be signed, step 308 is skipped.
In step 308, secure protocol module 204 signs the multipart MIME entity to form a __, , , _ _signed.data,package.. _In_this embodiment, the signed data package conforms to the known PKCS #7 data format.
In test step 310, secure protocol module 204 determines whether the message is to be encrypted. Sender 102 can specify whether the message is to be encrypted using conventional user interface techniques or, alternatively, can use logic to automatically determine whether encrypting the message is desired.
If the message is to be encrypted, processing transfers to step 312.
Conversely, if the message is not to be signed, steps 312-314 are skipped.
In step 312, secure protocol module 204 converts the signed data package to a new multipart MIME entity.
In step 314, secure protocol module 204 encrypts the new multipart MIME entity to form an encrypted data package which, in this illustrative embodiment, conforms to the known PKCS #7 data format.
In step 316, the data package is returned as the message to be sent. The data package is the signed data package of step 308 if the data. is signed but not encrypted or is the encrypted data package of step 314 if the data is encrypted. Accordingly, the secure message can be signed and/or encrypted.

Message Submission Module 2Q~
Message submission module 206 communicates with delivery server 104 to submit the secure message for delivery. In particular, message submission module 206 directs the secure e-mail message created by e-mail authoring process 202 and secure protocol module 204 to delivery server 104. In one embodiment, message submission module 206 is a component of e-mail authoring process 202 such that a human user of sender 102 uses a single, integrated user interface to compose and send a secure message to recipient 106.
In this embodiment, message submission module 206 uses HTTP to communicate with delivery server 104 through network 108 and, in particular, uses an HTTP
"Post"
command to send the secure message. HTTP and the H'.CTP "Post" command are known and are not described further herein.
In a more simple embodiment, message submission module 206 is a web browser with the ability to upload data files by use of the HTTP "Post" command. Such would require that the message created through e-mail authoring process 202 and secure protocol module 204 be saved within sender 102 as a data file itself and separately transferred to delivery server i 04 through message submission module: 206.
In a third embodiment, sender 102 sends the message formed according to logic flow diagram 300 by ordinary SMTP (Simple Mail Transfer Protocol). In this .
embodiment, secure e-mail addressed to recipient 106 is directed by an e-mail relay to delivery server 104.
Such a relay can be implemented using the well-lcnown "sendmail" program to invoke another well-known program, namely, "procmail,," to process each incoming e-mail message according to a script. The script first checks each e-mail message for secure content and forwards the e-mail message to delivery server 104 if the e-mail message contains secure content or forwards the e-mail message to a conventional SMTP
e-mail server otherwise.
For the relay to process each e-mail message for recipient 106, all e-mail for recipient 106 is routed through the relay. Such can be accomplished in a number of ways.
First, sender 102 can specify that ail outbound e-mail is t;o be routed through the e-mail relay. In particular, sender 102 can specify such an e-mail relay as the outgoing SMTP
server since most currently available e-mail readers/composers allow a user to specify the WO 00/42748 PCT/US00/Oi011 outgoing SMTP server. Accordingly, all e-mail sent by sender 102 according to a secure e-mail protocol is delivered through a secure e-mail delivery system such as that implemented by delivery server I04. Second, the relay can be a part of a component of the routing architecture of network I08 itself. For example, a Large company, a university, or a commercial Internet service provider can install such an e-mail relay as an integral part of its e-mail routing. As a result, all e-mail directed to and/or from the large company, university, or commercial Internet service provider is processed by such an e-mail relay and the secure e-mail delivery system of delivery server 1 ~04 is available to all recipients reachable therethrough. Third, routing information can be included in the e-mail address of recipient I 06 such that sender I 02 directs e-mail messages to recipient 106 to pass through the e-mail relay.
Aeliverv Server 104 Delivery server 104 is shown in greater detail in Fiigure 4. Delivery server includes a web server 402 which in turn includes a customized filter to intercept and redirect all HTTP requests. In particular, a.il HTTP requests which are unrelated to secure messages delivered by delivery server 104 are directed to .another, conventional HTTP web server. As an alternative to redirecting all HTTP requests., web server 402 can process ordinary HTTP requests in a conventional manner and simultaneously filter requests involving URLs which refer to secure messages to be delivered in the manner described herein. Web server 402 can use standard programming techniques to select specific HTTP
requests for special processing, including CGI, NSAPI, Active Server Page, and Servlet, for example. Web server 402 is the primary interface between delivery server 104 and recipient 106 in the delivery of the secure message createf, in accordance with a secure e-rnail protocol such as that iiiustrated by Logic flow diagram 300 as described above:
Delivery server 104 also includes an e-mail server 404. E-mail server 404 sends notification messages to an intended recipient in a manner described more completely below.
Delivery server 104 includes secure message Logic 406 which governs the overall operation and interaction of the components of delivery server 104.
Once the secure message addressed to recipient I06 is received by delivery server WO 00/42'148 PCTIUS00101011 104, secure message logic 406 causes delivery of the secure message according to logic flow diagram 500 {Figure 5). In step 502, secure message logic 406 initiates delivery pro-cess with recipient 106 by generating a URL which contains key data to uniquely identify the secure message within a secure message database 408. In step 504, secure message logic 406 (Figure 4) sends a notification message includiing the URL and the key data contained therein to recipient 106 through e-mail server 404. The notification message is sent to recipient 106 using the recipient e-mail address included in the secure message and using the known SMTP protocol.
The general paradigm of delivering data by sending a URL which references the data to a recipient is described in U.S. Patent 5,970,970 i:o Smith et al. for "Electronic Document Delivery System in which Notification of Said Electronic Document is Sent to a Recipient Thereof' and that description is incorporated herein by reference.
Inclusion of data identifying,a message to be delivered is described in U.S. Patent Application SIN
08/832,784 by Jeffrey C. Smith and Sean-Christophe Bandinii for "Private, Trackable URLs for Directed Document Delivery" and that description is incorporated herein by reference.
The remainder of the delivery of the secure message is accomplished through a "pull" paradigm according to logic flow 600 (Figure 6). In particular, recipient 106 (Figure 1) receives the notification message which includes the URL and the key data contained therein. Recipient 106 submits the URL through network 108 to web server 402 (Figure 4} using, for example, a conventional web browser 704 (Figure 7) in recipient 106.
In step 602 (Figure 6), web server 402 (Figure 4) receives the URL and determines that the URL pertains to a secure message to be delivered. As described above, URLs which are not related to secure messages to be delivered 'by delivery server 104 are re-directed to another, conventional HTTP web server or, alternative, are processed by web server 402 in a conventional manner. Web server 402 notifies secure message logic 406 of receipt of the URL.
In step 604 (Figure 6), secure message logic 406 !;Figure 4) identifies the secure message identified by the key data within the URL and forms a reference to the secure message.

In step 606, secure message logic 406 retrieves a secure message receiver applet 410 and adds a reference to the secure message to the appiet. In particular, secure message logic 406 builds an HTML document which includes a ta.g to secure message receiver applet 410 and includes the reference as a parameter to be used by secure message receiver applet 410 during execution. In one embodiment, the reference to the secure message is the key data from the URL received in step 602.
In step 608, secure message logic 406 sends the HfTML document, with the embedded tag to secure message receiver applet 410, to vveb server 402 to return to recipient 106 in response to the URL. Secure message receiver applet 410 executes within recipient 106 to handle the secure message in accordance with the secure e-mail protocol in a manner described more completely below.
Recipient 106 Recipient 106 is shown in greater detail in Figure 7. Recipient 106 includes an e-mail reader 702 which is conventional and by which the notification message described above is received and read. In one embodiment, the notification e-mail includes the URL
with key data in the form of an HTML attachment as described in U.S. Patent Application S!N 09/386,643 by Jeffrey C. Smith et al. entitled "Electronic Document Delivery System in Which Notification of Said Electronic Documents is SE;nt to a Recipient Thereof ' and that description is incorporated herein by reference. In this illustrative embodiment, the notification message includes the HTML attachment which is opened by recipient 106.
Within the computer system of recipient 106, HTML data, files such as the HTML
attachment are associated with a web browser as the default application with which to open, i.e., process and display the contents of, HTML date. files. Thus, in opening the HTML attachment, an HTML browser 704 is caused to ea;ecute and display the contents of the HTML attachment. HTML browser 704 is an ordinary web browser in this illustrative embodiment.
In an alternative embodiment, the URL is included as text in the notification message. Some e-mail readers will automatically open an. HTML browser in the manner described above when recipient 106 clicks on the URL. In other case, recipient 106 copies the URL from the notification message and independently starts the HTML
browser and enters the URL. It is assumed that recipient I06 is able to use both e-mail reader ?02 and HTML browser 704 and to retrieve an HTML document using HTML browser 704 and a URL found in a text message received through e-mail reader 702.
As described above, the HTML attachment or the HTML document sent in response to the URL includes an embedded tag referring tto secure message receiver applet 410 (Figure 4) with the reference to the secure e-mail message to be delivered to recipient 106. Embedded tags are known components of HTML data files. In displaying the contents of the HTML attachment, HTML browser 704 {Figure 7) requests secure message receiver applet 410 from web server 402 (Figure 4).
In an alternative embodiment, secure message receiver applet 410 is persistently installed in the computer system of recipient 106. In this alternative embodiment, comparison is made to the version of the persistently inst~~lled secure message receiver and the one most recently made available from delivery server 104. Such can be accomplished by initiating execution of the persistently installed secure message receiver which initially requests a newest version number from web server 402 of delivery server 104.
If the newest versian number is greater than the version of the persistently installed secure message receiver, the persistently installed secure message receiver initiates re-delivery and re-installation of a new secure message receiver..
HTML browser 704 (Figure 7) includes an applet interpreter 706 which, in this illustrative embodiment, is a JavaTM interpreter which executes computer instructions according to the JavaTM computer instruction language of Sun Microsystems, Inc. Receipt and execution of the computer instructions of the modified applet form secure e-mail receiver 708. Secure e-mail receiver 708 communicates v~~ith delivery server 104 to download the secure message and subsequently processes the secure message to render the message readable to recipient 106. Accordingly, secure e-mail receiver 708 requires cryptographic capabilities to decrypt the secure message and to verify the signature of the secure message. In addition, secure e-mail receiver 708 must be able to present the substantive content of the secure message or to save the substantive content to a local disk in such a manner that the substantive content is subsequently accessible, e.g., by storage at a location known recipient 106.
In this illustrative embodiment, secure e-mail receiiver 708 is a 3avaTM
Applet that is cryptographically signed by delivery server 104 and that is transparently and dynamically downloaded via HTML browser 704 by virtue of the recipient simply accessing the URL included in the notification message. Secure e-mail receiver 708 is shown in greater detail in Figure 8.
Secure e-mail receiver 708 includes a communication module 802 which is responsible for communicating with delivery server 104. In this illustrative embodiment, communication module 802 is implemented using the known java.net.URLConnection class that supports the HTTP protocol and that enables retrieval of data from, and sending data to, a web server such as web server 402 (Figure 4). Communication module (Figure 8) retrieves the secure message from web server 402 and, after processing of the secure message as described below, reports the success oi; such processing to web server 402 in this illustrative embodiment.
Secure e-mail receiver 708 also includes a secure :protocol module 804 which is responsible for decrypting the secure message, verifying the sender's signature, and extracting data files contained in the secure message. Secure protocol module 804 also provides supporting PKI functionality including key management, decryption, and signature and certificate verification as described more completely below.
Communication module 802 moves the content of the secure message from communication module 802 to secure protocol module 804 through a pipe 806 in this illustrative embodiment. Communication module 802 streams the secure message through pipe 806 as the secure message is received such that the secure message can be processed simultaneously with receipt of the secure message. Such significantly improves performance of secure e-mail receiver 708. Pipes are known inter-module communications mechanisms and can be implemented usiing, for example, the known java.io package for classes.
Processing by secure e-mail receiver 708 is shown in logic flow diagram 900.
In step 902, secure e-mail receiver 708 initializes communication module 802. In step 904, secure e-mail receiver 708 instructs communication module 802 to retrieve the secure message from delivery server 1 d4. In step 906, secure e-mail receiver 708 forms pipe 806 between communication module 802 and secure protocol module 804 such that data received by communication module 802 are sent immediately to secure protocol module 804. If processing of the received secure message by sec;ure protocol module $04 is successful, secure e-mail receiver 708 reports such success to web server 402 (Figure 4) in step 908.
In this illustrative embodiment, secure e-mail receiver 708 also provides a user interface by which recipient 106 can save to local persistent storage, and subsequently retrieve and open, any data files contained in. and recovered from, the secure message.
Furthermore, secure e-mail receiver 708 reports any errors occurring during the processing of the secure message by secure protocol module 804 to :recipient 106.
Secure Protocol Module 804 Processing by secure protocol module 804 is shown in logic flow diagram 1000 (Figure 10). As described above with respect to logic flow diagram 300 (Figure 3), logic flow diagram 1000 (Figure 10) represents but one illustrative example of processing according to a secure e-mail protocol. In test step 1002, secure protocol module 804 determines whether the secure message is encrypted. If the secure message is not encrypted, secure protocol module 804 skips steps 1004-1006.
In step 1004, secure protocol module 804 decrypts the secure message. Step is the inverse of step 314 (Figure 3) and the result is a MIME body. In step 1006 (Figure I 0), secure protocol module 804 parses the MIME body. If the secure message is signed, the result of such parsing is the signed data produced in step 308 (Figure 3).
Conversely, if the secure message is not signed, the result of such parsing is the collection of data files collected in step 302 (Figure 3).
In test step 1008 (Figure 10), secure protocol modLule 804 determines whether the secure message is signed. If the secure message is not signed, secure protocol module 804 skips steps 1010-1012.
In step 1010, secure protocol module 804 verifies the signature of the secure message. Step 1010 is the inverse of step 308 (Figure 3). The result of the verification of step 1010 (Figure 10) is the MIME body produced in step 304 (Figure 3). In addition, secure protocol module 804 reports the results of such signature verification to recipient 106, either as a report displayed to a user or as a report communicated to a process receiving the secure message. The report indicates whether the signature is verified and, if so, the identity of the sender as indicated by the signature:. In one embodiment, the report includes the certificate of the sender.
In step 1012 (Figure 10), secure protocol module 804 parses the MIME body produced in step 1010. The result of such parsing is the collection of data files collected in step 302 (Figure 3).
Thus, the result of processing according to logic flow diagram 1000 (Figure 10) by secure protocol module 804 is the collection of data files collected in step 302 (Figure 3) either in step 1012 if the secure message is signed or in sl:ep 1006 if the secure message is not signed.
To carry out steps 1004 and 1010, secure protocol module 804 requires some level of public key infrastructure. In particular, secure protocol module 804 requires the ability to manage keys on behalf of recipient 106 and access to certificates from trusted certificate authorities.
To receive secure e-mail according to many secure e-mail protocols such as S/MIME, PGP/MIME, and OpenPGP, recipient 106 must have a private/public key pair.
Asymmetric key encryption is known but is described here briefly for completeness.
Asymmetric key encryption involves a pair of reciprocal keys; ane is kept private and the other is made public and can be widely distributed. The keys are reciprocal in that data encrypted with either key can only be decrypted with the other key.
To encrypt a data file for recipient 106, the data fiJ~e is encrypted with the public key of recipient 106. The public key of recipient 106 can be obtained from a trusted certificate authority for example. Trusted certificate authorities are known but are described briefly below for completeness. Once the data file is encrypted with the public key of recipient 106, the data file can only be decrypted using the private key of recipient 106. Since the private key of recipient 106 is held in secrecy by recipient 106, only recipient 106 can decrypt the data file. Even the entity encrypting the data file using the public key of recipient 106 cannot reverse the encryption 1:o recover the data file in a cleartext, unencrypted form.
To sign a data file, the data file - or a hash thereof - is encrypted using the private key of the signing entity. As a result, any person or process with access to the public key of the signing entity can decrypt the data file, or the hash thereof. Successful wo ooiaz~ag ~cTivsoo~oiom decryption of the data file or hash using the public key of the signing entity verifies the signature since only the signing entity has access to the I>rivate key of the signing entity.
Accordingly, the signing entity is authenticated as the source of the data file.
Public keys are frequently stored in the form of a certificate. Certificates are well known but are described briefly fax completeness. A certificate combines data identifying an entity, such as a person or computer process, with a public key of the entity. A
certificate authority signs the certificate to ensure that the certificate has not been tampered with. Thus, a certificate provides a relatively high degree of confidence in the association between the public key and the identity of the key owner.
Currently available web browsers support secure communications such as SSL
(Secure Sockets Layer) and HTTPS {HyperText Transfer Protocol Secure) which use private keys and certificates. Creation of such private keys and certificates is part of the initial configuration of such web browsers.
In this illustrative embodiment, secure protocol module 804 imports such private keys and certificates from HTML browser 704 {Figure 71. Such certificates are communicated to delivery server 104 (Figure 1) and can'be used, by sender I02 fox example, in encrypting data for recipient 106 in step 3I4 (Figure 3). In addition, secure protocol module 804 {Figure 8) uses such imported private keys to decrypt such data in step 1004 (Figure 10).
In addition to importing certificates and keys fronn HTML browser 704 (Figure 7), secure protocol module 804 provides a user interface by which recipient 106 can view and manipulate keys. For example, recipient 106 can locate and add public keys from other entities to a keyring, i.e., a data structure which includes .a number of public keys. In addition, the user interface provided by secure protocol module 804 in this illustrative embodiment allows recipient I06 to delete keys from the keyring. The user interface provided by secure protocol module 804 in this illustrative embodiment alsa allows recipient 106 to export keys to, and import keys from, a password-protected data file stored on persistent storage accessible by recipient 106.
As described briefly above, secure protocol module 804 receives certificates from a trusted certificate authority. The certificate authority provides certificates which can be used by secure protocol module 804 to verify a signature as in step i 010 (Figure I0). A

number of certificate authorities currently exist and have established a reputation for being trustworthy, i.e., for faithfully producing certificates submitted to the certif cate authority.
In one embodiment, secure protocol module 804 (Figure 8) receives an initial list of trusted certif sate authorities and allows recipient 106, by providing a user interface for example, to modify the list to include other certif sate authorities trusted by recipient 106.
It is important that the initial list of trusted certificate authorities for secure protocol module 804 is secure from tampering by attackers hoping to assume identities of other entities by manipulation of certificates. Accordingly, in tthis illustrative embodiment, secure e-mail receiver 708 is received from delivery server 104 in a signed form, i.e., as signed by delivery server I04. Therefore, tampering with the contents of secure e-mail receiver 708, including a list of trusted certificate authorities, is prevented.
In an alternative embodiment, a list of trusted certificate authorities can be retrieved from web server 402 (Figure 4) of delivery server 104 each time such a list is needed by secure protocol module 804 (Figure 8). In thin alternative embodiment, the list is not modified by recipient 106. In addition, it is ixriportant that the list of trusted certificate authorities received from web server 402 is secure from tampering by attackers hoping to assume identities of other entities by manipulation of certificates.
Accordingly, in this alternative embodiment, the list of trusted certificate authorities is received from delivery server 104 through a secure channel such as an SSL connection.
Therefore, tampering with the list of trusted certificate authorities during delivery of the list is prevented.
In addition.to access to keys and certificates, seciure protocol module 804 can secure store such keys and certificates within persistent storage of the computer system of recipient 106. In the one embodiment, the private keys are stored locally by recipient 106 using the known PKCS #12 password-based encryption and a strong symmetric encryption algorithm such as the known Triple-DES algorithm.
As described above, the secure e-mail protocol supported by delivery server 104 is the SlMIME protocol in one embodiment. Accordingly, secure protocol module 804 in this embodiment is implemented using the RSA BSAFE Crypto-J'~'' 2.0 tooikit from RSA
Data Security, Inc. This toolkit provides basic cryptographic functionality based on the known PKCS #1 standard. In addition, this toolkit includes modules which can generate and verify message digests and digital signatures as well as encrypt and decrypt data using a number of encryption algorithms. Familiarity with this toolkit and the S/MIME protocol in general are helpful in implementing this illustrative embodiment of secure protocol module 804.
In addition, the following components are known and are helpful in implementing this illustrative embodiment of secure protocol module 804:
( 1 ) t~SN.1: The ASN. l DER data format provides a universal way to represent and encode structured data. ASN. l is used widely in public key cryptography.
Secure protocol module 804 can parse and generate ASN. l DER encoding in this illustrative embodiment.
(2} PKC #1 ~ PKCS #1 can calculate and verify nnessage digests and digital signa-tures as well as encrypt and decrypt data using a number of encryption algorithms. PKCS
#1 is provided by RSA BSAFE Crypto-JTM toolkit.
(3) X.509: X.509 specifies a format for certificates. In this embodiment, PKCS
#1 can parse and verify X.509 v3 certificates as well as build a certificate chain. This component of PKCS #1 also provides support for v3 certificate extensions required by S/MIME. X.509 can be implemented using ASN.I for certificate parsing and PKCS
#1 for verification.
(4) PKCS #12: PKCS #12 specifies password-protected data. By implementation of PKCS #12, secure protocol module 804 can extract private keys and certificates from password-protected PKCS # 12 data. In addition, secure protocol module 804 can also generate password-protected PKCS #12 data for a given set of keys and certificates, and a given password. PKCS #12 is implemented based on AS:f~.l, PKCS #l, and X.509.
(5) Private Kev Database By implementing a private key database, secure protocol module 804 manages the private key or keys of recipient 106. In this illustrative embodiment, secure protocol module 804 supports adding;, deleting, enumerating of the private keys. The private keys are stored protected by a user-defined password. While the term "password" can be considered to connote a single word, it is appreciated that "password" as used herein can include non-textual data arAd can include multiple words such as a passphrase. Secure protocol module 804 uses PKCS #12 to store the keys in the database and to import the keys from other applications.
(6) Trusted Certificate Authoritv Databace~ By implementing a trusted certificate authority database, secure protocol module 804 can access the list of trusted certificate authorities. Secure protocol module 804 uses X.509 to manipulate certificates of the certificate authorities.
(~ PKCS #7 Signed Data- PKCS #7 specifies a cryptographic message syntax. By implementing PKCS #7, secure protocol module 804 can verify the data signed using the PKCS #7 format and can extract the signed content and siigner's signature of such data.
Secure protocol module 804 uses ASN.1 for parsing of P1:~CS #7 data; PKCS #1 for verifying the signature; and X.509 and the trusted certificate authority far verifying the signer's certificate.
(8) PK_ S #7: PKCS #7 also specifies a format for enveloped data. By implementing the enveloped data portion of PKCS #7, secure protocol module 804 can decrypt data which is encrypted and packaged using the PKCS #7 format. Secure protocol module 804 uses ASN.1 for parsing of PKCS #7 data, the private key database for accessing the private key of recipient 106 needed to decrypt the secure message, and PKCS #1 for decryption.

(9) MIME Parser: Secure protocol module 804 can parse MIME messages and extract any attachments included in such MIME message.

(10) S/M~M~Message Proce~sor~ Secure protocol module 804 implements a S/MIME message parser which processes S/MIME messages with decryption and signature verification applied as necessary. The S/MIME message parser relies on the MIME parser of secure protocol module 804 to detect and extract S/MIME content as well as to process the original content once all of the cryptographic layers of signing and encryption are removed by using both aspects of PKCS #T described above as components (7) and (8).

(11} Certificate User Intenace~ Secure protocol module 804 implements a certificate user interface which can report certificate information to recipient 106. The certificate user interface relies on X.509 to provide such ir.~formation.

(12} Signature User nterface~ Secure protocol module 804 implements a signature user interface which can report S/MIME package signaturE; information to recipient 106.
The signature user interface can rely on the certificate user interface for displaying the signer's certificate and on signature info produced by PKCS #7 including, for example, the signing date and time.

(13) Private Ke~Database User Interface' Secure protocol module 804 implements a private key database user which provides the user with access to private key database operations. The private key database user interface uses the certificate user interface to show a user's certificate and the private key database to carry out the operations.
The above description is illustrative only and is not limiting. The present invention is limited only by the claims which follow.

Claims

What is claimed is:

I . A method for delivering an e-mail message which comports with a secure e-mail protocol to a recipient, the method comprising:
receiving, from the recipient through a computer network, a reference to the e-mail message;
sending, to the recipient through the computer network, computer instructions which, when executed, retrieve the e-mail message and process the message in accordance with the secure e-mail protocol.
2. The method of Claim 1 further comprising:
receiving the e-mail message from a sender through the computer network;
forming the reference to the e-mail message;
including the reference in a notification message; and sending the notification message to the recipient through the computer network.
3. The method of Claim 1 wherein the computer instructions collectively define an applet.
4. The method of Claim 1 wherein sending comprises sending the computer instructions in such a manner that causes the computer instructions to be executed upon receipt by the recipient without human intervention.
5. The method of Claim 1 wherein the secure e-mail protocol is an S/MIME
secure e-mail protocol.
6. The method of Claim 1 wherein the secure e-mail protocol is a PGP/MIME
secure e-mail protocol.
7. The method of Claim 1 wherein the secure e-mail protocol is an OpenPGP
secure e-mail protocol.
8. The method of Claim 1 wherein receiving is according to a hypertext transfer protocol.
9. The method of Claim 1 wherein sending is according to a hypertext transfer protocol.
10. The method of Claim 1 wherein the e-mail message includes one or more attached data files.
11. The method of Claim 1 wherein the computer instructions, when executed upon receipt by the recipient, process the e-mail message by decrypting at least a portion of the e-mail message.
12. The method of Claim 1 wherein the computer instructions, when executed upon receipt by the recipient, process the e-mail message by verifying a signature of at least a portion of the e-mail message.
13. The method of Claim 1 wherein the computer instructions provide a user interface for management of one or more encryption keys.
14. The method of Claim 1 wherein the computer instructions, when executed, import one or more encryption keys.
15. A computer readable medium useful in association with a computer which includes a processor and a memory, the computer readable medium including computer instructions which are configured to cause the computer to deliver an e-mail message which comports with a secure e-mail protocol to a recipient by:
receiving, from the recipient through a computer network, a reference to the e-mail message;
sending, to the recipient through the computer network, retrieval computer instructions which, when executed, retrieve the e-mail message and process the message in accordance with the secure e-mail protocol.
16. The computer readable medium of Claim 15 wherein the computer instructions are configured to cause the computer to deliver the e-mail message by also:
receiving the e-mail message from a sender through the computer network;
forming the reference to the e-mail message;
including the reference in a notification message; and sending the notification message to the recipient through the computer network.
17. The computer readable medium of Claim 15 wherein the retrieval computer instructions collectively define an applet.
18. The computer readable medium of Claim 15 wherein sending comprises sending the retrieval computer instructions in such a manner that causes the retrieval computer instructions to be executed upon receipt by the recipient without human intervention.
19. The computer readable medium of Claim 15 wherein the secure e-mail protocol is an S/MIME secure e-mail protocol.
20. The computer readable medium of Claim 15 wherein the secure e-mail protocol is a PGP/MIME secure e-mail protocol:
21. The computer readable medium of Claim 15 wherein the secure e-mail protocol is an OpenPGP secure e-mail protocol.
22. The computer readable medium of Claim 15 wherein receiving is according to a hypertext transfer protocol.
23. The computer readable medium of Claim 15 wherein sending is according to a hypertext transfer protocol.
24. The computer readable medium of Claim 15 wherein the e-mail message includes one or more attached data files.
25. The computer readable medium of Claim 15 wherein the retrieval computer instructions, when executed upon receipt by the recipient, process the e-mail message by decrypting at least a portion of the e-mail message.
26. The computer readable medium of Claim 15 wherein the retrieval computer instructions, when executed upon receipt by the recipient, process the e-mail message by verifying a signature of at least a portion of the e-mail message.
27. The computer readable medium of Claim 15 wherein the retrieval computer instructions provide a user interface for management of one or more encryption keys.
28. The computer readable medium of Claim 15 wherein the retrieval computer instructions, when executed, import one or more encryption keys.
29. A computer system comprising:
a processor;
a memory operatively coupled to the processor; and a delivery module (i) which executes in the processor from the memory and (ii) which, when executed by the processor, causes the computer to deliver an e-mail message which comports with a secure e-mail protocol to a recipient by:
receiving, from the recipient through a computer network, a reference to the e-mail message;
sending, to the recipient through the computer network, retrieval computer instructions which, when executed, retrieve the e-mail message and process the message in accordance with the secure e-mail protocol.
30. The computer system of Claim 29 wherein the delivery module is configured to cause the computer to deliver the e-mail message by also:
receiving the e-mail message from a sender through the computer network;
forming the reference to the e-mail message;
including the reference in a notification message; and sending the notification message to the recipient through the computer network.
31. The computer system of Claim 29 wherein the retrieval computer instructions collectively define an applet.
32. The computer system of Claim 29 wherein sending comprises sending the retrieval computer instructions in such a manner that causes the retrieval computer instructions to be executed upon receipt by the recipient without human intervention.
33. The computer system of Claim 29 wherein the secure e-mail protocol is an S/MIME secure e-mail protocol.
34. The computer system of Claim 29 wherein the secure e-mail protocol is a PGP/MIME secure e-mail protocol.
35. The computer system of Claim 29 wherein the secure e-mail protocol is an OpenPGP secure e-mail protocol.
36. The computer system of Claim 29 wherein receiving is according to a hypertext transfer protocol.
37. The computer system of Claim 29 wherein sending is according to a hypertext transfer protocol.
38. The computer system of Claim 29 wherein the e-mail message includes one or more attached data files.
39. The computer system of Claim 29 wherein the retrieval computer instructions, when executed upon receipt by the recipient, process the e-mail message by decrypting at least a portion of the e-mail message.
40. The computer system of Claim 29 wherein the retrieval computer instructions, when executed upon receipt by the recipient, process the e-mail message by verifying a signature of at least a portion of the e-mail message.
41. The computer system of Claim 29 wherein the retrieval computer instructions provide a user interface for management of one or more encryption keys.
42. The computer system of Claim 29 wherein the retrieval computer instructions, when executed, import one or more encryption keys.