Document Action: 'Certified Electronic Mail' to Informational RFC

[The IESG <[e-mail]>]

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.