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
* Review of prior art; and
* Replace the unregistered LDAP DN name space used in this
specification, which may lead to conflict with other registered or
unregistered names, with a registered name space.
In section 4.5, please make the following substitution
OLD
"providerName=<name>, o=postacert"
NEW
"<providerName=<name>,o=postacert>"
In section 4.5.2, please make the following substitution:
OLD
NOTE: By the time this draft is written, and after PEC had several
implementations up and running, RFC 2252 was rendered obsolete
by [LDAP-SYNTAXES], which removed the definition of the Binary
syntax (see [LDAP-SYNTAXES] Appendix B. point 12.).
NEW
As required by this attribute type's syntax, values of this
attribute are requested and transferred using the attribute
description "providerCertificate;binary" ([RFC4522]).
Please append the following paragraph to section 4.5.4:
The 'mailReceipt' attribute contains an email address within the provider
to which take in charge and virus detection PEC notifications are sent.
This address is a limited version of the addr-spec construct described
in [RFC3522] (without angle brackets); it only permits the dot-atom-text
form on both the left and right-hand sides of the "@", and does not have
internal CFWS.
Please append the following paragraph to section 4.5.5:
The 'managedDomains' attribute holds a set of domains [SMTP] that are
handled by a PEC provider. Domains are limited to dot-atom form
([RFC1034],[RFC5322]).
In Section 4.5.6:
OLD
The 'LDIFLocationURL' attribute contains an [HTTPS] URL that points
to the location of the [LDIF] file defining the provider's record.
When the attribute is present in the record "dn: o=postacert", then
it contains the definition of the entire directory in [LDIF] format.
NEW
The 'LDIFLocationURL' attribute contains an [HTTPS] URL that points
to the location of the [LDIF] file defining the provider's record.
When the attribute is present in the record "dn: o=postacert", then
it contains the definition of the entire directory in [LDIF] format.
The LDIF file will have a MIME type of application/pkcs7-mime,
with the parameter smime-type/signed-data. [SMIMEV3] The LDIF file
is encoded using the UTF-8 character set.
In section 4.5.7, please make the following substitutions
OLD
"providerUnits=<environment>,providerName=<name>, o=postacert"
NEW
"<providerUnits=<environment>,providerName=<name>,o=postacert>"
In section 4.5.8, please make the following substitution:
OLD:
Name: LDIFLocationURLObject
Description: Class for the insertion of a LDIFLocationURL
attribute
OID: ( 1.3.6.1.4.1.16572.2.1.1 )
Kind: auxiliary
SubclassOf: top
MAY Contain: ( LDIFLocationURL )
NEW:
( 1.3.6.1.4.1.16572.2.1.1 NAME 'LDIFLocationURLObject'
SUP top AUXILIARY
MAY ( LDIFLocationURL ) )
In section 4.5.9, please make the following substitution:
OLD:
Name: provider
Description: PEC provider
OID: ( 1.3.6.1.4.1.16572.2.1.2 )
SubclassOf: top
MUST Contain: ( providerCertificateHash
providerCertificate
providerName
mailReceipt
managedDomains )
MAY Contain: ( description
LDIFLocationURL
providerUnit )
NEW:
( 1.3.6.1.4.1.16572.2.1.2 NAME 'provider'
SUP top STRUCTURAL
MUST ( providerCertificateHash
providerCertificate
providerName
mailReceipt
managedDomains )
MAY ( description
LDIFLocationURL
providerUnit )
Please replace sections 8.2.1 & 8.2.2 by the following
single section:
8.2.1. Registration of Object Classes and Attribute Types
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): See comments
Object Identifier: See comments
Person & email address to contact for further information:
See "Author/Change Controller"
Usage: See comments
Specification: (I-D)
Author/Change Controller:
Claudio Petrucci
DigitPA
Viale Carlo Marx 31/49
00137 Roma
Italy
EMail: PETRUCCI@digitpa.gov.it
Comments:
The following object identifiers and associated object classes/
attribute types are requested to be registered.
OID Descriptor Usage
------------------------ --------------------- ------
1.3.6.1.4.1.16572.2.1.1 LDIFLocationURLObject O
1.3.6.1.4.1.16572.2.1.2 provider O
1.3.6.1.4.1.16572.2.2.1 providerCertificateHash A
1.3.6.1.4.1.16572.2.2.2 providerCertificate A
1.3.6.1.4.1.16572.2.2.3 providerName A
1.3.6.1.4.1.16572.2.2.4 mailReceipt A
1.3.6.1.4.1.16572.2.2.5 managedDomains A
1.3.6.1.4.1.16572.2.2.6 LDIFLocationURL A
1.3.6.1.4.1.16572.2.2.7 providerUnit A
Legend
-------------------
O => Object Class
A => Attribute Type
Please add informative references to RFC1034, RFC4522, and RFC4523.