Internet DRAFT - draft-gennai-appsawg-cem
draft-gennai-appsawg-cem
Internet-Draft F. Gennai
Intended Status: Informational L. Frosini
Expires: September 03, 2012 A. Shahin
ISTI - CNR
C. Petrucci
DigitPA
March 03, 2012
Certified Electronic Mail
draft-gennai-appsawg-cem-01
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.
[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]
