tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6109

 Errata 
Informational
Pages: 65
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~sec-smime

La Posta Elettronica Certificata - Italian Certified Electronic Mail

Part 1 of 3, p. 1 to 18
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Page 2 
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.

Top       Page 3 
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

Top      ToC       Page 4 
      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

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
   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

Top      ToC       Page 7 
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.

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
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).

Top      ToC       Page 11 
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:

Top      ToC       Page 12 
   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);

Top      ToC       Page 13 
   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]>

Top      ToC       Page 14 
   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);

Top      ToC       Page 15 
      -  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).

Top      ToC       Page 16 
      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.

Top      ToC       Page 17 
   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

Top      ToC       Page 18 
   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.



(page 18 continued on part 2)

Next RFC Part