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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux