[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 6109

Internet Draft                                               F. Gennai
Intended status: Standards track                             A. Shahin
Expires: August 8, 2009                                       ISTI-CNR
                                                           C. Petrucci
                                                        A. Vinciarelli
                                                                 CNIPA
                                                      February 4, 2009


                         Certified Electronic Mail
                    draft-gennai-smime-cnipa-pec-02.txt



Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 8, 2009.


Copyright Notice

   Copyright (c) 2009 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.


Gennai et al.             Expires August 8, 2009               [Page 1]


Internet-Draft        Certified Electronic Mail          February 2009


Abstract

   Since 1997, the Italian Laws have recognized electronic delivery
   systems as legally usable. After 2 years of technical tests, in 2005
   the characteristics of an official electronic delivery service,
   named certified electronic mail (in Italian "Posta Elettronica
   Certificata") were defined, giving the system legal value.

   Design of the entire system was carried out by the National Center
   for Informatics in the Public Administration of Italy (CNIPA),
   followed by efforts for the implementation and testing of the
   service. The CNIPA 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.

Table of Contents

   1. Introduction ................................................  4
      1.1. Scope ..................................................  4
      1.2. Notational Conventions .................................  5
   2. PEC model ...................................................  9
      2.1. System-generated messages ..............................  9
         2.1.1. Message types ..................................... 11
      2.2. Basic structure ........................................ 14
         2.2.1. Access point ...................................... 14
         2.2.2. Incoming point .................................... 16
         2.2.3. Delivery point .................................... 18
         2.2.4. Storage ........................................... 19
         2.2.5. Provider service mailbox .......................... 19
      2.3. Log .................................................... 19
   3. Message processing .......................................... 20
      3.1. Access point ........................................... 20
         3.1.1. Formal checks on messages ......................... 20
         3.1.2. Non-acceptance notification due to one or more formal
                exceptions ........................................ 20
         3.1.3. Non-acceptance notification due to virus .......... 21
         3.1.4. Acceptance notification ........................... 22
         3.1.5. Transport envelope ................................ 23
         3.1.6. Timeout delivery error notification ............... 24
      3.2. Incoming point ......................................... 26
         3.2.1. Take in charge notification ....................... 26
         3.2.2. Anomaly envelope .................................. 27
         3.2.3. Virus detection notification ...................... 28



Gennai et al.             Expires August 8, 2009              [Page 2]


Internet-Draft        Certified Electronic Mail          February 2009


         3.2.4. Virus-induced delivery error notification ......... 29
      3.3. Delivery point ......................................... 30
         3.3.1. Checks on incoming messages ....................... 30
         3.3.2. Delivery notification ............................. 30
         3.3.3. Non-delivery notification ......................... 35
   4. Formats ..................................................... 35
      4.1. Temporal reference ..................................... 35
      4.2. User date/time ......................................... 36
      4.3. Attachments ............................................ 36
      4.4. Certification data scheme .............................. 37
      4.5. PEC providers directory scheme ......................... 39
   5. Example: Complete transaction between 2 PEC domains ......... 46
   6. Security-related aspects .................................... 47
      6.1. Digital signature ...................................... 47
      6.2. Authentication ......................................... 47
      6.3. Secure interaction ..................................... 48
      6.4. Virus .................................................. 48
      6.5. S/MIME certificate ..................................... 49
      6.6. PEC providers directory ................................ 54
   7. PEC system client technical and functional prerequisites .... 55
   8. Security Considerations ..................................... 55
   9. IANA Considerations ......................................... 55
   10. References ................................................. 56
      10.1. Normative References .................................. 56
   11. Acknowledgments ............................................ 57
   APPENDIX A: Italian fields and values in English ............... 58
   Authors' Addresses ............................................. 59
























Gennai et al.             Expires August 8, 2009              [Page 3]


Internet-Draft        Certified Electronic Mail          February 2009


1. Introduction

   Since 1997, the Italian Laws have recognized electronic delivery
   systems as legally usable. After 2 years of technical tests, in 2005
   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 value.

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. But, even though end-to-end cryptography
   offers a high level of security, it has a downside; the need for an
   extensive penetration of technology in the society, since it would
   be essential for every user to have a couple of symmetric keys and a
   certificate, signed by a Certification Authority, associated with
   the public key. Along with that, users would need to have an
   adequate amount of knowledge regarding the use of such technology.

   PEC on the other hand offers the digital signing of messages through
   applications running directly on the servers, thus avoiding the
   complexity end-to-end systems bring about. By doing so, the user
   needs 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.

   A provider for such a service must follow certain regulations and
   undergo several tests of compatibility and interoperability before
   it can be considered legally functional.

   This document describes PEC's Technical Regulations and
   functionality. It presents the details of the protocol and the
   messages that are sent between service providers. It is meant to be
   an introduction to the system the Italian government has adopted for
   the sending and receiving of certified emails, giving them a legal
   value equivalent to that of Registered Mail with Return Receipt.








Gennai et al.             Expires August 8, 2009              [Page 4]


Internet-Draft        Certified Electronic Mail          February 2009


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:   National Center for Informatics in the Public
            Administration of Italy (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

1.2.3. Terminology and Definitions

   Acceptance notification: Emitted by the sending access point to its
   user upon the latter's request to send a PEC message. This occurs
   when checks on said message go smoothly, and serves to notify the
   user that the provider will be taking care of sending the PEC
   message to its intended destination(s). It contains certification
   data and is signed using the sender PEC provider's key.

   Access point: Is what interfaces the user to the rest of the PEC
   system. It provides access services for user identification, as well
   as sending and reading PEC messages. An access point also performs
   virus checks (on outgoing messages), and inserts the original
   message into a transport envelope. The messages it can emit are:




Gennai et al.             Expires August 8, 2009              [Page 5]


Internet-Draft        Certified Electronic Mail          February 2009


   o  acceptance notifications.

   o  non-acceptance notifications, either due to some formal exception
      or virus presence.

   Anomaly envelope: When a message contains errors or is not a PEC
   message it MUST be inserted inside an anomaly envelope to highlight
   the irregularity to the receiving user. The envelope is signed using
   the receiver PEC provider's key.

   Brief delivery notification: A type of delivery notification that
   contains the original message, certification data, and hash values
   of the attachments that were included in the original message, if
   any.

   Certification data: A set of data, certified by the sender's PEC
   provider, that describes the original message. This data is inserted
   in notifications and is transferred to the recipient, along with the
   original message, inside a transport envelope. Certification data
   include: date and time of dispatch, sender email address,
   recipient(s) email address(es), subject, and message ID.

   Certified electronic mail: A service based on electronic mail, as
   defined by the [SMTP] standard and its extensions, which permits the
   transmission of documents produced with informatics tools.

   Complete delivery notification: A type of notification that contains
   delivery confirmation text and certification data, as well as the
   entire original message.

   Concise delivery notification: A type of notification that contains
   delivery confirmation text and certification data only attached to
   it.

   Delivery point: Is the point that delivers PEC messages to the
   intended recipient's PEC mailbox. It also runs checks on the source
   and correctness of the message. The messages it can emit are:

   o  delivery notification.

   o  non-delivery notification.

   All messages received by the delivery point are stored in the
   recipient's mailbox.

   Delivery notification: Emitted by the receiver delivery point to the
   sender incoming point, which then forwards it to the sender delivery
   point, upon insertion of the message inside the recipient's PEC



Gennai et al.             Expires August 8, 2009              [Page 6]


Internet-Draft        Certified Electronic Mail          February 2009


   mailbox. A separate delivery notification is generated upon delivery
   of the message to each different recipient indicated in the "To:"
   and "Cc:" fields of said message. The notification is signed using
   the receiver PEC provider's key.

   Holder: The person to whom a PEC mailbox is assigned.

   Incoming point: Is the point that receives messages within a PEC
   domain. Once received, it runs checks on origin and correctness,
   inserts messages that contain errors in anomaly envelopes, checks
   for the presence of viruses in incoming messages, and, when all
   checks go smoothly, forwards the received message to the delivery
   point inside the same domain. The messages it can emit are:

   o  take in charge notifications (inter-provider acknowledgment);

   o  virus detection notifications;

   o  non-delivery notifications due to timeout;

   o  non-delivery notifications due to virus detection.

   All messages received by the incoming point are forwarded to the
   delivery point of the same domain.

   Message sent: A PEC message is considered sent when the sender's PEC
   provider, after several checks, accepts the email and returns an
   acceptance 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 notification to the sender.

   Msgid: Is the message ID generated by the email client, as defined
   in [EMAIL], before the message is submitted to the PEC system.

   Non-acceptance notification: Emitted by the sender access point to
   its user when it is impossible for it to accept the message. The
   reason (either virus or formal exceptions detection) is indicated
   within the notification text, which also explicitly informs the user
   that the message will not be forwarded to the receiver. The
   notification is signed using the sender PEC provider's key.

   Non-delivery notification: Emitted by the PEC provider to the sender
   of the original message, when message delivery is not possible, to
   indicate the anomaly. Non-delivery can be caused by one of the
   following 3 reasons:




Gennai et al.             Expires August 8, 2009              [Page 7]


Internet-Draft        Certified Electronic Mail          February 2009


   o  timeout; notification is generated by the sender incoming point
      and sent to the sender delivery point.

   o  virus detection; notification is generated by the receiver
      incoming point and sent to the sender incoming point.

   o  other reasons; such as disk quota exceeded, domain unknown or
      user unknown. In this case, the notification is generated by the
      receiver delivery point to the sender incoming point.

   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 transport envelope.

   PEC domain: Corresponds to a DNS domain dedicated to the holders'
   mailboxes. Within a PEC domain, all PEC mailboxes MUST belong to
   holders. PEC messages MUST be elaborated even if both sender and
   recipient belong to the same PEC domain.

   PEC mailbox: An electronic mailbox for which delivery 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.

   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 notifications and
   envelope, and it interacts with other PEC providers for
   interoperability with other holders.

   PEC provider's key: Is a key released by CNIPA to every PEC
   provider. It is used to sign 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 corresponding to the keys used for signing
   notifications and transport envelopes.

   Service mailbox: A mailbox for the sole use of the provider,
   dedicated for the reception of take in charge and virus detection
   notifications.





Gennai et al.             Expires August 8, 2009              [Page 8]


Internet-Draft        Certified Electronic Mail          February 2009


   Take in charge notification: Emitted by the receiver incoming point
   to the sender's service mailbox -through the latter's incoming
   point- to attest that the receiver PEC provider has taken
   responsibility for message delivery. Certification data is inserted
   within this notification to allow its association with the message
   it refers to. It is then signed using the receiving PEC provider's
   key.

   Time stamp: A digital evidence with which a temporal reference, that
   can be opposed by third parties, is attributed to one or more
   documents.

   Transport envelope: A message created by the sender access point, in
   which the original message and related certification data are
   inserted. It is signed using the sender PEC provider's key, and is
   delivered, unmodified, to the receiving PEC mailbox. Thus, allowing
   the verification of the certification data by the receiving user.

2. PEC model

2.1. System-generated messages

   The PEC system generates messages in MIME format. They are composed
   of a descriptive textual part and some other MIME 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.

   In order for the receiving mail client to be able to verify the
   signature, the sender address must coincide with the one indicated
   within the X.509v3 certificate. This mechanism requires transport



Gennai et al.             Expires August 8, 2009              [Page 9]


Internet-Draft        Certified Electronic Mail          February 2009


   envelopes to indicate in the "From:" field a sender address which is
   different from the one contained in the original message. To allow
   for better message usability by the receiving user, the sender'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.com>

   would result in the following "From:" value in the respective
   transport envelope:

     From: "On behalf of: john.smith@domain.com"
                                    <certified-mail@provider.com>

   It is necessary for the "Reply-To:" field to contain a correct value
   in the transport envelope, so replies can be correctly sent back to
   the proper destination. When such a field is not explicitly
   specified in the original message, the system that generates the
   transport envelope sees to its creation by extracting the
   information from the "From:" field in the original message. If on
   the other hand that field is specified in the original message, it
   MUST NOT be altered.

   When notifications need to be sent, the system uses as destination
   address that of the original message's sender only, exactly as is
   specified in the reverse path data of the SMTP protocol.
   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.








Gennai et al.             Expires August 8, 2009             [Page 10]


Internet-Draft        Certified Electronic Mail          February 2009


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. 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 notifications

   Indicates an acknowledgment on the provider's side for the reception
   or handling of a PEC message. More specifically, it can indicate one
   of 3 situations: acceptance, take in charge, or delivery.

   Added header fields are:

   o  X-Ricevuta

   o  X-Riferimento-Message-ID

   The field "X-Ricevuta" (Notification) indicates the type of
   notification contained in the message, whereas "X-Riferimento-
   Message-ID" (Reference Message-ID) contains the message ID generated
   by the mail client.

   The body contents differ according to the notification type. This is
   described more thoroughly in chapter 3.

   o  An acceptance 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 take in charge notification is an inter-provider communication
      only, it MUST NOT concern 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 notifications take place as the final communication of a
      transaction, indicating overall success in handing the message
      over to the addressee(s).



Gennai et al.             Expires August 8, 2009             [Page 11]


Internet-Draft        Certified Electronic Mail          February 2009


2.1.1.1.2. Delay notifications

   Delay notifications are sent out 12 hours after a message has been
   dispatched from the sending provider, and no take in charge or
   delivery notification was received. These have the sole purpose of
   notifying the user of the delay.

   If another 12 hours go by without any sign of a take in charge or
   delivery notification (amounting to a 24-hour delay), another delay
   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 notifications

   They are sent when there is some error in transmission or reception.
   More specifically, a failure 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" (Notification) and "X-Riferimento-Message-ID"
   (Reference Message-ID) have the same roles as indicated in section
   2.1.1.1.1 (Success Notifications). "X-VerificaSicurezza" (Security
   Verification) is an optional header field, used for virus-related
   notifications.

   Body contents differ according to notification type. This is
   described more thoroughly in chapter 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




Gennai et al.             Expires August 8, 2009             [Page 12]


Internet-Draft        Certified Electronic Mail          February 2009


   o  Cc

   o  Return-Path

   o  Reply-to (if present)

   Depending on the type of message requesting admission into the PEC
   network, it will be inserted either in a "Transport Envelope", or in
   a "Anomaly Envelope". Distinction will be possible through the
   addition of the "X-Transport" header field.








































Gennai et al.             Expires August 8, 2009             [Page 13]


Internet-Draft        Certified Electronic Mail          February 2009




   2.2. Basic structure

             +-------------+               +------------+
             |    +--+     |               |            |
             |    |AP|     |               |            |
   +----+    |    +--+     |   messages&   | +--+ +---+ |    +----+
   |user|<-->|             |<------------->| |DP| |InP| |<-->|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 6.2). The access point is then to receive the original
   messages its user wishes to send, run some formal checks, and act
   according to the outcome:

   o if the message passes all checks, the access point generates an
     acceptance notification and inserts the original message inside a
     transport envelope;

   o if some formal exception is detected, the access point refuses
     the message and emits the relevant non-acceptance notification
     (see section 3.1.1);

   o if a virus is detected, the access point generates a non-
     acceptance notification and inserts the original message as is in
     a special store.

   Generation of the 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



Gennai et al.             Expires August 8, 2009             [Page 14]


Internet-Draft        Certified Electronic Mail          February 2009


   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 acceptance notification (and relevant certification
   data) relates, for each address, the typology of its domain; PEC or
   non-PEC.

   The identifier (from now on PEC msgid) of accepted original messages
   within the PEC infrastructure MUST be unambiguous in order to
   consent correct tracking of messages and relative 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 transport
   envelope MUST contain the following header field:

       Message-ID: <[unique identifier]>

   In case the email client that is interacting with the access point
   has already inserted a Message ID (from now on 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
   notifications, the msgid MUST be inserted in the original message as
   well as the relative notifications and transport envelope. If
   existent, the msgid is REQUIRED to be provided in the original
   message's header by adding the following header field:

       X-Riferimento-Message-ID: <[original Message ID]>

   which will also be inserted in the transport envelope and
   notifications, and related in the certification data (see section
   4.4).







Gennai et al.             Expires August 8, 2009             [Page 15]


Internet-Draft        Certified Electronic Mail          February 2009


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 circuit 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 the emission of a signal
   to the user when an error occurs, coherently with the modalities
   defined in section 3.3.3, the systems that handle 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 nature of the incoming message;

   o if the incoming message is a correct and undamaged transport
     message:

   - emits a take in charge notification towards the sender
     provider (section 3.2.1);

   - forwards the transport envelope to the delivery point
     (section 3.3).

   o if the incoming message is a correct and undamaged notification:

   - forwards the notification to the delivery point.

   o if the incoming message does not conform to the prerequisites of
     a correct and undamaged transport envelope or notification, but
     comes from a PEC provider, therefore passes the verifications
     regarding existence, origin, and signature validity, then the
     message MUST be propagated towards the recipient. Therefore, the
     incoming point:

   - inserts the incoming message in an anomaly envelope (section
     3.2.2);

   - forwards the anomaly envelope to the delivery point.





Gennai et al.             Expires August 8, 2009             [Page 16]


Internet-Draft        Certified Electronic Mail          February 2009


   o if the incoming message does not originate from a PEC system,
     therefore fails verifications regarding existence, origin and
     signature validity, then the message will be treated as ordinary
     email, and, if propagated to the recipient:

   - is inserted in an anomaly envelope (section 3.2.2);

   - the anomaly envelope is forwarded to the delivery point.

   The take in charge 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 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 was emitted by a PEC provider. So, the incoming point
     extracts the certificate used for signing the incoming message and
     verifies its presence in the PEC providers directory. To ease the
     check, it is possible to calculate the extracted 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 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 - correctness is verified by recalculating the
     signature algorithm 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 formal correctness aspects which are
     necessary for interoperability.

   If a virus-infected 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



Gennai et al.             Expires August 8, 2009             [Page 17]


Internet-Draft        Certified Electronic Mail          February 2009


   contents of the transport envelope are verified. Thus, the incoming
   point will refrain from forwarding the message to the recipient,
   instead sending the appropriate notification of non-delivery and
   storing the virus-infected message in a 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 circuit. If a
   virus is detected in an ordinary mail message, the latter can be
   discarded at the incoming point before it enters the PEC circuit. In
   other words, no special treatment is reserved for the error, but a
   handling that is conformant to the procedures usually followed for
   messages going through the Internet.

   When a virus is detected inside a transport envelope during the
   reception phase, the receiver's provider emits a virus detection
   notification to the sender provider. The sender provider then MUST:

   o check what virus typologies were not detected by its own
     antivirus, to understand the motivations and verify the
     possibility of interventions;

   o send a virus-induced non-delivery notification to the sender.

2.2.3. Delivery 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. It first verifies the typology of the message, and
   decides whether or not a notification should be issued to the
   sender. The delivery 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 transport envelope, which can be identifiable
   by the presence of the header attribute:

         X-Trasporto: posta-certificata

   In all other cases, such as anomaly envelopes and notifications, the
   delivery notification is not emitted. In any case, the message
   received from the delivery point MUST be delivered unmodified to the
   recipient's mailbox.

   The delivery 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



Gennai et al.             Expires August 8, 2009             [Page 18]


Internet-Draft        Certified Electronic Mail          February 2009


   possible attachments added for extra features offered by the
   provider.

   If the message received at the delivery point can't be delivered to
   the destination mailbox, the delivery point emits a non-delivery
   notification (section 3.3.3). This notification is generated when an
   relative to the delivery of a correct transport envelope is
   encountered.

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
   notifications in 2 cases only:

   o take in charge notifications; and

   o virus detection notification.

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 ID (the value present in the Message-ID header field in
     the original message)

   o date and time of event

   o sender of original message

   o recipient(s) of original message

   o subject of original message

   o event type (reception, delivery, notification emission, etc)

   o Message-IDs of related generated messages

   o sending provider



Gennai et al.             Expires August 8, 2009             [Page 19]


Internet-Draft        Certified Electronic Mail          February 2009


   The service provider MUST store that data and preserve it for 30
   months.

3. Message processing

3.1. Access point

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, verifying that the:

   o message body contains a "From:" field holding a [EMAIL]-compliant
     email address;

   o message body contains a "To:" 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:" field;

   o recipients' addresses specified in the SMTP forward path coincide
     with the ones present in the "To:" or "Cc:" fields of the message;

   o "Bcc:" field does not hold 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 30MB.

   If the message does not pass the tests, the access point MUST NOT
   accept the message within the PEC system, thus emitting the relative
   notification of non-acceptance.

3.1.2. Non-acceptance notification due to one or more formal exceptions

   When the access point cannot forward the message received, due to
   failure in passing the formal checks, the sender is notified of such
   an outcome. If the error is caused by the message failing size
   checks, a non-acceptance 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 header for such a notification will contain the following
   fields:



Gennai et al.             Expires August 8, 2009             [Page 20]


Internet-Draft        Certified Electronic Mail          February 2009


     X-Ricevuta: non-accettazione
     Date: [date of notification emission]
     Subject: AVVISO DI NON ACCETTAZIONE: [original subject]
     From: certified-mail@[mail domain]
     To: [original sender]
     X-Riferimento-Message-ID: [Message-ID of original message]

   The body of this notification is composed of text 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 which prevents its acceptance due to [error
   description].
   The message was not accepted.
   Message identification: [Message-ID]

   The same certification information is inserted within an XML file to
   be attached to the notification message, allowing its automatic
   elaboration (section 4.4). Other attachments MAY BE added to the
   notification message to follow certain functional specifications
   supplied by the provider, but the original message MUST NOT in any
   case be inserted.

3.1.3. Non-acceptance notification due to virus detection

   If the access point receives virus-infected emails from its user, it
   MUST NOT accept them, but notify the sender immediately of dispatch
   impossibility instead.

   The access point MUST run some tests on the content of the incoming
   message and reject it if a virus is detected. In which case, a
   virus-detection-induced non-acceptance notification MUST be emitted
   to clearly communicate the reason of message refusal to the user.

   For this non-acceptance notification the header contains the
   following fields:

     X-Ricevuta: non-accettazione
     X-VerificaSicurezza: errore



Gennai et al.             Expires August 8, 2009             [Page 21]


Internet-Draft        Certified Electronic Mail          February 2009


     Date: [notification emission date]
     Subject: AVVISO DI NON ACCETTAZIONE PER VIRUS: [original subject]
     From: certified-mail@[mail_domain]
     To: [original sender]
     X-Riferimento-Message-ID: [Message-ID of original message]

   The notification's body is composed of readable text 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 identification: [Message-ID]

   The same certification data is inserted in an XML file added to the
   notification to allow for automatic elaboration (section 4.4). The
   notification MAY contain other attachments relevant to specific
   functionalities supplied by the provider, though the original
   message MUST NOT in any case be attached.

3.1.4. Acceptance notification

   The acceptance notification is a message sent to the sender,
   containing date and time of acceptance, sender and recipient data,
   and subject.

   The header will contain the following fields:

     X-Ricevuta: accettazione
     Date: [actual date of acceptance]
     Subject: ACCETTAZIONE: [original subject]
     From: certified-mail@[mail_domain]
     To: [original sender]
     X-Riferimento-Message-ID: [Message-ID of original message]

   The message body is composed of text that constitutes the
   notification in readable format, according to a model that relates
   the following information:





Gennai et al.             Expires August 8, 2009             [Page 22]


Internet-Draft        Certified Electronic Mail          February 2009


     Acceptance 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 identification: [Message-ID]

   The same certification information is inserted within an XML file
   attached to the notification message, allowing its automatic
   elaboration (section 4.4). Other attachments MAY BE added to the
   notification message to follow certain functional specifications
   supplied by the provider.

3.1.5. Transport envelope

   A transport envelope is a message generated by the access point
   which contains the original message as well as certification data.

   As was mentioned in section 2.1.1.2, the 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)

   On the other hand, the following fields will HAVE TO be modified, or
   inserted if necessary:

     X-Trasporto: posta-certificata
     Date: [actual date of acceptance]
     Subject: POSTA CERTIFICATA: [original subject]
     From: "On behalf of: [original sender]"
                                <certified-mail@[mail_domain]>
     Reply-To: [original sender] (inserted only if not already present)
     Message-ID: [PEC message ID generated as explained in 2.2.1]




Gennai et al.             Expires August 8, 2009             [Page 23]


Internet-Draft        Certified Electronic Mail          February 2009


     X-Riferimento-Message-ID: [message ID of original message]
     X-TipoRicevuta: [completa/breve/sintetica]

   The "X-TipoRicevuta" field indicates the type of delivery
   notification the sender wishes to receive - complete, brief, or
   concise.

   The body of the transport envelope is composed of text 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 identification: [Message-ID]

   Within the transport envelope, the entire, non-modified original
   message is attached in a [EMAIL]]compliant format (except for what
   has been said regarding the Message ID). In the same transport
   envelope, another part is added, which is an XML part. It is easy to
   elaborate, and contains the certification data that was already
   related in text format, as well as other information on the type of
   message and type of notification requested (section 4.4). Other
   elements MAY BE added to the transport envelope for functionalities
   supplied by the PEC provider.

   Even if the "From:" field of the transport envelope is modified to
   allow for the verification of the signature by the recipient,
   routing data of the transport envelope (forward and reverse paths)
   remain unchanged with respect to the same data of the original
   message.

3.1.6. Timeout delivery error notification

   If the sending provider does not receive a take in charge or
   delivery notification from the receiving provider within 12 hours
   after 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 notification within 24
   hours after message dispatch, it emits another non-delivery




Gennai et al.             Expires August 8, 2009             [Page 24]


Internet-Draft        Certified Electronic Mail          February 2009


   notification to the user by the 24-hour timeout, but not before 22
   hours have passed.

   Such a communication takes place through a 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: certified-mail@[mail_domain]
     To: [original recipient]
     X-Riferimento-Message-ID: [Message-ID of original message]

   The message body of the first non-delivery notification (12-hour
   timeout) is composed of text that represents the readable format of
   the notification, which will relate the following data:

     Non-delivery 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 notification if in the following twelve hours no
   confirmation is received from the recipient.
   Message identification: [Message-ID]

   On the other hand, 24-hour-timeout induced notifications, who have
   the same header as described above, will have the following text in
   their body:

     Non-delivery 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.
     Massage identification: [Message-ID]

   The same certification data is inserted in an XML file to be
   attached to both notification types to allow an automatic
   elaboration (section 4.4). Within the notification other attachments
   MAY be present for specific functionalities supplied by the PEC



Gennai et al.             Expires August 8, 2009             [Page 25]


Internet-Draft        Certified Electronic Mail          February 2009


   provider; nonetheless the original message MUST NOT in any case be
   included.

   A timeout notification is generated if one of the following
   scenarios occurs:

   o the sending provider receives a take in charge notification
     during the first 12 hours following message dispatch, but does not
     receive a delivery notification at all. In this case it would be a
     24-hour timeout notification.

   o the sending provider does not receive a take in charge
     notification, but receives a delivery notification after 12 hours
     and before the 24-hour timeout. In this case it would be a 12-hour
     timeout notification.

   o the sending provider doesn't receive neither a take in charge
     notification nor a delivery notification. In this case 2 timeout
     notifications are generated; a 12-hour and a 24-hour timeout
     notification.

3.2. Incoming point

3.2.1. Take in charge notification

   When correct PEC transport envelopes (as defined in section 2.2.2.)
   are exchanged between PEC providers, the receiver MUST dispatch a
   take in charge notification to the sender. The dispatched take in
   charge notifications concern all recipients 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 take in charge notification, all recipients of the
   message to which it refers are listed. In general, when receiving a
   transport envelope, each provider MUST emit one or more take in
   charge notifications in order to cover, in absence of SMTP transport
   errors, all the recipients in its jurisdiction.

   The header of a take in charge notification contains the following
   fields:

     X-Ricevuta: presa-in-carico
     Date: [date of take in charge]
     Subject: PRESA IN CARICO: [original subject]
     From: certified-mail@[mail_domain]
     To: [sender provider service mailbox]
     X-Riferimento-Message-ID: [Message-ID of original message]





Gennai et al.             Expires August 8, 2009             [Page 26]


Internet-Draft        Certified Electronic Mail          February 2009


   The provider's service mail address is obtained from the PEC
   providers directory during the necessary queries made in the
   signature verification stage.

   The notification body is constructed following the underlying model:

     take in charge 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.
     Message identification: [Message-ID]

   The same certification data is inserted in an XML file which is
   added to the notification message to allow for automatic elaboration
   (section 4.4). The notification MAY also contain other attachments
   relevant to specific functionalities supplied by the provider.

3.2.2. 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 inserts such a message in an
   anomaly envelope. Before delivery, the entire message received at
   the incoming point is inserted in an [EMAIL]-compliant format as an
   attachment inside a new message that HAS TO inherit the values for
   the following header fields unmodified from the message received:

   o Received

   o To

   o Cc

   o Return-Path

   o Message-ID

   Whereas, the following header fields will HAVE TO be modified or
   inserted:

     X-Trasporto: errore
     Date: [message arrival date]



Gennai et al.             Expires August 8, 2009             [Page 27]


Internet-Draft        Certified Electronic Mail          February 2009


     Subject: ANOMALIA MESSAGGIO: [original subject]
     From: "On behalf of: [original sender]"
                                     <certified-mail@[mail_domain]>
     Reply-To: [original sender (inserted only if not already present)]


   The body is composed of user-readable text 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 anomaly envelope MUST NOT contain attachments other
   than the entire message that arrived at the incoming point.

   Even though the "From:" field of the anomaly envelope is modified
   for signature verification purposes, routing data of such an
   envelope (forward and reverse paths) remain unchanged with respect
   to the same data present in the message received. Doing so
   guarantees both the forwarding of the message to the recipients, and
   the reception of SMTP error notifications, if any occur, by the
   sender (as specified in [SMTP] & [SMTP-DSN]).

3.2.3. Virus detection 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 impossibility to go
   through with the transmission. A separate notification of virus
   detection will HAVE to 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 notification, indicating the error
   found, to be sent to the sending provider's service mailbox.



Gennai et al.             Expires August 8, 2009             [Page 28]


Internet-Draft        Certified Electronic Mail          February 2009


   For this kind of notification, the header contains the following
   fields:

     X-Ricevuta: rilevazione-virus
     X-Sender: [original sender]
     Date: [date of notification emission]
     Subject: PROBLEMA DI SICUREZZA: [original subject]
     From: certified-mail@[mail_domain]
     To: [sender provider notifications]
     X-Riferimento-Message-ID: [Message-ID of original message]

   The body is composed of readable text according to a model which
   relates the following data:

     Virus detection 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 identification: [Message-ID]

   The same certification data is inserted in an XML file and attached
   to the notification to allow for automatic elaboration (section
   4.4). The notification MAY contain other attachments relevant to
   specific functionalities supplied by the provider; however, it MUST
   NOT contain the original message.

   The message body MUST contain the reason for which the transmission
   could not be completed.

3.2.4. Virus-induced delivery error notification

   At the arrival of a virus detected notification from the receiving
   provider, the sender provider emits a non-delivery 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: certified-mail@[mail_domain]
     To: [original sender]
     X-Riferimento-Message-ID: [Message-ID of original message]

   The body is composed of readable text according to the following
   data:



Gennai et al.             Expires August 8, 2009             [Page 29]


Internet-Draft        Certified Electronic Mail          February 2009


     Delivery error 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 identification: [Message-ID]

   All the information necessary for the construction of such a
   notification can be obtained from the correlated virus-detected
   notification.

   The same certification data is inserted in an XML file and attached
   to the notification message to allow for automatic elaboration
   (section 4.4). The notification message MAY contain other
   attachments relevant to specific functionalities supplied by the
   provider. The reason for which the transaction was impossible to
   complete MUST be specified within the message body.

3.3. Delivery point

3.3.1. Checks on incoming messages

   When a message arrives at the delivery point, the system verifies
   its type and determines whether or not a notification should be
   emitted to the sender.

3.3.2. Delivery notification

   A delivery notification is issued after the received message has
   been delivered to the recipient's mailbox, and only upon the
   reception of a correct PEC transport envelope. The latter can be
   easily identifiable for the presence of the following header field:

     X-Trasporto: posta-certificata

   In all other cases (e.g. anomaly envelopes, notifications), the
   delivery notification is not issued. In any case, 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 attachments for
   functionalities offered by the provider.




Gennai et al.             Expires August 8, 2009             [Page 30]


Internet-Draft        Certified Electronic Mail          February 2009


   The following fields are inserted in the header:

     X-Ricevuta: avvenuta-consegna
     Date: [delivery date]
     Subject: CONSEGNA: [original subject]
     From: certified-mail@[mail_domain]
     To: [original sender]
     X-Riferimento-Message-ID: [Message-ID of original message]

   The value of the "X-TipoRicevuta" header field in the transport
   envelope is derived from the original message, thus allowing the
   sender to determine the format of the delivery notifications
   relative to the primary recipients of the original message.

3.3.2.1. Delivery notification: complete

   This is the default value for delivery notifications. When no value
   for the "X-TipoRicevuta" is specified, or when it contains the value
   "complete", the system will require a complete delivery notification
   from addressees in the "To:" field, while a concise notification
   (section 3.3.2.3) will be required from those in the "Cc:" field.
   The distinction between primary recipients and those receiving in
   carbon copy is done through an analysis of the "To:" and "Cc:"
   fields of the message with respect to the delivery addressee.
   Exclusively in notifications sent on behalf of primary recipients,
   along with the attachments already described, a complete copy of the
   original message is inserted. 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 will HAVE
   TO be considered as if addressed to a primary recipient and include
   the complete copy of the original message.

   The notification body is composed of readable text according to a
   model that relates the following certification data:

     Delivery 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 identification: [Message-ID]

   The same certification data is inserted in an XML file to be
   attached to the notification (section 4.4), along with any other
   attachments that MAY be inserted for specific functionalities
   supplied by the provider. The delivery notification MUST be issued
   on the behalf of every recipient of the message.




Gennai et al.             Expires August 8, 2009             [Page 31]


Internet-Draft        Certified Electronic Mail          February 2009


3.3.2.2. Delivery notification: brief

   In order to decrease the amount of data flowing, it is possible for
   the sender to ask for a delivery notification in "brief" format. The
   brief delivery notification contains the original message, with all
   attachments, if present, substituted with their respective ciphered
   hash values. To be able to verify the transmitted contents, it is
   necessary for the sender to keep the original copy of the
   attachment(s), to which the hash values refer, unchanged.

   If the transport envelope contains the header

     X-TipoRicevuta: breve

   the delivery point emits a brief delivery 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 in the
   transport envelope is derived from the original message.

   The notification body is composed of readable text according to a
   model that relates the following certification data:

     Brief delivery 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 identification:  [Message-ID]

   The same certification data is inserted in an XML file and attached
   to the notification (section 4.4), along with other optional
   attachments specific to provider-supplied functionalities. The
   delivery notification is issued on behalf of every recipient of the
   message.

   The MIME structure of the original message is unaltered as it is
   attached to the notification, but its attachment(s) are substituted
   with as many text files as the attachments are, each containing the
   hash value of the file it substitutes. The attachments are
   identified through the presence of the "name" parameter in the
   header "content-type", or "filename" in the header "content-
   disposition" of the MIME part.

   When the original message has an S/MIME format, it is necessary not
   to alter the integrity of the message structure, which would result
   in modifying the MIME parts of the S/MIME construction. Verification
   of the S/MIME nature in the original message takes place when the
   MIME type of the top-level entity (which coincides with the message



Gennai et al.             Expires August 8, 2009             [Page 32]


Internet-Draft        Certified Electronic Mail          February 2009


   itself) is checked. An S/MIME message MAY have the following MIME
   types (as per [SMIMEV3]):

   o multipart/signed

   Represents an original message signed by the sender using the
   structure described in [MIME-SECURE]. The message is made up of 2
   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-signature"

   The message is composed of a sole CMS object within the MIME part.
   Given the impossibility to distinguish attachments, if present
   within the CMS object, the MIME part is left intact without being
   substituted by the respective hash value, thus determining the
   emission of a brief delivery notification with the same contents of
   a normal delivery notification.

   If the original message contains attachments 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 notification, the provider
   MUST:

   1. Identify and extract all the attachments 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 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.



Gennai et al.             Expires August 8, 2009             [Page 33]


Internet-Draft        Certified Electronic Mail          February 2009


   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
     impossibility of identification within a CMS structure. The
     content of the brief delivery notification will coincide with that
     of a normal delivery notification.

   The algorithm used for hash calculation is the [SHA1], calculated on
   the entire content of the attachment. 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 notification: concise

   If the transport envelope contains the header

     X-TipoRicevuta: sintetica

   the delivery point emits, both to primary and carbon copy
   recipients, a concise delivery notification that does not contain
   the original message.

   The message body of the notification is composed of readable text
   according to a model that relates the following certification data:

     Concise delivery 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 identification:  [Message-ID]

   The same certification data is inserted within an XML file to be
   attached to the notification (section 4.4), along with other
   optional attachments specific to provider-supplied functionalities.
   The notification is sent to each one of the recipients to whom the
   message is delivered.

   The concise delivery notification follows the same emission rules as
   the delivery notification; attached to it is the XML file which
   contains the certification data only, and not the original message.







Gennai et al.             Expires August 8, 2009             [Page 34]


Internet-Draft        Certified Electronic Mail          February 2009


3.3.3. Non-delivery notification

   If an error occurs during the delivery of a correct PEC transport
   message, the system generates a notification for non-delivery to be
   sent to the sender, with indication of the error.

   The header will contain the following fields:

     X-Ricevuta: errore-consegna
     Date: [date of notification emission]
     Subject: AVVISO DI MANCATA CONSEGNA: [original subject]
     From: certified-mail@[mail_domain]
     To: [original sender]
     X-Riferimento-Message-ID: [Message-ID of original message]

   The notification body is composed of readable text according to a
   model that relates the following data:

     Non-delivery notification
     On [date] at [time] ([time zone]), in the message "[subject]"
     originating from "[original sender]" and addressed to
     "[recipient]"
     an error was detected.
     The message was refused by the system.
     Message identification:  [Message-ID]

   The same certification data is inserted within an XML files added to
   the notification in order to allow for a an automatic elaboration
   (section 4.4). The notification MAY contain other attachments for
   specific functionalities supplied by the PEC provider.

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 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. Doing this
   renders the instant of message elaboration unambiguous within logs,
   notifications, messages, etc, generated by the server.







Gennai et al.             Expires August 8, 2009             [Page 35]


Internet-Draft        Certified Electronic Mail          February 2009


4.2. User date/time

   Temporal indications supplied by the service in readable format
   (text in notifications, transport envelopes, etc) are provided with
   reference to the legal time at the moment of the operation. The date
   employs the format, "dd/mm/yyyy", whereas the hour uses the format,
   "hh:mm:ss", where "hh" is in 24hour format. The date and time are
   followed by the time zone, i.e. the difference (hours and minutes)
   between local time and UTC, inserted between parentheses.
   Representation of such a value is in the "[+|-]hhmm" format, where
   the first character indicates a positive or negative difference.

4.3. Attachments

   This section describes the characteristics of the various components
   of messages and notifications generated by a PEC system. If one of
   the message parts contains characters with values outside of the
   interval 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).

4.3.1. Message body

   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 messages generated by the system. In this
   case, two sub-parts MUST be present: one of type text/plain, the
   other text/html. The HTML part will HAVE TO respect the following
   conditions:

   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 MUST NOT have active content (e.g. JavaScript, VBscript, Plug-in,
     ActiveX).

4.3.2. Original message

   MIME type: message/rfc822
   Attachment name: certmail.eml






Gennai et al.             Expires August 8, 2009             [Page 36]


Internet-Draft        Certified Electronic Mail          February 2009


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 the notifications.



   <?xml version="1.0" encoding="UTF-8"?>
   <!--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
         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-->



Gennai et al.             Expires August 8, 2009             [Page 37]


Internet-Draft        Certified Electronic Mail          February 2009


   <!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)>

   <!--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 transport envelopes and delivery notifications-->



Gennai et al.             Expires August 8, 2009             [Page 38]


Internet-Draft        Certified Electronic Mail          February 2009


   <!--indicate the type of 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 notifications-->
   <!--Recipient address to which delivery has been carried -->
   <!--out/tried-->
   <!ELEMENT consegna (#PCDATA)>

   <!--For take in charge notifications-->
   <!--recipients for whom it is the relative 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 providers' data and their corresponding PEC
   mail domains. The directory's base root is "o=certmail", and the
   "DistinguishedName" of single records are of the type,
   "providerName=<name>, o=certmail". Search within the directory is
   carried out mainly in case-sensitive mode using the
   "providerCertificateHash" attributes (during envelope signature
   verification phase) or "managedDomains" (during message acceptance
   phase). It is possible for the record of a single provider to
   contain multiple "providerCertificate", and the corresponding
   "providerCertificateHash", attributes in order to allow the handling
   of the renewal of expiring certificates. The provider MUST make sure
   to update its own record sufficiently beforehand with respect to the
   expiration date of the certificate, by adding a new certificate
   whose validity overlaps with that of the previous one. The
   "LDIFLocationURL" attribute MUST point to an HTTPS object supplied
   by the provider, and containing an LDIF file according to [LDIF]. To
   guarantee authenticity, the file MUST be signed by the provider for
   the operations regarding its PEC services. The LDIF 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 such a file on a



Gennai et al.             Expires August 8, 2009             [Page 39]


Internet-Draft        Certified Electronic Mail          February 2009


   daily basis, and, after opportune verifications of the appended
   signature, it applies it to the record relative to the provider. The
   LDIF file that encompasses the data of all the PEC providers is
   available, signed using the method described for single providers as
   an HTTPS object, and can be found at the URL to which the
   "LDIFLocationURL" attribute in the "dn: o=certmail" record points.
   Through the LDIF file, single providers HAVE TO keep a local copy of
   the directory, 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.

   It is possible for the provider to define several distinct records
   to indicate different secondary, administered operating
   environments. Every record refers to a single secondary operating
   environment for which it is possible to declare specific attributes,
   and if need be distinct from those relative to other environments
   and to the main environment. All records MUST contain the name of
   the provider in the "providerName" attribute, whereas the
   "providerUnit" attribute is used to identify the secondary operating
   environments. The "DistinguishedName" of the records relative to the
   secondary operating environments are of the type
   "providerUnit=<environment>,providerName=<name>,o=certmail". 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. Records for secondary
   environments MUST contain the "LDIFLocationURL" attribute, which is
   obtained from the main environment's attribute for all records
   connected to the provider. If secondary environments are present,
   the LDIF found in the main environment's record MUST hold the
   contents of all the provider-relevant records.

   Following are the attributes defined for the scheme of the PEC
   providers directory:

   - providerCertificateHash: IA5 string
   Hexadecimal representation of the hash in SHA1 format of the X.509v3
   certificate used by the provider for notifications and PEC envelope
   signatures.

   - providerCertificate: Certificate Binary transfer
   Certificate(s) used by the provider for signing notifications and
   transport envelopes.

   - providerName: Directory string Single value
   Name of PEC provider.






Gennai et al.             Expires August 8, 2009             [Page 40]


Internet-Draft        Certified Electronic Mail          February 2009


   - mailReceipt: IA5 string Single value
   Email address to which take in charge notifications and virus
   detection notifications are sent.

   - managedDomains: IA5 string
   PEC domains handled by the provider.

   - LDIFLocationURL: Directory string Single value
   HTTPS URL where the definition of the record related to the provider
   is maintained in LDIF format. When the attribute is present in the
   record "dn: o=postacert", then it contains the definition of the
   entire directory in LDIF format.

   - providerUnit: Directory string Single value
   Name of the secondary operating environment (not available for the
   principal environment)

   Next is the LDAP scheme for the PEC providers directory according to
   the syntax described in [LDAP]:



   attributetype ( 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{40} )

   attributetype ( 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 )

   attributetype ( 16572.2.2.3
           NAME 'providerName'
           DESC 'PEC provider'
           EQUALITY caseIgnoreMatch
           SUBSTR caseIgnoreSubstringsMatch
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768}
           SINGLE-VALUE )

   attributetype ( 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{256}



Gennai et al.             Expires August 8, 2009             [Page 41]


Internet-Draft        Certified Electronic Mail          February 2009


           SINGLE-VALUE )

   attributetype ( 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 )

   attributetype ( 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 )

   attributetype ( 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{32768}
           SINGLE-VALUE )

   objectclass ( 16572.2.1.1
           NAME 'LDIFLocationURLObject'
           DESC 'Class for the insertion of a LDIFLocationURL
                 attribute'
           MAY ( LDIFLocationURL )
           SUP top AUXILIARY )

   objectclass ( 16572.2.1.2
           NAME 'provider'
           DESC 'PEC provider'
           SUP top
           MUST    ( providerCertificateHash $
                     providerCertificate $
                     providerName $
                     mailReceipt $
                     managedDomains)
           MAY     ( description $
                     LDIFLocationURL $
                     providerUnit) )


   The following LDIF file represents an example of a providers'
   directory, containing a base root and 2 fictitious providers.




Gennai et al.             Expires August 8, 2009             [Page 42]


Internet-Draft        Certified Electronic Mail          February 2009


   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.it/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
    5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw==
   mailReceipt: ricevute@anpocert.it
   LDIFLocationURL: https://www.anpocert.it/LDIF/anpocert.ldif.p7m
   managedDomains: mail.anpocert.example
   managedDomains: cert.company.example
   managedDomains: costmec.it
   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



Gennai et al.             Expires August 8, 2009             [Page 43]


Internet-Draft        Certified Electronic Mail          February 2009


   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
    r5ri4XuxTq6sS9jRsEbZrS+NmbcJ7S7eFwNQMNxYFVJqdWoLh8qExsTLXn
    sKycSnHbCfuphrKvXjQvR2da75U4zGSkroiyvJ2s9TtiCcT3lQtIjmvrFb
    aSBiyzj+za7foFUCQmxCLtDaA==
   mailReceipt: takecharge@postalser.it
   LDIFLocationURL: https://services.postalser.it/ldif.txt.p7m
   managedDomains: postal-services.it
   managedDomains: receivedmail.it
   description: Certified mail services for the public

   The following LDIF file represents an example of a PEC providers'
   directory, containing a base root and 2 fictitious providers, the
   first of which handles a secondary environment as well. The
   certificates inserted are 2 self-signed certificates used for
   example purposes only:

   dn: o=postacert
   objectclass: top
   objectclass: organization
   objectClass: LDIFLocationURLObject
   o: postacert
   LDIFLocationURL: https://igpec.rupa.it/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



Gennai et al.             Expires August 8, 2009             [Page 44]


Internet-Draft        Certified Electronic Mail          February 2009


   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@anpocert.it
   LDIFLocationURL: http://www.anpocert.it/LDIF/anpocert.ldif.p7m
   managedDomains: mail.anpocert.example
   managedDomains: cert.company.example
   managedDomains: costmec.it
   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



Gennai et al.             Expires August 8, 2009             [Page 45]


Internet-Draft        Certified Electronic Mail          February 2009


    5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl
    cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B
    Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA
    XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9
    5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw==
   mailReceipt: notifications@secondary.anpocert.it
   managedDomains: management.anpocert.example
   managedDomains: personnel.anpocert.example
   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
    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: takecharge@postalser.it
   LDIFLocationURL: http://services.postalser.it/ldif.txt.p7m
   managedDomains: postal-services.it
   managedDomains: receivedmail.it
   description: Certified mail services for the public


5. Example: Complete transaction between 2 PEC domains

   A correct transaction between 2 PEC domains goes through the
   following steps:




Gennai et al.             Expires August 8, 2009             [Page 46]


Internet-Draft        Certified Electronic Mail          February 2009


   o The sending user sends an email to his provider's Access Point;

   o The Access Point runs all checks and emits an acceptance
     notification to the user;

   o The Access Point creates a transport envelope and forwards it to
     the Incoming Point of the receiving provider;

   o The receiver's Incoming Point verifies the transport envelope and
     creates a take in charge notification to be sent to the sending
     provider;

   o The sender's Incoming Point verifies the validity of the take in
     charge notification and forwards it to the Delivery Point;

   o The sender's Delivery Point saves the take in charge notification
     in the provider's service mailbox;

   o The receiver's Incoming Point forwards the transport envelope to
     the receiver's Delivery Point;

   o The receiver's Delivery Point verifies the contents of the
     transport envelope and saves it in the recipient's mailbox;

   o The receiver's Delivery Point creates a delivery notification and
     sends it to the sender's Incoming Point;

   o The sender's Incoming Point verifies the validity of the delivery
     notification and forwards it to the sender's Delivery Point;

   o The sender's Delivery Point saves the delivery notification in
     the sending user's mailbox;

   o The receiving user has the message at his disposition.

6. Security-related aspects

6.1. Digital signature

   The private key and signature operations MUST be handled using a
   dedicated hardware security module (FIPS 140-2) which is able to
   guarantee their security in compliance with the criteria adopted in
   the European or international setting.

6.2. Authentication

   User access to PEC services through the access point MUST be allowed
   upon authentication on the system by the user himself. For example,



Gennai et al.             Expires August 8, 2009             [Page 47]


Internet-Draft        Certified Electronic Mail          February 2009


   authentication modalities might use user-ID and password, or, if
   available and considered necessary for the type of service provided,
   the electronic ID card or the national services card. Choice of
   authentication modality 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.

6.3. Secure interaction

   In order to guarantee that the original message doesn't change
   during the interaction, envelopment of and signature application on
   outgoing messages is done at the access point, and the subsequent
   verification of incoming messages is done at the incoming point. The
   original message is inserted as attachment within a transport
   envelope. The transport envelope signed by the sending provider
   permits to verify that the original message hasn't been modified
   during its transition from sender domain to receiver domain.

   All communications within the PEC network MUST use secure channels,
   and integrity and confidentiality of the connections between the PEC
   provider and the 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 are conveyed (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 circuit. When
   exchanging messages between different providers, all transactions
   MUST take place between machines that belong to the PEC circuit, or
   those directly managed by the provider. Secondary PEC messages
   reception systems, if present, MUST be under direct control of the
   provider. An "MX" type record MUST be associated to each PEC domain,
   defined within the system for name resolution.

6.4. Virus

   Another important security aspect, that concerns the entire PEC
   system, is related to the technical and functional architecture
   which 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



Gennai et al.             Expires August 8, 2009             [Page 48]


Internet-Draft        Certified Electronic Mail          February 2009


   hinder infections as much as possible, without intervening on the
   content of the certified mail, in compliance with what has been
   discussed thus far.

6.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 [X509], which in turn are based on the
   standard ISO/IEC 9594-8:2001.

6.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). 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 [X509].

6.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




Gennai et al.             Expires August 8, 2009             [Page 49]


Internet-Draft        Certified Electronic Mail          February 2009


   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 [X509].

   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 [X509]; such added extension MUST NOT be marked as
   critical.

6.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.

6.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.













Gennai et al.             Expires August 8, 2009             [Page 50]


Internet-Draft        Certified Electronic Mail          February 2009


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

6.5.3.2. General-use certificate in dump asn.1




Gennai et al.             Expires August 8, 2009             [Page 51]


Internet-Draft        Certified Electronic Mail          February 2009


   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 {
   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 {



Gennai et al.             Expires August 8, 2009             [Page 52]


Internet-Draft        Certified Electronic Mail          February 2009


   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
       :         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



Gennai et al.             Expires August 8, 2009             [Page 53]


Internet-Draft        Certified Electronic Mail          February 2009


       :           }
   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
       :             [ Another 128 bytes skipped ]
       :   }

6.6. PEC providers directory

   The contents of the PEC providers directory can be queried via HTTP
   on SSL exclusively by licensed providers that have the necessary
   user certificates; this access modality guarantees authenticity,
   integrity and discretion of data.







Gennai et al.             Expires August 8, 2009             [Page 54]


Internet-Draft        Certified Electronic Mail          February 2009


7. 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
   phases;

   o support for MIME format according to [MIME1] and [MIME5];

   o handling of media type "message.rfc822";

   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 envelopes and notifications.

8. 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.

   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.

   A Hardware Security Module compliant with the FIPS-140-2 is REQUIRED
   to store the private key of each PEC provider.

9. IANA Considerations

   This document does not require any consideration from the IANA.






Gennai et al.             Expires August 8, 2009             [Page 55]


Internet-Draft        Certified Electronic Mail          February 2009


10. References

10.1. Normative References

   [CMS]     Housley, R., "Cryptographic Message Syntax (CMS)", RFC
             3852, Vigil Security, July 2004

   [EMAIL]   P. Resnick, Editor, "Internet Message Format", RFC 5322,
             QUALCOM Incorporated, April 2001

   [LDAP]    Legg, S., Editor, "Lightweight Directory Access Protocol
             (LDAP): Syntaxes and Matching Rules", RFC 4517, eB2Bcom,
             June 2006

   [LDIF]    Good, G., "The LDAP Data Interchange Format (LDIF) -
             Technical Specification", RFC 2849, iPlanet e-commerce
             Solutions, 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

   [REQ]     Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, Harvard University,
             March 1997

   [SHA1]    Eastlake, D., and P. Jones, "US Secure Hash Algorithm 1
             (SHA1)", RFC 3174, September 2001

   [MIME-SECURE] Galvin, J., S. Murphy, S. Crocker, and N. Freed
                 "Security Multiparts for MIME: Multipart/Signed and
                 Multipart/Encrypted", RFC 1847, October 1995

   [SMIMEV3] Ramsdell, B. Editor, "Secure/Multipurpose Internet Mail
             Extensions (S/MIME) Version 3.1 Message Specifications",
             RFC 3851, Sendmail, Inc., July 2004

   [SMIMECERT] Ramsdell, B., Editor, "Secure/Multipurpose internet Mail
               Extensions (S/MIME) Version 3.1 Certificate Handling",
               RFC 3850, Sendmail, Inc., July 2004

   [SMTP]    Klensin, J. Editor, "Simple Mail Transfer Protocol", RFC
             5321, AT&T Laboratories, April 2001




Gennai et al.             Expires August 8, 2009             [Page 56]


Internet-Draft        Certified Electronic Mail          February 2009


   [SMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)", RFC
              3461, University of Tennessee, January 2003

   [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, Internet Mail
              Consortium, February 2002

   [X509]    Cooper, D., S. Santesson, S. Farrell, S. Boeyen, R.
             Housley, and W. Polk, "Internet X.509 Public Key
             Infrastructure Certificate and Certificate Revocation List
             (CRL) Profile", RFC 5280, May 2008

11. Acknowledgments

   The Italian document, on which the present 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 (CNIPA).































Gennai et al.             Expires August 8, 2009             [Page 57]


Internet-Draft        Certified Electronic Mail          February 2009


APPENDIX A: Italian fields and values in English

   X-Riferimento-Message-ID        X-Reference-Message-ID
   X-Ricevuta                      X-Notification
     non-accettazione                non-acceptance
     accettazione                    acceptance
     preavviso-errore-consegna       advance-notice-delivery-error
     presa-in-carico                 take-charge
     rilevazione-virus               virus-detection
     errore-consegna                 delivery-error
     avvenuta-consegna               message-delivered
   X-VerificaSicurezza             X-SecurityVerification
   X-Trasporto                     X-Transport
     posta-certificata               certified-mail
     errore                          error
   X-VerificaSicurezza             X-SecurityVerification
     errore                          error
   X-TipoRicevuta                  X-NotificationType
     completa                        complete
     breve                           brief
     sintetica                       concise

   certificatore                   certificator

   Subject values:

   Accettazione                              ACCEPTANCE
   Posta certificata                         CERTIFIED MAIL
   Presa in carico                           TAKE IN CHARGE
   Consegna                                  DELIVERY
   Anomalia messaggio                        MESSAGE ANOMALY
   Problema di sicurezza                     SECURITY PROBLEM
   Avviso di non accettazione                NON-ACCEPTANCE
   NOTIFICATION
   Avviso di non accettazione per virus      VIRUS DETECTION INDUCED
   NON
                                             -ACCEPTANCE NOTIFICATION
   Avviso di mancata consegna                NON-DELIVERY NOTIFICATION
   Avviso di mancata consegna per virus      NON-DELIVERY NOTIFICATION
                                             DUE TO VIRUS
   Avviso di mancata consegna per sup.       NON-DELIVERY NOTIFICATION
   tempo massimo                             DUE TO TIMEOUT









Gennai et al.             Expires August 8, 2009             [Page 58]


Internet-Draft        Certified Electronic Mail          February 2009


Authors' Addresses

   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


   Claudio Petrucci
   CNIPA
   Via Isonzo 21/B
   00198 Roma
   Italy

   Email: c.petrucci@cnipa.it

   Alessandro Vinciarelli
   CNIPA
   Via Isonzo 21/B
   00198 Roma
   Italy

   Email: alessandro.vinciarelli@cnipa.it
















Gennai et al.             Expires August 8, 2009             [Page 60]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/