The IESG has approved the following document: - 'Certified Electronic Mail' <draft-gennai-smime-cnipa-pec-08.txt> as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-gennai-smime-cnipa-pec/ Technical Summary Posta Elettronica Certificata (PEC) defines an official electronic delivery service analogous to the postal service's registered mail with return receipt. Originators use an unaltered User Agent (UA) to submit emails to a PEC provider who performs checks (e.g., formatting, virus) on the message and then returns an acceptance receipt to the originator. After returning the acceptance receipt the PEC provider, the PEC provider generates the signed "transport message" that includes the original message and certification data (e.g., date and time of dispatch, sender email address, recipient(s) email address(es), subject, and message ID) and sends it to the recipient's PEC provider. Upon receipt of the transport message, the recipient's PEC provider returns a signed take charge receipt, which also includes certification data, to the originator's PEC provider indicating that the recipient's PEC provider has agreed to deliver the message. The recipient's PEC provider then delivers the message to the recipients mailbox. After successful delivery, the recipient's PEC provider returns a signed delivery notification to the originator. Both terse and verbose responses are supported as well as error conditions. The above system also relies on an PEC Direcotry (LDAP-based) to store certificates and CRLs, which are checked during signature verifications by the originator and recipient PEC providers. Working Group Summary The PEC concept was pitched to the SMIME WG at IETF 71. Numerous questions were asked and answered to the satisfaction of the WG. The WG did not adopt the PEC ID as a WG item not due to lack of interest, but due to lack of man power (SMIME is not very active at this point). The WG did agree to discuss it on the mailing list. Reviews, comments, and revisions were posted on the mailing list. Document Quality This document has already been implemented by the following vendors: Tmail, OpenPec, In Rete PEC, Microsoft, Critical Path, Babel, InnovaPuglia, and Infocert. In addition, the vendors undergo interoperability testing amongst each other to ensure they have properly implemented PEC. Note that the SMTP header fields use Italian as opposed to English. The Shepherd assumed that this was acceptable from a standardization perspective. An Italian-to-English translation is provided in an Appendix. Personnel Sean Turner is the document Shepherd. Tim Polk is the sponsoring AD. RFC Editor Note Please insert the following text at the end of the Introduction (section 1.): Since this specification describes existing deployment and implementation, some issues identified by the community were determined to be out of scope. However, these issues would need to be addressed before a successor to this document could be be published as a standards track document. In particular, a standards track document would need to include: * A clear statement of the requirements/goals that need to be satisfied by the protocol; * A comprehensive diagram and description of the overall message flow and delivery sequence required to achieve the requirements; * Alignment with traditional IETF email and security terminology; and * Review of prior art, and a comparison with the proposed standards track solution. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
