idnits 2.17.1 draft-gennai-appsawg-cem-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 03, 2012) is 4435 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 5750 (Obsoleted by RFC 8550) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft F. Gennai 2 Intended Status: Informational L. Frosini 3 Expires: September 03, 2012 A. Shahin 4 ISTI - CNR 5 C. Petrucci 6 DigitPA 8 March 03, 2012 10 Certified Electronic Mail 11 draft-gennai-appsawg-cem-01 13 Abstract 15 This document specifies the requirements for a Certified Electronic 16 Mail (CEM) system which provides people with proof of communication 17 when exchanging emails, giving strong evidences to the users involved 18 in the interchange. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2 Features and requirements . . . . . . . . . . . . . . . . . . . 4 61 2.1 Required features . . . . . . . . . . . . . . . . . . . . . 4 62 2.2 Desiderata . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.3 Involved parties requirements . . . . . . . . . . . . . . . 5 64 3. The CEM System . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1 General description of the system . . . . . . . . . . . . . 6 66 3.2 Possible scenario . . . . . . . . . . . . . . . . . . . . . 6 67 3.3 Observations . . . . . . . . . . . . . . . . . . . . . . . 7 68 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 69 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 70 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6.1 Normative References . . . . . . . . . . . . . . . . . . . 8 72 6.2 Informative References . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1 Introduction 77 Except in some particular situations, no party involved in a 78 traditional email communication can prove to have sent or received a 79 certain message. The user cannot be sure of obtaining proof of the 80 message exchange in terms of authenticity and integrity. 82 During the past few years, many certified email systems have been 83 theorized, implemented and deployed on the Internet to meet the needs 84 of submission and delivery warranty when sending messages. Some of 85 these were developed by private companies or consortiums, such as 86 PostX, Goodmail, Tumbleweed. Others were designed by European 87 governments, after the European Community created the EU Directives 88 which invite governments to facilitate the provision of services, 89 including reliable and good-quality digital communication [EU99- 90 93][EU06-123][EU08-6]. 92 However, this resulted in each country realizing its own system, in 93 some cases even more than one; some built up on standard email 94 systems (e.g. Italian PEC [RFC6109], German DeMail) with ad-hoc 95 extensions, others developed up on other web technologies (e.g. 96 Austrian DDS, Slovenian Moja.posta.si). Each system currently has 97 different characteristics and offers different guarantees, and is 98 incapable of communicating with others. A very good analysis of these 99 solutions has been made by Arne Tauber [TAUBER]. 101 The increasing need for standardization thus becomes evident. Some 102 standardization authorities are trying to close this loophole. For 103 example, ETSI (European Telecommunications Standards Institute) has 104 defined the REM standard (Registered Electronic Mail), upon which UPU 105 (Universal Postal Union) bases its PReM standard (Postal Registered 106 eMail). The latter seems currently the only way to communicate 107 worldwide in a "certified" way using digital messages. 109 Some private solutions failed because they didn't become a "de facto 110 standard," while governmental solutions are alive thanks to law 111 constraints that require companies to have a certified mailbox, but 112 many of them struggle to take off. The reasons for this could be 113 found in the following: 114 - Providers: lacking of a standard or de facto standard, each 115 company realizes its own solution and tries to penetrate it on the 116 market. 117 - Users: most developed solutions have different paradigms of use 118 compared to what users are used to. 119 - Interoperability: Users are required to have as many accounts as 120 many are the systems required by law and used by their partners. 122 1.1 Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2 Features and requirements 129 Analyzing existing systems and the state of the art, we can summarize 130 the required features of the solution. 132 2.1 Required features 134 Integrity: 135 The message MUST be delivered without modification. 137 Authenticity: 138 The message can only be generated by the person who asserts 139 sending the message. 141 Evidence Generation: 142 The system MUST generate the evidence of the following: 144 End-User <--> Provider 146 - Non-Repudiation: 147 Provides protection against false denial of involvement in 148 an association (especially a communication association that 149 transfers data) [RFC4949]. 151 In particular different kinds of Non-Repudiation can be 152 analyzed: 153 - Non-Repudiation of Origin (NRO) 154 Provides the recipient of data with evidence that proves 155 the origin of the data, and thus protects the recipient 156 against an attempt by the originator to falsely deny 157 sending the data [RFC4949]. 159 - Non-Repudiation of Receipt (NRR) 160 Provides the originator of data with evidence that proves 161 the data was received as addressed, and thus protects the 162 originator against an attempt by the recipient to falsely 163 deny receiving the data [RFC4949]. 165 - Non-Repudiation of Submission (NRS) 166 A protocol provides non-repudiation of submission if and 167 only if it gives evidence against the false denial of 168 having submitted the message. 170 - User Non-Repudiation of Delivery (U-NRD) 171 A protocol provides non-repudiation of delivery if and 172 only if it gives evidence against the false denial of 173 having delivered the message. 175 The system MUST support the possibility to obtain all types 176 of Non-Repudiation (and their negative equivalent) evidence. 177 U-NRD and NRS MUST be always guaranteed to the users in a 178 certified communication, while NRO and NRR can be OPTIONAL 179 depending on users configurations. 181 - Timeout Notification: 182 If the sender does not receive a notification about the 183 success or failure of delivery of his message, the system 184 send to the user a Timeout Notification. 186 Provider <--> Provider 188 - Provider Non-Repudiation of Delivery (P-NRD) 189 A protocol provides provider non-repudiation of delivery if 190 and only if it gives evidence against the false denial of 191 provider of having received the message and taken it in 192 charge. 194 2.2 Desiderata 196 Confidentiality: 197 Ensure that a message is read by the receiver only. The system 198 could use encryption to accomplish this. 200 2.3 Involved parties requirements 202 Users: 203 - Use already known programs and avoid having to learn another 204 method of operating. 205 - Possibility to communicate with Internet standard email users. 206 - Use the same email address (mailbox) for certified and standard 207 use. 209 Providers: 210 - Avoid implementing new solutions from scratch. 211 - Operate with well-known technologies where they have a good 212 know-how background, especially to face deployment and security 213 issues. 214 - Enrich their offers to customers. 216 3. The CEM System 217 3.1 General description of the system 219 The system SHOULD be mainly based on the standard Internet Mail 220 Architecture [RFC5598]. In particular the system SHOULD allow to send 221 certified email using a standard email client. 223 We will use CEM-P to indicate a provider of Certified Mail. 225 A CEM User (CEM-U) who wants to have a CEM Mailbox (CEM-M) MUST 226 register it with one of these providers. 228 The CEM-M can communicate both with other CEM-Ms worldwide and with 229 Internet standard mailboxes. 231 The communication between CEM-Ms MUST guarantee all the required 232 features listed above. 234 The communication between a CEM-M and a standard mailbox can 235 guarantee some of the required features listed above. 237 +------------+ +------------+ 238 | | | | 239 Sender CEM | | CEM | | CEM Receiver 240 +-----+ messages | | messages | | messages +-----+ 241 |CEM-U|<-------->| +-----+ |<-------->| +-----+ |<-------->|CEM-U| 242 +-----+ & | |CEM-M| | & | |CEM-M| | & +-----+ 243 evidences | +-----+ |evidences | +-----+ |evidences 244 | | | | 245 +------------+ +------------+ 246 CEM CEM 247 sender receiver 248 provider provider 250 3.2 Possible scenario 252 A user creates and sends a message with his email client using the 253 SMTP server of the CEM-P with which he has registered his CEM-M. 255 The CEM-P MUST use a secure way to authenticate the author of the 256 message. The author can sign the message personally with his own 257 certificate (which MUST be compliant with S/MIME [RFC1847] [RFC5750] 258 [RFC5751]) to generate the NRO evidence. If he doesn't do so, the 259 CEM-P can do it on his behalf, depending on account configuration. 261 Once received, the sending CEM-P makes some checks on the message. If 262 one of them fails, the system MUST reject the message and inform the 263 sender about the reason of rejection. Otherwise, it will try to 264 forward the message to the final destination's CEM-P. In this case, 265 the sending CEM-P releases an NRS evidence to the user. 267 If the final destination is a CEM-M, the message will be sent to the 268 receiver's CEM-P. After some checks to validate the CEM message, the 269 receiving CEM-P releases a P-NRD evidence to the sending CEM-P, 270 giving proof of the integrity of what it has received. If the checks 271 fail, a negative P-NRD evidence is released. 273 The receiving CEM-P tries to deposit the message into the addressee's 274 CEM-M. If this task is accomplished successfully, the receiving CEM-P 275 releases an U-NRD evidence. Otherwise, a negative U-NRD evidence is 276 released. 278 The sending CEM-P monitors the transaction for the receipt of P-NRD 279 and/or an U-NRD evidence (or their negative equivalents). If they're 280 not received, the sending CEM-P releases a Timeout evidence. 282 If the sender requests an NRR evidence, the receiver MUST be able to 283 provide it. The receiver SHOULD be able to provide this kind of 284 evidence even if the sender doesn't request it explicitly. 286 3.3 Observations 288 Analyzing the state of the art, it seems that most the necessary 289 technologies are already available and standardized. 291 Evidences in the CEM scenario could be generated by extending 292 Delivery Status Notifications (DSNs) [RFC3461][RFC3464] and Message 293 Disposition Notifications (MDNs) [RFC3798]. 295 The registration of new MIME types and new mail header fields seems 296 to be a good approach to define email messages in such a system. 298 Both these techniques should be done in a way that maintains backward 299 compatibility with older versions of email clients and supports 300 interoperability with Internet standard mailboxes. 302 As further step investigating if DKIM technologies [RFC5617][RFC6376] 303 could be useful for Non-Repudiation needs. 305 4 Security Considerations 307 No security considerations at the moment. 309 5 IANA Considerations 311 No IANA considerations at the moment. 313 6 References 315 6.1 Normative References 317 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 318 "Security Multiparts for MIME: Multipart/Signed and 319 Multipart/Encrypted", RFC 1847, October 1995. 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 325 Extension for Delivery Status Notifications (DSNs)", 326 RFC 3461, January 2003. 328 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 329 for Delivery Status Notifications", RFC 3464, January 330 2003. 332 [RFC3798] Hansen, T., Ed., and G. Vaudreuil, Ed., "Message 333 Disposition Notification", RFC 3798, May 2004. 335 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 336 36, RFC 4949, August 2007. 338 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 339 2009. 341 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, 342 "DomainKeys Identified Mail (DKIM) Author Domain Signing 343 Practices (ADSP)", RFC 5617, August 2009. 345 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 346 Mail Extensions (S/MIME) Version 3.2 Certificate 347 Handling", RFC 5750, January 2010. 349 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 350 Mail Extensions (S/MIME) Version 3.2 Message 351 Specification", RFC 5751, January 2010. 353 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 354 "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, 355 September 2011. 357 6.2 Informative References 359 [RFC6109] Petrucci, C., Gennai, F., Shahin, A., and A. Vinciarelli, 360 "La Posta Elettronica Certificata - Italian Certified 361 Electronic Mail", RFC 6109, April 2011. 363 [EU99-93] European Union, 1999, Directive 1999/93/EC of the European 364 Parliament and of the Council on a community framework for 365 electronic signatures. 367 [EU06-123] European Union, 2006, Directive 2006/123/EC of the 368 European Parliament and of the Council on services in the 369 internal market. 371 [EU08-6] European Union, 2008, Directive 2008/6/EC of the European 372 Parliament and of the Council of February 2008 amending 373 Directive 97/67/EC with regard to the full accomplishment 374 of the internal market of Community postal services 376 [TAUBER] Arne Tauber, "A survey of certified mail systems provided 377 on the Internet," Computers & Security, vol. 30, no. 6-7, 378 pp. 464-485, September-October 2011. 380 Authors' Addresses 381 Francesco Gennai 382 ISTI-CNR 383 Via Moruzzi, 1 384 56126 Pisa 385 Italy 387 Email: francesco.gennai@isti.cnr.it 389 Luca Frosini 390 ISTI-CNR 391 Via Moruzzi, 1 392 56126 Pisa 393 Italy 395 Email: luca.frosini@isti.cnr.it 397 Alba Shahin 398 ISTI-CNR 399 Via Moruzzi, 1 400 56126 Pisa 401 Italy 403 Email: alba.shahin@isti.cnr.it 405 Claudio Petrucci 406 DigitPA 407 Viale Marx 31/49 408 00137 Roma 409 Italy 411 Email: petrucci@digitpa.gov.it