2011/130/EU: Commission Decision of 25 February 2011 establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market (notified under document C(2011) 1081) Text with EEA relevance

• CELEX: Directive 2006/123/EC
• Articles: 4

Article 1 Reference format for electronic signatures

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 Application

This Decision shall apply from 1 August 2011.

Article 3 Addressees

This Decision is addressed to the Member States.

Schedules & Appendices

ANNEX

ANNEX

Specifications for an XML, CMS or PDF advanced electronic signature to be technically supported by the receiving Member State

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  ( 1 ) .

SECTION 1 —   XAdES-BES/EPES

The signature is conform with the W3C XML Signature specifications  ( 2 )

The signature MUST at least be a XAdES-BES (or -EPES) signature form as specified in the ETSI TS 101 903 XAdES specifications  ( 3 ) 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-20010315

Canonical XML 1.1 (omits comments)

:

http://www.w3.org/2006/12/xml-c14n11

Exclusive 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  ( 4 ) and to the ECRYPT2 D.SPA.x report  ( 5 ) 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 XMLDSig

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

Table 1

SECTION 2 —   CAdES-BES/EPES

The signature is conform with the Cryptographic Message Syntax (CMS) Signature specifications  ( 6 ) .

The signature uses CAdES-BES (or -EPES) signature attributes as specified in the ETSI TS 101 733 CAdES specifications  ( 7 ) 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  ( 8 ) and to the ECRYPT2 D.SPA.x report  ( 9 ) 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.

Table 2

SECTION 3 —   PAdES-PART 3 (BES/EPES)

The signature MUST use a PAdES-BES (or -EPES) signature extension as specified in the ETSI TS 102 778 PAdES-Part3 specifications  ( 10 ) 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  ( 11 ) and to the ECRYPT2 D.SPA.x report  ( 12 ) 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.

( 1 )   IETF RFC 2119: ‘Key words for use in RFCs to indicate Requirements Levels’.

( 2 )   W3C, XML Signature Syntax and Processing, (Version 1.1), http://www.w3.org/TR/xmldsig-core1/

W3C, XML Signature Syntax and Processing, (Second Edition), http://www.w3.org/TR/xmldsig-core/

W3C, XML Signature Best Practices, http://www.w3.org/TR/xmldsig-bestpractices/

( 3 )   ETSI TS 101 903 v1.4.1: XML Advanced Electronic Signatures (XAdES).

( 4 )   ETSI TS 102 176: Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms; Part 2: ‘Secure channel protocols and algorithms for signature creation devices’.

( 5 )   Latest version is D.SPA.13 ECRYPT2 Yearly Report on Algorithms and Key sizes (2009 to 2010), dated 30 March 2010 (http://www.ecrypt.eu.org/documents/D.SPA.13.pdf).

( 6 )   IETF, RFC 5652, Cryptographic Message Syntax (CMS), http://tools.ietf.org/html/rfc5652.

IETF, RFC 5035, Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility, http://tools.ietf.org/html/rfc5035.

IETF, RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), http://tools.ietf.org/html/rfc3161.

( 7 )   ETSI TS 101 733 v.1.8.1: CMS Advanced Electronic Signatures (CAdES).

( 8 )   ETSI TS 102 176: Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms; Part 2: ‘Secure channel protocols and algorithms for signature creation devices’.

( 9 )   Latest version is D.SPA.13 ECRYPT2 Yearly Report on Algorithms and Key sizes (2009 to 2010), dated 30 March 2010 (http://www.ecrypt.eu.org/documents/D.SPA.13.pdf).

( 10 )   ETSI TS 102 778-3 v1.2.1: PDF Advanced Electronic Signatures (PAdES), PAdES Enhanced — PAdES-Basic Electronic Signatures and PAdES-Explicit Policy Electronic Signatures Profiles.

( 11 )   ETSI TS 102 176: Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms; Part 2: ‘Secure channel protocols and algorithms for signature creation devices’.

( 12 )   Latest version is D.SPA.13 ECRYPT2 Yearly Report on Algorithms and Key sizes (2009 to 2010), dated 30 March 2010 (http://www.ecrypt.eu.org/documents/D.SPA.13.pdf).