Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6109

La Posta Elettronica Certificata - Italian Certified Electronic Mail

Pages: 65
Informational
Errata
Part 3 of 3 – Pages 48 to 65
First   Prev   None

Top   ToC   RFC6109 - Page 48   prevText

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