tech-invite   World Map     

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

RFC 6109

 
 
 

La Posta Elettronica Certificata - Italian Certified Electronic Mail

Part 3 of 3, p. 48 to 65
Prev RFC Part

 


prevText      Top      Up      ToC       Page 48 
5.  Security-Related Aspects

5.1.  Digital Signature

   It is recommended that a dedicated hardware module be used to handle
   private key and signature operations, the specifications of which are
   outside the scope of this document.  It's up to the PEC providers to
   conform to security requisites expected for the service.

5.2.  Authentication

   User access to PEC services through the Access Point MUST be allowed
   only upon successful user authentication on the system.

   For example, authentication might use user-ID and password, or, if
   available and considered necessary for the type of service provided,
   an electronic ID card or the national services card.  Choice of
   authentication method is left to the better judgment of the service
   provider.  Authentication is necessary to guarantee as much as
   possible that the message is sent by a PEC user whose identification
   data is congruent with the specified sender, so as to avoid
   falsification of the latter.

Top      Up      ToC       Page 49 
5.3.  Secure Interaction

   To guarantee that the original message remains unaltered during
   transaction, envelopment and signature are applied on outgoing
   messages at the Access Point, and subsequent verification of incoming
   messages is done at the Incoming Point.

   All communications within the PEC network MUST use secure channels.
   Integrity and confidentiality of connections between PEC provider and
   user MUST be guaranteed through the use of secure protocols, such as
   those based on [TLS] and those that create a secure transport channel
   on which non-secure protocols can transmit (e.g., IPsec).

   The interaction between providers MUST take place using SMTP on
   [TLS], as per [SMTP-TLS].  The Incoming Point MUST provide and
   announce its support for the STARTTLS extension, as well as accept
   both unencrypted connections (for ordinary mail) and protected ones.
   To guarantee complete traceability in the flow of PEC messages, these
   MUST NOT transit on systems external to the PEC network.  When
   exchanging messages between different providers, all transactions
   MUST take place between machines that belong to the PEC network or
   are directly managed by the provider.  An "MX" type record MAY be
   associated to each PEC domain defined within the system for name
   resolution, in which case secondary reception systems specified in
   that record MUST be under direct control of the provider.  All in
   conformance with [SMTP].

5.4.  Virus

   Another important security aspect that concerns the PEC system, is
   related to the technical and functional architecture that MUST block
   the presence of viruses from endangering the security of all handled
   messages.  It is therefore REQUIRED to have installations and
   continuous updates of anti-virus systems that hinder infections as
   much as possible without intervening on the content of the certified
   mail, in compliance with what has been discussed thus far.

5.5.  S/MIME Certificate

   In this document the S/MIME certificate profile is defined for use in
   the certification of PEC messages done by the providers.  The
   proposed profile of the S/MIME certificate is based on the IETF
   standards [SMIMECERT] and [CRL], which in turn are based on the
   standard ISO/IEC 9594-8:2001.

Top      Up      ToC       Page 50 
5.5.1.  Provider-Related Information (Subject)

   The information related to the PEC provider holder of the certificate
   MUST be inserted in the Subject field (Subject DN).  More precisely,
   the Subject DN MUST contain the PEC provider's name as it is in the
   "providerName" attribute published in the PEC providers directory
   (section 4.5), but the Subject DN does not have to match the Provider
   entry DN in the LDIF.  The providerName MUST be present in the
   CommonName or OrganizationName attributes of the "Subject:" field in
   the certificate.

   Certificates MUST contain an Internet mail address, which MUST have a
   value in the subjectAltName extension, and SHOULD NOT be present in
   the Subject Distinguished Name.

   Valid subjectDN are:

        C=IT, O=AcmePEC S.p.A, CN=Posta Certificata

        C=IT, O=ServiziPEC S.p.A, CN=Posta Certificata

   Valorization of other attributes in the Subject DN, if present, MUST
   be done in compliance with [CRL].

5.5.2.  Certificate Extensions

   Extensions that MUST be present in the S/MIME certificate are:

   o  Key Usage

   o  Authority Key Identifier

   o  Subject Key Identifier

   o  Subject Alternative Name

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

   The valorization of the above listed extensions for the described
   profile follows.

   The Key Usage extension (Object ID: 2.5.29.15) MUST have the
   digitalSignature bit (bit 0) activated and MUST be marked as
   critical.  The extension MAY contain other active bits corresponding
   to different Key Usage, as long as that doesn't contrast with the
   indications in [CRL].

Top      Up      ToC       Page 51 
   The Authority Key Identifier (Object ID: 2.5.29.35) MUST contain at
   least the keyIdentifier field and MUST NOT be marked as critical.

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

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

   Adding other extensions that have not been described in this document
   is to be considered OPTIONAL, as long as it remains compliant with
   [CRL]; such added extensions MUST NOT be marked as critical.

5.5.3.  Example

   Following is an example of an S/MIME certificate compliant with the
   minimal requisites described in this profile.  Values used are of
   fictitious providers generated for example purposes only.

5.5.3.1.  General-Use Certificate in Annotated Version

   An asterisk near the label of an extension means that such an
   extension has been marked as critical.

       VERSION: 3
       SERIAL: 11226 (0x2bda)
       INNER SIGNATURE:
         ALG. ID: id-sha1-with-rsa-encryption
         PARAMETER: 0
       ISSUER:
         Country Name: IT
         Organization Name: Certifier 1
         Organizational Unit Name: Certification Service Provider
         Common Name: Certifier S.p.A.
       VALIDITY:
         Not Before: Oct 5, 04 09:04:23 GMT
         Not After: Oct 5, 05 09:04:23 GMT
       SUBJECT:
         Country Name: IT
         Organization Name: AcmePEC S.p.A.
         Common Name: Certified Mail
       PUBLIC KEY: (key size is 1024 bits)
       ALGORITHM:
         ALG. ID: id-rsa-encryption
         PARAMETER: 0
       MODULUS: 0x00afbeb4 5563198a aa9bac3f 1b29b5be
                7f691945 89d01569 ca0d555b 5c33d7e9

Top      Up      ToC       Page 52 
                ...
                d15ff128 6792def5 b3f884e6 54b326db
                cf
       EXPONENT: 0x010001
       EXTENSIONS:
         Subject Alt Name:
         RFC Name: posta-certificata@acmepec.it
         Key Usage*: Digital Signature
         Authority Key Identifier: 0x12345678 aaaaaaaa bbbbbbbb
                                   cccccccc dddddddd
         Subject Key Identifier: 0x3afae080 6453527a 3e5709d8 49a941a8
                                 a3a70ae1
       SIGNATURE:
         ALG. ID: id-sha1-with-rsa-encryption
         PARAMETER: 0
         VALUE: 0x874b4d25 70a46180 c9770a85 fe7923ce
                b22d2955 2f3af207 142b2aba 643aaa61
                ...
                d8fd10b4 c9e00ebc c089f7a3 549a1907
                ff885220 ce796328 b0f8ecac 86ffb1cc

5.5.3.2.  General-Use Certificate in Dump ASN.1

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

Top      Up      ToC       Page 53 
   79 30   20:    SEQUENCE {
   81 06   3:   OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
   86 13   13:    PrintableString 'Certification Service Provider'
         :      }
         :    }
   101 31  32:   SET {
   103 30  30:    SEQUENCE {
   105 06  3:      OBJECT IDENTIFIER commonName (2 5 4 3)
   110 13  23:     PrintableString 'Certificatore S.p.A.'
         :      }
         :    }
         :  }
   135 30  30:  SEQUENCE {
   137 17  13:   UTCTime '041005090423Z'
   152 17  13:   UTCTime '051005090423Z'
         :     }
   167 30  66:  SEQUENCE {
   169 31  11:   SET {
   171 30  9:     SEQUENCE {
   173 06  3:      OBJECT IDENTIFIER countryName (2 5 4 6)
   178 13  2:      PrintableString 'IT'
         :      }
         :    }
   182 31  23:  SET {
   184 30  21:   SEQUENCE {
   186 06  3:     OBJECT IDENTIFIER organizationName (2 5 4 10)
   191 13  14:    PrintableString 'AcmePEC S.p.A.'
         :      }
         :    }
   207 31  26:  SET {
   209 30  24:   SEQUENCE {
   211 06  3:     OBJECT IDENTIFIER commonName (2 5 4 3)
   216 13  17:    PrintableString 'Posta Certificata'
         :      }
         :    }
         :  }
   235 30  159: SEQUENCE {
   238 30  13:   SEQUENCE {
   240 06  9:     OBJECT IDENTIFIER rsaEncryption (1 2 840 113549
                  1 1 1)
   251 05  0:     NULL
         :      }
   253 03  141:  BIT STRING 0 unused bits
         :     30 81 89 02 81 81 00 AF BE B4 55 63 19 8A AA 9B
         :     AC 3F 1B 29 B5 BE 7F 69 19 45 89 D0 15 69 CA 0D
         :     55 5B 5C 33 D7 E9 C8 6E FC 14 46 C3 C3 09 47 DD
         :     CD 10 74 1D 76 4E 71 14 E7 69 42 BE 1C 47 61 85
         :     4D 74 76 DD 0B B5 78 4F 1E 84 DD B4 86 7F 96 DF

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

Top      Up      ToC       Page 55 
         :         [ Another 128 bytes skipped ]
         : }

5.6.  PEC Providers Directory

   The contents of the PEC providers directory MUST be queried via
   [HTTP] on a Secure Socket Layer (SSL), as described in [TLS],
   exclusively by licensed providers that have the necessary user
   certificates; this access modality guarantees authenticity,
   integrity, and confidentiality of data.  Each provider downloads the
   LDIF file through an [HTTPS] session, which is authenticated by
   checking the X.509 certificate issued by a certification authority.

6.  PEC System Client Technical and Functional Prerequisites

   This section lists the prerequisites that must be respected by a
   client in order to guarantee the minimal operative functionalities to
   the user of a general PEC system:

   o  handling of Access and Delivery Points through secure channels;

   o  handling of user authentication in message dispatch and reception
      which make use of standard protocols, such as [IMAP], [POP3], and
      [HTTP];

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

   o  support for "ISO-8859-1 (Latin-1)" character set;

   o  support for S/MIME v3 standard, as in [SMIMEV3], for verification
      of signatures applied to PEC envelopes and notifications.

7.  Security Considerations

   All security considerations from [CMS] and [SMIMEV3] apply to
   applications that use procedures described in this document.

   The centralized LDAP server is a critical point for the security of
   the whole PEC system.  An attack could compromise the whole PEC
   system.  PEC providers that periodically download the LDIF file
   SHOULD use the best security technology to protect it from local
   attacks.  A PEC provider could be compromised if an attacker changed
   a certificate or modified the list of domains associated to it in the
   LDIF file that was copied to the PEC provider system.

Top      Up      ToC       Page 56 
   When verifying the validity of the signature of a message, the
   recipient system SHOULD verify that the certificate included in the
   [CMS] message is present in the LDIF file (section 4.5) and that the
   domain extracted by the [EMAIL] "From:" header is listed in the
   managedDomains attribute associated to said certificate.

8.  IANA Considerations

8.1.  Registration of PEC Message Header Fields

   This document defines new header fields used in the messages that
   transit in the PEC network.  As specified and required by
   [HEADERS-IANA], this document registers new header fields as
   Provisional Message Header Fields as follows.

8.1.1.  Header Field: X-Riferimento-Message-ID:

   Applicable protocol: mail [EMAIL]

   Status: provisional

   Author/Change controller:

      Claudio Petrucci
      DigitPA
      Viale Carlo Marx 31/49
      00137 Roma
      Italy
      EMail: PETRUCCI@digitpa.gov.it

   Specification document: this document, section 2.2.1, Appendix A.

8.1.2.  Header Field: X-Ricevuta:

   Applicable protocol: mail [EMAIL]

   Status: provisional

   Author/Change controller:

      Claudio Petrucci
      DigitPA
      Viale Carlo Marx 31/49
      00137 Roma
      Italy
      EMail: PETRUCCI@digitpa.gov.it

Top      Up      ToC       Page 57 
   Specification document: this document, sections 2.1.1.1.1, 3.1.2,
                           3.1.3, 3.1.4, 3.1.6, 3.2.1, 3.2.3, 3.2.4,
                           3.3.2, 3.3.3, Appendix A.

8.1.3.  Header Field: X-VerificaSicurezza:

   Applicable protocol: mail [EMAIL]

   Status: provisional

   Author/Change controller:

      Claudio Petrucci
      DigitPA
      Viale Carlo Marx 31/49
      00137 Roma
      Italy
      EMail: PETRUCCI@digitpa.gov.it

   Specification document: this document, sections 2.1.1.1.3, 3.1.3,
                           3.2.4, Appendix A.

8.1.4.  Header Field: X-Trasporto:

   Applicable protocol: mail [EMAIL]

   Status: provisional

   Author/Change controller:

      Claudio Petrucci
      DigitPA
      Viale Carlo Marx 31/49
      00137 Roma
      Italy
      EMail: PETRUCCI@digitpa.gov.it

   Specification document: this document, sections 3.1.5, 3.2.2,
                           Appendix A.

8.1.5.  Header Field: X-TipoRicevuta:

   Applicable protocol: mail [EMAIL]

   Status: provisional

Top      Up      ToC       Page 58 
   Author/Change controller:

      Claudio Petrucci
      DigitPA
      Viale Carlo Marx 31/49
      00137 Roma
      Italy
      EMail: PETRUCCI@digitpa.gov.it

   Specification document: this document, sections 3.1.5, 3.3.2,
                           3.3.2.1, 3.3.2.2, 3.3.2.3, Appendix A.

8.1.6.  Header Field: X-Mittente:

   Applicable protocol: mail [EMAIL]

   Status: provisional

   Author/Change controller:

      Claudio Petrucci
      DigitPA
      Viale Carlo Marx 31/49
      00137 Roma
      Italy
      EMail: PETRUCCI@digitpa.gov.it

   Specification document: this document, sections 3.2.3, Appendix A.

8.2.  Registration of LDAP Object Identifier Descriptors

   This document defines new LDAP attributes and object classes for
   object identifier descriptors.  As specified and required by
   [LDAP-IANA], this document registers new descriptors as follows per
   the Expert Review.

8.2.1.  Registration of Object Classes and Attribute Types

   Subject: Request for LDAP Descriptor Registration

   Descriptor (short name): See comments

   Object Identifier: See comments

   Person & email address to contact for further information:
      See "Author/Change Controller"

   Usage: See comments

Top      Up      ToC       Page 59 
   Specification: (I-D)

   Author/Change Controller:

      Claudio Petrucci
      DigitPA
      Viale Carlo Marx 31/49
      00137 Roma
      Italy
      EMail: PETRUCCI@digitpa.gov.it

   Comments:

      The following object identifiers and associated object classes/
      attribute types are requested to be registered.

   OID                         Descriptor              Usage
   ------------------------    ---------------------   ------
   1.3.6.1.4.1.16572.2.1.1     LDIFLocationURLObject      O
   1.3.6.1.4.1.16572.2.1.2     provider                   O
   1.3.6.1.4.1.16572.2.2.1     providerCertificateHash    A
   1.3.6.1.4.1.16572.2.2.2     providerCertificate        A
   1.3.6.1.4.1.16572.2.2.3     providerName               A
   1.3.6.1.4.1.16572.2.2.4     mailReceipt                A
   1.3.6.1.4.1.16572.2.2.5     managedDomains             A
   1.3.6.1.4.1.16572.2.2.6     LDIFLocationURL            A
   1.3.6.1.4.1.16572.2.2.7     providerUnit               A

   Legend
   -------------------
   O => Object Class
   A => Attribute Type

9.  References

9.1.  Normative References

   [ABNF]          Crocker, D., Ed., and P. Overell, "Augmented BNF for
                   Syntax Specifications: ABNF", STD 68, RFC 5234,
                   January 2008.

   [CMS]           Housley, R., "Cryptographic Message Syntax (CMS)",
                   STD 70, RFC 5652, September 2009.

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

Top      Up      ToC       Page 60 
   [EMAIL]         Resnick, P., Ed., "Internet Message Format", RFC
                   5322, October 2008.

   [HEADERS-IANA]  Klyne, G., Nottingham, M., and J. Mogul,
                   "Registration Procedures for Message Header Fields",
                   BCP 90, RFC 3864, September 2004.

   [HTTP]          Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                   Masinter, L., Leach, P., and T. Berners-Lee,
                   "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
                   June 1999.

   [HTTPS]         Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [IMAP]          Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
                   VERSION 4rev1", RFC 3501, March 2003.

   [LDAP]          Zeilenga, K., Ed., "Lightweight Directory Access
                   Protocol (LDAP): Technical Specification Road Map",
                   RFC 4510, June 2006.

   [LDAP-IANA]     Zeilenga, K., "Internet Assigned Numbers Authority
                   (IANA) Considerations for the Lightweight Directory
                   Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

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

   [LDIF]          Good, G., "The LDAP Data Interchange Format (LDIF) -
                   Technical Specification", RFC 2849, June 2000.

   [MIME1]         Freed, N. and N. Borenstein, "Multipurpose Internet
                   Mail Extensions (MIME) Part One: Format of Internet
                   Message Bodies", RFC 2045, November 1996.

   [MIME5]         Freed, N. and N. Borenstein, "Multipurpose Internet
                   Mail Extensions (MIME) Part Five: Conformance
                   Criteria and Examples", RFC 2049, November 1996.

   [SUBMISSION]    Gellens, R. and J. Klensin, "Message Submission for
                   Mail", RFC 4409, April 2006.

   [POP3]          Myers, J. and M. Rose, "Post Office Protocol -
                   Version 3", STD 53, RFC 1939, May 1996.

Top      Up      ToC       Page 61 
   [REQ]           Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

   [SMIMEV3]       Ramsdell, B. and S. Turner, "Secure/Multipurpose
                   Internet Mail Extensions (S/MIME) Version 3.2 Message
                   Specification", RFC 5751, January 2010.

   [SMIMECERT]     Ramsdell, B. and S. Turner, "Secure/Multipurpose
                   Internet Mail Extensions (S/MIME) Version 3.2
                   Certificate Handling", RFC 5750, January 2010.

   [SMTP]          Klensin, J., "Simple Mail Transfer Protocol", RFC
                   5321, October 2008.

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

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

   [TIMESTAMP]     Klyne, G. and C. Newman, "Date and Time on the
                   Internet: Timestamps", RFC 3339, July 2002.

   [TLS]           Dierks, T. and E. Rescorla, "The Transport Layer
                   Security (TLS) Protocol Version 1.2", RFC 5246,
                   August 2008.

   [XML]           W3C, "Extensible Markup Language (XML) 1.0 (Fifth
                   Edition)", W3C Recommendation, November 2008,
                   <http://www.w3.org/TR/2006/REC-xml-20060816/>.

9.2. Informative References

   [RFC1034]       Mockapetris, P., "Domain names - concepts and
                   facilities", STD 13, RFC 1034, November 1987.

Top      Up      ToC       Page 62 
   [RFC4522]       Legg, S., "Lightweight Directory Access Protocol
                   (LDAP): The Binary Encoding Option", RFC 4522, June
                   2006.

   [RFC4523]      Zeilenga, K., "Lightweight Directory Access Protocol
                   (LDAP) Schema Definitions for X.509 Certificates",
                   RFC 4523, June 2006.

10.  Acknowledgments

   The Italian document on which this document is based, is a product of
   the collaboration of many with the supervision of the National Center
   for Informatics in the Public Administration of Italy (DigitPA).

Top      Up      ToC       Page 63 
Appendix A.  Italian Fields and Values in English

   NOTE: The right column represents a translation of the Italian fields
         for readability's sake only.  Header fields that MUST be used
         are the ones in the left column.

    X-Riferimento-Message-ID        Reference Message Identifier
    X-Ricevuta                      Notification
      non-accettazione                non acceptance
      accettazione                    server-user acceptance
      preavviso-errore-consegna       delivery error advance notice
      presa-in-carico                 server-server acceptance
      rilevazione-virus               virus detection
      errore-consegna                 delivery error
      avvenuta-consegna               message delivered
    X-Mittente                      Sender
    X-VerificaSicurezza             Security Verification
      errore                          error
    X-Trasporto                     Transport
      posta-certificata               certified mail
      errore                          error
    X-TipoRicevuta                  Notification Type
      completa                        complete
      breve                           brief
      sintetica                       concise

    certificatore                   certificator

    Subject values:

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

Top      Up      ToC       Page 64 
   Italian terms in the DTD relative to the certification XML file:

      accettazione                   server-user acceptance
      altro                          other
      avvenuta-consegna              delivered
      certificato                    certificate
      consegna                       delivery
      data                           date
      dati                           data
      destinatari                    recipients
      esterno                        external
      errore                         error
      errore-consegna                delivery error
      errore-esteso                  extensive error
      gestore-emittente              transmitting provider
      giorno                         day
      identificativo                 identifier
      intestazione                   header
      mittente                       sender
      no-dest(inatario)              no recipient
      no-dominio                     no domain
      non-accettazione               non acceptance
      nessuno                        none
      oggetto                        subject
      ora                            hour
      posta-certificata              certified mail
      preavviso-errore-consegna      delivery error advance notice
      presa-in-carico                server-server acceptance
      ricevuta                       notification
      ricezione                      receipt (the act of receiving)
      rilevazione-virus              virus detection
      risposte                       replies
      tipo                           type

Top      Up      ToC       Page 65 
Authors' Addresses

   Claudio Petrucci
   DigitPA
   Viale Marx 31/49
   00137 Roma
   Italy

   EMail: petrucci@digitpa.gov.it

   Francesco Gennai
   ISTI-CNR
   Via Moruzzi, 1
   56126 Pisa
   Italy

   EMail: francesco.gennai@isti.cnr.it


   Alba Shahin
   ISTI-CNR
   Via Moruzzi, 1
   56126 Pisa
   Italy

   EMail: alba.shahin@isti.cnr.it


   Alessandro Vinciarelli
   Via delle Vigne di Morena 113
   00118 Roma
   Italy

   EMail: alessandro.vinciarelli@gmail.com