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

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

Internet Draft                                           F. Gennai
Intended status: Informational                           A. Shahin
Expires: December 2008                                    ISTI-CNR
                                                       C. Petrucci
                                                    A. Vinciarelli
                                                             CNIPA
                                                         June 2008



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



Status of this Memo

   This memo provides information for the Internet community.  It
   does not specify an Internet standard of any kind. Distribution
   of this memo is unlimited.

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   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 December 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).



Gennai et al.           Expires December 2008            [Page 1]


Internet-Draft        Certified Electronic Mail         June 2008





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
   to run 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
         1.2.1. Requirement Conventions..........................5
         1.2.2. Acronyms.........................................5
         1.2.3. Terminology and Definitions......................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


Gennai et al.           Expires December 2008            [Page 2]


Internet-Draft        Certified Electronic Mail         June 2008


         3.1.2. Non-acceptance notification due to one or more
                formal exceptions...............................21
         3.1.3. Non-acceptance notification due to virus
                detection.......................................22
         3.1.4. Acceptance notification.........................23
         3.1.5. Transport envelope..............................23
         3.1.6. Timeout delivery error notification.............25
      3.2. Incoming point.......................................27
         3.2.1. Take charge notification........................27
         3.2.2. Anomaly envelope................................28
         3.2.3. Virus detection notification....................29
         3.2.4. Virus-induced delivery error notification.......30
      3.3. Delivery point.......................................31
         3.3.1. Checks on incoming messages.....................31
         3.3.2. Delivery notification...........................32
         3.3.3. Non-delivery notification.......................36
   4. Formats...................................................37
      4.1. Temporal reference...................................37
      4.2. User date/time.......................................37
      4.3. Attachments..........................................37
         4.3.1. Message body....................................37
         4.3.2. Original message................................38
         4.3.3. Certification data..............................38
      4.4. Certification data scheme............................38
      4.5. PEC providers directory scheme.......................41
   5. Example: Complete transaction between 2 PEC domains.......48
   6. Security-related aspects..................................49
      6.1. Digital signature....................................49
      6.2. Authentication.......................................49
      6.3. Secure interaction...................................50
      6.4. Virus................................................50
      6.5. S/MIME certificate...................................51
         6.5.1. Provider-related information (subject)..........51
         6.5.2. Certificate extensions..........................51
         6.5.3. Example.........................................52
      6.6. PEC providers directory..............................57
   7. PEC system client technical and functional prerequisites..57
   8. Security Considerations...................................57
   9. IANA Considerations.......................................58
   10. References...............................................58
      10.1. Normative References................................58
   11. Acknowledgments..........................................59
   APPENDIX A: Italian fields and values in English.............60
   Author's Addresses...........................................61
   Intellectual Property Statement..............................61
   Disclaimer of Validity.......................................62



Gennai et al.           Expires December 2008            [Page 3]


Internet-Draft        Certified Electronic Mail         June 2008


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 December 2008            [Page 4]


Internet-Draft        Certified Electronic Mail         June 2008


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


Gennai et al.           Expires December 2008            [Page 5]


Internet-Draft        Certified Electronic Mail         June 2008


   performs virus checks (on outgoing messages), and inserts the
   original message into a transport envelope. The messages it can
   emit are:

   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.



Gennai et al.           Expires December 2008            [Page 6]


Internet-Draft        Certified Electronic Mail         June 2008


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



Gennai et al.           Expires December 2008            [Page 7]


Internet-Draft        Certified Electronic Mail         June 2008


   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:

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





Gennai et al.           Expires December 2008            [Page 8]


Internet-Draft        Certified Electronic Mail         June 2008


   PEC provider's key: Is a key released by CNIPA to ever PEC
   provider. It is used to sign notifications and envelopes, and to
   authenticate 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 charge and virus detection
   notifications.

   Take 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 receiver
   PEC provider key.

   Time stamp: A digital evidence with which a temporal reference,
   opposable 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;


Gennai et al.           Expires December 2008            [Page 9]


Internet-Draft        Certified Electronic Mail         June 2008


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



Gennai et al.           Expires December 2008           [Page 10]


Internet-Draft        Certified Electronic Mail         June 2008


   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.

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



Gennai et al.           Expires December 2008           [Page 11]


Internet-Draft        Certified Electronic Mail         June 2008


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

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 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 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. "X-VerificaSicurezza" (Security Verification)


Gennai et al.           Expires December 2008           [Page 12]


Internet-Draft        Certified Electronic Mail         June 2008


   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

   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 December 2008           [Page 13]


Internet-Draft        Certified Electronic Mail         June 2008




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


Gennai et al.           Expires December 2008           [Page 14]


Internet-Draft        Certified Electronic Mail         June 2008


   user-readable text, and an XML part containing the certification
   data. The notification MAY also contain other attachments for
   extra features offered by the provider.

   Using the data available in the PEC providers directory (see
   section 4.5), the access point runs checks on every recipient in
   the "To:" and "Cc:" fields present in the original message to
   verify whether they belong to the PEC infrastructure or to
   non-PEC domains. Such checks are done by verifying the existence,
   through a case insensitive search, of the recipients' domains in
   the "managedDomains" attribute found within the PEC providers
   directory. Therefore, the acceptance notification (and relevant
   certification data) relates, for each recipient, 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 December 2008           [Page 15]


Internet-Draft        Certified Electronic Mail         June 2008


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 can be handled using the
   standard error notification mechanisms, as provided by SMTP in
   [SMTP] and [SMTP-DSN]. The same mechanism is also adapted 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 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:





Gennai et al.           Expires December 2008           [Page 16]


Internet-Draft        Certified Electronic Mail         June 2008


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

      -  forwards the anomaly envelope to the delivery point.

   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 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 facilitate 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 - S/MIME signature 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;


Gennai et al.           Expires December 2008           [Page 17]


Internet-Draft        Certified Electronic Mail         June 2008


   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, whereas
   the presence of the virus will be detected in a second phase,
   during which the contents of the transport envelope are
   verified. The incoming point thus refrains 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  control what virus typologies were not detected by its own
      antivirus, so as to understand the motivations and verify the
      possibility of making 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:



Gennai et al.           Expires December 2008           [Page 18]


Internet-Draft        Certified Electronic Mail         June 2008


         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 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 error is encountered, relative to the delivery
   of a correct transport envelope.

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 for the reception
   of notifications in 2 cases only:

   o  take charge notifications

   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


Gennai et al.           Expires December 2008           [Page 19]


Internet-Draft        Certified Electronic Mail         June 2008


   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

   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 also depending on the number of
      recipients; by multiplying it to the message size, the
      outcome should fall within the limits accepted by the
      provider. Italian Laws have specified this limit as being
      30MB.



Gennai et al.           Expires December 2008           [Page 20]


Internet-Draft        Certified Electronic Mail         June 2008


   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. In the case of message size, a non-
   acceptance notification is sent if the size doesn't exceed a
   certain limit, after which error handling is left to SMTP.

   The header for such a notification will contain the following
   fields:

      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.


Gennai et al.           Expires December 2008           [Page 21]


Internet-Draft        Certified Electronic Mail         June 2008


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, and instead notify the sender
   immediately of the impossibility to dispatch the message.

   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
      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 to be
   added to the notification to allow for an 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.




Gennai et al.           Expires December 2008           [Page 22]


Internet-Draft        Certified Electronic Mail         June 2008


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:

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

3.1.5. Transport envelope

   A transport envelope is a message generated by the access point,
   and 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


Gennai et al.           Expires December 2008           [Page 23]


Internet-Draft        Certified Electronic Mail         June 2008


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

   The body of the transport envelope is composed of text that
   constitutes the readable format, 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, the 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


Gennai et al.           Expires December 2008           [Page 24]


Internet-Draft        Certified Electronic Mail         June 2008


   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 path and reverse
   path) 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 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 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.



Gennai et al.           Expires December 2008           [Page 25]


Internet-Draft        Certified Electronic Mail         June 2008


   Not excluding that this will eventually take place, it is deemed
   useful to consider that the message dispatch might not have a
   positive outcome. The system will see to sending another non-
   delivery notification if in the coming 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 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 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 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 charge
      notification nor a delivery notification. In this case 2
      timeout notifications are generated; a 12-hour and a 24-hour
      timeout notification.




Gennai et al.           Expires December 2008           [Page 26]


Internet-Draft        Certified Electronic Mail         June 2008


3.2. Incoming point

3.2.1. Take 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 charge notification to the sender. The
   dispatched take 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
   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 charge
   notifications in order to cover, in absence of SMTP transport
   errors, all the recipients in its jurisdiction.

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

      X-Ricevuta: presa-in-carico
      Date: [date of take 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]

   The provider service mail address is obtained from the PEC
   providers directory during the necessary queries made for checks
   on the signature in the incoming message verification stage.

   The notification body is constructed following the underlying
   model:

      take 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]




Gennai et al.           Expires December 2008           [Page 27]


Internet-Draft        Certified Electronic Mail         June 2008


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


Gennai et al.           Expires December 2008           [Page 28]


Internet-Draft        Certified Electronic Mail         June 2008


      .
      .
      [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 message that arrived at the reception
   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 in a
   message whose origin was asserted through sender signature
   verification, the system generates a virus-detected notification
   to be sent to the sending provider, indicating as destination
   the address specified for notifications in the PEC providers
   directory, along with the error found.

   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]


Gennai et al.           Expires December 2008           [Page 29]


Internet-Draft        Certified Electronic Mail         June 2008


   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 to be
   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
   recipient 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:

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




Gennai et al.           Expires December 2008           [Page 30]


Internet-Draft        Certified Electronic Mail         June 2008


      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 to be
   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 it should send a
   notification to the sender. The delivery notification is issued
   after the message has been delivered to the recipient's mailbox,
   and only when a correct PEC transport envelope is received. 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.

   A delivery notification indicates to the user that his/her
   message has been successfully delivered to the specified
   recipient and certifies the date and time of delivery through a
   readable text and an attached XML file containing certification
   data, along with other optional attachments for functionalities
   offered by the provider.

   If the message that arrived at the delivery point cannot be
   delivered to the destination's mailbox, the delivery point emits
   a non-delivery notification (section 3.3.3). Such a notification
   is generated when encountering a problem related to the delivery
   of a correct PEC transport envelope.



Gennai et al.           Expires December 2008           [Page 31]


Internet-Draft        Certified Electronic Mail         June 2008


3.3.2. Delivery notification

   Delivery notifications are made up of a message sent to the
   sender which relates the date and time of message delivery,
   sender and recipient data, and the subject.

   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.


Gennai et al.           Expires December 2008           [Page 32]


Internet-Draft        Certified Electronic Mail         June 2008


      The message was not accepted.
      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.

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.
      The message was not accepted.
      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.




Gennai et al.           Expires December 2008           [Page 33]


Internet-Draft        Certified Electronic Mail         June 2008


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



Gennai et al.           Expires December 2008           [Page 34]


Internet-Draft        Certified Electronic Mail         June 2008


   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.

   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]"


Gennai et al.           Expires December 2008           [Page 35]


Internet-Draft        Certified Electronic Mail         June 2008


      originating from "[original sender]" and addressed to
      "[recipient]"
      was placed in the destination's mailbox.
      The message was not accepted.
      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.

3.3.3. Non-delivery notification

   If an error occurs during the delivery phase, 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]), the message "[subject]"
      originating from "[original sender]" and addressed to
      "[recipient]"
      was placed in the destination's mailbox.
      The message was not accepted.
      Message identification:  [Message-ID]

   The same certification data is inserted within an XML files to
   be attached to the notification in order to allow for a an
   automatic elaboration (section 4.4). The notification MAY



Gennai et al.           Expires December 2008           [Page 36]


Internet-Draft        Certified Electronic Mail         June 2008


   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.

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


Gennai et al.           Expires December 2008           [Page 37]


Internet-Draft        Certified Electronic Mail         June 2008


   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

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


Gennai et al.           Expires December 2008           [Page 38]


Internet-Draft        Certified Electronic Mail         June 2008


         tipo (accettazione |
               non-accettazione |
               presa-in-carico |
               avvenuta-consegna |
               posta-certificata |
               errore-consegna |
               preavviso-errore-consegna |
               rilevazione-virus) #REQUIRED
         errore (nessuno |
                 no-dest |
                 no-dominio |
                 virus |
                 altro) "nessuno">

   <!--Header of the original message-->
   <!ELEMENT intestazione (mittente,
                           destinatari+,
                           risposte,
                           oggetto?)>

   <!--Sender ("From" field) of the original message-->
   <!ELEMENT mittente (#PCDATA)>

   <!--Complete list of recipients ("To" and "Cc" fields)-->
   <!--of the original message-->
   <!--"tipo" indicates the typology of the recipient-->
   <!ELEMENT destinatari (#PCDATA)>
   <!ATTLIST destinatari
         tipo (certificato | esterno) "certificato">

   <!--Value of the "Reply-To" field of the original message-->
   <!ELEMENT risposte (#PCDATA)>
   <!--Value of the "Subject" field of the original message-->
   <!ELEMENT oggetto (#PCDATA)>

   <!--PEC message data-->
   <!ELEMENT dati (gestore-emittente,
                   data,
                   identificativo,
                   msgid?,
                   ricevuta?,
                   consegna?,
                   ricezione*,
                   errore-esteso?)>

   <!--Descriptive string of the provider that certifies -->
   <!--the data-->


Gennai et al.           Expires December 2008           [Page 39]


Internet-Draft        Certified Electronic Mail         June 2008


   <!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 "gg/mm/aaaa" 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-->
   <!--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 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)>






Gennai et al.           Expires December 2008           [Page 40]


Internet-Draft        Certified Electronic Mail         June 2008


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 modality
   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 in binary ASN.1 DER format as a file with ".p7m"
   extension. The centralized LDAP system downloads such a file on
   a 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 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 in the "providerName" attribute the name of the
   provider, whereas the "providerUnit" attribute is used to
   identify the secondary operating environments. The
   "DistinguishedName" of the records relative to the secondary


Gennai et al.           Expires December 2008           [Page 41]


Internet-Draft        Certified Electronic Mail         June 2008


   operating environments are of the type
   "providerUnit=<environment>,providerName=<name>,o=certmail".
   Every provider MUST have a record associated to its own main
   environment, to be distinguished for the lack of the
   "providerUnit" attribute with the record, and of 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 records relevant to the provider.

   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.

   - mailReceipt: IA5 string Single value
   Email address to which take 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]:



Gennai et al.           Expires December 2008           [Page 42]


Internet-Draft        Certified Electronic Mail         June 2008




   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}
           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'


Gennai et al.           Expires December 2008           [Page 43]


Internet-Draft        Certified Electronic Mail         June 2008


           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.
   The inserted certificates are two self-signed certificates used
   for example purposes only:


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


Gennai et al.           Expires December 2008           [Page 44]


Internet-Draft        Certified Electronic Mail         June 2008


    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.it
   managedDomains: cert.company.it
   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
   providerCertificateHash:
    e00fdd9d88be0e2cc766b893315caf93d5701a6a
   providerCertificate;binary::
    MIIDHjCCAoegAwIBAgIBADANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEw
    JJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIFMuci5sLjEPMA0GA1UE
    CxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0YS1jZXJ0aWZpY2F0YU
    BzZXJwb3N0YWwuaXQwHhcNMDIxMjA5MTczMjE2WhcNMDMxMjA5MTczMjE2
    WjBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YWxpIF
    Muci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5wb3N0
    YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXQwgZ8wDQYJKoZIhvcNAQEBBQ
    ADgY0AMIGJAoGBAKoc7n6zA+sO8NATMcfJ+U2aoDEsrj/cObG3QAN6Sr+l
    ygWxYXLBZNfSDWqL1K4edLr4gCZIDFsq0PIEaYZhYRGjhbcuJ9H/ZdtWdX
    xcwEWN4mwFzlsASogsh5JeqS8db3A1JWkvhO9EUfaCYk8YMAkXYdCtLD9s
    9tCYZeTE2ut9AgMBAAGjgcswgcgwHQYDVR0OBBYEFHPw7VJIoIM3VYhuHa
    eAwpPF5leMMIGYBgNVHSMEgZAwgY2AFHPw7VJIoIM3VYhuHaeAwpPF5leM
    oXKkcDBuMQswCQYDVQQGEwJJVDEfMB0GA1UEChMWU2Vydml6aSBQb3N0YW
    xpIFMuci5sLjEPMA0GA1UECxMGRC5DLkMuMS0wKwYJKoZIhvcNAQkBFh5w
    b3N0YS1jZXJ0aWZpY2F0YUBzZXJwb3N0YWwuaXSCAQAwDAYDVR0TBAUwAw


Gennai et al.           Expires December 2008           [Page 45]


Internet-Draft        Certified Electronic Mail         June 2008


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


Gennai et al.           Expires December 2008           [Page 46]


Internet-Draft        Certified Electronic Mail         June 2008


    XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9
    5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw==
   mailReceipt: notifications@anpocert.it
   LDIFLocationURL: http://www.anpocert.it/LDIF/anpocert.ldif.p7m
   managedDomains: mail.anpocert.it
   managedDomains: cert.company.it
   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
    5BLjEsMCoGCSqGSIb3DQEJARYdcG9zdGEtY2VydGlmaWNhdGFAYW5wb2Nl
    cnQuaXSCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQA58B
    Z+q1qSKpuffzTBpMtbeFkDIxMqMa+ycnxdMNvcWgCm1A9ZiFJsvqYhDDqA
    XxfHjkrzXuSZkYq6WiQCsLp0aYVy40QCIwbOunhrvsxh3vsG5CgN76JzZ9
    5Z/1OCFNhLfqf1VH2NSS8TaYCCi/VO7W1Q1KkcA2VlxlQP7McSUw==
   mailReceipt: notifications@secondary.anpocert.it
   managedDomains: management.anpocert.it
   managedDomains: personnel.anpocert.it
   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


Gennai et al.           Expires December 2008           [Page 47]


Internet-Draft        Certified Electronic Mail         June 2008


   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:

   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 charge notification to be sent to the
      sending provider;

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


Gennai et al.           Expires December 2008           [Page 48]


Internet-Draft        Certified Electronic Mail         June 2008


   o  The sender's Delivery Point saves the take charge
      notification in the provider's notifications store;

   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 its security in compliance with the criteria adopted
   in the European or international setting.

6.2. Authentication

   The possibility for a user to access PEC services through the
   access point MUST include authentication on the system by the
   user himself. For example, 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.






Gennai et al.           Expires December 2008           [Page 49]


Internet-Draft        Certified Electronic Mail         June 2008


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 transit 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. To each PEC domain an "MX"
   type record MUST be associated, defined within the system for
   name resolution.

6.4. Virus

   Another important security aspect, that concerns the entire PEC
   system, is relative 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 hinder infections as much as possible, without intervening
   on the content of the certified mail, in compliance with what
   has been discussed thus far.




Gennai et al.           Expires December 2008           [Page 50]


Internet-Draft        Certified Electronic Mail         June 2008


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 present 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. The email
   address 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

   The Basic Constraints extension (Object ID:2.5.29.19) MUST NOT
   be present.


Gennai et al.           Expires December 2008           [Page 51]


Internet-Draft        Certified Electronic Mail         June 2008


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

   The Subject Key Identifier extension (Object ID: 2.5.29.14) MUST
   contain at least the keyIdentifier field, and MUST NOT be marked
   critical.

   The Subject Alternative Name (Object ID: 2.5.29.17) MUST contain
   at least the rfc822Name field, and MUST NOT be marked critical.

   Adding other extensions that have not been described in this
   document is to be considered OPTIONAL, a s long as it is
   compliant with [X509]; such added extension MUST NOT be marked
   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 December 2008           [Page 52]


Internet-Draft        Certified Electronic Mail         June 2008


   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



Gennai et al.           Expires December 2008           [Page 53]


Internet-Draft        Certified Electronic Mail         June 2008


6.5.3.2. General-use certificate in dump asn.1

   0 30  794: SEQUENCE {
   4 30  514:   SEQUENCE {
   8 A0    3:     [0] {
   10 02   1:       INTEGER 2
         :       }
   13 02    2:     INTEGER 11226
   17 30   13:     SEQUENCE {
   19 06    9:       OBJECT IDENTIFIER
         :         sha1withRSAEncryption (1 2 840 113549 1 1 5)
   30 05    0:       NULL
         :       }
   32 30  101:     SEQUENCE {
   34 31   11:       SET {
   36 30    9:         SEQUENCE {
   38 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
   43 13    2:           PrintableString 'IT'
         :           }
         :         }
   47 31   28:       SET {
   49 30   26:         SEQUENCE {
   51 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
   56 13   19:           PrintableString 'Certificatore 1'
         :           }
         :         }
   77 31   22:       SET {
   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'





Gennai et al.           Expires December 2008           [Page 54]


Internet-Draft        Certified Electronic Mail         June 2008


         :       }
   167 30   66:     SEQUENCE {
   169 31   11:       SET {
   171 30    9:         SEQUENCE {
   173 06    3:           OBJECT IDENTIFIER
              :            countryName (2 5 4 6)
   178 13    2:           PrintableString 'IT'
         :           }
         :         }
   182 31   23:       SET {
   184 30   21:         SEQUENCE {
   186 06    3:           OBJECT IDENTIFIER
              :            organizationName (2 5 4 10)
   191 13   14:           PrintableString 'AcmePEC S.p.A.'
         :           }
         :         }
   207 31   26:       SET {
   209 30   24:         SEQUENCE {
   211 06    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
   216 13   17:           PrintableString 'Posta Certificata'
         :           }
         :         }
         :       }
   235 30  159:     SEQUENCE {
   238 30   13:       SEQUENCE {
   240 06    9:         OBJECT IDENTIFIER
              :          rsaEncryption (1 2 840 113549 1 1 1)
   251 05    0:         NULL
         :         }
   253 03  141:       BIT STRING 0 unused bits
         :         30 81 89 02 81 81 00 AF BE B4 55 63 19 8A AA 9B
         :         AC 3F 1B 29 B5 BE 7F 69 19 45 89 D0 15 69 CA 0D
         :         55 5B 5C 33 D7 E9 C8 6E FC 14 46 C3 C3 09 47 DD
         :         CD 10 74 1D 76 4E 71 14 E7 69 42 BE 1C 47 61 85
         :         4D 74 76 DD 0B B5 78 4F 1E 84 DD B4 86 7F 96 DF
         :         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


Gennai et al.           Expires December 2008           [Page 55]


Internet-Draft        Certified Electronic Mail         June 2008


         :          30 1E 81 1C 70 6F 73 74 61 2D 63 65 72 74 69 66
         :          69 63 61 74 61 40 61 63 6D 65 70 65 63 2E 69 74
         :           }
   442 30   14:         SEQUENCE {
   444 06    3:           OBJECT IDENTIFIER keyUsage (2 5 29 15)
   449 01    1:           BOOLEAN TRUE
   452 04    4:           OCTET STRING
         :             03 02 07 80
         :           }
   458 30   31:         SEQUENCE {
   460 06    3:           OBJECT IDENTIFIER
              :            authorityKeyIdentifier (2 5 29 35)
   465 04   24:           OCTET STRING
         :          30 16 11 11 11 11 AA AA AA AA AA BB BB BB BB CC
         :          CC CC CC DD DD DD DD
         :           }
   491 30   29:         SEQUENCE {
   493 06    3:           OBJECT IDENTIFIER
              :            subjectKeyIdentifier (2 5 29 14)
   498 04   22:           OCTET STRING
         :          04 14 3A FA E0 80 64 53 52 7A 3E 57 09 D8 49 A9
         :          41 A8 A3 A7 0A E1
         :           }
         :         }
         :       }
         :     }
   522 30   13:   SEQUENCE {
   524 06    9:     OBJECT IDENTIFIER
         :       sha1withRSAEncryption (1 2 840 113549 1 1 5)
   535 05    0:     NULL
         :     }
   537 03  257:   BIT STRING 0 unused bits
         :     87 4B 4D 25 70 A4 61 80 C9 77 0A 85 FE 79 23 CE
         :     B2 2D 29 55 2F 3A F2 07 14 2B 2A BA 64 3A AA 61
         :     1F F0 E7 3F C4 E6 13 E2 09 3D F0 E1 83 A0 C0 F2
         :     C6 71 7F 3A 1C 80 7F 15 B3 D6 1E 22 79 B8 AC 91
         :     51 83 F2 3A 84 86 B6 07 2B 22 E8 01 52 2D A4 50
         :     9F C6 42 D4 7C 38 B1 DD 88 CD FC E8 C3 12 C3 62
         :     64 0F 16 BF 70 15 BC 01 16 78 30 2A DA FA F3 70
         :     E2 D3 0F 00 B0 FD 92 11 6C 55 45 48 F5 64 ED 98
         :             [ Another 128 bytes skipped ]
         :   }






Gennai et al.           Expires December 2008           [Page 56]


Internet-Draft        Certified Electronic Mail         June 2008








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.

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 to such server 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



Gennai et al.           Expires December 2008           [Page 57]


Internet-Draft        Certified Electronic Mail         June 2008


   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
   a [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 attribute managedDomains associated to such
   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.

10. References

10.1. Normative References

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

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

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

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

   [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

Gennai et al.           Expires December 2008           [Page 58]


Internet-Draft        Certified Electronic Mail         June 2008


   [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 2821, AT&T Laboratories, April 2001

   [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 December 2008           [Page 59]


Internet-Draft        Certified Electronic Mail         June 2008


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 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. tempo massimo
                                            NON-DELIVERY
                                             NOTIFICATION
                                             DUE TO TIMEOUT



Gennai et al.           Expires December 2008           [Page 60]


Internet-Draft        Certified Electronic Mail         June 2008





Author's 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


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the
   technology described in this document or the extent to which any
   license under such rights might or might not be available; nor


Gennai et al.           Expires December 2008           [Page 61]


Internet-Draft        Certified Electronic Mail         June 2008


   does it represent that it has made any independent effort to
   identify any such rights.  Information on the procedures with
   respect to rights in RFC documents can be found in BCP 78 and
   BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the
   use of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR
   repository at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be
   required to implement this standard.  Please address the
   information to the IETF at ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
   THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM
   ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
   ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
   OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and
   restrictions contained in BCP 78, and except as set forth
   therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.








Gennai et al.           Expires December 2008           [Page 62]


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