WO2004111790A2 - Procede et appareil de messagerie privee entre utilisateurs, pris en charge par des courriers independants et interoperables - Google Patents

Procede et appareil de messagerie privee entre utilisateurs, pris en charge par des courriers independants et interoperables Download PDF

Info

Publication number
WO2004111790A2
WO2004111790A2 PCT/US2004/018404 US2004018404W WO2004111790A2 WO 2004111790 A2 WO2004111790 A2 WO 2004111790A2 US 2004018404 W US2004018404 W US 2004018404W WO 2004111790 A2 WO2004111790 A2 WO 2004111790A2
Authority
WO
WIPO (PCT)
Prior art keywords
courier
message
private
agent
trusted
Prior art date
Application number
PCT/US2004/018404
Other languages
English (en)
Other versions
WO2004111790A3 (fr
Inventor
James W. Bishop, Jr.
Richard Mo
Original Assignee
Autouptodate Llc D/B/A Armorpost
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US10/701,355 external-priority patent/US20040148356A1/en
Priority claimed from US10/709,952 external-priority patent/US7313688B2/en
Application filed by Autouptodate Llc D/B/A Armorpost filed Critical Autouptodate Llc D/B/A Armorpost
Publication of WO2004111790A2 publication Critical patent/WO2004111790A2/fr
Publication of WO2004111790A3 publication Critical patent/WO2004111790A3/fr

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/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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
    • 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/0891—Revocation or update of secret information, e.g. encryption key update or rekeying

Definitions

  • This invention pertains in general to electronic messaging such as electronic mail ("email”) and similar communication, and in particular to providing message privacy services.
  • the Trusted Courier is a single network element owned by a single entity.
  • the Trusted Courier represents a nexus through which both Private Messages and their corresponding Access Restrictions Messages flow.
  • the fact that these messages are sent separately in time provides substantial security.
  • an even greater degree of assurance against abuse of the Trusted Courier's unique position in the network can be achieved by routing those two messages through completely separate elements.
  • the present invention provides a private messaging system using trusted couriers to relay private messages as well as key material used to protect the private messages that is enhanced by the deployment of multiple independent yet interoperating Trusted Couriers.
  • the independent trusted couriers may be operated by independent organizations, some of which may compete with one another for users and others of which may support closed user communities.
  • the present invention contemplates that any of these independent organizations may choose to operate multiple trusted couriers itself, whether for the purpose of aligning traffic distribution with enterprise network architecture, for the purpose of providing greater capacity than is achievable in a single node, or for any other reason.
  • any single trusted courier may be deployed in such a way as to separate the handling of private message content and access restrictions messages that contain key material. While the basic methods for such handling are described in Provisional Application 60/466,910, the present invention provides enhanced methods that ensure the two messages which correspond with one another are not handled in the same network element, hi other words, key material used to protect a particular private message is handled by a set of network elements that are at least partially and preferably wholly independent of the network elements used to convey the private message.
  • FIG. 1 illustrates a high-level block diagram of the multi-Courier Private Messaging system of the present invention
  • FIG. 2 illustrates a block diagram exemplifying the topology of the Courier Network of the present invention
  • FIG. 3 illustrates a combination signaling sequence chart and flow chart for the Registration process in accordance with the present invention
  • FIG. 4 illustrates a combination signaling sequence chart and flow chart for the
  • FIG. 5 illustrates a combination signaling sequence chart and flow chart for the Registration Transfer process in accordance with the present invention
  • FIG. 6 illustrates a combination signaling sequence chart and flow chart for a Message Transfer involving a single Trusted Courier with separate foreground and background elements in accordance with the present invention
  • FIG. 7 illustrates a combination signaling sequence chart and flow chart for a Message Transfer involving two Trusted Couriers, which have been previously introduced to one another, in accordance with the present invention
  • FIG. 8 illustrates a combination signaling sequence chart and flow chart for a Message Transfer involving two Trusted Couriers, which have not been previously introduced to one another, as well as the Deferral procedure which intervenes to ensure end-to-end flow and the Introduction procedure which follows to prevent future Deferrals between these two Trusted Courier pairs, in accordance with the present invention
  • FIG. 9 illustrates a combination signaling sequence chart and flow chart for a
  • Multi-Courier Private Messaging System 100 represents the system in accordance with the present invention.
  • End-to-End Messaging mfrastructure 101 represents the messaging backbone to which the Private Messaging capability of the foundation disclosure, as enhanced by the present invention, is added.
  • This Infrastructure can be any messaging system that allows users and/or software entities to exchange messages with one another. It is preferably the Internet-standard email service, but may also be implemented as an instant messaging service, a wireless short message service (SMS), any other messaging service, or any combination of these.
  • SMS wireless short message service
  • Packet Network 102 forms the foundation for all communication among elements, including End-to-End Messaging Infrastructure 101 and the messages exchanged thereon, but also supporting other non-messaging interactions such as web browsing.
  • This element is preferably an Internet-based network, and may be the Internet itself, another network like it, or a composite of networks using multiple inter-networl ing technologies.
  • Agents 110 connected to End-to-End Messaging Infrastructure 101 and Packet Network 102 are one or more Agents 110, which are computer software applications and devices which enable the Private Messaging capability for an end user.
  • Agent 110 is a composite of some existing Messaging Client 112, an Information Security component 111, an interface 113 to the Messaging Infrastrucrure 101, and an interface 114 to the Packet Network 102. Agent 110 and its components are described in detail in the foundation disclosure, and are used here exactly as they are there.
  • each Trusted Courier 103 comprises a Background and a Foreground element, such that Background and Foreground signaling as defined in the foundation disclosure are handled in completely separate Courier elements. This enhances the security of the system because with foreground and background signaling handled separately, the content of any single Private or Restricted Message cannot be decrypted by any Trusted Courier. This satisfies the distribution goal cited above.
  • Each Trusted Courier 103 comprises two elements. Trusted Courier
  • Foreground Element 120 is substantially identical in every way to Trusted Courier 120 from the foundation disclosure.
  • Trusted Courier Background Element 130 is based on Trusted Courier 120 from the foundation disclosure, and its Information Security module 131 is substantially identical to Information Security module 121 from the foundation disclosure.
  • Trusted Courier Background Element 130 differs from the previous Trusted Courier 120 in that it lacks an Account Management module; no such module is necessary in Trusted Courier background element 130 because the Account Management module 122 in its corresponding Trusted Courier foreground element 120 serves for the entire Trusted Courier 103.
  • Trusted Courier background element 130 handles only background element signaling, it interacts directly with Agents 110 and other Trusted Courier background elements 130 only via its Interface 124 and Packet Network 102.
  • Agents 110 and Trusted Courier Elements 120/130 may be deployed in the same room on the same Internet access interface, in different cities, or using any topology in between. It is also conceivable that they may be implemented as separate processes in the same computer, although this is not expected to be common or advisable due to security concerns.
  • the foundation disclosure details the structure and functionality of Agents 110 and Trusted Courier Elements 120/130, which description is incorporated herein by reference.
  • FIG. 2 shows a schematic summary of the possible topologies in which the multiple Trusted Couriers 103 of Multi-Courier Private Messaging System 100 may be arranged relative to one another. This figure depicts four distinct organizational roles a
  • Trusted Courier 103 might play in the network, along with two distinct inter-Courier relationships.
  • the organizational roles represent different sets of constraints on certain significant behaviors, which make each particular role suitable for certain types of organization.
  • the relationships pertain to how these Couriers interact with one another to form networks. Note that these relationships represent meaningful interactions, not direct communication links. All communication takes place via Packet Network 102.
  • Agents 110 are not shown in this diagram, but are instead implied.
  • Each User and Agent is registered with and served by a single Courier.
  • each Trusted Courier 103 forms an island of service, and with respect to the Private
  • Messaging service acts as a gateway for its registered Agents/Users.
  • the relationships among Trusted Couriers 103 represented in FIG. 2 insulates those Agents 110 from one another, particularly with respect to encryption/authentication certificates.
  • each Trusted Courier 103 has exactly one Relationship 201 superior, and may have many Relationship 201 inferiors. No peer Relationships 201 may exist, as there is no meaning within a certification hierarchy for such peering.
  • the Couriers 103 each of which is a Certificate Authority for its Agents 110 and any other Couriers 103 which subtend it, form a conventional Certificate Authority tree via their Relationships 201 with one another.
  • Root Courier 200 At the top of this tree is Root Courier 200, which acts as the root Certificate Authority for the entire network.
  • Conventional Public-Key hifrastructure technologies and techniques, well known to those sldlled in the art, are used to form this tree.
  • the Root Courier 200 role is filled by exactly one Trusted Courier 103 in the network, h the preferred embodiment, this is the Trusted Courier 103 operated by the authors of the present invention, although the business environment will dictate whether this continues to be the case.
  • Public Courier 210 and Private Courier 220 represent Couriers 103 that are operated by different classes of organization, and which have different constraints on their service domain.
  • a Public Courier is permitted to serve any User without constraints, while a Private Courier is constrained to serve only those Users whose addresses fall within the same network namespace as the Private Courier.
  • a Private Courier in a particular Internet Domain Name would only serve Users whose email addresses are also in that same Internet Domain Name.
  • a major ISP or carrier would operate a Public Courier, while an Enterprise or small ISP would operate a Private Courier.
  • Public Courier 210 might be a major ISP serving numerous Users in multiple domains, while Private Couriers 211 and 212, which subtend it in the CA hierarchy, might be particular Enterprises that are customers of that ISP but operate their own Couriers for security reasons.
  • Private Courier 220 might be the first Courier placed in service by a large Enterprise, which later installed Private Couriers 221 and 222 to diversify their traffic.
  • Relationship 201 hierarchy is appropriate for certificate authentication, it is not optimal for traffic flow.
  • Relationships 202 (indicated by non- bold lines in Fig. 2) represent the opportunity for flow of Private/Restricted Messages, Access Restrictions Messages, and other traffic between Couriers 103 so related on behalf of their Agents 110.
  • the Couriers 103 involved have previously exchanged encryption authentication certificates with one another so that information privacy and authenticity are ensured.
  • these certificates are governed by the certificate authenticity hierarchy formed of Relationships 201, so every participating Trusted Courier 103 may be assured of the others by validating the certificates up to the Root Courier 200. This exchange process is called Introduction, and the mechanics of it are depicted in FIG. 8, which will be described below.
  • any Courier 103 may be introduced to any other Courier 103, thus forming a traffic mesh according to the demand of the Agents 110 involved.
  • an optimal network is formed dynamically.
  • a Relationship 202 is automatically formed in parallel with every Relationship 201 as a corollary to the certificate authentication process. Additional Relationships 202 form as demanded by the traffic flow, and may appear anywhere.
  • Gateway Courier 230 may also be either a Private Courier or a Public Courier, as the relevant behavioral characteristics for determining Public vs. Private or Gateway vs. non-Gateway are orthogonal to one another.
  • Registration begins with step 301, in which the registering user receives an
  • Step 302 the user follows this link with a web browser and fills out the resulting form.
  • Step 303 condenses the retrieval and submittal of the form, which appear as steps 503-506 in the foundation disclosure's FIG. 5.
  • Trusted Courier foreground element 120 Upon receipt of the completed form in step 303, Trusted Courier foreground element 120 will at step 304 create the user's account, and at step 305 construct an Agent Installer for the user.
  • the Agent Installer is a software application that will install an Agent 110 in the user's computer or device.
  • the Agent Installer package is downloaded to the user's computer or device in step 306, through the same secure path used by the registration form in step 303.
  • the Agent Installer is executed in the User's computer or device at step 307.
  • the foregoing steps 304-307 correspond exactly to steps 507-510 in the foundation disclosure's FIG. 5.
  • the installer establishes that it has landed in the right place, so its first action at step 308 will be to validate its configuration as described in step 511 of the foundation disclosure's FIG. 5, and prompt the User for a local password as described in step 512 of the foundation disclosure's FIG. 5.
  • the User will create and enter the requested local password at step 309, and the Agent Installer will store it and create the necessary encryption keys at step 310; these steps correspond exactly to steps 513-515 in the foundation disclosure's FIG. 5.
  • the Agent Installer and Trusted Courier foreground element 120 will in steps 311-313 exchange keys with one another and store the results of the exchange, in exactly the manner as described in detail for steps 516-520 of the foundation disclosure's FIG. 5.
  • the foundation procedure concludes with an Agent Alive Indication message being sent by the Agent Installer to Trusted Courier foreground element 120 in steps 314-315, corresponding exactly with final steps 521-522 of the foundation disclosure's FIG. 5.
  • Step 316 shows Trusted Courier foreground element 120 sending a Distribute Account message to Trusted Courier background element 130. This message carries the User's and Agent's addresses, along with encryption keys for both Courier and Agent.
  • the Registration procedure concludes at step 317 with Trusted Courier background element 130 activating its view of the User's account.
  • FIG. 4 depicts an exemplary process of replacing cryptographic keys. Functionally, steps 401-409 correspond exactly to steps 601-609 of the foundation disclosure's FIG. 6, and so are not detailed further.
  • Trusted Courier foreground element 120 drives the Key Replacement process from the perspective of Trusted Courier 103, but Trusted Courier background element 130 participates in two ways.
  • Agent 110 can only receive background messages from Trusted Courier background element 130, the Notice to Rekey and Exchange Keys messages are relayed through it. Therefore steps 402 and 407, respectively, depict these messages going not directly to Agent 110 but to Trusted Courier background element 130, which performs a relay function in steps 402a and 407a. The messages then go to Agent 110 at steps 402b and 407b, respectively.
  • FIG. 5 depicts a Registration Transfer procedure that satisfies these requirements.
  • the process begins with the operator(s) of the two involved Trusted Couriers 103 agreeing at step 501 to perform the transfer of a particular User.
  • This is a business-process step that may or may not involve automation but definitely involves human decisions. As such the details of this part of the procedure will vary among different operators and are not further specified here.
  • this decision step also offers the operator of the old Courier 103 an opportunity to attempt various marketing actions that might retain the customer.
  • step 502 the operator of the Courier 103 that will gain the User, termed here the "new” one, will through an administrative action record the transferring User's messaging address such that "new" Courier foreground element 120 will accept the transfer and execute the automated steps involved.
  • step 503 the operator of the Courier 103 that will lose the User, termed here the "old” one, will through an administrative action initiate the automated portion of the procedure. Note that this implies the "old" Courier 103 and its operator cooperate in the transfer, in fact to the point of actively relinquishing the User. Between this and the continued use of cryptographic authentication throughout the process, slamming is quite impossible.
  • the automatic portion of the Registration Transfer procedure commences then at step 504, wherein the "old" Courier foreground element 120 transmits the User's subscription data and Agent key to "new" Courier foreground element 120 in a Transfer Subscription message.
  • Courier foreground element 120 drives the process, only informing Courier background element 130 after certain key steps.
  • this message is preferably encrypted to protect its sensitive content, as are all others in the system of the present invention and the foundation disclosure.
  • "new" Courier foreground element 120 Upon arrival of the Transfer Subscription message, "new" Courier foreground element 120 at step 505 creates a database entry for the transferring User using the information in the message. At step 506 it creates new keys for itself which are to be used in communicating with the User's Agent 110. At this point "new" Courier background element 130 needs to know about this User, so step 507 conveys the necessary information in a Distribute Account message that is substantially identical to the one in step 316 of FIG. 3. "New" Courier background element 130 records this information in step 507a to activate this User's support there.
  • "new" Courier foreground element 120 informs "old" Courier foreground element 120 of the parameters required for Agent 110 to access the new account by sending a Configuration Update message to "old" Courier foreground element 120 at step 508.
  • These parameters include network names and addresses for the servers that comprise "new" Trusted Courier 103, as well as the messaging addresses and encryption/authentication certificate to be used by Agent 110 when communicating with "new" Courier 103. Because this information goes first to "old" Courier 103 and not directly to Agent 110 from "new” Courier 103, slamming by arbitrary would-be "new” Couriers 103 is prevented.
  • Steps 514- 521 in which Agent 110 and "new" Courier 103 exchange their new keys and record them accordingly, are substantially identical to steps 404-409.
  • the Background Key Replacement that occurs in steps 522 and 522a whereby "new" Courier foreground element 120 informs "new" Courier background element 130 of the completed Key Replacement, is substantially identical to the one in steps 411 and 412.
  • the Distribute Account message in step 525 is semantically identical to message of the same name in step 507, although the specific update to the account data is different in each case.
  • subsequent attempts to send a message to the transferred User or the corresponding Agent 110 via the "old" Courier 103 will therefore be rerouted to the "new" Courier 103.
  • the User and corresponding Agent 110 are safely hosted on "new" Trusted Courier 103 and no longer hosted on "old” Trasted Courier 103.
  • FIG. 6 depicts exemplary processes which are followed to do so when both sender and recipients are served by the same Courier 103.
  • This diagram is derived from FIG. 7 of the foundation disclosure, condensed for brevity where no change has been made and enhanced where necessary to describe what changes in the context of the present invention.
  • step 601 the sending User and Agent 110 will prepare the message, including composing it, marking it as Private or Restricted as appropriate, and commanding that it be sent. Also embodied in this step are the various conversion, encryption, and formatting actions that take place afterward, including construction and storage of the ARM Record. Though combined into a single step here, these items are substantially identical to steps 701-705 of FIG. 7 in the foundation disclosure.
  • Step 602 provides for the construction of an Access Restrictions Message using the same recipient lists as the Private or Restricted message being processed, and containing the corresponding ARM Record. As detailed in the foundation disclosure, it is via this separate message that the ARM Record is conveyed to the recipients of the Private or Restricted message such that end-to-end message privacy is assured, hi step 603, the Access Restrictions Message so composed is signed and encrypted according to the S/MLME email encryption standard (IETF document RFC1847) and sent to Trusted Courier Background 130.
  • S/MLME email encryption standard IETF document RFC1847
  • Step 604 shows the Access Restrictions Message being transported to Courier background element 130 and carrying both the Message Identifier and the Content Encryption Key, which are elements of the ARM Record.
  • Step 605 Upon arrival of the Access Restrictions Message at Courier background element 130, at step 605 it is decrypted and validated.
  • Step 606 and 607 find the appropriate set of keys, use them to create the S/MIME signature and transport encryption for the Access Request Message, and send the signed and encrypted Access Request Message to that recipient.
  • Step 608 depicts this message in transit to the recipient, whose Agent 110 will in step 609 decrypt and validate the Access Restrictions Message, then store the enclosed ARM Record.
  • Step 610 Courier background element 130 will make a copy of the Access Restrictions Message for each recipient that isn't already Registered in the system, creating a new database entry for each one in preparation for their eventual Registration.
  • Step 611 depicts Courier background element 130 quiescing at this point to await notice from Courier foreground element 120 that the Registration has completed; this occurs, as usual, for each of the relevant addresses. Processing will resume at step 628, but first the foreground handling is described. Note that good server hygiene practice will dictate that an implementation audit these outstanding messages and clean up any that have not been released within a reasonable time.
  • the foreground message with the actual encrypted content is wrapped in an S/MIME package (signed and encrypted) in step 612 and sent to the Courier foreground element 120 in step 613.
  • Courier foreground element 120 unwraps the S/MIME package (decrypt and validate) in step 614.
  • This sequence is substantially identical to steps 722-726 in FIG. 7 of the foundation disclosure. Note that the Courier Receipt and corresponding process steps described in the foundation disclosure are implied here, though not shown in FIG. 6 for the sake of brevity.
  • Now Trusted Courier foreground element 120 steps through the list of recipients' addresses in the header, determining which refer to registered users and which are unregistered as did Trusted Courier background element 130 above. For each Registered recipient address, Courier foreground element 120 will retrieve the correct keys in step 615, rewrap the foreground message in an S/MIME package (signed and encrypted) in step 616, and send it to the corresponding Agent 110 in step 617. This sequence is substantially identical to steps 727, 729, and 730 in FIG. 7 of the foundation disclosure.
  • each recipient's Agent 110 will decrypt and validate the S/MIME package in step 618, find in step 619 the ARM Record stored previously at step 609, and use the content encryption key kept there to decrypt and present the message in step 620.
  • This sequence is an abbreviated depiction of the detailed process described in the foundation disclosure. Specifically, steps 615-620 here are meant to be substantially identical to steps 727-738 there.
  • the final steps of Registration include notifications at both Courier foreground element 120 and Courier background element 130. These final steps are used as triggers by which each element detects that Registration is complete.
  • Courier foreground element 120 makes this detection, and so at step 626 it releases the held copy of the foreground message previously stored for the particular recipient whose Registration has just concluded.
  • Courier foreground element 120 returns to step 615 and processes the message for transmission to the recipient.
  • Courier background element 130 detects the completed Registration
  • at step 629 releases the held Access Restrictions Message for that recipient, and at step 630 returns to step 606 to process the background message for transmission to the recipient's Agent 110.
  • FIG. 7 depicts the scenario in which the sender and the recipient are Registered in different Couriers 103, and those Couriers 103 both have been Introduced to one another. Note that Introduction scenarios are depicted in Figures 8 and 9, and will be described later. For now, the inter-Courier routing of messages will be clearer if we start with them already Introduced.
  • Step 701 The message flow begins as usual in step 701 with the preparation of a Private or Restricted message.
  • Steps 701-705 in which the message is created and prepared, and the Access Restrictions Message is sent to Courier background element 130, are substantially identical to steps 601-605 in FIG. 6.
  • Step 706 the process differs because Courier background element 130 detects that the recipient address is served in another Courier 103. This detection can take one of two forms. If the sender's Courier 103 is Private (refer back to FIG. 2), that the recipient's domain is different from the sender's domain will denote that a different Courier 103 serves the recipient.
  • the sender's Courier 103 is Public, it can know a different Courier 103 serves this specific recipient address if a previous Introduction has taken place as described in FIG. 9 for this recipient. Any Courier 103, Public or Private, may also make this detection if the recipient's domain matches that of a Private Courier 103 that is subordinate to the current one according to the certification hierarchy described in
  • the sender's Courier background element 130 Once the sender's Courier background element 130 has determined the recipient's Courier background element 130, it will at step 707 imbed the Access Restrictions Message in an hiter-Courier message addressed to the recipient's Courier background element 130, and rewrap it in an S/MIME package (signed and encrypted) suitable for the destination Courier.
  • the encryption key is found in the certificate provided by the recipient's Courier background element 130 during the aforementioned Introduction, while the signature key is that of the sender's Courier background element 130. Note that, unlike the certificates for Agent 110 communication, which are allocated per Registered address for both Courier and Agent, each Courier 103 Introduces itself to all other Couriers 103 using the same certificate.
  • step 708 the Access Restrictions Message, imbedded in the Inter-Courier message, is transported from the sender's Courier background element 130 to the recipient's Courier background element 103. Upon arrival, at step 709 this message is unwrapped, decrypted, and validated as usual. Steps 710-713, wherein the background message is rewrapped and transported to the recipient Agent 110, and there saved for future use, are substantially identical to steps 606-609 in FIG. 6
  • the foreground processing continues substantially identically to the single-Courier case, with steps 714-716 moving the Private or Restricted message into the sender's Courier foreground element 120.
  • steps 714-716 moving the Private or Restricted message into the sender's Courier foreground element 120.
  • step 717 the same routing decision that is made at step 706 in the sender's Courier background element 130 is made in the sender's Courier foreground element 130. This brings to the fore the point that
  • transport of the foreground message from the sender's Courier foreground element 120 to the recipient's Courier foreground element 120 is substantially identical to transport of the background message between the two Courier background elements 130.
  • Steps 717-720 are thus the same in the two Courier foreground elements 120 as steps 706-709 in the two Courier background elements 130.
  • processing steps 721-726 to move it into Agent 110 and there present it to the User are substantially identical to steps 615- 620 in FIG. 6.
  • FIG. 8 depicts the scenario in which the sender's Trusted Courier 103 is a Private Courier, not permitted to serve Users outside its domain, that has not been Introduced to the recipient's Trusted Courier 103.
  • Steps 801-803 prepare the message and transport the background component
  • steps 815-816 transport the foreground component to the sender's Courier foreground element 120. This sequence is substantially identical to steps 701-705 and
  • the critical decision is made that the recipient's address cannot be served in this Trusted Courier 103, and is not known to be served in any other Trusted Courier 103 that has been Introduced to this one. Since this is a Private Courier, the decision is quite simple: the domain of the recipient's address does not match the domain of the sender's Courier 103, nor does it match the domain of any other Courier 103 to which this one has been Introduced. Therefore, the message is Deferred to the superior Courier 103. Refer to the discussion of the certification hierarchy in the context of FIG. 2 for a definition of the superior for each Trusted Courier 103.
  • Deferral takes the form of wrapping the message at hand in an friter-Courier message, performing the S/MIME signature and encryption using appropriate keys, and sending the package to the appropriate member of the superior Courier 103. Steps 805-806 and 818-819 depict this action. Note that in both foreground and background, the Inter-Courier package carries not only the corresponding message, but in this case it also carries the certificate of the sender's Courier 103 in order to begin the Introduction. As the package is propagated to the proper Courier 103 for the recipient, this certificate will go along and serve to Introduce each member of the recipient's Courier 103 to the corresponding member of the sender's Courier 103.
  • One or more Superior Couriers 103 act upon the message as it is Deferred.
  • the decision is made that this message should be directed to the corresponding member of the recipient's Courier 103. h this scenario that decision is substantially identical to the one made in steps 706 and 717 of FIG. 7.
  • the immediate superior also does not know the recipient Courier 103, and executes another Deferral to its superior. Deferral can continue until the first Public Courier 103 is reached, which may be the Root Courier as described in the context of FIG. 2.
  • FIG. 9 details what happens at that point.
  • steps 808-811 and 821-826 are substantially identical to steps 707-713 and 718-726 of FIG. 7.
  • the members of the recipient's Courier 103 have not yet completed their processing, however. Noting at steps 812 and 827 that an Introduction was carried by the message, the certificate and address from that Introduction are captured in a new database entry for future reference. Subsequent messages addressed to recipients in the domain of the sender's Courier 103 in this scenario will be routed directly to that Courier 103 now that it has Introduced itself. The Introduction is then completed back to the first Courier 103 in order to close the loop. To do so the recipient's Courier background element 130 and Courier foreground element 120 each create an Introduction message and send it to the sender's Courier background element 130 and Courier foreground element 120 respectively in steps 813 and 828.
  • These Introduction messages contain the certificate and address of the recipient's Courier 103. Upon arrival in the sender's Courier 103, these Introduction messages are consumed, and a new database entry is made for the recipient's Courier 103, its address and certificate. Note that no coordination is required between the foreground and background planes, because they are each handled independently of one another, providing the same information without synchronization points in the protocol.
  • FIG. 8 Introduction is driven by Deferral of a message from a Private
  • FIG. 9 depicts what appears to be an ordinary message flow involving a single Trusted Courier 103 and a recipient whose address is unknown there.
  • the processing in this sequence is substantially identical to steps 601-605, 610-614, and 621-623 in FIG. 6, depicted here in a highly condensed fashion.
  • the sender's Courier foreground element 120 includes its Introduction certificate in the message, and signs the entire invitation. This change is actually a benefit even without the multi-Courier network, because it allows invited recipients an opportunity to validate the authenticity of the message. Nevertheless, while it would have been useful before it is critical here in order to trigger Introductions between the members of the sender's and recipient's Couriers 103.
  • the Agent 110 which receives the invitation from the sender's Courier foreground element
  • Agent 110 is implemented in a loosely-coupled fashion as described in the foundation disclosure; even in that case the only action required is to open the message, whereupon the Agent 110 software is called and the process continues.
  • the pending Access Restrictions Message is handled.
  • the sender's Courier background element 130 is holding that message, and awaiting notice from the corresponding Courier foreground element 120 that the addressed recipient has Registered.
  • the forwarded invitation carried by the Introduction message in step 912 is consulted.
  • the original recipient's address is available there, so the sender's Courier background element 130 can correlate the Introduction to the held message.
  • step 914 it stops waiting for a Registration that will not occur, and instead records in the database entry for the recipient address that subsequent messages should be relayed to the just- mtroduced Courier background element 130.
  • the pending Access Restrictions Message is released, to be relayed in the usual S/MIME package to the recipient's Courier background element 130 via the IhterCourier Message in step 915.
  • the processing and signaling in steps 916-918, which move the Access Restrictions Message the rest of the way to its destination, are substantially identical to steps 709- 713 of FIG. 7.
  • the steps taken are substantially identical to those of the previous paragraph, except that the messages flow through and the actions are taken by the respective Courier Foregrounds 120.
  • the invitation Reject message in step 919 is substantially identical to the one in step 910, and the remainder of the Introduction in steps 920-922 is the same as steps 911-913.
  • canceling the Registration and releasing the held message in step 923 is the same as canceling the Registration and releasing the held message in step 914.
  • the inter-Courier message propagation and final delivery shown in steps 924-929 are substantially identical to the same processing and signaling in steps 717-726 in FIG. 7.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Cette invention se rapporte à un système de messagerie privée qui utilise de multiples courriers sécurisés qui sont interopérables tout en étant potentiellement concurrents. Cette invention concerne un procédé et un appareil servant à distribuer un courrier sécurisé, afin que les messages de premier plan et d'arrière-plan soient traités indépendamment par des composants séparés.
PCT/US2004/018404 2003-06-11 2004-06-10 Procede et appareil de messagerie privee entre utilisateurs, pris en charge par des courriers independants et interoperables WO2004111790A2 (fr)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US47773603P 2003-06-11 2003-06-11
US60/477,736 2003-06-11
US10/701,355 US20040148356A1 (en) 2002-11-04 2003-10-04 System and method for private messaging
PCT/US2003/035077 WO2004042534A2 (fr) 2002-11-04 2003-11-04 Systeme et procede de messagerie privee
US10/701,355 2003-11-04
USPCT/US03/35077 2003-11-04
US10/709,952 US7313688B2 (en) 2003-06-11 2004-06-08 Method and apparatus for private messaging among users supported by independent and interoperating couriers
US10/709,952 2004-06-08

Publications (2)

Publication Number Publication Date
WO2004111790A2 true WO2004111790A2 (fr) 2004-12-23
WO2004111790A3 WO2004111790A3 (fr) 2005-06-09

Family

ID=33556565

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2004/018404 WO2004111790A2 (fr) 2003-06-11 2004-06-10 Procede et appareil de messagerie privee entre utilisateurs, pris en charge par des courriers independants et interoperables

Country Status (1)

Country Link
WO (1) WO2004111790A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008065245A1 (fr) * 2006-11-28 2008-06-05 Nokia Corporation Communication de groupe
WO2016082697A1 (fr) * 2014-11-26 2016-06-02 阿里巴巴集团控股有限公司 Procédé et dispositif de messagerie instantanée

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5629982A (en) * 1995-03-21 1997-05-13 Micali; Silvio Simultaneous electronic transactions with visible trusted parties
US6009173A (en) * 1997-01-31 1999-12-28 Motorola, Inc. Encryption and decryption method and apparatus
US6532488B1 (en) * 1999-01-25 2003-03-11 John J. Ciarlante Method and system for hosting applications

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5629982A (en) * 1995-03-21 1997-05-13 Micali; Silvio Simultaneous electronic transactions with visible trusted parties
US6009173A (en) * 1997-01-31 1999-12-28 Motorola, Inc. Encryption and decryption method and apparatus
US6532488B1 (en) * 1999-01-25 2003-03-11 John J. Ciarlante Method and system for hosting applications

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008065245A1 (fr) * 2006-11-28 2008-06-05 Nokia Corporation Communication de groupe
KR101120656B1 (ko) * 2006-11-28 2012-04-18 노키아 코포레이션 그룹 통신
WO2016082697A1 (fr) * 2014-11-26 2016-06-02 阿里巴巴集团控股有限公司 Procédé et dispositif de messagerie instantanée
CN105704002A (zh) * 2014-11-26 2016-06-22 阿里巴巴集团控股有限公司 一种即时通信方法和装置
CN105704002B (zh) * 2014-11-26 2018-11-06 阿里巴巴集团控股有限公司 一种即时通信方法和装置

Also Published As

Publication number Publication date
WO2004111790A3 (fr) 2005-06-09

Similar Documents

Publication Publication Date Title
US10298708B2 (en) Targeted notification of content availability to a mobile device
US8032750B2 (en) Method for establishing a secure e-mail communication channel between a sender and a recipient
US6981139B2 (en) Digital certificate management system, digital certificate management apparatus, digital certificate management method, update procedure determination method and program
US20040230658A1 (en) System and method for message downloading and initializing a collaborative work environment
US20040148356A1 (en) System and method for private messaging
JP4703438B2 (ja) サーバと通信相手が互換性のある安全な電子メールを有することを立証するためのシステムおよび方法
JP2007318809A (ja) モバイルデータ通信デバイスと交換するために暗号化されたメッセージを処理する方法
JP2005517348A (ja) 復号化鍵を引き出すための鍵検索を必要とする安全な電子メッセージングシステム
JP2008533879A (ja) 身元情報とディレクトリ管理とを備える通信方法及びシステム
US7313688B2 (en) Method and apparatus for private messaging among users supported by independent and interoperating couriers
US7260224B1 (en) Automated secure key transfer
US11575767B2 (en) Targeted notification of content availability to a mobile device
US10158610B2 (en) Secure application communication system
JP5336262B2 (ja) ユーザ認証システムおよびユーザ認証方法
KR101642665B1 (ko) 다이렉트 전자 메일
WO2004111790A2 (fr) Procede et appareil de messagerie privee entre utilisateurs, pris en charge par des courriers independants et interoperables
Sparrow et al. LEAP: A next-generation client VPN and encrypted email provider
US20100263019A1 (en) Secure exchange of messages
Dogan Email Authentication Best Practices the Optimal Ways to Deploy SPF, DKIM and DMARC
Boucadair et al. RFC 8921 Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP)
Aslanoglou et al. A Generic Connectivity Service for peer-to-peer applications
Hansen et al. DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
Hansen et al. RFC 5863: DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
Finch Exim configuration at the University of Cambridge

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase