Fwd: UPDATED Document Action: 'Certified Electronic Mail' to Informational RFC

Of interest to this no-longer-WG:

>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
>
>There was an IETF Last Call for this document, but the result shows that
>there is not IETF Consensus for the content of this document.
>
>Please change the title of the document to:
>La Posta Elettronica Certificata - Italian Certified Electronic Mail
>
>Please change the Introduction as follows:
>
>OLD:
>
>Since 1997, the Italian Laws have recognized electronic delivery
>systems as legally usable. In 2005 after two years of technical
>tests, the characteristics of an official electronic delivery
>service, named certified electronic mail (in Italian Posta
>Elettronica Certificata, from now on "PEC") were defined, giving
>the system legal standing.
>This document represents the English version of the Italian
>specfications, (http://www.cnipa.gov.it/site/_files/Pec-def.pdf)
>which will be the ultimate PEC reference.
>
>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.
>
>NEW:
>
>Since 1997, the Italian Laws have recognized electronic delivery
>systems as legally usable. In 2005 after two years of technical
>tests, the characteristics of an official electronic delivery
>service, named certified electronic mail (in Italian Posta
>Elettronica Certificata, from now on "PEC") were defined, giving
>the system legal standing.
>
>This document represents the English version of the Italian
>specifications (http://www.cnipa.gov.it/site/_files/Pec-def.pdf);
>the Italian version is the normative PEC reference.
>
>IETF review did not result in community consensus. Since this
>specification describes existing deployment and implementation,
>the issues identified by the IETF community have not been
>addressed in this document. However, these issues would need to
>be addressed before a successor to this document could be be
>published. At a minimum, the successor 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 terminology for IETF email and
>security; and
>
>* Review of prior art.
_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime