RFC 6109
La Posta Elettronica Certificata - Italian Certified Electronic Mail
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.
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.
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].
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
...
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 {
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
: 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
: [ 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.
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
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
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
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.
[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.
[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.
[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).
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
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
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