24 Jun 2012

RPost Registered Email Services Meet the ETSI Registered Electronic Mail Standard

This posting may serve as a useful reference to RPost Registered Email services compliance with the European Telecommunications Standards Institute (ETSI) Technical Specification (TS) produced by ETSI Technical Committee Electronic Signatures and Infrastructures (ESI) on the multi-part standards documentation covering Registered Electronic Mail (REM); Architecture, Formats, Policies and Profiles. ETSI claims to be officially recognized by the European Union as a European Standards Organization. ETSI is a not-for-profit organization with more than 700 ETSI member organizations drawn from 62 countries across 5 continents world-wide.

While RPost has undergone an evaluation to certify compliance with each required part of this ETSI Registered Electronic Mail standard, this paper is not intended to map each element of the ETSI standard to RPost architecture, formats, policies and profiles directly. Rather, this paper is intended to provide a guide to users on which RPost service features they may wish to enable that would be most relevant to elements of this standard.

The ETSI documents reviewed as part of the evaluation, in addition to RPost service and system documents included: ETSI TS 102 640-1 V2.1.1 (2010-01) Part 1: “Architecture”; ETSI TS 102 640-2 V2.1.1 (2010-01) Part 2: “Data requirements, Formats and Signatures for REM”; ETSI TS 102 640-3 V2.1.1 (2010-01) Part 3: “Information Security Policy Requirements for REM Management Domains”; ETSI TS 102 640-4 V2.1.1 (2010-01) Part 4: “REM-MD Conformance Profiles”; and ETSI TS 102 640-5 V2.1.1 (2010-01) Part 5: “REM-MD Interoperability Profiles”.

The purpose of the ETSI Registered Electronic Mail Technical Specification is to identify a consistent form of evidence for email across Europe.

For those interested in using RPost services in a manner compliant with the ETSI Registered Electronic Mail standard, we specify in this document RPost features and settings that one should consider using. RPost believes some of the important elements of this ETSI Registered Electronic Mail standard referenced above fall within the categories below. RPost believes the RPost Registered Email® service, with specified features and settings referenced in this document, satisfies the requirements specified in the following categories.

A. Uniform time records of transmission, which includes
1. Sending
2. Delivery
3. Receipt

B. Non-repudiation and proof, which includes
1. Authentication for sender of time records of transmission with associated message content including attachments.
2. Authentication for recipient of time records of sending with associated message content including attachments.
3. Certificate based digital signatures on timestamps and authentication for sender and recipient.

C. Identity, which includes
1. Sender
2. Recipient

D. Secure Transmission

F. Message Store and Evidence Record

G. Interoperability

While RPost has operated its services under its tradename “Registered Email” and various iterations in different languages since 2000, RPost operates an electronic service, not to be compared or confused with paper-based postal service offered registered mail or registered post services. ETSI’s intent by issuing its ETSI Registered Electronic Mail standard is to provide users with a service that would directly correlate to paper-based postal service offering registered mail or registered post services. Using the RPost settings noted in this paper may provide an implementation of RPost services that meet this ETSI standard and the intent of ETSI, but each user may have specific situations and users should consult their lawyers or other experts for legal opinions or guidance specific to their needs or situation.

A. Uniform time records of transmission.
RPost defines transmission as the process of sending and receiving. Within sending and receiving, RPost notes two steps: the fact of sending, defined as message induction into the RPost system for processing, and the fact of delivery, defined as acceptance of the message by the recipient or recipient system of record (mail server, mail box, or designated as opened). Some make distinction between fact of delivery and fact of receipt, and in this case, with fact of receipt it is message received at the recipient mail box or opened.

Within the RPost service, the records of sending, delivery, and receipt are indicated in the following RPost services:

1. Sending:
a. RPost Acknowledgement Receipt email returned within 1 minute of sending/induction for processing by RPost.
b. RPost Registered Receipt email returned within 2 hours of sending/induction for processing by RPost. The RPost Registered Receipt email includes a verifiable record for proof of uniform time (UTC) of sending.

2. Delivery:
a. RPost Registered Receipt email includes a verifiable record for proof of uniform time (UTC) of delivery (to the mail server, mail box, delivered and opened, or delivery failure).
b. RPost Open Receipt email, returned upon opening of email or within 30 days of sending when opening can be detected, also provides a verifiable record for proof of uniform time (UTC) of delivery (delivered and opened).

3. Receipt:
a. RPost Registered Receipt email includes a verifiable record for proof of uniform time (UTC) of receipt (delivered to mail box, delivered and opened) when this can be determined within 2 hours of sending/induction for processing by RPost. The data within the receipt is also embedded in an attached XML file.
b. RPost Open Receipt email, returned upon opening of email or within 30 days of sending when opening can be detected, also provides a verifiable record for proof of uniform time (UTC) of delivery (delivered and opened).

B. Non-repudiation and proof:
From a mediator, arbitrator, or judicial officer perspective, one looks at the evidentiary value of what is submitted — how much they can trust the information. Evidential weight is about reducing uncertainty surrounding the evidence. The party with the greater evidential weight will win in most cases, or at least mitigate its liability. The RPost Registered Email service records put the holder of RPost receipts in a position of advantage, as the evidential weight of their Registered Email service records will be in most cases stronger than the evidential weight of standard email, prints of email or attachments, or records of what may have been claimed to have been sent or received, submitted by the other party.

1. Authentication for sender of time records of transmission with associated message content including attachments:

The RPost Registered Receipt email returned to the sender provides a record that can be authenticated using cryptographic techniques and certificate based digital signatures, for proof of uniform time stamp (UTC) of sending, delivery, and receipt, with associated message body text and attachment content. This receipt also includes an XML file with receipt data.

2. Authentication for recipient of time records of sending with associated message content including attachments:

The RPost Digital Seal HTML file attachment to received email messages provides the recipient a means to authenticate using cryptographic techniques, the uniform time stamp (UTC) of sending, with associated message body text and attachment content.

3. Public Key Infrastructure Certificate based digital signatures on timestamps and authentication for sender and recipient:

The Registered Receipt email record uses PKI certificate based cryptographic techniques to secure and authenticate the integrity of their associated information. RPost provides a simple verification process. In some jurisdiction, RPost also includes a PKI digitally signed timestamp with the time sourced from a government official time source.

The Digital Seal HTML attachment uses cryptographic techniques to authenticate the integrity of its associated information. With the Digital Seal® service, RPost also PKI digitally signs and timestamps each PDF attachment and RPost converts each attachment to PDF format, with the attachment including a scripted handwritten signature of the sender if the sender desires.

C. Identity:
RPost offers standard levels of identity as well as higher levels.

1. Sender: The recipient can verify the sender’s identity to at least the sender’s verified email account as an authorized RPost sender, and the sender can optionally add their handwritten time-stamped scripted signature to their verification, or can additionally authenticate personal information with RPost or RPost partners.

2. Recipient: The sender can verify the recipient identity to at least the recipient provided email account listed within the Internet mail exchange records. The sender should maintain a separate record that the recipient has authorized contact at the designated email address (i.e. exchange of business cards in person, contact name listed in purchase agreement or other contact, or other methods), or use additional recipient identity services provided by RPost or others to provide the desired level of assurance of identity of the recipient associated with the receiver email account. RPost does provide options for recipients to enter a PIN, designated password, retrieve a password, or answer a series of questions to further authenticate the recipient.

D. Secure Transmission:
With regards to RPost’s email encryption service, RPost provides for a variety of methods for recipients of messages to decrypt them, with personalized or pre-arranged passwords or codes. For example, RPost uses combinations of SHA-1 and 3-DES and PKI cryptographic methods for verification of authenticity and integrity of data (content, timestamps, signoff indications, audit trails, etc.). RPost provides the sender options to use PKI, TLS, or PDF 128-bit, AES 256-bit and SSL and/or combinations of, for recipient identity verification and transmission content privacy. These methods provide for desktop-to-desktop encryption.

F. Message Store and Evidence Record:
The RPost Registered Receipt and Digital Seal evidence records are themselves self-contained message stores returned to the sender and receiver. RPost by default stores no record, but from these evidence records, RPost can re-construct the authenticated original message content and message metadata, should the record be returned to RPost. RPost and RPost partners do offer separate services to store copies of these evidence records for those that choose to have third-party storage.

G. Interoperability:
RPost Registered Email messages transport over SMTP or other standard protocols for electronic mail delivery, to the message recipient. Therefore, the RPost services are interoperable with any recipient mail system configured to receive Internet email. RPost Registered Receipt emails contain an attached XML file that includes all of the evidence records in a standard XML schema.

In summary, users who wish to comply with the ETSI Registered Electronic Mail standard should use the RPost service with at least the following features turned on:

a. Registered Email message marked or unmarked with Registered Receipt

b. Digital Seal service option

c. Encryption option with or without preferred TLS setting enabled

d. Either maintain a record that the recipient has authorized contact at the designated email address (i.e. exchange of business cards in person, contact name listed in purchase agreement or other contact, or other methods), or use additional recipient identity services provided by RPost or others to provide the desired level of assurance of identity of the recipient associated with the receiver email account.

Contact RPost for options to use RPost service with higher levels of identity or security.

…………………………………………………………………………………………………………………………..

Suggested RPost Resources:

– Comprehensive, Technical and Legal Review by Locke Lord Bissell & Liddell)

– Europe Focused Technical and Court Admissibility Review with Reference to British Standards Institute Code of Practice

– Legal Opinion – Europe and others

Technical Definitions of Registered Receipt™ Email: The Registered Receipt email is the resulting evidentiary record returned to the sender when the sender sends a Registered Email message. It includes the underlying Internet forensics (server-level delivery audit trail, IP addresses, official uniform times), and uses mathematical methods and cryptography to associate the message content and attachments (back and forth) with the Internet forensics. This provides non-repudiation of delivery and non-repudiation of replies or signatures depending on the service selected. The Registered Receipt, at any time, can be independently (third-party) authenticated and if validated, will reconstruct the electronic originals – original message text, attachments, and Internet forensic records all in native format. This record is portable so that, in a dispute resolution situation, the Receipt can be forwarded by email to any opposing party, counsel, arbitrator, mediator or judicial officer, and that party can, independent of any cooperation or complexity, simply forward the Receipt to the Registered Email service verification email address to have the Receipt authenticated with original content returned to the party requesting authentication. RPost can accomplish this authentication and reconstruction of the original WITHOUT storing any content as RPost attaches to the Registered Receipt email a data package that contains an encoded record of the original content, signed contracts, time stamps, hashes, audit trails, etc. The data record is therefore stored by the sender embedded in the Registered Receipt email returned to the sender. Legal opinions describe this Registered Receipt email as providing the sender with delivery proof, content proof, and an official time stamp; packaged as court admissible evidence, providing the functional equivalence to records returned through certified mail, registered mail, return receipt mail, private express mail services, fax logs and similar types of paper mail services; and provides a true electronic original of the message content, message attachments and transmission meta-data including the delivery audit trail. The form in which RPost packages this Registered Receipt email is such that the RPost system does not store any information (yet the Receipt can re-construct the electronic original content when authenticated). RPost is Safe Harbor Certified.

The referenced RPost certification of compliance with this ETSI standard has been conducted by RPost within the guidelines of The Cloud Industry Forum (http://www.cloudindustryforum.org/), which promotes a self-certification process. The referenced RPost certification of compliance is a self-certification.

RPost technology has been granted more than 35 patents in more than 20 countries.

RPost makes third party legal analyses available on its website for information purposes, but neither provides neither legal opinions nor legal guidance, and this information should not be considered a legal opinion or legal guidance from RPost. RPost uses the trademark “Legal Proof” and various iterations in different languages since the early 2000’s. Use of the word “Legal” within this trademark should not be interpreted as providing legal opinions or legal guidance as to the legal nature of RPost services. RPost recommends users consult their own lawyers or other experts for legal opinions or guidance specific to their needs or situation.

“RPost”, “Registered Email” and “Legal Proof” are registered trademarks in the United States and unregistered trademarks in other countries.