CA2531163A1 - System and method for providing certified proof of delivery receipts for electronic mail - Google Patents
System and method for providing certified proof of delivery receipts for electronic mail Download PDFInfo
- Publication number
- CA2531163A1 CA2531163A1 CA002531163A CA2531163A CA2531163A1 CA 2531163 A1 CA2531163 A1 CA 2531163A1 CA 002531163 A CA002531163 A CA 002531163A CA 2531163 A CA2531163 A CA 2531163A CA 2531163 A1 CA2531163 A1 CA 2531163A1
- Authority
- CA
- Canada
- Prior art keywords
- sender
- recipient
- pod
- ttp
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/23—Reliability checks, e.g. acknowledgments or fault reporting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
Description
SYSTEM AND METHOD FOR PROVIDING CERTIFIED PROOF
OF DELIVERY RECEIPTS FOR ELECTRONIC MAIL
Field of the invention The present invention relates to data processing and, more particularly, to a method and apparatus for certifying the delivery of electronic mail messages using mechanisms based on public key encryption.
Background of.the Invention Electronic mail (e-mail) has become a primary means of communication for a large number of organizations, businesses and individuals. Its simpiicity, efficiency, and, most importantly, its virtually inexistent cost have made it very popular. In recent times, however, many problems have come to plague the use of email. The ever-increasing quantity of spam and phishing circulating on networks, for example, have put a dent in email's reliability. Even the solutions used to alleviate such problems, like mail filters, have only exacerbated the problem further by making it more difficult to guarantee the delivery of a sender's email. The issues are such that users are increasingly relying on more traditional means for verifying the delivery of their emails. Many users, for example, will not hesitate to phone a recipient to make sure they received a piece of email.
There is, therefore, a need for automatically and reliably informing a sender that an email has been properly received by the recipient.
Currently, there are a few methods allowing the sender to positively ensure that a recipient has indeed received a sent email. Here is a non-exhaustive list:
OF DELIVERY RECEIPTS FOR ELECTRONIC MAIL
Field of the invention The present invention relates to data processing and, more particularly, to a method and apparatus for certifying the delivery of electronic mail messages using mechanisms based on public key encryption.
Background of.the Invention Electronic mail (e-mail) has become a primary means of communication for a large number of organizations, businesses and individuals. Its simpiicity, efficiency, and, most importantly, its virtually inexistent cost have made it very popular. In recent times, however, many problems have come to plague the use of email. The ever-increasing quantity of spam and phishing circulating on networks, for example, have put a dent in email's reliability. Even the solutions used to alleviate such problems, like mail filters, have only exacerbated the problem further by making it more difficult to guarantee the delivery of a sender's email. The issues are such that users are increasingly relying on more traditional means for verifying the delivery of their emails. Many users, for example, will not hesitate to phone a recipient to make sure they received a piece of email.
There is, therefore, a need for automatically and reliably informing a sender that an email has been properly received by the recipient.
Currently, there are a few methods allowing the sender to positively ensure that a recipient has indeed received a sent email. Here is a non-exhaustive list:
2 = Mail-client features: Some mail client software (i.e the software users use to read, write, send, and receive email) allows the sender to flag some email as requiring a receipt. In that case, the recipient is prompted by his mail client whether he wants to send a receipt back to the sender. This, however, is a voluntary process and the recipient may decide not to send such a receipt and still read the email. In addition, this feature is not supported by all mail client software.
= Intermediary storage gateway: In this method, the sender sends his emails to the recipient through a special server or provider, the latter stores the email and sends a notification to the end recipient, usually in the form of another email, that an email is stored for him by the underlying system and provides instructions as to how to retrieve the email. Upon retrieving the sender's email, the recipient thereby triggers a receipt to be sent back to the sender. While this method is indeed effective in making sure that the recipient cannot read the message without triggering a receipt being sent to the sender, it is counter-intuitive for both the sender and the recipient and, more so, requires that the sender change his infrastructure to use a server or provider implementing this system instead of his standard emaii server or provider. In addition, this requires the sender to entrust his email to a third party, which constitutes a breach of privacy risk.
= Embedded web image: In this method, a provider embeds a URL in a sender's HTML-written email, records all accesses to this URL, and reports those accesses back to the sender. Basically, this method takes advantage of the fact that most modern mail clients are capable of reading HTML
emails and, therefore, are typically configured to automatically download images which are pointed to by incoming HTML emails. This automatic download triggers a mechanism that records the time at which the access was made and how long the image was displayed. While this technique is used by apparent legitimate services, it is also widely used by spammers and phishing attempts to record user behavior. It is often considered spyware and its use by senders is regarded by some as immoral because
= Intermediary storage gateway: In this method, the sender sends his emails to the recipient through a special server or provider, the latter stores the email and sends a notification to the end recipient, usually in the form of another email, that an email is stored for him by the underlying system and provides instructions as to how to retrieve the email. Upon retrieving the sender's email, the recipient thereby triggers a receipt to be sent back to the sender. While this method is indeed effective in making sure that the recipient cannot read the message without triggering a receipt being sent to the sender, it is counter-intuitive for both the sender and the recipient and, more so, requires that the sender change his infrastructure to use a server or provider implementing this system instead of his standard emaii server or provider. In addition, this requires the sender to entrust his email to a third party, which constitutes a breach of privacy risk.
= Embedded web image: In this method, a provider embeds a URL in a sender's HTML-written email, records all accesses to this URL, and reports those accesses back to the sender. Basically, this method takes advantage of the fact that most modern mail clients are capable of reading HTML
emails and, therefore, are typically configured to automatically download images which are pointed to by incoming HTML emails. This automatic download triggers a mechanism that records the time at which the access was made and how long the image was displayed. While this technique is used by apparent legitimate services, it is also widely used by spammers and phishing attempts to record user behavior. It is often considered spyware and its use by senders is regarded by some as immoral because
3 the recipient is spied on unknowingly.
= Transactional email gateways: In US2005/0251861 and US2005/0210106 a method is described whereby the outgoing mail server gateway signs outgoing emails with a generated key, forwards the email to the recipient, receives requests for validation from the end recipient, validates the request, and responds to the recipient with a validation status and, by the same token, flags the email as having been properly delivered.
In this case, nothing precludes the recipient not to request the validation request, and therefore the recipient from reading the email without acknowledging receipt.
= Trusted third-party (TTP) encryption key storage: In US 6,807,277 and US2003/0147536 a method is described whereby a sender uses a key to encrypt a message to a recipient, provides the TTP with part of the key and sends the encrypted message and the rest of the key to the recipient. Upon receipt, the recipient requests the part of the key he is missing from the TTP
which retrieves the key part stored by the sender earlier, sends it to the recipient and notifies the sender that the recipient has, in effect, "received"
the message. This method's most obvious shortcomings are the fact that the TTP must store data for each message sent by the sender and the fact that both the sender and the recipient must share the same exact TTP.
= TTP message decryption: In their article "TRICERT: A Distributed Certified E-Mail Scheme" presented at the 2001 "Network and Distributed System Security Symposium" in San Diego, California, Ateniese et al.
describe a method whereby the sender encrypts the message using the recipient's public key, encrypts the result using the TTP's public key, signs the result with his private key and sends this last result to the recipient.
Upon receiving the message, the recipient first validates the sender's signature, then creates and signs a receipt which he sends along with the sender's message to the TTP. The TTP verifies the recipient's signature, and, if it is valid, notifies the sender that the message was indeed delivered, decrypts the encrypted message using its private key and sends the result
= Transactional email gateways: In US2005/0251861 and US2005/0210106 a method is described whereby the outgoing mail server gateway signs outgoing emails with a generated key, forwards the email to the recipient, receives requests for validation from the end recipient, validates the request, and responds to the recipient with a validation status and, by the same token, flags the email as having been properly delivered.
In this case, nothing precludes the recipient not to request the validation request, and therefore the recipient from reading the email without acknowledging receipt.
= Trusted third-party (TTP) encryption key storage: In US 6,807,277 and US2003/0147536 a method is described whereby a sender uses a key to encrypt a message to a recipient, provides the TTP with part of the key and sends the encrypted message and the rest of the key to the recipient. Upon receipt, the recipient requests the part of the key he is missing from the TTP
which retrieves the key part stored by the sender earlier, sends it to the recipient and notifies the sender that the recipient has, in effect, "received"
the message. This method's most obvious shortcomings are the fact that the TTP must store data for each message sent by the sender and the fact that both the sender and the recipient must share the same exact TTP.
= TTP message decryption: In their article "TRICERT: A Distributed Certified E-Mail Scheme" presented at the 2001 "Network and Distributed System Security Symposium" in San Diego, California, Ateniese et al.
describe a method whereby the sender encrypts the message using the recipient's public key, encrypts the result using the TTP's public key, signs the result with his private key and sends this last result to the recipient.
Upon receiving the message, the recipient first validates the sender's signature, then creates and signs a receipt which he sends along with the sender's message to the TTP. The TTP verifies the recipient's signature, and, if it is valid, notifies the sender that the message was indeed delivered, decrypts the encrypted message using its private key and sends the result
4 back to the recipient. The recipient can then decrypt the message using his private key and read it. The basic shortcoming of this system is the requirement for the recipient to transmit the entire message to the TTP and the TTP doing the same back again, along with the fact that the mechanism assumes the recipient itself possesses a private/public key pair. In other words, the recipient must also be known or identifiable to the TTP before senders can send him messages that trigger proof of delivery.
= TTP symmetric key decryption: In US 2002/0143710 a method is described whereby the sender encrypts a message using a symmetric key, encrypts the symmetric key using the TTP's public key and sends both the encrypted message and the encrypted symmetric key to the sender.
(Provisions are also provided for sending the encrypted symmetric key to the TTP instead of sending it to the recipient, but the focus is on the scheme where the key is sent to the recipient along with the encrypted message.) Upon receiving the encrypted message and the encrypted symmetric key, the recipient produces a receipt and signs it with his own private key. He then submits the encrypted symmetric key along with the signed receipt to the TTP. The TTP first verifies the signed receipt and, if it is valid, forwards the receipt to the sender, thereby notifying him that the message has been "received", decrypts the symmetric key using its private key and provides the decrypted symmetric key to the recipient. The recipient can then use the symmetric key to decrypt the message it has received from the sender. The most obvious shortcoming of this method is the same as in the case of the TTP message decryption, namely that the recipient is assumed to be known or identifiable to the TTP. A recipient that is not known to the TTP and does not himself possess a private/public key pair cannot read messages sent to him that are meant to trigger proof of delivery. In addition, the fact that the symmetric key is encrypted using the TTP's public key means that the sender, and therefore the organization he works for, cannot, in case of need - such as forensic analysis or data recovery/retrieval --, decrypt messages sent using this method. Also, the fact that the sender itself is encrypting the message means that the sender's organization cannot itself audit the message's content prior to its being sent to the recipient, an increasingly important requirement for organizations.
= TTP symmetric key decryption: In US 2002/0143710 a method is described whereby the sender encrypts a message using a symmetric key, encrypts the symmetric key using the TTP's public key and sends both the encrypted message and the encrypted symmetric key to the sender.
(Provisions are also provided for sending the encrypted symmetric key to the TTP instead of sending it to the recipient, but the focus is on the scheme where the key is sent to the recipient along with the encrypted message.) Upon receiving the encrypted message and the encrypted symmetric key, the recipient produces a receipt and signs it with his own private key. He then submits the encrypted symmetric key along with the signed receipt to the TTP. The TTP first verifies the signed receipt and, if it is valid, forwards the receipt to the sender, thereby notifying him that the message has been "received", decrypts the symmetric key using its private key and provides the decrypted symmetric key to the recipient. The recipient can then use the symmetric key to decrypt the message it has received from the sender. The most obvious shortcoming of this method is the same as in the case of the TTP message decryption, namely that the recipient is assumed to be known or identifiable to the TTP. A recipient that is not known to the TTP and does not himself possess a private/public key pair cannot read messages sent to him that are meant to trigger proof of delivery. In addition, the fact that the symmetric key is encrypted using the TTP's public key means that the sender, and therefore the organization he works for, cannot, in case of need - such as forensic analysis or data recovery/retrieval --, decrypt messages sent using this method. Also, the fact that the sender itself is encrypting the message means that the sender's organization cannot itself audit the message's content prior to its being sent to the recipient, an increasingly important requirement for organizations.
5 There are also other existing and proposed systems, including combinations of the above-described schemes. However, few have the ability to reliably provide certified proof of delivery receipts without modifying the sender's networking infrastructure, without requiring the sender to entrust his email to a third party, and without using dubious methods to spy on the recipient's behavior, while still requiring the recipient to confirm receipt upon reading a sender's email. Even those that achieve these goals using a TTP have not been designed to take in account how modern organizations deploy and maintain their networks and user configurations while catering for the needs created by the problems facing all email systems nowadays including spam, viruses and phishing. In addition, none have succeeded in gathering mainstream adoption nor established themselves as the preferred method for providing senders with certified delivery receipts for email.
Summary of the Invention The present invention provides a method and system for providing certified proof of delivery receipts for electronic mail. In one embodiment, the sender contacts a proof-of-delivery (PoD) request server which identifies the sender as being authorized to use its services, receives the message the sender would like to obtain a PoD for, generates a random symmetric key, encrypts the sender's message with the symmetric key, encrypts the symmetric key and other data items related to the message using a public key associated with the sender or the sender's organization, thereby creating a PoD request, and returns the encrypted message and the PoD request to the sender. The sender then uses his regular
Summary of the Invention The present invention provides a method and system for providing certified proof of delivery receipts for electronic mail. In one embodiment, the sender contacts a proof-of-delivery (PoD) request server which identifies the sender as being authorized to use its services, receives the message the sender would like to obtain a PoD for, generates a random symmetric key, encrypts the sender's message with the symmetric key, encrypts the symmetric key and other data items related to the message using a public key associated with the sender or the sender's organization, thereby creating a PoD request, and returns the encrypted message and the PoD request to the sender. The sender then uses his regular
6 email infrastructure to transmit to the recipient the message and the PoD
request as a single email. Upon receiving the sender's email, the recipient contacts a TTP
which has a copy of the sender's private key, and sends it the PoD request.
The TTP decrypts the PoD request using the sender's private key, notifies the sender that the recipient has received the message and provides the symmetric key back to the recipient which can then decrypt and read the message.
As in co-pending "System and Method for Warranting Electronic Mail Using a Hybrid Public Key Encryption Scheme" assigned International Application Number PCT/CA20051000173, the contents of which are expressly incorporated herein by reference, in this invention the sender does not have access to his private key and cannot, therefore, generate a PoD request for himself. This is an important departure from existing systems which rely on a TTP where the sender generates his own PoD request. Amongst other things, the use of a PoD request server allows the sender's organization to centralize management rules related to the use of this server, and allows for the PoD request server to enforce policies on message content. Also, the user can generate PoD requests without having to understand the intricacies of public key infrastructure (PKI), symmetric keys, and hybrid cryptosystems. All he likely needs is a username/password pair and a software component running on his system, possibly a plugin, for interacting with the PoD request server.
Also, unlike other TTP-based PoD systems, this invention does not rely on the TTP's public key. Instead, it's the sender's public key that is used. In addition to allowing the sender's organization to continue being able to access previously PoD-request-server-processed messages, possibly using a management console on the PoD request server or something similar, the sender and/or his organization need not specify beforehand which TTP must be used by the recipient to process the PoD request. It is, in fact, possible that in a distributed environment, many TTPs may be able to process the PoD request for the recipient, and he can therefore select the one most convenient to his location or his network
request as a single email. Upon receiving the sender's email, the recipient contacts a TTP
which has a copy of the sender's private key, and sends it the PoD request.
The TTP decrypts the PoD request using the sender's private key, notifies the sender that the recipient has received the message and provides the symmetric key back to the recipient which can then decrypt and read the message.
As in co-pending "System and Method for Warranting Electronic Mail Using a Hybrid Public Key Encryption Scheme" assigned International Application Number PCT/CA20051000173, the contents of which are expressly incorporated herein by reference, in this invention the sender does not have access to his private key and cannot, therefore, generate a PoD request for himself. This is an important departure from existing systems which rely on a TTP where the sender generates his own PoD request. Amongst other things, the use of a PoD request server allows the sender's organization to centralize management rules related to the use of this server, and allows for the PoD request server to enforce policies on message content. Also, the user can generate PoD requests without having to understand the intricacies of public key infrastructure (PKI), symmetric keys, and hybrid cryptosystems. All he likely needs is a username/password pair and a software component running on his system, possibly a plugin, for interacting with the PoD request server.
Also, unlike other TTP-based PoD systems, this invention does not rely on the TTP's public key. Instead, it's the sender's public key that is used. In addition to allowing the sender's organization to continue being able to access previously PoD-request-server-processed messages, possibly using a management console on the PoD request server or something similar, the sender and/or his organization need not specify beforehand which TTP must be used by the recipient to process the PoD request. It is, in fact, possible that in a distributed environment, many TTPs may be able to process the PoD request for the recipient, and he can therefore select the one most convenient to his location or his network
7 configuration. In terms of scalability, there is therefore clear advantages to this invention's approach.
In addition, the recipient does not need to be known or be identifiable to any TTP.
Instead, he just needs the proper software to interact with the TTP, possibly a plugin, which could be the same as the one used by the sender. Again, this is a departure from other TTP-based approaches where the recipient is assumed to have the same capabilities as the sender, in particular with regards to his having a private/public key pair with the public key being recognized, in some fashion, to match his identity by the TTP.
In sum, this invention is thus composed of the PoD request server, the software used by the sender and the recipient to obtain PoD requests and talk to the PoD-generating TTP, and all additional software and hardware required to implement this invention.
Detailed Description of the Invention The following drawing illustrates the invention's main components.
Sender's 5 Recipient's mail server mail server TTP ~
In addition, the recipient does not need to be known or be identifiable to any TTP.
Instead, he just needs the proper software to interact with the TTP, possibly a plugin, which could be the same as the one used by the sender. Again, this is a departure from other TTP-based approaches where the recipient is assumed to have the same capabilities as the sender, in particular with regards to his having a private/public key pair with the public key being recognized, in some fashion, to match his identity by the TTP.
In sum, this invention is thus composed of the PoD request server, the software used by the sender and the recipient to obtain PoD requests and talk to the PoD-generating TTP, and all additional software and hardware required to implement this invention.
Detailed Description of the Invention The following drawing illustrates the invention's main components.
Sender's 5 Recipient's mail server mail server TTP ~
8 1 PoD reques Seraer 2 7 Sender ~ Recipient Figure 1 In 1, the sender contacts the PoD request server to obtain a PoD request.
First, the sender must provide the proper information in order to obtain the authorization to use the PoD request server. This information may be a username/password pair, or it may be a function of the network layout, such as an IP address or a MAC
address, or both, or something else. The PoD request server may also be configured to accept connections from any senders with access to it. Having been authorized to use the PoD request server's services, the sender transmits the messages he wishes to obtain a PoD request for to the PoD request server. Note that PoD request server could be located on a sender's organization's LAN or it could be remotely accessible through another network such as the Internet. The functionality of the PoD server should be fairly similar whether it is on local LAN or on a remote network.
In 2, the PoD request server first receives the sender's message and likely stores it in a temporary buffer in RAM for further processing. The PoD request server could then conduct a series of analysis on the sender's message, including verifying compliance to corporate guidelines and spam detection, amongst other possibilities. Having done so, the PoD request server generates a random symmetric key and encrypts the sender's message with this key. The server then generates a PoD request by encrypting the symmetric key possibly along with other data items related to the message using a public key attributed to the sender or his organization. The PoD server could also conduct a number of other operations on the message, such as generating a signature for the sender akin the description found in co-pending PCT/CA2005/000173, or it may even encrypt the message for exclusive viewing by the recipient.
In 3, the PoD request server returns the encrypted message and the PoD request to the sender.
Both steps 1 and 3 are automated using software on the sender's station. Said software could possibly be a plugin to the sender's existing email client software.
First, the sender must provide the proper information in order to obtain the authorization to use the PoD request server. This information may be a username/password pair, or it may be a function of the network layout, such as an IP address or a MAC
address, or both, or something else. The PoD request server may also be configured to accept connections from any senders with access to it. Having been authorized to use the PoD request server's services, the sender transmits the messages he wishes to obtain a PoD request for to the PoD request server. Note that PoD request server could be located on a sender's organization's LAN or it could be remotely accessible through another network such as the Internet. The functionality of the PoD server should be fairly similar whether it is on local LAN or on a remote network.
In 2, the PoD request server first receives the sender's message and likely stores it in a temporary buffer in RAM for further processing. The PoD request server could then conduct a series of analysis on the sender's message, including verifying compliance to corporate guidelines and spam detection, amongst other possibilities. Having done so, the PoD request server generates a random symmetric key and encrypts the sender's message with this key. The server then generates a PoD request by encrypting the symmetric key possibly along with other data items related to the message using a public key attributed to the sender or his organization. The PoD server could also conduct a number of other operations on the message, such as generating a signature for the sender akin the description found in co-pending PCT/CA2005/000173, or it may even encrypt the message for exclusive viewing by the recipient.
In 3, the PoD request server returns the encrypted message and the PoD request to the sender.
Both steps 1 and 3 are automated using software on the sender's station. Said software could possibly be a plugin to the sender's existing email client software.
9 In 4, the sender transmits the encrypted message and the PoD request as a regular email to his existing mail server.
In 5, the sender's mail server transmits the sender's mail to the recipient's mail server.
In 6, the recipient retrieves messages stored for him by his mail server. It is at this stage that software located on the recipient's station, possibly a plugin to his email client software, which could possibly be the same one used by the sender to initiate the PoD process, would detect emails containing PoD requests and act appropriately. The PoD requests generated by PoD request servers would likely contain plain-text messages so that recipients that lack the software required to deal with PoD requests could still be informed of the functionality and how they could obtain the software required to deal with such messages. It could be possible for the software on the recipient's station to request input from the user as to whether he desires to in fact participate in the PoD process or whether he wishes not to, in which case he would be unable to read the message sent by the sender.
In 7, the recipient (or, more specifically, the software on the recipient's station) contacts the TTP in order to obtain the decrypted symmetric key. This process does not require the recipient to be a party known to or identifiable by the TTP.
Instead, any recipient can interact with the TTP to request the processing of PoD
requests. As part of this process, the recipient transmits the PoD request received from the sender to the TTP.
In 8, the TTP processes the PoD request obtained from the recipient. The essential task of the TTP at this stage is to identify the sender who sent the PoD
request to the recipient, retrieve the private key related to this sender from a private key database, decrypt the symmetric key found in the PoD request using the retrieved private key, and create a certified PoD for the sender. The TTP
may, however, do much more. First, the certified PoD created for the sender could likely be signed by the TTP thereby attesting to its origin and validity, possibly using the process described in co-pending PCT/CA2005/000173. Secondly, the sender may have the ability to inform the TTP of messages it wishes to "retract". In such a 5 case, the TTP would refuse to provide the recipient with the symmetric key for decrypting the sender's message, thereby making the message unreadable to the recipient. Thirdly, the TTP could be made to log as much information about the recipient as possible. For example, the recipient's IP address and the time at which the PoD request was transmitted could be logged as part of data stored for
In 5, the sender's mail server transmits the sender's mail to the recipient's mail server.
In 6, the recipient retrieves messages stored for him by his mail server. It is at this stage that software located on the recipient's station, possibly a plugin to his email client software, which could possibly be the same one used by the sender to initiate the PoD process, would detect emails containing PoD requests and act appropriately. The PoD requests generated by PoD request servers would likely contain plain-text messages so that recipients that lack the software required to deal with PoD requests could still be informed of the functionality and how they could obtain the software required to deal with such messages. It could be possible for the software on the recipient's station to request input from the user as to whether he desires to in fact participate in the PoD process or whether he wishes not to, in which case he would be unable to read the message sent by the sender.
In 7, the recipient (or, more specifically, the software on the recipient's station) contacts the TTP in order to obtain the decrypted symmetric key. This process does not require the recipient to be a party known to or identifiable by the TTP.
Instead, any recipient can interact with the TTP to request the processing of PoD
requests. As part of this process, the recipient transmits the PoD request received from the sender to the TTP.
In 8, the TTP processes the PoD request obtained from the recipient. The essential task of the TTP at this stage is to identify the sender who sent the PoD
request to the recipient, retrieve the private key related to this sender from a private key database, decrypt the symmetric key found in the PoD request using the retrieved private key, and create a certified PoD for the sender. The TTP
may, however, do much more. First, the certified PoD created for the sender could likely be signed by the TTP thereby attesting to its origin and validity, possibly using the process described in co-pending PCT/CA2005/000173. Secondly, the sender may have the ability to inform the TTP of messages it wishes to "retract". In such a 5 case, the TTP would refuse to provide the recipient with the symmetric key for decrypting the sender's message, thereby making the message unreadable to the recipient. Thirdly, the TTP could be made to log as much information about the recipient as possible. For example, the recipient's IP address and the time at which the PoD request was transmitted could be logged as part of data stored for
10 or later transmitted to the sender. Fourthly, the TTP could be configured to only allow one PoD through. In other words, only the first recipient requesting PoD
processing would be allowed, subsequent PoD processing requests from other recipients would result in the TTP refusing to give them the symmetric key.
There are, of course, many other enhancements possible to the TTP's involvement in the scheme described in this invention.
In 9, the TTP sends the certified PoD to the sender. In this illustration, the certified PoD is shown as being sent as a regular email back to the sender. However, the certified PoD could be transmitted using other means, including storing it in a database for the user to consult online, or transferring certified PoDs in batches back to the sender.
In 10, the TTP transfers the decrypted symmetric key to the recipient. Having received the decrypted symmetric key, the recipient can then decrypt the sender's message and read it.
In 11, the sender retrieves his emails from his mail server and obtains the certified PoD. As in the explanation for 9, it is important to note that the sender could be provided with other means for obtaining or viewing certified PoDs.
processing would be allowed, subsequent PoD processing requests from other recipients would result in the TTP refusing to give them the symmetric key.
There are, of course, many other enhancements possible to the TTP's involvement in the scheme described in this invention.
In 9, the TTP sends the certified PoD to the sender. In this illustration, the certified PoD is shown as being sent as a regular email back to the sender. However, the certified PoD could be transmitted using other means, including storing it in a database for the user to consult online, or transferring certified PoDs in batches back to the sender.
In 10, the TTP transfers the decrypted symmetric key to the recipient. Having received the decrypted symmetric key, the recipient can then decrypt the sender's message and read it.
In 11, the sender retrieves his emails from his mail server and obtains the certified PoD. As in the explanation for 9, it is important to note that the sender could be provided with other means for obtaining or viewing certified PoDs.
11 While embodiments of this invention have been illustrated and described above, it will be evident to those skilled in the art that changes and modifications may be made therein without departing from the essence of this invention.
Claims
Priority Applications (9)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002531163A CA2531163A1 (en) | 2005-12-19 | 2005-12-19 | System and method for providing certified proof of delivery receipts for electronic mail |
| EP06840509A EP1964325A1 (en) | 2005-12-19 | 2006-12-19 | System and method for providing certified proof of delivery receipts for electronic mail |
| CA002633784A CA2633784A1 (en) | 2005-12-19 | 2006-12-19 | System and method for end-to-end electronic mail encryption |
| PCT/CA2006/002083 WO2007071041A1 (en) | 2005-12-19 | 2006-12-19 | System and method for end-to-end electronic mail encryption |
| US12/086,697 US20090327714A1 (en) | 2005-12-19 | 2006-12-19 | System and Method for End-to-End Electronic Mail-Encryption |
| US12/086,702 US20100217979A1 (en) | 2005-12-19 | 2006-12-19 | System and Method for Providing Certified Proof of Delivery Receipts for Electronic Mail |
| PCT/CA2006/002082 WO2007071040A1 (en) | 2005-12-19 | 2006-12-19 | System and method for providing certified proof of delivery receipts for electronic mail |
| CA002633780A CA2633780A1 (en) | 2005-12-19 | 2006-12-19 | System and method for providing certified proof of delivery receipts for electronic mail |
| EP06840510A EP1964304A1 (en) | 2005-12-19 | 2006-12-19 | System and method for end-to-end electronic mail encryption |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002531163A CA2531163A1 (en) | 2005-12-19 | 2005-12-19 | System and method for providing certified proof of delivery receipts for electronic mail |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2531163A1 true CA2531163A1 (en) | 2007-06-19 |
Family
ID=38175407
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002531163A Abandoned CA2531163A1 (en) | 2005-12-19 | 2005-12-19 | System and method for providing certified proof of delivery receipts for electronic mail |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2531163A1 (en) |
-
2005
- 2005-12-19 CA CA002531163A patent/CA2531163A1/en not_active Abandoned
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2913695C (en) | Automatic delivery selection for electronic content | |
| US20100217979A1 (en) | System and Method for Providing Certified Proof of Delivery Receipts for Electronic Mail | |
| US9917828B2 (en) | Secure message delivery using a trust broker | |
| US7376835B2 (en) | Implementing nonrepudiation and audit using authentication assertions and key servers | |
| US7277549B2 (en) | System for implementing business processes using key server events | |
| US6904521B1 (en) | Non-repudiation of e-mail messages | |
| US7640427B2 (en) | System and method for secure electronic communication in a partially keyless environment | |
| US20090210708A1 (en) | Systems and Methods for Authenticating and Authorizing a Message Receiver | |
| US7673004B1 (en) | Method and apparatus for secure IM communications using an IM module | |
| US20040133520A1 (en) | System and method for secure and transparent electronic communication | |
| US20040133774A1 (en) | System and method for dynamic data security operations | |
| JP2010522488A (en) | Secure electronic messaging system requiring key retrieval to distribute decryption key | |
| CA2587239A1 (en) | System and method for ad-hoc processing of cryptographically-encoded data | |
| US20070288746A1 (en) | Method of providing key containers | |
| CA2531163A1 (en) | System and method for providing certified proof of delivery receipts for electronic mail | |
| CA2530937A1 (en) | System and method for end-to-end electronic mail encryption | |
| Whittacre | Collaborative intelligent email ranking system | |
| AU2005220240B1 (en) | Method of providing key containers |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |