
Article 1 

1. Member States shall put in place the necessary technical means allowing them to process electronically signed documents that service providers submit in the context of completing procedures and formalities through the Points of Single Contact as foreseen by Article 8 of Directive 2006/123/EC, and which are signed by competent authorities of other Member States with an XML or a CMS or a PDF advanced electronic signature in the BES or EPES format, that complies with the technical specifications set out in the Annex.
2. Member States whose competent authorities sign the documents referred to in paragraph 1 using other formats of electronic signatures than those referred to in that same paragraph, shall notify to the Commission existing validation possibilities that allow other Member States to validate the received electronic signatures online, free of charge and in a way that is understandable for non-native speakers unless the required information is already included in the document, in the electronic signature or in the electronic document carrier. The Commission will make that information available to all Member States.
Article 2 
This Decision shall apply from 1 August 2011.
Article 3 
This Decision is addressed to the Member States.
Done at Brussels, 25 February 2011.
For the Commission
Michel BARNIER
Member of the Commission
ANNEX
Within the following part of the document the key words ‘MUST’, ‘MUST NOT’, ‘REQUIRED’, ‘SHALL’, ‘SHALL NOT’, ‘SHOULD’, ‘SHOULD NOT’, ‘RECOMMENDED’, ‘MAY’, and ‘OPTIONAL’ are to be interpreted as described in RFC 2119.

SECTION 1 —
The signature is conform with the W3C XML Signature specifications

The signature MUST at least be a XAdES-BES (or -EPES) signature form as specified in the ETSI TS 101 903 XAdES specifications and complies with all the following additional specifications:


 The ds:CanonicalizationMethod that specifies the canonicalization algorithm applied to the SignedInfo element prior to performing signature calculations identifies one of the following algorithms only:
Canonical XML 1.0 (omits comments)http://www.w3.org/TR/2001/REC-xml-c14n-20010315Canonical XML 1.1 (omits comments)http://www.w3.org/2006/12/xml-c14n11Exclusive XML Canonicalization 1.0 (omits comments)http://www.w3.org/2001/10/xml-exc-c14n#
 Other algorithms or of ‘With comments’ versions of the above listed algorithms SHOULD NOT be used for the signature creation but SHOULD be supported for residual interoperability for the signature verification.
 MD5 (RFC 1321) MUST NOT be used as a digest algorithm. Signers are referred to applicable national laws, and for the purposes of guidelines to ETSI TS 102 176 and to the ECRYPT2 D.SPA.x report for further recommendations on algorithms and parameters eligible for electronic signatures.

The use of transforms is restricted to the ones listed below:


 Canonicalization transforms: see related specifications above;
 Base64 encoding (http://www.w3.org/2000/09/xmldsig#base64);
 Filtering:
XPath (http://www.w3.org/TR/1999/REC-xpath-19991116)for compatibility reasons and conformance with XMLDSigXPath Filter 2.0 (http://www.w3.org/2002/06/xmldsig-filter2)as a successor for XPath due to performance issues
 Enveloped signature transform: (http://www.w3.org/2000/09/xmldsig#enveloped-signature).
 XSLT (style sheet) transform.

The ds:KeyInfo element MUST include the signer’s X.509 v3 digital certificate (i.e. its value and not only a reference to it).

The ‘SigningCertificate’ signed signature property MUST contain the digest value (CertDigest) and IssuerSerial of the signer’s certificate stored in ds:KeyInfo and the optional URI in ‘SigningCertificate’ field MUST NOT be used.

The SigningTime signed signature property is present and contains the UTC expressed as xsd:dateTime (http://www.w3.org/TR/xmlschema-2/#dateTime).

The DataObjectFormat element MUST BE present and contain MimeType sub-element.

In case the signatures used by Member States are based on a qualified certificate, the PKI objects (certificate chains, revocation data, time-stamps) that are included in the signatures are verifiable using the Trusted List, in accordance with Commission Decision 2009/767/EC, of the Member State who is supervising or accrediting the CSP having issued the signatory’s certificate.

Table 1 summarises the specifications that a XAdES-BES/EPES signature must comply with to be supported technically by the receiving Member State.

SECTION 2 —
The signature is conform with the Cryptographic Message Syntax (CMS) Signature specifications.

The signature uses CAdES-BES (or -EPES) signature attributes as specified in the ETSI TS 101 733 CAdES specifications and complies with the additional specifications as indicated in Table 2 below.

All attributes of CAdES which are included in the archive timestamp hash calculation (ETSI TS 101 733 V1.8.1 Annex K) MUST be in DER encoding and any other can be in BER to simplify one-pass processing of CAdES.

MD5 (RFC 1321) MUST NOT be used as a digest algorithm. Signers are referred to applicable national laws, and for the purposes of guidelines to ETSI TS 102 176 and to the ECRYPT2 D.SPA.x report for further recommendations on algorithms and parameters eligible for electronic signatures.

The signed attributes MUST include a reference to the signer’s X.509 v3 digital certificate (RFC 5035) and SignedData.certificates field MUST include its value.

The SigningTime signed attribute MUST be present and MUST contain the UTC expressed as in http://tools.ietf.org/html/rfc5652#section-11.3.

The ContentType signed attribute MUST be present and contains id-data (http://tools.ietf.org/html/rfc5652#section-4) where the data content type is intended to refer to arbitrary octet strings, such as UTF-8 text or ZIP container with MimeType sub-element.

In case the signatures used by Member States are based on a qualified certificate, the PKI objects (certificate chains, revocation data, time-stamps) that are included in the signatures are verifiable using the Trusted List, in accordance with Commission Decision 2009/767/EC, of the Member State who is supervising or accrediting the CSP having issued the signatory’s certificate.

SECTION 3 —
The signature MUST use a PAdES-BES (or -EPES) signature extension as specified in the ETSI TS 102 778 PAdES-Part3 specifications and complies with the following additional specifications:

MD5 (RFC 1321) MUST NOT be used as a digest algorithm. Signers are referred to applicable national laws, and for the purposes of guidelines, to ETSI TS 102 176 and to the ECRYPT2 D.SPA.x report for further recommendations on algorithms and parameters eligible for electronic signatures.

The signed attributes MUST include a reference to the signer’s X.509 v3 digital certificate (RFC 5035) and SignedData.certificates field MUST include its value.

The time of signing is indicated by the value of the M entry in the signature dictionary.

In case the signatures used by Member States are based on a qualified certificate, the PKI objects (certificate chains, revocation data, time-stamps) that are included in the signatures are verifiable using the Trusted List, in accordance with Decision 2009/767/EC, of the Member State who is supervising or accrediting the CSP having issued the signatory’s certificate.
