Internet-Draft F. Gennai Intended Status: Standards Track L. Frosini Expires: August 27, 2012 A. Shahin ISTI - CNR C. Petrucci DigitPA February 24, 2012 Certified Electronic Mail draft-gennai-appsawg-cem-00 Abstract This document specifies the requirements for a Certified Electronic Mail (CEM) system which provides people with proof of communication when exchanging emails, giving strong evidences to the users involved in the interchange. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. F. Gennai Expires August 27, 2012 [Page 1] Internet-Draft Certified Electronic Mail February 24, 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Features and requirements . . . . . . . . . . . . . . . . . . . 4 2.1 Required features . . . . . . . . . . . . . . . . . . . . . 4 2.2 Desiderata . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Involved parties requirements . . . . . . . . . . . . . . . 5 3. The CEM System . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 General description of the system . . . . . . . . . . . . . 6 3.2 Possible scenario . . . . . . . . . . . . . . . . . . . . . 6 3.3 Observations . . . . . . . . . . . . . . . . . . . . . . . 7 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1 Normative References . . . . . . . . . . . . . . . . . . . 8 6.2 Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 F. Gennai Expires August 27, 2012 [Page 2] Internet-Draft Certified Electronic Mail February 24, 2012 1 Introduction Except in some particular situations, no party involved in a traditional email communication can prove to have sent or received a certain message. The user cannot be sure of obtaining proof of the message exchange in terms of authenticity and integrity. During the past few years, many certified email systems have been theorized, implemented and deployed on the Internet to meet the needs of submission and delivery warranty when sending messages. Some of these were developed by private companies or consortiums, such as PostX, Goodmail, Tumbleweed. Others were designed by European governments, after the European Community created the EU Directives which invite governments to facilitate the provision of services, including reliable and good-quality digital communication [EU99- 93][EU06-123][EU08-6]. However, this resulted in each country realizing its own system, in some cases even more than one; some built up on standard email systems (e.g. Italian PEC [RFC6109], German DeMail) with ad-hoc extensions, others developed up on other web technologies (e.g. Austrian DDS, Slovenian Moja.posta.si). Each system currently has different characteristics and offers different guarantees, and is incapable of communicating with others. A very good analysis of these solutions has been made by Arne Tauber [TAUBER]. The increasing need for standardization thus becomes evident. Some standardization authorities are trying to close this loophole. For example, ETSI (European Telecommunications Standards Institute) has defined the REM standard (Registered Electronic Mail), upon which UPU (Universal Postal Union) bases its PReM standard (Postal Registered eMail). The latter seems currently the only way to communicate worldwide in a "certified" way using digital messages. Some private solutions failed because they didn't become a "de facto standard," while governmental solutions are alive thanks to law constraints that require companies to have a certified mailbox, but many of them struggle to take off. The reasons for this could be found in the following: - Providers: lacking of a standard or de facto standard, each company realizes its own solution and tries to penetrate it on the market. - Users: most developed solutions have different paradigms of use compared to what users are used to. - Interoperability: Users are required to have as many accounts as many are the systems required by law and used by their partners. 1.1 Terminology F. Gennai Expires August 27, 2012 [Page 3] Internet-Draft Certified Electronic Mail February 24, 2012 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2 Features and requirements Analyzing existing systems and the state of the art, we can summarize the required features of the solution. 2.1 Required features Integrity: The message MUST be delivered without modification. Authenticity: The message can only be generated by the person who asserts sending the message. Evidence Generation: The system MUST generate the evidence of the following: End-User <--> Provider - Non-Repudiation: Provides protection against false denial of involvement in an association (especially a communication association that transfers data) [RFC4949]. In particular different kinds of Non-Repudiation can be analyzed: - Non-Repudiation of Origin (NRO) Provides the recipient of data with evidence that proves the origin of the data, and thus protects the recipient against an attempt by the originator to falsely deny sending the data [RFC4949]. - Non-Repudiation of Receipt (NRR) Provides the originator of data with evidence that proves the data was received as addressed, and thus protects the originator against an attempt by the recipient to falsely deny receiving the data [RFC4949]. - Non-Repudiation of Submission (NRS) A protocol provides non-repudiation of submission if and only if it gives evidence against the false denial of having submitted the message. F. Gennai Expires August 27, 2012 [Page 4] Internet-Draft Certified Electronic Mail February 24, 2012 - User Non-Repudiation of Delivery (U-NRD) A protocol provides non-repudiation of delivery if and only if it gives evidence against the false denial of having delivered the message. The system MUST support the possibility to obtain all types of Non-Repudiation (and their negative equivalent) evidence. U-NRD and NRS MUST be always guaranteed to the users in a certified communication, while NRO and NRR can be OPTIONAL depending on users configurations. - Timeout Notification: If the sender does not receive a notification about the success or failure of delivery of his message, the system send to the user a Timeout Notification. Provider <--> Provider - Provider Non-Repudiation of Delivery (P-NRD) A protocol provides provider non-repudiation of delivery if and only if it gives evidence against the false denial of provider of having received the message and taken it in charge. 2.2 Desiderata Confidentiality: Ensure that a message is read by the receiver only. The system could use encryption to accomplish this. 2.3 Involved parties requirements Users: - Use already known programs and avoid having to learn another method of operating. - Possibility to communicate with Internet standard email users. - Use the same email address (mailbox) for certified and standard use. Providers: - Avoid implementing new solutions from scratch. - Operate with well-known technologies where they have a good know-how background, especially to face deployment and security issues. - Enrich their offers to customers. 3. The CEM System F. Gennai Expires August 27, 2012 [Page 5] Internet-Draft Certified Electronic Mail February 24, 2012 3.1 General description of the system The system SHOULD be mainly based on the standard Internet Mail Architecture [RFC5598]. In particular the system SHOULD allow to send certified email using a standard email client. We will use CEM-P to indicate a provider of Certified Mail. A CEM User (CEM-U) who wants to have a CEM Mailbox (CEM-M) MUST register it with one of these providers. The CEM-M can communicate both with other CEM-Ms worldwide and with Internet standard mailboxes. The communication between CEM-Ms MUST guarantee all the required features listed above. The communication between a CEM-M and a standard mailbox can guarantee some of the required features listed above. +------------+ +------------+ | | | | Sender CEM | | CEM | | CEM Receiver +-----+ messages | | messages | | messages +-----+ |CEM-U|<-------->| +-----+ |<-------->| +-----+ |<-------->|CEM-U| +-----+ & | |CEM-M| | & | |CEM-M| | & +-----+ evidences | +-----+ |evidences | +-----+ |evidences | | | | +------------+ +------------+ CEM CEM sender receiver provider provider 3.2 Possible scenario A user creates and sends a message with his email client using the SMTP server of the CEM-P with which he has registered his CEM-M. The CEM-P MUST use a secure way to authenticate the author of the message. The author can sign the message personally with his own certificate (which MUST be compliant with S/MIME [RFC1847] [RFC5750] [RFC5751]) to generate the NRO evidence. If he doesn't do so, the CEM-P can do it on his behalf, depending on account configuration. Once received, the sending CEM-P makes some checks on the message. If one of them fails, the system MUST reject the message and inform the sender about the reason of rejection. Otherwise, it will try to F. Gennai Expires August 27, 2012 [Page 6] Internet-Draft Certified Electronic Mail February 24, 2012 forward the message to the final destination's CEM-P. In this case, the sending CEM-P releases an NRS evidence to the user. If the final destination is a CEM-M, the message will be sent to the receiver's CEM-P. After some checks to validate the CEM message, the receiving CEM-P releases a P-NRD evidence to the sending CEM-P, giving proof of the integrity of what it has received. If the checks fail, a negative P-NRD evidence is released. The receiving CEM-P tries to deposit the message into the addressee's CEM-M. If this task is accomplished successfully, the receiving CEM-P releases an U-NRD evidence. Otherwise, a negative U-NRD evidence is released. The sending CEM-P monitors the transaction for the receipt of P-NRD and/or an U-NRD evidence (or their negative equivalents). If they're not received, the sending CEM-P releases a Timeout evidence. If the sender requests an NRR evidence, the receiver MUST be able to provide it. The receiver SHOULD be able to provide this kind of evidence even if the sender doesn't request it explicitly. 3.3 Observations Analyzing the state of the art, it seems that most the necessary technologies are already available and standardized. Evidences in the CEM scenario could be generated by extending Delivery Status Notifications (DSNs) [RFC3461][RFC3464] and Message Disposition Notifications (MDNs) [RFC3798]. The registration of new MIME types and new mail header fields seems to be a good approach to define email messages in such a system. Both these techniques should be done in a way that maintains backward compatibility with older versions of email clients and supports interoperability with Internet standard mailboxes. As further step investigating if DKIM technologies [RFC5617][RFC6376] could be useful for Non-Repudiation needs. F. Gennai Expires August 27, 2012 [Page 7] Internet-Draft Certified Electronic Mail February 24, 2012 4 Security Considerations No security considerations at the moment. 5 IANA Considerations No IANA considerations at the moment. 6 References 6.1 Normative References [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [RFC3798] Hansen, T., Ed., and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, May 2004. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009. F. Gennai Expires August 27, 2012 [Page 8] Internet-Draft Certified Electronic Mail February 24, 2012 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011. 6.2 Informative References [RFC6109] Petrucci, C., Gennai, F., Shahin, A., and A. Vinciarelli, "La Posta Elettronica Certificata - Italian Certified Electronic Mail", RFC 6109, April 2011. [EU99-93] European Union, 1999, Directive 1999/93/EC of the European Parliament and of the Council on a community framework for electronic signatures. [EU06-123] European Union, 2006, Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market. [EU08-6] European Union, 2008, Directive 2008/6/EC of the European Parliament and of the Council of February 2008 amending Directive 97/67/EC with regard to the full accomplishment of the internal market of Community postal services [TAUBER] Arne Tauber, "A survey of certified mail systems provided on the Internet," Computers & Security, vol. 30, no. 6-7, pp. 464-485, September-October 2011. Authors' Addresses F. Gennai Expires August 27, 2012 [Page 9] Internet-Draft Certified Electronic Mail February 24, 2012 Francesco Gennai ISTI-CNR Via Moruzzi, 1 56126 Pisa Italy Email: francesco.gennai@isti.cnr.it Luca Frosini ISTI-CNR Via Moruzzi, 1 56126 Pisa Italy Email: luca.frosini@isti.cnr.it Alba Shahin ISTI-CNR Via Moruzzi, 1 56126 Pisa Italy Email: alba.shahin@isti.cnr.it Claudio Petrucci DigitPA Viale Marx 31/49 00137 Roma Italy Email: petrucci@digitpa.gov.it F. Gennai Expires August 27, 2012 [Page 10]