Note: Descriptions are shown in the official language in which they were submitted.
CA 02357016 2001-06-29
WO 00!42748 PCT/US00101011
WEB-BASED DELIVERY OF SECURE 1G-MAIL MESSAGES
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
CA 02357016 2001-06-29
WO 00/42748 PCTIUS0010101I
-2
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
CA 02357016 2001-06-29
WO 00/42748 PCT/US00/01011
-3
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
CA 02357016 2001-06-29
WO 0014274$ PCT/US00/01011
-4
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.
CA 02357016 2001-06-29
WO 00/42748 PCTlUS00/01011
-5
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,
CA 02357016 2001-06-29
WO 00/42748 PCT/US00101011
-6
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
CA 02357016 2001-06-29
WO 00/42748 PCT/US00101011
_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
CA 02357016 2001-06-29
WO 00/42748 PCTIUS00/01011
_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
CA 02357016 2001-06-29
WO 00/42748 PCT/US00/01011
_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.
CA 02357016 2001-06-29
WO 00/42748 PCTIUSfl0101011
- 10
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.
CA 02357016 2001-06-29
WO 00/42748 PCT/US00101011
-11
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
CA 02357016 2001-06-29
WO 00/42748 PCT/US00/Oi011
-12-
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
104
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
CA 02357016 2001-06-29
WO 00/42'148 PCTIUS00101011
-13
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.
CA 02357016 2001-06-29
WO 00142748 PCT/US00/01011
-14
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
CA 02357016 2001-06-29
WO 00/42748 PCT/US0010101I
-15
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
CA 02357016 2001-06-29
WO 00/42748 PCTILJS00/01011
- 16
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
802
(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
CA 02357016 2001-06-29
WO 00/42748 PCT/ITSOOI01011
- 17
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
1004
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
CA 02357016 2001-06-29-
WO 00/42748 PCT/US00/01011
-18
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
CA 02357016 2001-06-29
wo ooiaz~ag ~cTivsoo~oiom
- 19
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
CA 02357016 2001-06-29
WO 00/42748 PCT/US00/01011
-20
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
CA 02357016 2001-06-29
WO 00/42748 PCT/US00/01011
-21
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
CA 02357016 2001-06-29
WO 00142748 PCT/US00/01011
-22-
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
CA 02357016 2001-06-29
WO 00/42748 PCT/US00/01011
-23-
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.
