summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6109.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6109.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6109.txt')
-rw-r--r--doc/rfc/rfc6109.txt3643
1 files changed, 3643 insertions, 0 deletions
diff --git a/doc/rfc/rfc6109.txt b/doc/rfc/rfc6109.txt
new file mode 100644
index 0000000..6439122
--- /dev/null
+++ b/doc/rfc/rfc6109.txt
@@ -0,0 +1,3643 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) C. Petrucci
+Request for Comments: 6109 DigitPA
+Category: Informational F. Gennai
+ISSN: 2070-1721 A. Shahin
+ ISTI-CNR
+ A. Vinciarelli
+ April 2011
+
+
+ La Posta Elettronica Certificata - Italian Certified Electronic Mail
+
+Abstract
+
+ 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") were defined, giving the system legal
+ standing.
+
+ The design of the entire system was carried out by the National
+ Center for Informatics in the Public Administration of Italy
+ (DigitPA), followed by efforts for the implementation and testing of
+ the service. The DigitPA has given the Italian National Research
+ Council (CNR), and in particular the Institute of Information Science
+ and Technologies at the CNR (ISTI), the task of running tests on
+ providers of the service to guarantee the correct implementation and
+ interoperability. This document describes the certified email system
+ adopted in Italy. It represents the system as it is at the moment of
+ writing, following the technical regulations that were written based
+ upon the Italian Law DPR. November 2, 2005.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It has been approved for publication by the Internet
+ Engineering Steering Group (IESG). Not all documents approved by the
+ IESG are a candidate for any level of Internet Standard; see Section
+ 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6109.
+
+
+
+
+
+Petrucci, et al. Informational [Page 1]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 2]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+Table of Contents
+
+ 1. Introduction ....................................................5
+ 1.1. Scope ......................................................5
+ 1.2. Notational Conventions .....................................6
+ 1.2.1. Requirement Conventions .............................6
+ 1.2.2. Acronyms ............................................6
+ 1.2.3. Terminology and Definitions .........................7
+ 2. PEC Model .......................................................8
+ 2.1. System-Generated Messages ..................................8
+ 2.1.1. Message Types ......................................10
+ 2.2. Basic Structure ...........................................12
+ 2.2.1. Access Point .......................................12
+ 2.2.2. Incoming Point .....................................14
+ 2.2.3. Delivery Point .....................................16
+ 2.2.4. Storage ............................................17
+ 2.2.5. Provider Service Mailbox ...........................17
+ 2.2.6. Provider Service Email Address .....................17
+ 2.3. Log .......................................................17
+ 3. Message Processing .............................................18
+ 3.1. Access Point ..............................................18
+ 3.1.1. Formal Checks on Messages ..........................18
+ 3.1.2. Non-Acceptance PEC Notification Due to
+ Formal Exceptions ..................................19
+ 3.1.3. Non-Acceptance PEC Notification Due to
+ Virus Detection ....................................20
+ 3.1.4. Server-User Acceptance PEC Notification ............20
+ 3.1.5. PEC Transport Envelope .............................21
+ 3.1.6. Timeout Delivery Error PEC Notification ............23
+ 3.2. Incoming Point ............................................24
+ 3.2.1. Server-Server Acceptance PEC Notification ..........24
+ 3.2.2. PEC Anomaly Envelope ...............................25
+ 3.2.3. Virus Detection PEC Notification ...................27
+ 3.2.4. Virus-Induced Delivery Error PEC notification ......28
+ 3.3. Delivery Point ............................................29
+ 3.3.1. Checks on Incoming Messages ........................29
+ 3.3.2. Delivery PEC Notification ..........................29
+ 3.3.3. Non-Delivery PEC Notification ......................34
+ 3.4. Sender and Receiver Belonging to the Same Domain ..........34
+ 3.5. Example: Complete Transaction between Two PEC Domains .....34
+ 4. Formats ........................................................35
+ 4.1. Temporal Reference ........................................35
+ 4.2. User Date/Time ............................................36
+ 4.3. Format of a PEC Message Body ..............................36
+ 4.3.1. User Readable Text .................................37
+ 4.3.2. Original Message ...................................37
+ 4.3.3. Certification Data .................................37
+ 4.4. Certification Data Scheme .................................37
+
+
+
+Petrucci, et al. Informational [Page 3]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ 4.5. PEC Providers Directory Scheme ............................39
+ 4.5.1. providerCertificateHash Attribute ..................41
+ 4.5.2. providerCertificate Attribute ......................41
+ 4.5.3. providerName Attribute .............................41
+ 4.5.4. mailReceipt Attribute ..............................42
+ 4.5.5. managedDomains Attribute ...........................42
+ 4.5.6. LDIFLocationURL Attribute ..........................43
+ 4.5.7. providerUnit Attribute .............................43
+ 4.5.8. LDIFLocationURLObject Object Class .................44
+ 4.5.9. Provider Object Class ..............................44
+ 4.5.10. LDIF File Example .................................44
+ 5. Security-Related Aspects .......................................48
+ 5.1. Digital Signature .........................................48
+ 5.2. Authentication ............................................48
+ 5.3. Secure Interaction ........................................49
+ 5.4. Virus .....................................................49
+ 5.5. S/MIME Certificate ........................................49
+ 5.5.1. Provider-Related Information (Subject) .............50
+ 5.5.2. Certificate Extensions .............................50
+ 5.5.3. Example ............................................51
+ 5.6. PEC Providers Directory ...................................55
+ 6. PEC System Client Technical and Functional Prerequisites .......55
+ 7. Security Considerations ........................................55
+ 8. IANA Considerations ............................................56
+ 8.1. Registration of PEC Message Header Fields .................56
+ 8.1.1. Header Field: X-Riferimento-Message-ID: ............56
+ 8.1.2. Header Field: X-Ricevuta: ..........................56
+ 8.1.3. Header Field: X-VerificaSicurezza: .................57
+ 8.1.4. Header Field: X-Trasporto: .........................57
+ 8.1.5. Header Field: X-TipoRicevuta: ......................57
+ 8.1.6. Header Field: X-Mittente: ..........................58
+ 8.2. Registration of LDAP Object Identifier Descriptors ........58
+ 8.2.1. Registration of Object Classes and
+ Attribute Types ....................................58
+ 9. References .....................................................59
+ 9.1. Normative References ......................................59
+ 9.2. Informative References ....................................61
+ 10. Acknowledgments ...............................................62
+ Appendix A. Italian Fields and Values in English ..................63
+
+
+
+
+
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 4]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+1. Introduction
+
+ 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.digitpa.gov.it/sites/default/files/normativa/
+ Pec_regole_tecniche_DM_2-nov-2005.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 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
+
+ * A review of prior art; and
+
+ * A replacement of 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.
+
+1.1. Scope
+
+ To ensure secure transactions over the Internet, cryptography can be
+ associated with electronic messages in order to provide some
+ guarantee on sender identity, message integrity, confidentiality, and
+ non-repudiation of origin. Many end-to-end techniques exist to
+ accomplish such goals, and some offer a high level of security. The
+ downside of end-to-end cryptography is the need for an extensive
+ penetration of technology in society, because it is essential for
+ every user to have asymmetric keys and certificates signed by a
+ Certification Authority. Along with that, users would need to have
+ an adequate amount of knowledge regarding the use of such technology.
+
+
+
+Petrucci, et al. Informational [Page 5]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ PEC, on the other hand, uses applications running on servers to
+ digitally sign messages, thus avoiding the complexity end-to-end
+ systems bring about. By doing so, the user need only have an
+ ordinary mail client with which to interact. The downside is that
+ the level of security drops, since the protection does not cover the
+ entire transaction. Nonetheless, application is simpler and does not
+ require specific user skills, making it easily more widespread among
+ users.
+
+ This document describes PEC's technical aspects and features. It
+ presents the details of the protocol and the messages that are sent
+ between service providers, introducing the system adopted by the
+ Italian government for the exchange of certified emails.
+
+1.2. Notational Conventions
+
+1.2.1. Requirement Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [REQ].
+
+1.2.2. Acronyms
+
+ CMS: Cryptographic Message Syntax
+ CNIPA: Italian National Agency for Digital Administration
+ (Centro Nazionale per l'Informatica nella Pubblica
+ Amministrazione)
+ CNR: Italian National Research Council (Consiglio Nazionale
+ delle Ricerche)
+ CRL: Certificate Revocation List
+ CRL DP: Certificate Revocation List Distribution Point
+ DNS: Domain Name Service
+ DTD: Document Type Definition
+ FQDN: Fully Qualified Domain Name
+ ISTI: The Institute of Information Science and Technologies
+ at the CNR (Istituto di Scienza e Tecnologie
+ dell'Informazione "A.Faedo")
+ LDAP: Lightweight Directory Access Protocol
+ LDIF: LDAP Data Interchange Format
+ MIME: Multipurpose Internet Mail Extensions
+ PEC: Certified Electronic Mail (Posta Elettronica
+ Certificata)
+ S/MIME: Secure/MIME
+ SMTP: Simple Mail Transfer Protocol
+ TLS: Transport Layer Security
+ XML: eXtensible Markup Language
+
+
+
+
+Petrucci, et al. Informational [Page 6]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+1.2.3. Terminology and Definitions
+
+ Certification data: A set of data certified by the sender's PEC
+ provider that describes the original message. It includes the date
+ and time of dispatch, sender email address, recipient(s) email
+ address(es), subject, and message identifier.
+
+ Certified electronic mail: A service based on electronic mail, as
+ defined by the [EMAIL] and [SMTP] standards and extensions, which
+ permits the transmission of documents produced with informatics
+ tools.
+
+ DigitPA: Ex-CNIPA.
+
+ Holder: The person or organization to whom a PEC mailbox is assigned.
+
+ Message sent: A PEC message is considered sent when the sender's PEC
+ provider, after several checks, accepts the email and returns a
+ server-user acceptance PEC notification to the sender.
+
+ Message received: A PEC message is considered received when it is
+ stored in the receiver's mailbox, after which the receiver PEC
+ provider returns a delivery PEC notification to the sender.
+
+ Msgid: Is the message identifier generated by the email client, as
+ defined in [EMAIL], before the message is submitted to the PEC
+ system.
+
+ Ordinary mail: Non-PEC email messages.
+
+ Original message: Is the user-generated message before its arrival to
+ the sender Access Point. The original message is delivered to the
+ recipient inside a PEC transport envelope.
+
+ PEC domain: Corresponds to a DNS domain dedicated to the holders'
+ mailboxes.
+
+ PEC mailbox: An electronic mailbox for which delivery PEC
+ notifications are issued upon reception of PEC messages. Such a
+ mailbox can be defined exclusively within a PEC domain.
+
+ PEC msgid: Is a unique identifier generated by the PEC system, which
+ will substitute the msgid.
+
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 7]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ PEC provider: The entity that handles one or more PEC domains with
+ their relative points of Access, Reception, and Delivery. It is the
+ holder of the key that is used for signing PEC notifications and
+ envelopes, and it interacts with other PEC providers for
+ interoperability with other holders.
+
+ PEC provider's key: Is a key released by DigitPA to every PEC
+ provider. It is used to sign PEC notifications and envelopes and to
+ authorize access to the PEC providers directory.
+
+ PEC providers directory: Is an LDAP server positioned in an area
+ reachable by all PEC service providers. It constitutes the technical
+ structure related to the public list of PEC service providers and
+ contains the list of PEC domains and service providers with relevant
+ certificates.
+
+ Service mailbox: A mailbox for the sole use of the provider,
+ dedicated for the reception of server-server acceptance and virus
+ detection PEC notifications.
+
+ Time stamp: Digital evidence with which a temporal reference, that
+ can't be repudiated, is attributed to one or more documents.
+
+2. PEC Model
+
+2.1. System-Generated Messages
+
+ The PEC system generates messages in MIME format composed of a
+ descriptive textual part and other [MIME1] parts, the number and
+ content of which varies according to the type of message generated.
+
+ A system-generated message falls into one of the following
+ categories:
+
+ o Notifications;
+
+ o Envelopes.
+
+ The message is inserted in an S/MIME v3 structure in CMS format and
+ signed with the PEC provider's private key. The X.509v3 certificate
+ associated with the key MUST be included in the aforementioned
+ structure. The S/MIME format used to sign system-generated messages
+ is the "multipart/signed" format (.p7s), as described in section
+ 3.4.3 of [SMIMEV3].
+
+ To guarantee the verifiability of signatures on as many mail clients
+ as possible, X.509v3 certificates used by certified email systems
+ MUST abide by the profile found in section 6.5.
+
+
+
+Petrucci, et al. Informational [Page 8]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ In order for the receiving mail client to verify the signature, the
+ sender address MUST coincide with the one indicated within the
+ X.509v3 certificate. For this mechanism, PEC transport envelopes
+ MUST indicate in the "From:" field a single author's address which is
+ different from the one contained in the original message. To allow
+ for better message usability by the receiving user, the author's mail
+ address in the original message is inserted as a "display name". For
+ example, a "From:" field such as:
+
+ From: "John Smith" <john.smith@domain.example.com>
+
+ would result in the following "From:" value in the respective PEC
+ transport envelope:
+
+ From: "On behalf of: john.smith@domain.example.com"
+ <certified-mail@provider.example.com>
+
+ Both "From:" and "Sender:" fields MUST contain the same value. In
+ order for replies to be correctly sent back to the proper
+ destination, the "Reply-To:" field in the PEC transport envelope MUST
+ contain the same unaltered value of the original message's
+ "Reply-To:" field. When it is not explicitly specified in the
+ original message, the system that generates the PEC transport
+ envelope creates it by extracting the information from the "From:"
+ field in the original message.
+
+ When PEC notifications are sent, the system MUST use the original
+ message sender's address as the destination address, as is specified
+ in the reverse path data of the SMTP protocol. PEC notifications
+ MUST be sent to the sender's PEC mailbox without taking into account
+ the "Reply-To:" field, which might be present in the original
+ message's header.
+
+ All system-generated PEC messages are identifiable for having a
+ specific header defined in PEC according to the type of message
+ generated.
+
+ To determine the certification data, the elements used for the actual
+ routing of the message are employed. In SMTP dialog phases, the
+ reverse path and forward path data ("MAIL FROM" and "RCPT TO"
+ commands) are thus considered certification data of both the sender
+ and the recipients, respectively. Addressing data present in the
+ message body ("To:" and "Cc:" fields) are used solely in order to
+ discriminate between primary and carbon copy recipients when
+ necessary; addressing data present in the "Bcc:" field MUST be
+ considered invalid by the system.
+
+
+
+
+
+Petrucci, et al. Informational [Page 9]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+2.1.1. Message Types
+
+ All system-generated messages inherit their header fields and values
+ from the original message, with extra fields added according to the
+ type of message generated.
+
+2.1.1.1. PEC Notifications
+
+ They have the purpose of informing the sending user and interacting
+ providers of the progress the message is making within the PEC
+ network.
+
+2.1.1.1.1. Success PEC Notifications
+
+ These notifications indicate an acknowledgment on the provider's side
+ for the reception or handling of a PEC message. More specifically,
+ it can indicate one of three situations: server-user acceptance,
+ server-server acceptance, or delivery.
+
+ Added header fields are:
+
+ o X-Ricevuta:
+
+ o X-Riferimento-Message-ID:
+
+ The field "X-Ricevuta:" indicates the type of PEC notification
+ contained in the message, whereas "X-Riferimento-Message-ID:"
+ contains the message identifier generated by the mail client (msgid).
+
+ Body contents differ according to notification type. This is
+ described more thoroughly in section 3.
+
+ o A server-user acceptance PEC notification informs the user that
+ his provider has accepted the message and will be taking care of
+ passing it on to the provider(s) of the addressee(s).
+
+ o A server-server acceptance PEC notification is an inter-provider
+ communication only, it MUST NOT be sent to the users. With this
+ notification, the receiving provider simply informs the sending
+ one that it has received a PEC message, and will take the
+ responsibility of forwarding it to the addressee(s). From then
+ on, the sender provider is no longer held responsible as to the
+ whereabouts of the message, but is limited to notifying its user
+ of the success or failure of delivery.
+
+ o Delivery PEC notifications take place as the final communication
+ of a transaction, indicating overall success in handing the
+ message over to the addressee(s).
+
+
+
+Petrucci, et al. Informational [Page 10]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+2.1.1.1.2. Delay PEC Notifications
+
+ Delay PEC notifications are sent out 12 hours after a message has
+ been dispatched from the sending provider, and no server-server
+ acceptance or delivery PEC notification has been received. These
+ have the sole purpose of notifying the user of the delay.
+
+ If another 12 hours go by without any sign of a server-server
+ acceptance or delivery PEC notification (amounting to a 24-hour
+ delay), another delay PEC notification is dispatched to the user
+ informing him of the possible delivery failure. The provider will
+ not keep track of the delay any further.
+
+2.1.1.1.3. Failure PEC Notifications
+
+ They are sent when there is some error in transmission or reception.
+ More specifically, a failure PEC notification can indicate either a
+ formal-exception error or a virus detection.
+
+ Added header fields are:
+
+ o X-Ricevuta:
+
+ o X-Riferimento-Message-ID:
+
+ o X-VerificaSicurezza: [optional]
+
+ "X-Ricevuta:" and "X-Riferimento-Message-ID:" have the same role as
+ indicated in section 2.1.1.1.1 (Success Notifications).
+ "X-VerificaSicurezza:" (security verification) is an optional header
+ field, used for virus-related PEC notifications.
+
+ Body contents differ according to notification type. This is
+ described more thoroughly in section 3.
+
+2.1.1.2. PEC Envelopes
+
+ Messages entering the PEC network are inserted within specific PEC
+ messages, called envelopes, before they are allowed to circulate
+ further within the network. These envelopes MUST inherit the
+ following header fields, along with their unmodified values, from the
+ message itself:
+
+ o Received:
+
+ o To:
+
+ o Cc:
+
+
+
+Petrucci, et al. Informational [Page 11]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ o Return-Path:
+
+ o Reply-To: (if present)
+
+ Depending on the type of message requesting admission into the PEC
+ network, it will be inserted in either a PEC transport envelope or a
+ PEC anomaly envelope. Distinction will be possible through the
+ addition of the "X-Trasporto:" header field.
+
+2.2. Basic Structure
+
+ +-------------+ +------------+
+ | +--+ | | |
+ | |AP| | PEC | |
+ +----+ | +--+ | messages & | +---+ +--+ | +----+
+ |user|<-->| |<------------->| |InP| |DP| |<-->|user|
+ +----+ | +--+ +---+ | notifications | +---+ +--+ | +----+
+ | |DP| |InP| | | |
+ | +--+ +---+ | | |
+ +-------------+ +------------+
+ PEC PEC
+ sender receiver
+ provider provider
+
+ where:
+
+ AP = Access Point
+ DP = Delivery Point
+ InP = Incoming Point
+
+2.2.1. Access Point
+
+ This is what the user client at the sender side interacts with,
+ giving the user access to PEC services set up by the provider.
+
+ Such access MUST be preceded by user authentication on the system
+ (see section 5.2). The Access Point receives the original messages
+ its user wishes to send, runs some formal checks, and acts according
+ to the outcome:
+
+ o if the message passes all checks, the Access Point generates a
+ server-user acceptance PEC notification and inserts the original
+ message inside a PEC transport envelope;
+
+ o if a formal exception is detected, the Access Point refuses the
+ message and emits the relevant non-acceptance PEC notification
+ (see section 3.1.1);
+
+
+
+
+Petrucci, et al. Informational [Page 12]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ o if a virus is detected, the Access Point generates a non-
+ acceptance PEC notification and inserts the original message as is
+ in the provider's special store.
+
+ Generation of the server-user acceptance notification indicates to
+ the user that the message was accepted by the system, certifying also
+ the date and time of the event. The notification MUST contain user-
+ readable text, and an XML part containing the certification data.
+ The notification MAY also contain other attachments for extra
+ features offered by the provider.
+
+ Using the data available in the PEC providers directory (see section
+ 4.5), the Access Point runs checks on every recipient in the "To:"
+ and "Cc:" fields present in the original message to verify whether
+ they belong to the PEC infrastructure or to non-PEC domains. Such
+ checks are done by verifying the existence, through a case-
+ insensitive search, of the recipients' domains in the
+ "managedDomains" attribute found within the PEC providers directory.
+ Therefore, the server-user acceptance PEC notification (and relevant
+ certification data) relates to, for each address, the typology of its
+ domain; PEC or non-PEC.
+
+ The message identifier (PEC msgid) of accepted original messages
+ within the PEC infrastructure MUST be unambiguous in order to consent
+ correct tracking of messages and relative PEC notifications. The
+ format of such an identifier is:
+
+ [alphanumeric string]@[provider mail domain]
+
+ or:
+
+ [alphanumeric string]@[FQDN mail server]
+
+ Therefore, both the original message and the corresponding PEC
+ transport envelope MUST contain the following header field:
+
+ Message-ID: <[unique identifier]>
+
+ When an email client that is interacting with the Access Point has
+ already inserted a message identifier (msgid) in the original
+ message, that msgid SHALL be substituted by a PEC msgid. In order to
+ allow the sender to link the message sent with the relative PEC
+ notifications, the msgid MUST be inserted in the original message as
+ well as the relative PEC notifications and transport envelope. If
+ present, the msgid is REQUIRED in the original message's header by
+ adding the following header field:
+
+ X-Riferimento-Message-ID: <[msgid]>
+
+
+
+Petrucci, et al. Informational [Page 13]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ which will also be inserted in the PEC transport envelope and
+ notifications, and related in the certification data (see section
+ 4.4).
+
+2.2.2. Incoming Point
+
+ This point permits the exchange of PEC messages and notifications
+ between PEC providers. It is also the point through which ordinary
+ mail messages can be inserted within the system of certified mail.
+
+ The exchange of messages between providers takes place through SMTP-
+ based transactions, as defined in [SMTP]. If SMTP communication
+ errors occur, they MAY be handled using the standard error
+ notification mechanisms, as provided by SMTP in [SMTP] and
+ [SMTP-DSN]. The same mechanism is also adopted for handling
+ transitory errors, that result in long idling periods, during an SMTP
+ transmission phase. In order to guarantee that an error is returned
+ to the user, as defined in section 3.3.3, the system that handles PEC
+ traffic MUST adopt a time limit for message idleness equal to 24
+ hours.
+
+ Once a message arrives, the Incoming Point runs the following list of
+ checks and operations:
+
+ o verifies correctness and type of the incoming message;
+
+ o if the incoming message is a correct and undamaged PEC transport
+ envelope:
+
+ - emits a server-server acceptance PEC notification towards the
+ sender provider (section 3.2.1);
+
+ - forwards the PEC transport envelope to the Delivery Point
+ (section 3.3).
+
+ o if the incoming message is a correct and undamaged PEC
+ notification, forwards the notification to the Delivery Point.
+
+ o if the incoming message does not conform to the prerequisites of a
+ correct and undamaged PEC transport envelope or notification, but
+ comes from a PEC provider, i.e., passes the verifications
+ regarding existence, origin, and validity of the signature, then
+ the message MUST be propagated towards the recipient.
+
+ Therefore, the Incoming Point:
+
+ - inserts the incoming message in a PEC anomaly envelope (section
+ 3.2.2);
+
+
+
+Petrucci, et al. Informational [Page 14]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ - forwards the PEC anomaly envelope to the Delivery Point.
+
+ o if the incoming message does not originate from a PEC system,
+ i.e., fails verifications regarding existence, origin, and
+ validity of the signature, then the message will be treated as
+ ordinary email, and, if propagated to the recipient:
+
+ - is inserted in a PEC anomaly envelope (section 3.2.2);
+
+ - the PEC anomaly envelope is forwarded to the Delivery Point.
+
+ The server-server acceptance PEC notification is generated by the
+ receiving provider and sent to the sending provider. Its purpose
+ is to keep track of the message in its transition from one
+ provider to another, and is therefore strictly intra-provider
+ communication; the end user knows nothing about it.
+
+ To check the correctness and integrity of a PEC transport envelope
+ or notification, the Incoming Point runs the following tests:
+
+ o Signature existence - the system verifies the presence of an
+ S/MIME signature structure within the incoming message;
+
+ o Signature origin - the system verifies whether or not the
+ signature belongs to a PEC provider by extracting the certificate
+ used for signing and verifying its presence in the PEC providers
+ directory. To ease the check, it is possible to calculate the
+ certificate's [SHA1] hash value and perform a case-insensitive
+ search of its hexadecimal representation within the
+ "providerCertificateHash" attribute found in the PEC providers
+ directory. This operation allows one to easily identify the
+ sender provider for subsequent and necessary matching checks
+ between the extracted certificate and the one present in the
+ provider's record;
+
+ o Signature validity - S/MIME signature correctness is verified by
+ recalculating the signature value, checking the entire
+ certification path, and verifying the [CRL] and temporal validity
+ of the certificate. In case some caching mechanism is used for
+ CRL contents, an update interval MUST be adopted so that the most
+ up-to-date data is guaranteed, thus minimizing the possible delay
+ between a publication revocation by the Certification Authority
+ and the variation acknowledgment by the provider;
+
+ o Formal correctness - the provider performs sufficient and
+ necessary checks to guarantee that the incoming message is
+ compliant with the formats specified in this document (PEC
+ transport envelope and notifications).
+
+
+
+Petrucci, et al. Informational [Page 15]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ If a virus-infected PEC transport envelope passes the checks just
+ mentioned, it is still considered correct and undamaged. The
+ presence of the virus will be detected in a second phase, during
+ which the contents of the PEC transport envelope are verified.
+ Thus, the Incoming Point will refrain from forwarding the message
+ to the recipient, instead sending the appropriate PEC notification
+ of non-delivery and storing the virus-infected message in the
+ provider's special storage.
+
+ In case ordinary mail messages are received, the PEC provider
+ SHALL perform virus checks in order to prevent the infiltration of
+ potentially dangerous mail messages within the PEC system. If a
+ virus is detected in an ordinary mail message, the latter can be
+ discarded at the Incoming Point before it enters the PEC system.
+ In other words, no special treatment is reserved for the error; it
+ is handled in a manner that is conformant to the procedures
+ usually followed for messages going through the Internet.
+
+ When the receiving provider detects a virus inside a PEC transport
+ envelope during the reception phase, it emits a virus detection
+ PEC notification to the sending provider, which then realizes its
+ checks failed to detect that virus. When this happens, the
+ sending provider MUST:
+
+ o check what virus typologies were not detected by its own antivirus
+ to verify the possibility of interventions
+
+ o send a virus-induced non-delivery PEC notification to the sender's
+ mailbox.
+
+2.2.3. Delivery Point
+
+ This point is the point that receives messages from the Incoming
+ Point and forwards them to the final recipient.
+
+ It MUST run a series of tests on received messages before forwarding
+ them to the user (see section 3.3.1). It first verifies the typology
+ of the message and decides whether or not a PEC notification should
+ be issued to the sender. The delivery PEC notification (section
+ 3.3.2) is emitted after the message was delivered to the recipient's
+ PEC mailbox and only at reception of a valid PEC transport envelope
+ (sections 2.2.2 and 3.1.5).
+
+ In all other cases, such as PEC anomaly envelopes and PEC
+ notifications, the delivery PEC notification is not emitted.
+ Regardless, the message received from the Delivery Point MUST be
+ delivered unmodified to the recipient's mailbox.
+
+
+
+
+Petrucci, et al. Informational [Page 16]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ The delivery PEC notification indicates to the sender that the
+ message sent was in fact conveyed to the specified recipient's
+ mailbox and certifies the date and time of delivery through use of
+ user-readable text and an XML part containing certification data,
+ along with other possible attachments added for extra features
+ offered by the provider.
+
+ If a PEC transport envelope received at the Delivery Point can't be
+ delivered to the destination mailbox, the Delivery Point emits a non-
+ delivery PEC notification (section 3.3.3). If, on the other hand,
+ the delivery error concerns a message that arrives from Internet
+ (i.e., a non-PEC message), no such notification is emitted.
+
+2.2.4. Storage
+
+ Each provider MUST dedicate a special storage for the deposition of
+ any virus-infected messages encountered. Whether the virus be
+ detected by the sender's Access Point or the receiver's Incoming
+ Point, the provider that detects it MUST store the mail message in
+ its own storage, and keep it for 30 months.
+
+2.2.5. Provider Service Mailbox
+
+ For exclusive use of the provider, dedicated to the reception of PEC
+ notifications in two cases only:
+
+ o server-server acceptance notification; and
+
+ o virus detection notification.
+
+2.2.6. Provider Service Email Address
+
+ Each provider MUST register a special purpose email address for use
+ when sending PEC transport envelopes and notifications, as delineated
+ in section 3. This address MAY coincide with that of the service
+ mailbox described in section 2.2.5.
+
+2.3. Log
+
+ The server administrator MUST keep track of any and all operations
+ carried out in a specific message log file. The information kept in
+ the log for each operation is the following:
+
+ o message identifier (msgid)
+
+ o date and time of event
+
+ o sender of original message
+
+
+
+Petrucci, et al. Informational [Page 17]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ o recipient(s) of original message
+
+ o subject of original message
+
+ o event type (reception, delivery, PEC notification emission, etc.)
+
+ o message identifiers of related generated messages
+
+ o sending provider
+
+ The service provider MUST store this data and preserve it unmodified.
+ Italian laws have specified that the service provider retain the data
+ for 30 months.
+
+3. Message Processing
+
+3.1. Access Point
+
+ The Access Point acts as a submission service as defined in
+ [SUBMISSION].
+
+3.1.1. Formal Checks on Messages
+
+ When the Access Point receives a message the user wishes to send, it
+ MUST guarantee said message's formal conformity as defined in
+ [EMAIL], and verify that the:
+
+ o [EMAIL] header section contains a "From:" header field holding an
+ [EMAIL] compliant email address;
+
+ o [EMAIL] header section contains a "To:" header field holding one
+ or more [EMAIL] compliant email addresses;
+
+ o sender's address, specified in the SMTP reverse path, coincides
+ with the one in the message's "From:" header field;
+
+ o recipients' addresses specified in the SMTP forward path coincide
+ with the ones present in the "To:" or "Cc:" header fields of the
+ message;
+
+ o "Bcc:" header field does not contain any value;
+
+ o total message size falls within the limits accepted by the
+ provider. Such limits apply depending on the number of recipients
+ as well; by multiplying it to the message size, the outcome MUST
+ fall within the limits accepted by the provider. Italian laws
+ have specified this limit as being 30 MB.
+
+
+
+
+Petrucci, et al. Informational [Page 18]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ If the message does not pass the tests, the Access Point MUST NOT
+ accept the message within the PEC system, thus emitting the relative
+ PEC notification of non-acceptance.
+
+3.1.2. Non-Acceptance PEC Notification Due to Formal Exceptions
+
+ When the Access Point cannot forward the message received due to
+ failure in passing formal checks, the sender is notified of such an
+ outcome. If the error is caused by the message failing size checks,
+ a non-acceptance PEC notification is sent as long as the size remains
+ bound by a certain limit. If the size exceeds said limit, error
+ handling is left to SMTP.
+
+ The notification header will contain the following fields:
+
+ X-Ricevuta: non-accettazione
+ Date: [date of notification emission]
+ Subject: AVVISO DI NON ACCETTAZIONE: [original subject]
+ From: posta-certificata@[mail domain]
+ To: [original sender]
+ X-Riferimento-Message-ID: [msgid]
+
+ The notification body will contain a text part that constitutes the
+ actual notification in readable format according to a model that
+ relates the following information:
+
+ Error in message acceptance
+ On [date] at [time] ([time zone]), in the message "[subject]"
+ originating from "[original sender]" and addressed to:
+ [recipient_1]
+ [recipient_2]
+ [recipient_n]
+ a problem was detected that prevents its acceptance due to
+ [error description].
+ The message was not accepted.
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ The same certification information is inserted in an XML file to be
+ added to the notification body, thus allowing automatic checks on the
+ message (section 4.4). Parsing MUST be done on the XML part only.
+ Additional parts MAY be included by the provider for provider-
+ specific services. Regardless, the original message MUST NOT be
+ included. The message MUST follow the format described in section
+ 4.3.
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 19]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+3.1.3. Non-Acceptance PEC Notification Due to Virus Detection
+
+ The Access Point MUST run some tests on the content of messages it
+ receives from its users and reject them if a virus is detected. In
+ which case, a virus-detection-induced non-acceptance PEC notification
+ MUST be emitted to clearly inform the user of the reason the message
+ was refused.
+
+ The notification header contains the following fields:
+
+ X-Ricevuta: non-accettazione
+ X-VerificaSicurezza: errore
+ Date: [notification emission date]
+ Subject: AVVISO DI NON ACCETTAZIONE PER VIRUS: [original
+ subject]
+ From: posta-certificata@[mail domain]
+ To: [original sender]
+ X-Riferimento-Message-ID: [msgid]
+
+ The body contains a readable text part according to the following
+ model:
+
+ Error in message acceptance due to virus presence
+ On [date] at [time] ([time zone]), in the message "[subject]"
+ originating from "[original sender]" and addressed to:
+ [recipient_1]
+ [recipient_2]
+ [recipient_n]
+ a security problem was detected [ID of detected content type].
+ The message was not accepted.
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ The same certification data is inserted in an XML file added to the
+ notification to allow for automatic checks (section 4.4). Parsing
+ MUST be done on the XML part only. Additional parts MAY be included
+ by the provider for provider-specific services. Regardless, the
+ original message MUST NOT be included. The message MUST follow the
+ format described in section 4.3.
+
+3.1.4. Server-User Acceptance PEC Notification
+
+ The server-user acceptance PEC notification is a message sent to the
+ sender by his server, containing date and time of message acceptance
+ into the system, sender and recipient data, and subject.
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 20]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ The header contains the following fields:
+
+ X-Ricevuta: accettazione
+ Date: [actual date of server-user acceptance]
+ Subject: ACCETTAZIONE: [original subject]
+ From: posta-certificata@[mail domain]
+ To: [original sender]
+ X-Riferimento-Message-ID: [msgid]
+
+ The message body contains a text part that constitutes the
+ notification in readable format, according to a model that relates
+ the following information:
+
+ Server-User Acceptance PEC notification
+ On [date] at [time] ([time zone]), the message "[subject]"
+ originating from "[original sender]" and addressed to:
+ [recipient_1] (["certified mail" | "ordinary mail"])
+ [recipient_2] (["certified mail" | "ordinary mail"])
+ [recipient_n] (["certified mail" | "ordinary mail"])
+ was accepted by the system and forwarded to the recipient(s).
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ The same certification data is inserted in an XML file added to the
+ notification message, allowing automatic checks on it (section 4.4).
+ Parsing MUST be done on the XML part only. Additional parts MAY be
+ included by the provider for provider-specific services. The message
+ MUST follow the format described in section 4.3.
+
+3.1.5. PEC Transport Envelope
+
+ A PEC transport envelope is a message generated by the Access Point
+ that contains the original message as well as certification data.
+
+ As mentioned in section 2.1.1.2, the PEC transport envelope inherits
+ from the original message the values of the following header fields,
+ which MUST be related unmodified:
+
+ o Received:
+
+ o To:
+
+ o Cc:
+
+ o Return-Path:
+
+ o Reply-To: (if present)
+
+
+
+
+Petrucci, et al. Informational [Page 21]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ On the other hand, the following fields MUST be modified, or inserted
+ if necessary:
+
+ X-Trasporto: posta-certificata
+ Date: [actual date of server-user acceptance]
+ Subject: POSTA CERTIFICATA: [original subject]
+ From: "On behalf of: [original sender]"
+ <certified-mail@[mail_domain]>
+ Reply-To: [original sender] (inserted only if not present)
+ Message-ID: [PEC msgid generated as in section 2.2.1]
+ X-Riferimento-Message-ID: [msgid]
+ X-TipoRicevuta: [completa/breve/sintetica]
+
+ The "X-TipoRicevuta:" field indicates the type of delivery PEC
+ notification the sender wishes to receive -- complete, brief, or
+ concise.
+
+ The body of the PEC transport envelope contains a text part that
+ constitutes the readable format of the message according to a model
+ that relates the following certification data:
+
+ Certified mail message
+ On [date] at [time] ([time zone]), the message "[subject]" was
+ sent by "[original sender]" and addressed to:
+ [recipient_1]
+ [recipient_2]
+ [recipient_n]
+ The original message is included in attachment.
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ Within the PEC transport envelope, the entire, non-modified original
+ message is inserted in a format compliant with [EMAIL] (except for
+ what has been said regarding the message identifier), as well as an
+ XML part, which contains the certification data that was already
+ related in text format, and information on the type of message and
+ PEC notification requested (section 4.4). Parsing MUST be done on
+ the XML part only. Additional parts MAY be included by the provider
+ for provider-specific services. The message MUST follow the format
+ described in section 4.3.
+
+ Note that the routing data of the PEC transport envelope (forward and
+ reverse paths) remain unaltered.
+
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 22]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+3.1.6. Timeout Delivery Error PEC Notification
+
+ If the sending provider doesn't receive a server-server acceptance or
+ delivery PEC notification from the receiving provider within 12 hours
+ of the message dispatch, it informs the user that the recipient's
+ provider might not be able to deliver the message. In case the
+ sending provider doesn't receive a delivery PEC notification within
+ 24 hours after message dispatch, it emits another non-delivery PEC
+ notification to the user by the 24-hour timeout, but not before 22
+ hours have passed.
+
+ Such a communication takes place through a PEC notification of non-
+ delivery due to timeout, the header of which contains the following
+ fields:
+
+ X-Ricevuta: preavviso-errore-consegna
+ Date: [date of notification emission]
+ Subject: AVVISO DI MANCATA CONSEGNA PER SUP. TEMPO MASSIMO:
+ [original subject]
+ From: posta-certificata@[mail domain]
+ To: [original recipient]
+ X-Riferimento-Message-ID: [msgid]
+
+ The body of the first non-delivery PEC notification (12-hour timeout)
+ contains a text part that represents the readable format of the
+ notification which will relate the following data:
+
+ Non-delivery PEC notification
+ On [date] at [time] ([time zone]), the message
+ "[subject]" originating from "[original sender]"
+ and addressed to "[recipient]"
+ has not been delivered within the first 12 hours following
+ its dispatch. Not excluding that the message might eventually
+ be delivered, it is deemed useful to consider that dispatch
+ might not have a positive outcome. The system will see to
+ sending another non-delivery PEC notification if in the
+ following twelve hours no confirmation is received from the
+ recipient.
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ On the other hand, 24-hour-timeout induced PEC notifications, which
+ have the same header as described above, will have the following text
+ in their body:
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 23]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ Non-delivery PEC notification
+ On [date] at [time] ([time zone]), the message
+ "[subject]" originating from "[original sender]"
+ and addressed to "[recipient]"
+ has not been delivered within 24 hours of its dispatch.
+
+ The transaction is deemed to be considered terminated with a
+ negative outcome.
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ The same certification data is inserted in an XML file added to both
+ PEC notification types to allow automatic checks (section 4.4).
+
+ Parsing MUST be done on the XML part only. Additional parts MAY be
+ added for services supplied by the PEC provider. Regardless, the
+ original message MUST NOT be included. The message MUST follow the
+ format described in section 4.3.
+
+ A timeout PEC notification is generated if one of the following
+ scenarios occurs:
+
+ o the sending provider receives a server-server acceptance PEC
+ notification during the first 12 hours following message dispatch,
+ but does not receive a delivery PEC notification at all. In this
+ case, it would be a 24-hour timeout PEC notification.
+
+ o the sending provider does not receive a server-server acceptance
+ PEC notification, but receives a delivery PEC notification after
+ 12 hours and before the 24-hour timeout. In this case it would be
+ a 12-hour timeout PEC notification.
+
+ o the sending provider doesn't receive either a server-server
+ acceptance or a delivery PEC notification. In this case, two
+ timeout PEC notifications are generated; a 12-hour and a 24-hour
+ timeout PEC notification.
+
+3.2. Incoming Point
+
+3.2.1. Server-Server Acceptance PEC Notification
+
+ When correct PEC transport envelopes (as defined in section 2.2.2.)
+ are exchanged between PEC providers, the receiver MUST send a server-
+ server acceptance PEC notification to the sender. The single
+ dispatched notification concerns all recipients who belong to the
+ same provider, and to whom the incoming message was addressed, as
+ stated in the routing data (forward and reverse paths) of the SMTP
+ transaction. Within the certification data of a single server-server
+
+
+
+Petrucci, et al. Informational [Page 24]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ acceptance PEC notification, all recipients of the message to which
+ it refers are listed. In general, when receiving a PEC transport
+ envelope, each provider MUST emit one or more server-server
+ acceptance PEC notifications to cover, in absence of SMTP transport
+ errors, all the recipients in its jurisdiction.
+
+ The header of a server-server acceptance PEC notification contains
+ the following fields:
+
+ X-Ricevuta: presa-in-carico
+ Date: [date of server-server acceptance]
+ Subject: PRESA IN CARICO: [original subject]
+ From: posta-certificata@[mail domain]
+ To: [sender provider service mailbox]
+ X-Riferimento-Message-ID: [msgid]
+
+ The provider's service email address is obtained from the PEC
+ providers directory during the necessary queries made in the
+ signature verification stage.
+
+ The body contains a text part that follows the underlying model:
+
+ Server-server acceptance PEC notification
+ On [date] at [time] ([time zone]), the message "[subject]"
+ originating from "[original sender]" and addressed to:
+ [recipient_1]
+ [recipient_2]
+ [recipient_n]
+ was accepted by the system.
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ The same certification data is inserted in an XML file which is added
+ to the notification message to allow for automatic checks (section
+ 4.4). Parsing MUST be done on the XML part only. Additional parts
+ MAY be added by the provider for provider-specific services. The
+ message MUST follow the format described in section 4.3.
+
+3.2.2. PEC Anomaly Envelope
+
+ If the tests on an incoming message detect an error, or the message
+ is identified as being ordinary mail and the provider is set to
+ forward it to the recipient, the system MUST insert such a message in
+ a PEC anomaly envelope. Before delivery, the entire message received
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 25]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ at the Incoming Point is inserted in a format compliant with [EMAIL]
+ as a [MIME1] part inside a new message that MUST inherit the
+ unmodified values for the following header fields from the received
+ message:
+
+ o Received:
+
+ o To:
+
+ o Cc:
+
+ o Return-Path:
+
+ o Message-ID:
+
+ Whereas, the following header fields MUST be modified or inserted:
+
+ X-Trasplorto: errore
+ Date: [mlessage arrival date]
+ Subject: ANOMALIA MESSAGGIO: [original subject]
+ From: "On behalf of: [original sender]"
+ <posta-certificata@[mail_domain]>
+ Reply-To: [original sender (inserted only if not already
+ present)]
+
+ The body contains a user-readable text part according to a model that
+ relates the following data:
+
+ Message anomaly
+ On [date] at [time] ([time zone]), the message "[subject]"
+ originating from "[original sender]" and addressed to:
+ [recipient_1]
+ [recipient_2]
+ [recipient_n]
+ was received.
+ The data has not been certified due to the following error:
+ [concise description of error]
+ The original message is attached.
+
+ Due to uncertainty regarding origin and/or conformity of the message
+ received, the PEC anomaly envelope MUST NOT contain [MIME1] parts
+ other than the entire message that arrived at the Incoming Point.
+
+ Note that the routing data of such an envelope (forward and reverse
+ paths) remain unaltered. Doing so guarantees both message forwarding
+ to the recipients, and reception of SMTP error notifications, if any
+ occur, by the sender (as specified in [SMTP] and [SMTP-DSN]).
+
+
+
+
+Petrucci, et al. Informational [Page 26]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+3.2.3. Virus Detection PEC Notification
+
+ If the Incoming Point receives virus-infected PEC messages, it MUST
+ NOT forward them. Rather it MUST inform the sending provider, which
+ will in turn inform the sending user, of the failed transmission. A
+ separate PEC notification of virus detection MUST be sent on behalf
+ of every recipient within the provider's domain.
+
+ In case a virus is detected during the reception phase of a message
+ whose origin was asserted through sender signature verification, the
+ system generates a virus-detected PEC notification indicating the
+ error found, and sends it to the sending provider's service mailbox.
+
+ The header of this PEC notification contains the following fields:
+
+ X-Ricevuta: rilevazione-virus
+ X-Mittente: [original sender]
+ Date: [date of notification emission]
+ Subject: PROBLEMA DI SICUREZZA: [original subject]
+ From: posta-certificata@[mail domain]
+ To: [sender provider notifications]
+ X-Riferimento-Message-ID: [msgid]
+
+ The body contains a readable text part according to a model that
+ relates the following data:
+
+ Virus detection PEC notification
+ On [date] at [time] ([time zone]), in the message "[subject]"
+ originating from "[original sender]" and addressed to
+ "[recipient]"
+ a security problem was detected [ID of content type detected].
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ The same certification data is inserted in an XML file and added to
+ the notification to allow for automatic checks (section 4.4).
+ Parsing MUST be done on the XML part only. Additional parts MAY be
+ included by the provider for provider-specific services. Regardless,
+ the original message MUST NOT be included. The message MUST follow
+ the format described in section 4.3.
+
+ The message body MUST contain the reason for which the transmission
+ could not be completed.
+
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 27]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+3.2.4. Virus-Induced Delivery Error PEC notification
+
+ At the reception of a virus detection PEC notification from the
+ receiving provider, the sender provider emits a non-delivery PEC
+ notification to the sending user.
+
+ The header for this notification contains the following fields:
+
+ X-Ricevuta: errore-consegna
+ X-VerificaSicurezza: errore
+ Date: [date of notification emission]
+ Subject: AVVISO DI MANCATA CONSEGNA PER VIRUS: [original
+ subject]
+ From: posta-certificata@[mail domain]
+ To: [original sender]
+ X-Riferimento-Message-ID: [msgid]
+
+ The body contains a readable text part according to a model that
+ relates the following data:
+
+ Delivery error PEC notification due to virus
+ On [date] at [time] ([time zone]), in the message "[subject]"
+ addressed to "[recipient]"
+ a security problem was detected [ID of content type detected
+ by the anti-virus].
+ The message was not delivered.
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ All the information necessary for the construction of such a PEC
+ notification can be obtained from the correlated virus-detected PEC
+ notification.
+
+ The same certification data is inserted in an XML file and added to
+ the notification message to allow for automatic checks (section 4.4).
+ Parsing MUST be done on the XML part only. Additional parts MAY be
+ included by the provider for provider-specific services. The reason
+ the transaction was not completed MUST be specified in the message,
+ which MUST follow the format described in section 4.3.
+
+
+
+
+
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 28]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+3.3. Delivery Point
+
+3.3.1. Checks on Incoming Messages
+
+ When a message arrives at the Delivery Point, the system verifies:
+
+ o message type
+
+ o whether or not a PEC notification has to be returned.
+
+3.3.2. Delivery PEC Notification
+
+ A delivery PEC notification is issued only after a correct PEC
+ transport envelope (sections 2.2.2 and 3.1.5) has been delivered to
+ the recipient's mailbox.
+
+ In all other cases (e.g., PEC anomaly envelopes, PEC notifications),
+ the delivery PEC notification is not issued. Regardless, the message
+ received at the Delivery Point MUST be delivered to the recipient's
+ mailbox unchanged.
+
+ This notification tells the user that his/her message has been
+ successfully delivered to the specified recipient. It includes
+ readable text that certifies the date and time of delivery, sender
+ and receiver data, and the subject. It also contains an XML
+ certification data file and other optional parts for functionalities
+ offered by the provider.
+
+ The following fields are inserted in the header:
+
+ X-Ricevuta: avvenuta-consegna
+ Date: [delivery date]
+ Subject: CONSEGNA: [original subject]
+ From: posta-certificata@[mail domain]
+ To: [original sender]
+ X-Riferimento-Message-ID: [msgid]
+
+ The value of the "X-TipoRicevuta:" header field in the PEC transport
+ envelope is derived from the original message, thus allowing the
+ sender to determine the type of delivery PEC notification requested
+ from the primary recipients of the original message. The
+ notification MUST follow the format described in section 4.3.
+
+3.3.2.1. Delivery PEC Notification: Complete
+
+ This is the default value for delivery PEC notifications. When no
+ value for "X-TipoRicevuta:" is specified, or when it contains the
+ value "completa" (complete), the system will require a complete
+
+
+
+Petrucci, et al. Informational [Page 29]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ delivery PEC notification from addressees in the "To:" field, while a
+ concise PEC notification (section 3.3.2.3) will be required from
+ those in the "Cc:" field. The distinction between primary recipients
+ and those in carbon copy is done through an analysis of the "To:" and
+ "Cc:" fields. For PEC notifications sent on behalf of primary
+ recipients, a complete copy of the original message along with any
+ attachments is inserted in the notification. In case the system in
+ charge of delivery is not able to determine the recipient type due to
+ ambiguity problems in the "To:" and "Cc:" fields, delivery MUST be
+ considered as if addressed to a primary recipient and include the
+ complete copy of the original message.
+
+ The notification body contains a readable text part that relates
+ certification data according to the following model:
+
+ Delivery PEC notification
+ On [date] at [time] ([time zone]), the message "[subject]"
+ originating from "[original sender]" and addressed to
+ "[recipient]"
+ was placed in the destination's mailbox.
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ The same certification data is inserted in an XML file and added to
+ the notification (section 4.4), along with any other parts that MAY
+ be inserted by the provider for provider-specific services. Parsing
+ MUST be done on the XML part only. The delivery PEC notification
+ MUST be issued on behalf of every recipient of the message, and MUST
+ follow the format described in section 4.3.
+
+3.3.2.2. Delivery PEC Notification: Brief
+
+ In order to decrease the amount of data flowing, it is possible for
+ the sender to ask for a delivery PEC notification in "brief" format.
+ The brief delivery PEC notification contains the original message and
+ a ciphered hash value for each of its parts. The hash value SHOULD
+ be calculated on base64 encoded parts. As specified in section 5.3,
+ PEC messages MUST transit only on machines that belong to the PEC
+ network and that MUST NOT alter the encoding of the message during
+ its transition/processing.
+
+ NOTE: Even though PEC uses these relaxed specifications, PEC
+ interoperability tests between over 20 service providers have never
+ revealed any problems. This is probably due to mail servers leaning
+ more towards leaving the messages they receive intact without
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 30]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ applying any changes. But issues might arise if a server decides to
+ modify encoded parts; for example, change the base64 line length,
+ whose hash value calculated at the receiver's end would then differ
+ from that at the sender's side.
+
+ To be able to verify the transmitted contents it is necessary for the
+ sender to keep the unaltered original copy of the part(s) to which
+ the hash values refer.
+
+ If the PEC transport envelope contains the header:
+
+ X-TipoRicevuta: breve
+
+ the Delivery Point emits a brief delivery PEC notification on behalf
+ of the primary recipients, and a concise one (section 3.3.2.3) on
+ behalf of carbon copy recipients. The value of the header field in
+ the PEC transport envelope is derived from the original message.
+
+ The notification body contains a readable text part according to a
+ model that relates the following certification data:
+
+ Brief delivery PEC notification
+ On [date] at [time] ([time zone]), the message "[subject]"
+ originating from "[original sender]" and addressed to
+ "[recipient]"
+ was placed in the destination's mailbox.
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ The same certification data is inserted in an XML file and added to
+ the notification (section 4.4), along with other parts that MAY be
+ included for specific provider-supplied services. Parsing MUST be
+ done on the XML part only. The delivery PEC notification is issued
+ on behalf of every recipient of the message, and MUST follow the
+ format described in section 4.3.
+
+ The MIME structure of the original message is unaltered as it is
+ added to the notification, but each MIME part with a "name" parameter
+ in the header field "Content-Type:" or a "filename" parameter in the
+ header field "Content-Disposition:" MUST be substituted by a text
+ file containing that MIME part's hash value.
+
+ When the original message has an S/MIME format, it is necessary not
+ to alter the integrity of the message structure. Verification of the
+ S/MIME part in the original message takes place when the MIME type of
+ the top-level entity (which coincides with the message itself) is
+ checked. An S/MIME message MAY have the following MIME types (as per
+ [SMIMEV3]):
+
+
+
+Petrucci, et al. Informational [Page 31]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ o multipart/signed
+
+ Represents an original message signed by the sender using the
+ structure described in [MIME-SECURE]. The message is made up of
+ two MIME parts: the first is the message itself before the
+ application of the sender's signature, whereas the second contains
+ signature data. The second part (generally of type
+ "application/pkcs7-signature" or "application/x-pkcs-signature")
+ contains data added during the signing phase and MUST be left
+ unchanged to avoid compromising the overall message structure;
+
+ o "application/pkcs7-mime" or "application/x-pkcs7-mime"
+
+ The message is composed of a sole CMS object within the MIME part.
+ Given that attachments cannot be separated from the CMS object,
+ the MIME part is left intact (i.e., it is not replaced by the hash
+ value); therefore, the brief PEC notification is the same as the
+ complete PEC notification.
+
+ If the original message contains parts whose "Content-Type:" is
+ "message/rfc822", i.e., contains an email message as attachment, the
+ entire attached message is substituted with its corresponding hash
+ value.
+
+ Therefore, when emitting a brief delivery PEC notification, the
+ provider MUST:
+
+ 1. identify and extract all the parts from the first MIME part of the
+ multipart/signed S/MIME message;
+
+ 2. calculate the hash values of all the files attached by the sender
+ to the original message;
+
+ 3. substitute originals with their hash values.
+
+ In general, in the case of original messages in S/MIME format, the
+ copy of the message inserted within the brief delivery PEC
+ notification will have the following characteristics:
+
+ o if the original message is signed, the S/MIME structure and
+ signature-relative data will remain unchanged. The message will
+ generate an error in a future signature integrity verification
+ phase following the substitution of attachments with the
+ corresponding hash values.
+
+ o if the original message contains the "application/pkcs7-mime" or
+ "application/x-pkcs7-mime" MIME type, attachments present in the
+ message will not be substituted by their hash values, due to
+
+
+
+Petrucci, et al. Informational [Page 32]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ impossibility of identification within a CMS structure. The
+ content of the brief delivery PEC notification will coincide with
+ that of a normal delivery PEC notification.
+
+ The algorithm used for hash calculation is the [SHA1], calculated on
+ the entire content of the part. To allow distinction between hash
+ files and the files to which they refer, the suffix ".hash" is added
+ to the original filename. The hash value is written in the file
+ using a hexadecimal representation as a single sequence of 40
+ characters. The MIME type of these attachments is set to
+ "text/plain" to highlight their textual nature.
+
+3.3.2.3. Delivery PEC Notification: Concise
+
+ If the PEC transport envelope contains the header:
+
+ X-TipoRicevuta: sintetica
+
+ the Delivery Point emits, both to primary and carbon copy recipients,
+ a concise delivery PEC notification that does not contain the
+ original message.
+
+ The message body of the notification contains a readable text part
+ according to a model that relates the following certification data:
+
+ Concise delivery PEC notification
+ On [date] at [time] ([time zone]), the message "[subject]"
+ originating from "[original sender]" and addressed to
+ "[recipient]"
+ was placed in the destination's mailbox.
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ The same certification data is inserted within an XML file and added
+ to the notification (section 4.4), along with additional parts that
+ MAY be included for provider-specific services. Parsing MUST be done
+ on the XML part only. The notification is sent to each one of the
+ recipients to whom the message is delivered, and MUST follow the
+ format described in section 4.3.
+
+ The concise delivery PEC notification follows the same emission rules
+ as the delivery PEC notification; added to it is only the XML file
+ containing the certification data, not the original message.
+
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 33]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+3.3.3. Non-Delivery PEC Notification
+
+ If an error occurs during the delivery of a correct PEC transport
+ message, the system returns to the sender a non-delivery PEC
+ notification that indicates the error condition.
+
+ The header will contain the following fields:
+
+ X-Ricevuta: errore-consegna
+ Date: [date of notification emission]
+ Subject: AVVISO DI MANCATA CONSEGNA: [original subject]
+ From: posta-certificata@[mail domain]
+ To: [original sender]
+ X-Riferimento-Message-ID: [msgid]
+
+ The notification body contains a readable text part according to a
+ model that relates the following data:
+
+ Non-delivery PEC notification
+ On [date] at [time] ([time zone]), in the message "[subject]"
+ originating from "[original sender]" and addressed to
+ "[recipient]"
+ an error was detected [brief error description].
+ The message was refused by the system.
+ Message identifier: [PEC msgid of corresponding
+ PEC transport envelope]
+
+ The same certification data is inserted within an XML file and added
+ to the notification in order to allow for automatic checks (section
+ 4.4). Parsing MUST be done on the XML part only. Additional parts
+ MAY be included by the PEC provider for provider-specific services.
+ The notification MUST follow the format described in section 4.3.
+
+3.4. Sender and Receiver Belonging to the Same Domain
+
+ PEC messages MUST be processed even if both sender and receiver(s)
+ belong to the same PEC domain.
+
+3.5. Example: Complete Transaction between Two PEC Domains
+
+ A correct transaction between two PEC domains goes through the
+ following steps:
+
+ o The sending user sends an email to his provider's Access Point;
+
+ o The Access Point runs all checks and emits a server-user
+ acceptance PEC notification to the user;
+
+
+
+
+Petrucci, et al. Informational [Page 34]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ o The Access Point creates a PEC transport envelope and forwards it
+ to the Incoming Point of the receiving provider;
+
+ o The receiver's Incoming Point verifies the PEC transport envelope
+ and creates a server-server acceptance PEC notification to be sent
+ to the sending provider;
+
+ o The sender's Incoming Point verifies the validity of the server-
+ server acceptance PEC notification and forwards it to the Delivery
+ Point;
+
+ o The sender's Delivery Point saves the server-server acceptance PEC
+ notification in the provider's service mailbox;
+
+ o The receiver's Incoming Point forwards the PEC transport envelope
+ to the receiver's Delivery Point;
+
+ o The receiver's Delivery Point verifies the contents of the PEC
+ transport envelope and saves it in the recipient's mailbox;
+
+ o The receiver's Delivery Point creates a delivery PEC notification
+ and sends it to the sender's Incoming Point;
+
+ o The sender's Incoming Point verifies the validity of the delivery
+ PEC notification and forwards it to the sender's Delivery Point;
+
+ o The sender's Delivery Point saves the delivery PEC notification in
+ the sending user's mailbox;
+
+ o The receiving user has the message at his disposition.
+
+ NOTE: Some of these steps might occur in parallel, thus the
+ interaction might complete in a different order.
+
+4. Formats
+
+4.1. Temporal Reference
+
+ For all operations carried out during message, notification, and log
+ elaboration processes by the Access, Incoming, and Delivery Points,
+ it is necessary to have an accurate temporal reference available.
+ All events (generation of PEC notifications, transport envelopes,
+ logs, etc.) that constitute the transaction of message elaboration at
+ the Access, Incoming, and Delivery Points MUST employ a sole temporal
+ value obtained from within the transaction itself.
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 35]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ Doing this renders the instant of message elaboration unambiguous
+ within PEC logs, notifications, messages, etc., generated by the
+ server.
+
+4.2. User Date/Time
+
+ Temporal indications supplied by the service in readable format (text
+ in PEC notifications, transport envelopes, etc.) are provided with
+ reference to the legal time at the moment of the operation.
+ Following is the specification using the syntax description notation
+ defined in [ABNF].
+
+ date-fullyear = 4DIGIT
+ date-month = 2DIGIT ; 01-12
+ date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
+ ; month/year
+ time-hour = 2DIGIT ; 00-23
+ time-minute = 2DIGIT ; 00-59
+ time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
+ ; rules
+
+ time-offset = "(" ("+" / "-") time-hour ":" time-minute ")"
+
+ partial-time = time-hour ":" time-minute ":" time-second
+
+ full-date = date-mday "/" date-month "/" date-fullyear
+ full-time = partial-time time-offset
+
+ NOTE: For number of days in a month, leap year, and leap second
+ restrictions see section 5.7 of [TIMESTAMP].
+
+4.3. Format of a PEC Message Body
+
+ This section describes the characteristics of the various components
+ of PEC messages and notifications generated by a PEC system. If one
+ of the message parts contains characters with values outside of the
+ range 0-127 (7-bit ASCII), that part will have to be adequately
+ encoded so that 7-bit transportation compatibility is guaranteed
+ (e.g., quoted-printable, base64 as per [MIME1]).
+
+ Before applying the signature, the message body has Content-Type:
+ multipart/mixed. Each part is described in the sections below. The
+ first part is the user readable text generated by the PEC system,
+ while the second and third parts are interchangeable in order and
+ contain the original message and the XML file for the certification
+ data.
+
+
+
+
+
+Petrucci, et al. Informational [Page 36]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+4.3.1. User Readable Text
+
+ Character set: ISO-8859-1 (Latin-1)
+ MIME type: text/plain or multipart/alternative
+
+ The multipart/alternative MIME type MAY be used to add an HTML
+ version of the body of system-generated messages. In this case, two
+ sub-parts MUST be present: one of type text/plain, the other
+ text/html. For the HTML part:
+
+ o it MUST contain the same information as related in the text part;
+
+ o it MUST NOT contain references to elements (e.g., images, sounds,
+ font, style sheets), neither internal to the message (added MIME
+ parts) nor external (e.g., hosted on the provider's server);
+
+ o it MUST NOT have active content (e.g., JavaScript, VBscript, Plug-
+ in, ActiveX).
+
+4.3.2. Original Message
+
+ MIME type: message/rfc822
+ Attachment name: postacert.eml
+
+4.3.3. Certification Data
+
+ Character set: UTF-8
+ MIME type: application/xml
+ Attachment name: certdata.xml
+
+4.4. Certification Data Scheme
+
+ Following is the DTD relative to the [XML] file that contains
+ certification data attached to PEC notifications.
+
+ <!--Use the element "postacert" as root-->
+ <!--"tipo" indicates the typology of the PEC message-->
+ <!--The attribute "errore" can have the following values-->
+ <!--"nessuno" = no error-->
+ <!--"no-dest" (with type="errore-consegna") = -->
+ <!-- wrong recipient-->
+ <!--"no-dominio" (with type="errore-consegna") = -->
+ <!-- wrong domain-->
+ <!--"virus" (with type="errore-consegna") = virus-->
+ <!--"virus" (with type="non-accettazione") = virus-->
+ <!--"altro" = generic error-->
+ <!ELEMENT postacert (intestazione, dati)>
+ <!ATTLIST postacert
+
+
+
+Petrucci, et al. Informational [Page 37]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ tipo (accettazione |
+ non-accettazione |
+ presa-in-carico |
+ avvenuta-consegna |
+ posta-certificata |
+ errore-consegna |
+ preavviso-errore-consegna |
+ rilevazione-virus) #REQUIRED
+ errore (nessuno |
+ no-dest |
+ no-dominio |
+ virus |
+ altro) "nessuno">
+
+ <!--Header of the original message-->
+ <!ELEMENT intestazione (mittente,
+ destinatari+,
+ risposte,
+ oggetto?)>
+
+ <!--Sender ("From:" field) of the original message-->
+ <!ELEMENT mittente (#PCDATA)>
+
+ <!--Complete list of recipients ("To:" and "Cc:" fields)-->
+ <!--of the original message-->
+ <!--"tipo" indicates the typology of the recipient-->
+ <!ELEMENT destinatari (#PCDATA)>
+ <!ATTLIST destinatari
+ tipo (certificato | esterno) "certificato">
+
+ <!--Value of the "Reply-To:" field of the original message-->
+ <!ELEMENT risposte (#PCDATA)>
+ <!--Value of the "Subject:" field of the original message-->
+ <!ELEMENT oggetto (#PCDATA)>
+
+ <!--PEC message data-->
+ <!ELEMENT dati (gestore-emittente,
+ data,
+ identificativo,
+ msgid?,
+ ricevuta?,
+ consegna?,
+ ricezione*,
+ errore-esteso?)>
+
+ <!--Descriptive string of the provider that certifies -->
+ <!--the data-->
+ <!ELEMENT gestore-emittente (#PCDATA)>
+
+
+
+Petrucci, et al. Informational [Page 38]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ <!--Date/time of message elaboration-->
+ <!--"zona" is the difference between local time and UTC in -->
+ <!--"[+|-]hhmm" format-->
+ <!ELEMENT data (giorno, ora)>
+ <!ATTLIST data
+ zona CDATA #REQUIRED>
+
+ <!--Day in "dd/mm/yyyy" format-->
+ <!ELEMENT giorno (#PCDATA)>
+ <!--Local hour in "hh:mm:ss" format-->
+ <!ELEMENT ora (#PCDATA)>
+
+ <!--PEC msgid-->
+ <!ELEMENT identificativo (#PCDATA)>
+
+ <!--msgid of the original message before modifications-->
+ <!ELEMENT msgid (#PCDATA)>
+
+ <!--For PEC transport envelopes and delivery notifications-->
+ <!--indicate the type of PEC notification requested by the-->
+ <!--sender-->
+ <!ELEMENT ricevuta EMPTY>
+ <!ATTLIST ricevuta
+ tipo (completa |
+ breve |
+ sintetica ) #REQUIRED>
+
+ <!--For delivery, non-delivery, virus-induced non-delivery, -->
+ <!-- virus detection, and timeout PEC notifications-->
+ <!--Recipient address to which delivery has been carried -->
+ <!--out/tried-->
+ <!ELEMENT consegna (#PCDATA)>
+ <!--For server-server acceptance PEC notifications-->
+ <!--recipients for whom it is the relative PEC notification-->
+ <!ELEMENT ricezione (#PCDATA)>
+
+ <!--In case of error-->
+ <!--brief description of the error-->
+ <!ELEMENT errore-esteso (#PCDATA)>
+
+4.5. PEC Providers Directory Scheme
+
+ The PEC providers directory is created through a centralized LDAP
+ server that contains the providers' data and their corresponding PEC
+ mail domains.
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 39]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ The following are the directory scheme's attributes:
+
+ - providerCertificateHash: hash of provider's certificate
+
+ - providerCertificate: provider certificate
+
+ - providerName: provider name
+
+ - mailReceipt: provider reception email address
+
+ - managedDomains: managed domains
+
+ - LDIFLocationURL: provider LDIF record URL
+
+ - providerUnit: secondary operating environment name
+
+ The directory's base root is "o=postacert" and the
+ "DistinguishedName" of single records is of the type
+ "<providerName=<name>,o=postacert>". Search within the directory is
+ carried out mainly in case-sensitive mode using the
+ "providerCertificateHash" attribute (during envelope signature
+ verification phase) or the "managedDomains" attribute (during message
+ acceptance phase). It is possible for the record of a single
+ provider to contain multiple "providerCertificate" attributes with
+ the related "providerCertificateHash" attributes in order to allow
+ the handling of the renewal of expiring certificates. The provider
+ MUST make sure to update its record with sufficient advance before
+ the certificate expiration date, by adding a new certificate whose
+ validity overlaps that of the previous one.
+
+ The data of all PEC providers is encompassed in a [LDIF] file, which
+ is available as an [HTTPS] object and can be found at the URL to
+ which the 'LDIFLocationURL' attribute in the "dn: o=postacert" record
+ points (see section 4.5.6). To guarantee authenticity, that file
+ MUST be signed by the provider for the operations regarding its PEC
+ services using the method described for single providers. The file,
+ the signature, and the X.509v3 certificate MUST be inserted in a
+ PKCS#7 structure in binary ASN.1 DER format as a file with ".p7m"
+ extension. The centralized [LDAP] system downloads that file on a
+ daily basis and, after suitable verifications of the signature,
+ applies it to the provider's record.
+
+ Through the [LDIF] file, single providers MUST keep a copy of the
+ directory locally, updated on a daily basis, in order to improve
+ system performance by avoiding continuous request dispatches to the
+ central system for every message elaboration phase.
+
+
+
+
+
+Petrucci, et al. Informational [Page 40]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ If secondary environments are present, the [LDIF] file indicated in
+ the main environment's record MUST relate the contents of all the
+ provider-relevant records.
+
+ NOTE: This specification uses an unregistered LDAP DN name space
+ that may lead to conflict with other registered or
+ unregistered names.
+
+4.5.1. providerCertificateHash Attribute
+
+ The 'providerCertificateHash' attribute is a hexadecimal
+ representation of the hash in SHA1 format of the X.509v3 certificate
+ used by the provider for PEC notifications and envelope signatures.
+
+ ( 1.3.6.1.4.1.16572.2.2.1 NAME 'providerCertificateHash'
+ DESC 'Hash SHA1 of X.509 certificate in hexadecimal format'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ The IA5String ( 1.3.6.1.4.1.1466.115.121.1.26 ) syntax is defined in
+ [LDAP-SYNTAXES].
+
+4.5.2. providerCertificate Attribute
+
+ The 'providerCertificate' attribute holds a set of certificate(s)
+ used by the provider to sign PEC notifications and transport
+ envelopes.
+
+ ( 1.3.6.1.4.1.16572.2.2.2 NAME 'providerCertificate'
+ DESC 'X.509 certificate in ASN.1 DER binary format'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+ The Certificate syntax ( 1.3.6.1.4.1.1466.115.121.1.8 ) is defined in
+ [RFC4523].
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "providerCertificate;binary" [RFC4522].
+
+4.5.3. providerName Attribute
+
+ The 'providerName' attribute contains the name of the PEC provider.
+ All records MUST contain their provider's name in this attribute.
+
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 41]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ ( 1.3.6.1.4.1.16572.2.2.3 NAME 'providerName'
+ DESC 'PEC provider name'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is
+ defined in [LDAP-SYNTAXES].
+
+4.5.4. mailReceipt Attribute
+
+ The 'mailReceipt' attribute contains the provider's email address
+ within the provider to which server-server acceptance and virus
+ detection PEC notifications are sent. This address is a limited
+ version of the addr-spec construct described in [EMAIL] (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.
+
+ ( 1.3.6.1.4.1.16572.2.2.4 NAME 'mailReceipt'
+ DESC 'E-mail address of the service mailbox'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE )
+
+ The IA5String ( 1.3.6.1.4.1.1466.115.121.1.26 ) syntax is defined in
+ [LDAP-SYNTAXES].
+
+4.5.5. managedDomains Attribute
+
+ The 'managedDomains' attribute holds a set of domains [SMTP] that are
+ handled by a PEC provider. Domains are limited to dot-atom form
+ ([RFC1034], [EMAIL]).
+
+ ( 1.3.6.1.4.1.16572.2.2.5 NAME 'managedDomains'
+ DESC 'Domains handled by the PEC provider'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ The IA5String ( 1.3.6.1.4.1.1466.115.121.26 ) syntax is defined in
+ [LDAP-SYNTAXES].
+
+ The 'managedDomains' attribute holds a set of domains [SMTP] that are
+ handled by a PEC provider. Domains are limited to dot-atom form
+ ([RFC1034], [EMAIL]).
+
+
+
+Petrucci, et al. Informational [Page 42]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+4.5.6. LDIFLocationURL Attribute
+
+ 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.
+
+ Secondary environment records MUST NOT contain the 'LDIFLocationURL'
+ attribute which is obtained from the main environment's attributes
+ for all records connected to the provider.
+
+ ( 1.3.6.1.4.1.16572.2.2.6 NAME 'LDIFLocationURL'
+ DESC 'URL of the LDIF file that defines the entry'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is
+ defined in [LDAP-SYNTAXES].
+
+4.5.7. providerUnit Attribute
+
+ The 'providerUnit' attribute contains the name of secondary operating
+ environments -- an attribute not present for the main environment.
+ It is possible for the provider to define several distinct records,
+ each indicating a single, different, secondary operating environment,
+ for which it is possible to declare specific attributes that are, if
+ need be, distinct from those relative to the main and other
+ environments.
+
+ The "DistinguishedName" of the records relative to the secondary
+ operating environments are of the type
+ "<providerUnits=<environment>,providerName=<name>,o=postacert>".
+ Every provider MUST have a record associated to its own main
+ environment, distinguishable for the absence of the "providerUnit"
+ attribute within the record and the DistinguishedName.
+
+ ( 1.3.6.1.4.1.16572.2.2.7 NAME 'providerUnit'
+ DESC 'Name of the secondary operative environment'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+
+
+
+
+Petrucci, et al. Informational [Page 43]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ The Directory String ( 1.3.6.1.4.1.1466.115.121.1.15 ) syntax is
+ defined in [LDAP-SYNTAXES].
+
+4.5.8. LDIFLocationURLObject Object Class
+
+ The schema definition of the 'LDIFLocationURLObject' object class:
+
+ ( 1.3.6.1.4.1.16572.2.1.1 NAME 'LDIFLocationURLObject'
+ SUP top AUXILIARY
+ MAY ( LDIFLocationURL ) )
+
+4.5.9. Provider Object Class
+
+ The schema definition of the 'provider' object class:
+
+ ( 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 )
+
+4.5.10. LDIF File Example
+
+ The following LDIF file represents an example of a providers'
+ directory, containing a base root and two fictitious providers. The
+ inserted certificates are two self-signed certificates used for
+ example purposes only:
+
+ dn: o=postacert
+ objectclass: top
+ objectclass: organization
+ objectClass: LDIFLocationURLObject
+ o: postacert
+ LDIFLocationURL: https://igpec.rupa.example.com/igpec.ldif.p7m
+ description: Base root for the PEC providers directory
+ dn: providerName=Anonymous Certified Mail S.p.A.,o=postacert
+ objectclass: top
+ objectclass: provider
+ providerName: Anonymous Certified Mail S.p.A.
+ providerCertificateHash:
+ 7E7AEF1059AE0F454F2643A95F69EC3556009239
+ providerCertificate;binary::
+
+
+
+Petrucci, et al. Informational [Page 44]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw
+ JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu
+ QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX
+ J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG
+ A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG
+ EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh
+ bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK
+ KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC
+ 2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf
+ alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB
+ wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw
+ SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT
+ AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC
+ 5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl
+ cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B
+ Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA
+ XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9
+ 5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw==
+ mailReceipt: ssacceptance@postalser.example.com
+ LDIFLocationURL: https://anpocert.example.com/anpocert.ldif.p7m
+ managedDomains: mail.anpocert.example.com
+ managedDomains: cert.company.example.com
+ managedDomains: costmec.example.com
+ description: Certified mail services for companies
+
+ dn: providerName=Postal Services S.p.A,o=postacert
+ objectclass: top
+ objectclass: provider
+ providerName: Postal Services S.p.A
+ providerCertificateHash:
+ e00fdd9d88be0e2cc766b893315caf93d5701a6a
+ providerCertificate;binary::
+ MIIDHjCCAoegAwIBAgIBADANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEw
+ JJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIFMuci5sLjEPMA0GA1UE
+ CxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0YS1jZXJ0aWZpY2F0YU
+ BzZXJwb3N0YWwuaXQwHhcNMDIxMjA5MTczMjE2WhcNMDMxMjA5MTczMjE2
+ WjBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIF
+ Muci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0
+ YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQ
+ ADgY0AMIGJAoGBAKoc7n6zA+sO8NATMcfJ+U2aoDEsrj/cObG3QAN6Sr+l
+ ygWxYXLBZNfSDWqL1K4edLr4gCZIDFsq0PIEaYZhYRGjhbcuJ9H/ZdtWdX
+ xcwEWN4mwFzlsASogsh5JeqS8db3A1JWkvhO9EUfaCYk8YMAkXYdCtLD9s
+ 9tCYZeTE2ut9AgMBAAGjgcswgcgwHQYDVR0OBBYEFHPw7VJIoIM3VYhuHa
+ eAwpPF5leMMIGYBgNVHSMEgZAwgY2AFHPw7VJIoIM3VYhuHaeAwpPF5leM
+ oXKkcDBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YW
+ xpIFMuci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5w
+ b3N0YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXSCAQAwDAYDVR0TBAUwAw
+ EB/zANBgkqhkiG9w0BAQQFAAOBgQApqeXvmOyEjwhMrXezPAXELMZwv4qq
+
+
+
+Petrucci, et al. Informational [Page 45]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ r5ri4XuxTq6sS9jRsEbZrS+NmbcJ7S7eFwNQMNxYFVJqdWoLh8qExsTLXn
+ sKycSnHbCfuphrKvXjQvR2da75U4zGSkroiyvJ2s9TtiCcT3lQtIjmvrFb
+ aSBiyzj+za7foFUCQmxCLtDaA==
+ mailReceipt: takecharge@postalser.example.com
+ LDIFLocationURL: https://postalser.example.com/ldif.txt.p7m
+ managedDomains: postal-services.example.com
+ managedDomains: receivedmail.example.com
+ description: Certified mail services for the public
+
+ The following LDIF file represents an example of a PEC providers'
+ directory, containing a base root and two fictitious providers, the
+ first of which handles a secondary environment as well. The
+ certificates inserted are two self-signed certificates used for
+ example purposes only:
+
+ dn: o=postacert
+ objectclass: top
+ objectclass: organization
+ objectClass: LDIFLocationURLObject
+ o: postacert
+ LDIFLocationURL: https://igpec.rupa.example.com/igpec.ldif.p7m
+ description: Base root for the PEC providers directory
+
+ dn: providerName=Anonymous Certified Mail S.p.A.,o=postacert
+ objectclass: top
+ objectclass: provider
+ providerName: Anonymous Certified Mail S.p.A.
+
+ providerCertificateHash:
+ 7E7AEF1059AE0F454F2643A95F69EC3556009239
+ providerCertificate;binary::
+ MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw
+ JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu
+ QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX
+ J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG
+ A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG
+ EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh
+ bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK
+ KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC
+ 2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf
+ alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB
+ wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw
+ SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT
+ AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC
+ 5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl
+ cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B
+ Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA
+ XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9
+
+
+
+Petrucci, et al. Informational [Page 46]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ 5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw==
+ mailReceipt: notifications@anpocert.it.example
+ LDIFLocationURL: http://anpocert.example.com/anpocert.ldif.p7m
+ managedDomains: mail.anpocert.example.com
+ managedDomains: cert.company.example.com
+ managedDomains: costmec.example.com
+ description: Certified mail services for companies
+ dn: providerUnit=Secondary Environment, providerName=Anonymous
+ Certified Mail S.p.A.,o=postacert
+ objectclass: top
+ objectclass: provider
+ providerName: Certified Mail S.p.A.
+ providerUnit: Secondary Environment
+ providerCertificateHash:
+ 7E7AEF1059AE0F454F2643A95F69EC3556009239
+ providerCertificate;binary::
+ MIIDBjCCAm+gAwIBAgIBADANBgkqhkiG9w0BAQQFADBmMQswCQYDVQQGEw
+ JJVDEpMCcGA1UEChMgQW5vbmltYSBQb3N0YSBDZXJ0aWZpY2F0YSBTLnAu
+ QS4xLDAqBgkqhkiG9w0BCQEWHXBvc3RhLWNlcnRpZmljYXRhQGFucG9jZX
+ J0Lml0MB4XDTAyMTIwOTE3MjQxNVoXDTAzMTIwOTE3MjQxNVowZjELMAkG
+ A1UEBhMCSVQxKTAnBgNVBAoTIEFub25pbWEgUG9zdGEgQ2VydGlmaWNhdG
+ EgUy5wLkEuMSwwKgYJKoZIhvcNAQkBFh1wb3N0YS1jZXJ0aWZpY2F0YUBh
+ bnBvY2VydC5pdDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr8J+qK
+ KdxV9LzDMPqwnEy0P8H/KwbI0Szs8p6UZajZdpeUK0Ncbrv1QyXZNNtSMC
+ 2uL09HDyx8agjgZWdhypnehguiSK3busha15RSpMGhiqxmz2b0HhOG73Gf
+ alZelqrwqmElna4MNUaLhbOvTd/sqPUS378w5IaIhWxzy34XcCAwEAAaOB
+ wzCBwDAdBgNVHQ4EFgQUN8lC0znQWEs0xspZ/aBzsaGvRZMwgZAGA1UdIw
+ SBiDCBhYAUN8lC0znQWEs0xspZ/aBzsaGvRZOhaqRoMGYxCzAJBgNVBAYT
+ AklUMSkwJwYDVQQKEyBBbm9uaW1hIFBvc3RhIENlcnRpZmljYXRhIFMucC
+ 5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl
+ cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B
+ Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA
+ XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9
+ 5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw==
+ mailReceipt: notifications@secondary.anpocert.example.com
+ managedDomains: management.anpocert.example.com
+ managedDomains: personnel.anpocert.example.com
+ description: Corporate internal services
+ dn: providerName=Postal Services S.r.l.,o=postacert
+ objectclass: top
+ objectclass: provider
+ providerName: Postal Services S.r.l.
+ providerCertificateHash:
+ e00fdd9d88be0e2cc766b893315caf93d5701a6a
+ providerCertificate;binary::
+ MIIDHjCCAoegAwIBAgIBADANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEw
+ JJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIFMuci5sLjEPMA0GA1UE
+ CxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0YS1jZXJ0aWZpY2F0YU
+
+
+
+Petrucci, et al. Informational [Page 47]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ BzZXJwb3N0YWwuaXQwHhcNMDIxMjA5MTczMjE2WhcNMDMxMjA5MTczMjE2
+ WjBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIF
+ Muci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0
+ YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQ
+ ADgY0AMIGJAoGBAKoc7n6zA+sO8NATMcfJ+U2aoDEsrj/cObG3QAN6Sr+l
+ ygWxYXLBZNfSDWqL1K4edLr4gCZIDFsq0PIEaYZhYRGjhbcuJ9H/ZdtWdX
+ xcwEWN4mwFzlsASogsh5JeqS8db3A1JWkvhO9EUfaCYk8YMAkXYdCtLD9s
+ 9tCYZeTE2ut9AgMBAAGjgcswgcgwHQYDVR0OBBYEFHPw7VJIoIM3VYhuHa
+ eAwpPF5leMMIGYBgNVHSMEgZAwgY2AFHPw7VJIoIM3VYhuHaeAwpPF5leM
+ oXKkcDBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YW
+ xpIFMuci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5w
+ b3N0YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXSCAQAwDAYDVR0TBAUwAw
+ EB/zANBgkqhkiG9w0BAQQFAAOBgQApqeXvmOyEjwhMrXezPAXELMZwv4qq
+ r5ri4XuxTq6sS9jRsEbZrS+NmbcJ7S7eFwNQMNxYFVJqdWoLh8qExsTLXn
+ sKycPSnHbCfuphrKvXjQvR2da75U4zGSkroiyvJ2s9TtiCcT3lQtIjmvrF
+ baSBiyzj+za7foFUCQmxCLtDaA==
+ mailReceipt: ssacceptance@postalser.example.com
+ LDIFLocationURL: http://postalser.example.com/ldif.txt.p7m
+ managedDomains: postal-services.example.com
+ managedDomains: receivedmail.example.com
+ description: Certified mail services for the public
+
+5. Security-Related Aspects
+
+5.1. Digital Signature
+
+ It is recommended that a dedicated hardware module be used to handle
+ private key and signature operations, the specifications of which are
+ outside the scope of this document. It's up to the PEC providers to
+ conform to security requisites expected for the service.
+
+5.2. Authentication
+
+ User access to PEC services through the Access Point MUST be allowed
+ only upon successful user authentication on the system.
+
+ For example, authentication might use user-ID and password, or, if
+ available and considered necessary for the type of service provided,
+ an electronic ID card or the national services card. Choice of
+ authentication method is left to the better judgment of the service
+ provider. Authentication is necessary to guarantee as much as
+ possible that the message is sent by a PEC user whose identification
+ data is congruent with the specified sender, so as to avoid
+ falsification of the latter.
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 48]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+5.3. Secure Interaction
+
+ To guarantee that the original message remains unaltered during
+ transaction, envelopment and signature are applied on outgoing
+ messages at the Access Point, and subsequent verification of incoming
+ messages is done at the Incoming Point.
+
+ All communications within the PEC network MUST use secure channels.
+ Integrity and confidentiality of connections between PEC provider and
+ user MUST be guaranteed through the use of secure protocols, such as
+ those based on [TLS] and those that create a secure transport channel
+ on which non-secure protocols can transmit (e.g., IPsec).
+
+ The interaction between providers MUST take place using SMTP on
+ [TLS], as per [SMTP-TLS]. The Incoming Point MUST provide and
+ announce its support for the STARTTLS extension, as well as accept
+ both unencrypted connections (for ordinary mail) and protected ones.
+ To guarantee complete traceability in the flow of PEC messages, these
+ MUST NOT transit on systems external to the PEC network. When
+ exchanging messages between different providers, all transactions
+ MUST take place between machines that belong to the PEC network or
+ are directly managed by the provider. An "MX" type record MAY be
+ associated to each PEC domain defined within the system for name
+ resolution, in which case secondary reception systems specified in
+ that record MUST be under direct control of the provider. All in
+ conformance with [SMTP].
+
+5.4. Virus
+
+ Another important security aspect that concerns the PEC system, is
+ related to the technical and functional architecture that MUST block
+ the presence of viruses from endangering the security of all handled
+ messages. It is therefore REQUIRED to have installations and
+ continuous updates of anti-virus systems that hinder infections as
+ much as possible without intervening on the content of the certified
+ mail, in compliance with what has been discussed thus far.
+
+5.5. S/MIME Certificate
+
+ In this document the S/MIME certificate profile is defined for use in
+ the certification of PEC messages done by the providers. The
+ proposed profile of the S/MIME certificate is based on the IETF
+ standards [SMIMECERT] and [CRL], which in turn are based on the
+ standard ISO/IEC 9594-8:2001.
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 49]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+5.5.1. Provider-Related Information (Subject)
+
+ The information related to the PEC provider holder of the certificate
+ MUST be inserted in the Subject field (Subject DN). More precisely,
+ the Subject DN MUST contain the PEC provider's name as it is in the
+ "providerName" attribute published in the PEC providers directory
+ (section 4.5), but the Subject DN does not have to match the Provider
+ entry DN in the LDIF. The providerName MUST be present in the
+ CommonName or OrganizationName attributes of the "Subject:" field in
+ the certificate.
+
+ Certificates MUST contain an Internet mail address, which MUST have a
+ value in the subjectAltName extension, and SHOULD NOT be present in
+ the Subject Distinguished Name.
+
+ Valid subjectDN are:
+
+ C=IT, O=AcmePEC S.p.A, CN=Posta Certificata
+
+ C=IT, O=ServiziPEC S.p.A, CN=Posta Certificata
+
+ Valorization of other attributes in the Subject DN, if present, MUST
+ be done in compliance with [CRL].
+
+5.5.2. Certificate Extensions
+
+ Extensions that MUST be present in the S/MIME certificate are:
+
+ o Key Usage
+
+ o Authority Key Identifier
+
+ o Subject Key Identifier
+
+ o Subject Alternative Name
+
+ The Basic Constraints extension (Object ID:2.5.29.19) MUST NOT be
+ present.
+
+ The valorization of the above listed extensions for the described
+ profile follows.
+
+ The Key Usage extension (Object ID: 2.5.29.15) MUST have the
+ digitalSignature bit (bit 0) activated and MUST be marked as
+ critical. The extension MAY contain other active bits corresponding
+ to different Key Usage, as long as that doesn't contrast with the
+ indications in [CRL].
+
+
+
+
+Petrucci, et al. Informational [Page 50]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ The Authority Key Identifier (Object ID: 2.5.29.35) MUST contain at
+ least the keyIdentifier field and MUST NOT be marked as critical.
+
+ The Subject Key Identifier extension (Object ID: 2.5.29.14) MUST
+ contain at least the keyIdentifier field and MUST NOT be marked as
+ critical.
+
+ The Subject Alternative Name (Object ID: 2.5.29.17) MUST contain at
+ least the rfc822Name field and MUST NOT be marked as critical.
+
+ Adding other extensions that have not been described in this document
+ is to be considered OPTIONAL, as long as it remains compliant with
+ [CRL]; such added extensions MUST NOT be marked as critical.
+
+5.5.3. Example
+
+ Following is an example of an S/MIME certificate compliant with the
+ minimal requisites described in this profile. Values used are of
+ fictitious providers generated for example purposes only.
+
+5.5.3.1. General-Use Certificate in Annotated Version
+
+ An asterisk near the label of an extension means that such an
+ extension has been marked as critical.
+
+ VERSION: 3
+ SERIAL: 11226 (0x2bda)
+ INNER SIGNATURE:
+ ALG. ID: id-sha1-with-rsa-encryption
+ PARAMETER: 0
+ ISSUER:
+ Country Name: IT
+ Organization Name: Certifier 1
+ Organizational Unit Name: Certification Service Provider
+ Common Name: Certifier S.p.A.
+ VALIDITY:
+ Not Before: Oct 5, 04 09:04:23 GMT
+ Not After: Oct 5, 05 09:04:23 GMT
+ SUBJECT:
+ Country Name: IT
+ Organization Name: AcmePEC S.p.A.
+ Common Name: Certified Mail
+ PUBLIC KEY: (key size is 1024 bits)
+ ALGORITHM:
+ ALG. ID: id-rsa-encryption
+ PARAMETER: 0
+ MODULUS: 0x00afbeb4 5563198a aa9bac3f 1b29b5be
+ 7f691945 89d01569 ca0d555b 5c33d7e9
+
+
+
+Petrucci, et al. Informational [Page 51]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ ...
+ d15ff128 6792def5 b3f884e6 54b326db
+ cf
+ EXPONENT: 0x010001
+ EXTENSIONS:
+ Subject Alt Name:
+ RFC Name: posta-certificata@acmepec.it
+ Key Usage*: Digital Signature
+ Authority Key Identifier: 0x12345678 aaaaaaaa bbbbbbbb
+ cccccccc dddddddd
+ Subject Key Identifier: 0x3afae080 6453527a 3e5709d8 49a941a8
+ a3a70ae1
+ SIGNATURE:
+ ALG. ID: id-sha1-with-rsa-encryption
+ PARAMETER: 0
+ VALUE: 0x874b4d25 70a46180 c9770a85 fe7923ce
+ b22d2955 2f3af207 142b2aba 643aaa61
+ ...
+ d8fd10b4 c9e00ebc c089f7a3 549a1907
+ ff885220 ce796328 b0f8ecac 86ffb1cc
+
+5.5.3.2. General-Use Certificate in Dump ASN.1
+
+ 0 30 794: SEQUENCE {
+ 4 30 514: SEQUENCE {
+ 8 A0 3: [0] {
+ 10 02 1: INTEGER 2
+ : }
+ 13 02 2: INTEGER 11226
+ 17 30 13: SEQUENCE {
+ 19 06 9: OBJECT IDENTIFIER
+ : sha1withRSAEncryption (1 2 840 113549 1 1 5)
+ 30 05 0: NULL
+ : }
+ 32 30 101: SEQUENCE {
+ 34 31 11: SET {
+ 36 30 9: SEQUENCE {
+ 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
+ 43 13 2: PrintableString 'IT'
+ : }
+ : }
+ 47 31 28: SET {
+ 49 30 26: SEQUENCE {
+ 51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
+ 56 13 19: PrintableString 'Certificatore 1'
+ : }
+ : }
+ 77 31 22: SET {
+
+
+
+Petrucci, et al. Informational [Page 52]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ 79 30 20: SEQUENCE {
+ 81 06 3: OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
+ 86 13 13: PrintableString 'Certification Service Provider'
+ : }
+ : }
+ 101 31 32: SET {
+ 103 30 30: SEQUENCE {
+ 105 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
+ 110 13 23: PrintableString 'Certificatore S.p.A.'
+ : }
+ : }
+ : }
+ 135 30 30: SEQUENCE {
+ 137 17 13: UTCTime '041005090423Z'
+ 152 17 13: UTCTime '051005090423Z'
+ : }
+ 167 30 66: SEQUENCE {
+ 169 31 11: SET {
+ 171 30 9: SEQUENCE {
+ 173 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
+ 178 13 2: PrintableString 'IT'
+ : }
+ : }
+ 182 31 23: SET {
+ 184 30 21: SEQUENCE {
+ 186 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
+ 191 13 14: PrintableString 'AcmePEC S.p.A.'
+ : }
+ : }
+ 207 31 26: SET {
+ 209 30 24: SEQUENCE {
+ 211 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
+ 216 13 17: PrintableString 'Posta Certificata'
+ : }
+ : }
+ : }
+ 235 30 159: SEQUENCE {
+ 238 30 13: SEQUENCE {
+ 240 06 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549
+ 1 1 1)
+ 251 05 0: NULL
+ : }
+ 253 03 141: BIT STRING 0 unused bits
+ : 30 81 89 02 81 81 00 AF BE B4 55 63 19 8A AA 9B
+ : AC 3F 1B 29 B5 BE 7F 69 19 45 89 D0 15 69 CA 0D
+ : 55 5B 5C 33 D7 E9 C8 6E FC 14 46 C3 C3 09 47 DD
+ : CD 10 74 1D 76 4E 71 14 E7 69 42 BE 1C 47 61 85
+ : 4D 74 76 DD 0B B5 78 4F 1E 84 DD B4 86 7F 96 DF
+
+
+
+Petrucci, et al. Informational [Page 53]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ : 5E 7B AF 0E CE EA 12 57 0B DF 9B 63 67 4D F9 37
+ : B7 48 35 27 C2 89 F3 C3 54 66 F7 DA 6C BE 4F 5D
+ : 85 55 07 A4 97 8C D1 5F F1 28 67 92 DE F5 B3 F8
+ : [ Another 12 bytes skipped ]
+ : }
+ 397 A3 123: [3] {
+ 399 30 121: SEQUENCE {
+ 401 30 39: SEQUENCE {
+ 403 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
+ 408 04 32: OCTET STRING
+ : 30 1E 81 1C 70 6F 73 74 61 2D 63 65 72 74 69 66
+ : 69 63 61 74 61 40 61 63 6D 65 70 65 63 2E 69 74
+ : }
+ 442 30 14: SEQUENCE {
+ 444 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
+ 449 01 1: BOOLEAN TRUE
+ 452 04 4: OCTET STRING
+ : 03 02 07 80
+ : }
+ 458 30 31: SEQUENCE {
+ 460 06 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35)
+ 465 04 24: OCTET STRING
+ : 30 16 11 11 11 11 AA AA AA AA AA BB BB BB BB CC CC
+ : CC CC DD DD DD DD
+ : }
+ 491 30 29: SEQUENCE {
+ 493 06 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
+ 498 04 22: OCTET STRING
+ : 04 14 3A FA E0 80 64 53 52 7A 3E 57 09 D8 49 A9
+ : 41 A8 A3 A7 0A E1
+ : }
+ : }
+ : }
+ : }
+ 522 30 13: SEQUENCE {
+ 524 06 9: OBJECT IDENTIFIER
+ : sha1withRSAEncryption (1 2 840 113549 1 1 5)
+ 535 05 0: NULL
+ : }
+ 537 03 257: BIT STRING 0 unused bits
+ : 87 4B 4D 25 70 A4 61 80 C9 77 0A 85 FE 79 23 CE
+ : B2 2D 29 55 2F 3A F2 07 14 2B 2A BA 64 3A AA 61
+ : 1F F0 E7 3F C4 E6 13 E2 09 3D F0 E1 83 A0 C0 F2
+ : C6 71 7F 3A 1C 80 7F 15 B3 D6 1E 22 79 B8 AC 91
+ : 51 83 F2 3A 84 86 B6 07 2B 22 E8 01 52 2D A4 50
+ : 9F C6 42 D4 7C 38 B1 DD 88 CD FC E8 C3 12 C3 62
+ : 64 0F 16 BF 70 15 BC 01 16 78 30 2A DA FA F3 70
+ : E2 D3 0F 00 B0 FD 92 11 6C 55 45 48 F5 64 ED 98
+
+
+
+Petrucci, et al. Informational [Page 54]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ : [ Another 128 bytes skipped ]
+ : }
+
+5.6. PEC Providers Directory
+
+ The contents of the PEC providers directory MUST be queried via
+ [HTTP] on a Secure Socket Layer (SSL), as described in [TLS],
+ exclusively by licensed providers that have the necessary user
+ certificates; this access modality guarantees authenticity,
+ integrity, and confidentiality of data. Each provider downloads the
+ LDIF file through an [HTTPS] session, which is authenticated by
+ checking the X.509 certificate issued by a certification authority.
+
+6. PEC System Client Technical and Functional Prerequisites
+
+ This section lists the prerequisites that must be respected by a
+ client in order to guarantee the minimal operative functionalities to
+ the user of a general PEC system:
+
+ o handling of Access and Delivery Points through secure channels;
+
+ o handling of user authentication in message dispatch and reception
+ which make use of standard protocols, such as [IMAP], [POP3], and
+ [HTTP];
+
+ o support for MIME format according to [MIME1] and [MIME5];
+
+ o support for "ISO-8859-1 (Latin-1)" character set;
+
+ o support for S/MIME v3 standard, as in [SMIMEV3], for verification
+ of signatures applied to PEC envelopes and notifications.
+
+7. Security Considerations
+
+ All security considerations from [CMS] and [SMIMEV3] apply to
+ applications that use procedures described in this document.
+
+ The centralized LDAP server is a critical point for the security of
+ the whole PEC system. An attack could compromise the whole PEC
+ system. PEC providers that periodically download the LDIF file
+ SHOULD use the best security technology to protect it from local
+ attacks. A PEC provider could be compromised if an attacker changed
+ a certificate or modified the list of domains associated to it in the
+ LDIF file that was copied to the PEC provider system.
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 55]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ When verifying the validity of the signature of a message, the
+ recipient system SHOULD verify that the certificate included in the
+ [CMS] message is present in the LDIF file (section 4.5) and that the
+ domain extracted by the [EMAIL] "From:" header is listed in the
+ managedDomains attribute associated to said certificate.
+
+8. IANA Considerations
+
+8.1. Registration of PEC Message Header Fields
+
+ This document defines new header fields used in the messages that
+ transit in the PEC network. As specified and required by
+ [HEADERS-IANA], this document registers new header fields as
+ Provisional Message Header Fields as follows.
+
+8.1.1. Header Field: X-Riferimento-Message-ID:
+
+ Applicable protocol: mail [EMAIL]
+
+ Status: provisional
+
+ Author/Change controller:
+
+ Claudio Petrucci
+ DigitPA
+ Viale Carlo Marx 31/49
+ 00137 Roma
+ Italy
+ EMail: PETRUCCI@digitpa.gov.it
+
+ Specification document: this document, section 2.2.1, Appendix A.
+
+8.1.2. Header Field: X-Ricevuta:
+
+ Applicable protocol: mail [EMAIL]
+
+ Status: provisional
+
+ Author/Change controller:
+
+ Claudio Petrucci
+ DigitPA
+ Viale Carlo Marx 31/49
+ 00137 Roma
+ Italy
+ EMail: PETRUCCI@digitpa.gov.it
+
+
+
+
+
+Petrucci, et al. Informational [Page 56]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ Specification document: this document, sections 2.1.1.1.1, 3.1.2,
+ 3.1.3, 3.1.4, 3.1.6, 3.2.1, 3.2.3, 3.2.4,
+ 3.3.2, 3.3.3, Appendix A.
+
+8.1.3. Header Field: X-VerificaSicurezza:
+
+ Applicable protocol: mail [EMAIL]
+
+ Status: provisional
+
+ Author/Change controller:
+
+ Claudio Petrucci
+ DigitPA
+ Viale Carlo Marx 31/49
+ 00137 Roma
+ Italy
+ EMail: PETRUCCI@digitpa.gov.it
+
+ Specification document: this document, sections 2.1.1.1.3, 3.1.3,
+ 3.2.4, Appendix A.
+
+8.1.4. Header Field: X-Trasporto:
+
+ Applicable protocol: mail [EMAIL]
+
+ Status: provisional
+
+ Author/Change controller:
+
+ Claudio Petrucci
+ DigitPA
+ Viale Carlo Marx 31/49
+ 00137 Roma
+ Italy
+ EMail: PETRUCCI@digitpa.gov.it
+
+ Specification document: this document, sections 3.1.5, 3.2.2,
+ Appendix A.
+
+8.1.5. Header Field: X-TipoRicevuta:
+
+ Applicable protocol: mail [EMAIL]
+
+ Status: provisional
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 57]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ Author/Change controller:
+
+ Claudio Petrucci
+ DigitPA
+ Viale Carlo Marx 31/49
+ 00137 Roma
+ Italy
+ EMail: PETRUCCI@digitpa.gov.it
+
+ Specification document: this document, sections 3.1.5, 3.3.2,
+ 3.3.2.1, 3.3.2.2, 3.3.2.3, Appendix A.
+
+8.1.6. Header Field: X-Mittente:
+
+ Applicable protocol: mail [EMAIL]
+
+ Status: provisional
+
+ Author/Change controller:
+
+ Claudio Petrucci
+ DigitPA
+ Viale Carlo Marx 31/49
+ 00137 Roma
+ Italy
+ EMail: PETRUCCI@digitpa.gov.it
+
+ Specification document: this document, sections 3.2.3, Appendix A.
+
+8.2. Registration of LDAP Object Identifier Descriptors
+
+ This document defines new LDAP attributes and object classes for
+ object identifier descriptors. As specified and required by
+ [LDAP-IANA], this document registers new descriptors as follows per
+ the Expert Review.
+
+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
+
+
+
+Petrucci, et al. Informational [Page 58]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ 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
+
+9. References
+
+9.1. Normative References
+
+ [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", STD 68, RFC 5234,
+ January 2008.
+
+ [CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
+ STD 70, RFC 5652, September 2009.
+
+ [CRL] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+ Housley, R., and W. Polk, "Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation
+ List (CRL) Profile", RFC 5280, May 2008.
+
+
+
+Petrucci, et al. Informational [Page 59]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ [EMAIL] Resnick, P., Ed., "Internet Message Format", RFC
+ 5322, October 2008.
+
+ [HEADERS-IANA] Klyne, G., Nottingham, M., and J. Mogul,
+ "Registration Procedures for Message Header Fields",
+ BCP 90, RFC 3864, September 2004.
+
+ [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee,
+ "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
+ June 1999.
+
+ [HTTPS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+ [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+ VERSION 4rev1", RFC 3501, March 2003.
+
+ [LDAP] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map",
+ RFC 4510, June 2006.
+
+ [LDAP-IANA] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [LDAP-SYNTAXES] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [LDIF] Good, G., "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+ [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) Part One: Format of Internet
+ Message Bodies", RFC 2045, November 1996.
+
+ [MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) Part Five: Conformance
+ Criteria and Examples", RFC 2049, November 1996.
+
+ [SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for
+ Mail", RFC 4409, April 2006.
+
+ [POP3] Myers, J. and M. Rose, "Post Office Protocol -
+ Version 3", STD 53, RFC 1939, May 1996.
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 60]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ [REQ] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash
+ Algorithm 1 (SHA1)", RFC 3174, September 2001.
+
+ [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
+ "Security Multiparts for MIME: Multipart/Signed and
+ Multipart/Encrypted", RFC 1847, October 1995.
+
+ [SMIMEV3] Ramsdell, B. and S. Turner, "Secure/Multipurpose
+ Internet Mail Extensions (S/MIME) Version 3.2 Message
+ Specification", RFC 5751, January 2010.
+
+ [SMIMECERT] Ramsdell, B. and S. Turner, "Secure/Multipurpose
+ Internet Mail Extensions (S/MIME) Version 3.2
+ Certificate Handling", RFC 5750, January 2010.
+
+ [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC
+ 5321, October 2008.
+
+ [SMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP)
+ Service Extension for Delivery Status Notifications
+ (DSNs)", RFC 3461, January 2003.
+
+ [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP
+ over Transport Layer Security", RFC 3207, February
+ 2002.
+
+ [TIMESTAMP] Klyne, G. and C. Newman, "Date and Time on the
+ Internet: Timestamps", RFC 3339, July 2002.
+
+ [TLS] Dierks, T. and E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.2", RFC 5246,
+ August 2008.
+
+ [XML] W3C, "Extensible Markup Language (XML) 1.0 (Fifth
+ Edition)", W3C Recommendation, November 2008,
+ <http://www.w3.org/TR/2006/REC-xml-20060816/>.
+
+9.2. Informative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, November 1987.
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 61]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ [RFC4522] Legg, S., "Lightweight Directory Access Protocol
+ (LDAP): The Binary Encoding Option", RFC 4522, June
+ 2006.
+
+ [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Schema Definitions for X.509 Certificates",
+ RFC 4523, June 2006.
+
+10. Acknowledgments
+
+ The Italian document on which this document is based, is a product of
+ the collaboration of many with the supervision of the National Center
+ for Informatics in the Public Administration of Italy (DigitPA).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 62]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+Appendix A. Italian Fields and Values in English
+
+ NOTE: The right column represents a translation of the Italian fields
+ for readability's sake only. Header fields that MUST be used
+ are the ones in the left column.
+
+ X-Riferimento-Message-ID Reference Message Identifier
+ X-Ricevuta Notification
+ non-accettazione non acceptance
+ accettazione server-user acceptance
+ preavviso-errore-consegna delivery error advance notice
+ presa-in-carico server-server acceptance
+ rilevazione-virus virus detection
+ errore-consegna delivery error
+ avvenuta-consegna message delivered
+ X-Mittente Sender
+ X-VerificaSicurezza Security Verification
+ errore error
+ X-Trasporto Transport
+ posta-certificata certified mail
+ errore error
+ X-TipoRicevuta Notification Type
+ completa complete
+ breve brief
+ sintetica concise
+
+ certificatore certificator
+
+ Subject values:
+
+ Accettazione SERVER-USER ACCEPTANCE
+ Posta certificata CERTIFIED MAIL
+ Presa in carico SERVER-SERVER ACCEPTANCE
+ Consegna DELIVERY
+ Anomalia messaggio MESSAGE ANOMALY
+ Problema di sicurezza SECURITY PROBLEM
+ Avviso di non accettazione NON ACCEPTANCE PEC NOTIFICATION
+ Avviso di non accettazione VIRUS DETECTION INDUCED NON
+ per virus ACCEPTANCE PEC NOTIFICATION
+ Avviso di mancata consegna NON DELIVERY PEC NOTIFICATION
+ Avviso di mancata consegna NON DELIVERY DUE TO VIRUS PEC
+ per virus NOTIFICATION
+ Avviso di mancata consegna NON DELIVERY DUE TO TIMEOUT PEC
+ per sup. tempo massimo NOTIFICATION
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 63]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+ Italian terms in the DTD relative to the certification XML file:
+
+ accettazione server-user acceptance
+ altro other
+ avvenuta-consegna delivered
+ certificato certificate
+ consegna delivery
+ data date
+ dati data
+ destinatari recipients
+ esterno external
+ errore error
+ errore-consegna delivery error
+ errore-esteso extensive error
+ gestore-emittente transmitting provider
+ giorno day
+ identificativo identifier
+ intestazione header
+ mittente sender
+ no-dest(inatario) no recipient
+ no-dominio no domain
+ non-accettazione non acceptance
+ nessuno none
+ oggetto subject
+ ora hour
+ posta-certificata certified mail
+ preavviso-errore-consegna delivery error advance notice
+ presa-in-carico server-server acceptance
+ ricevuta notification
+ ricezione receipt (the act of receiving)
+ rilevazione-virus virus detection
+ risposte replies
+ tipo type
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 64]
+
+RFC 6109 Certified Electronic Mail April 2011
+
+
+Authors' Addresses
+
+ Claudio Petrucci
+ DigitPA
+ Viale Marx 31/49
+ 00137 Roma
+ Italy
+
+ EMail: petrucci@digitpa.gov.it
+
+ Francesco Gennai
+ ISTI-CNR
+ Via Moruzzi, 1
+ 56126 Pisa
+ Italy
+
+ EMail: francesco.gennai@isti.cnr.it
+
+
+ Alba Shahin
+ ISTI-CNR
+ Via Moruzzi, 1
+ 56126 Pisa
+ Italy
+
+ EMail: alba.shahin@isti.cnr.it
+
+
+ Alessandro Vinciarelli
+ Via delle Vigne di Morena 113
+ 00118 Roma
+ Italy
+
+ EMail: alessandro.vinciarelli@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Petrucci, et al. Informational [Page 65]
+