Implementation Options with RPost Encryption – TLS, PKI, 128-bit PDF?

SENDER    ------ Path A ----->   SERVICE PROVIDER (RPOST)  ----- Path B ----->   RECIPIENT

With RPost service, the sender can opt to send encrypted messages by Message-Level Encryption, Transport Layer Encryption, or a combination. As such, there are four scenarios for encrypted transmission.  In all cases, the encrypted message is delivered direct to the recipient’s desktop; RPost never requires the recipient to visit a website to collect their email.

Encrypted Data Flow

Path A

Path B

Desktop-to-Desktop

Message-Level Encryption

Message-Level Encryption

Desktop-to-Server

Message-Level Encryption

Transport Layer Encryption

Server-to-Desktop

Transport Layer Encryption

Message-Level Encryption

Server-to-Server

Transport Layer Encryption

Transport Layer Encryption


OPTIONS FOR PATH A: SENDER TO PROVIDER

A sender using RPost’s Outlook plug-in has two administrative settings that we will discuss here.  Once set by the sender or sender IT department, they are transparent from a user perspective. When sending Registered Email messages with the encryption option selected, the message will either:

1. Message Level Encrypt. This is done locally at sender’s desktop (invisible to sender) using an embedded RPost digital certificate for PKI encryption. The sender does not need their own digital certificate.

2. Transport Layer Encrypt. This is done by transmitting, relying on TLS transmission encryption. Here, the sender would need assurance that they were transmitting to RPost using TLS encryption.

OPTIONS FOR PATH B: SENDER TO PROVIDER
RPost will deliver the sender’s message encrypted, using one of the following techniques as selected by the sender in their administrative settings:

1. Message Level Encrypt. This is done using 128-bit PDF encryption salted with a unique decryption code. The email body text is converted to PDF and encrypted with the attachments embedded in the PDF in their native format.  The receiver receives a Registered Email message with the encrypted message attached in PDF format.

2. Transport Layer Encrypt. If the sender has selected this option, RPost tests to determine if the receiver server supports and will accept at that moment a secure connection for TLS encrypted transmission. If it can, RPost delivers the message via the encrypted connection to the recipient server and the message displays in the recipient’s inbox in a standard email message form with markings on it so the sender knows that it had been transmitted encrypted and contains sensitive or protected information.

C. AUDITABLE PROOF OF ENCRYPTED DELIVERY

It is important to note that with all options, the sender does receive verifiable and auditable proof of compliance with regulated (HIPAA, FSA, GLB, FDCPA, etc.) encrypted delivery requirements – a patented capability unique to RPost service. These options discussed can be sent by individual senders or sender’s IT departments, in most cases.

Consider the Council of Insurance Agents and Brokers (CIAB) top level evaluation criteria in their recommendations.

When considering data breach, we are considering two points, a data breach when the data is (a) within the sender’s control (i.e. where the email is sent from sender to recipient - “security of sender-controlled data”); and (b) after the data leaves the sender’s control (i.e. if there is a data breach on the recipient’s system or after the recipient forwards the information on to others - “downstream data breach”).

In reference to protection from downstream data breach, CIAB cites as the most important criteria, as having “Auditable proof of compliance”.

CIAB goes on to state, “It seems that only RPost has a robust mechanism in place to provide an auditable record of precisely what message content (body text and attachments) was in fact sent and received in an encrypted manner to each intended recipient.  This is important because, in the case where there is a data breach after the email has reached the recipient (in the recipient’s environment, or after they have passed the information along to others), the sender will need to retain information to prove that the breach did not happen “on their watch” – that they in fact complied with the data security requirements and delivered the information in a compliant, encrypted manner. 

RPost addresses this issue by having built its encrypted email service on top of its core Registered Email® service, which The Council endorsed in 2004 as the best way to prove email content, time, and delivery with court-admissible records.  By doing this, RPost provides not only effective encryption, but also the most robust proof and record of compliance with the rules of regulators.

For information on how to set or change your settings, you may contact RPost at This e-mail address is being protected from spambots. You need JavaScript enabled to view it .