EU Member States Trusted Lists Scheme Type Community Rules: Common statement


Participation in a scheme

Each Member State must create a trusted list including information related to the qualified trust service providers that are under supervision, together with information related to the qualified trust services provided by them, in accordance with the relevant provisions laid down in Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC.
 
The present implementation of such trusted lists is also to be referred to in the list of links (pointers) towards each Member State's trusted list, compiled by the European Commission.

Policy/rules for the assessment of the listed services

Member States must supervise qualified trust service providers established in the territory of the designating Member State as laid down in Chapter III of Regulation (EU) No 910/2014 to ensure that those qualified trust service providers and the qualified trust services that they provide meet the requirements laid down in the Regulation. The trusted lists of Member States include, as a minimum, information specified in Articles 1 and 2 of Commission Implementing Decision (EU) 2015/1505. The trusted lists include both current and historical information about the status of listed trust services. Each Member State's trusted list must provide information on the national supervisory scheme and where applicable, national approval (e.g. accreditation) scheme(s) under which the trust service providers and the trust services that they provide are listed.

Interpretation of the Trusted List

The general user guidelines for applications, services or products relying on a trusted list published in accordance with Regulation (EU) No 910/2014 are as follows: The “qualified” status of a trust service is indicated by the combination of the “Service type identifier” (“Sti”) value in a service entry and the status according to the “Service current status” field value as from the date indicated in the “Current status starting date and time”. Historical information about such a qualified status is similarly provided when applicable. Regarding qualified trust service providers issuing qualified certificates for electronic signatures, for electronic seals and/or for website authentication: A “CA/QC” “Service type identifier” (“Sti”) entry (possibly further qualified as being a “RootCA-QC” through the use of the appropriate “Service information extension” (“Sie”) additionalServiceInformation Extension)
  • indicates that any end-entity certificate issued by or under the CA represented by the “Service digital identifier” (“Sdi”) CA's public key and CA's name (both CA data to be considered as trust anchor input), is a qualified certificate (QC) provided that it includes at least one of the following:
    • the id-etsi-qcs-QcCompliance ETSI defined statement (id-etsi-qcs 1),
    • the 0.4.0.1456.1.1 (QCP+) ETSI defined certificate policy OID,
    • the 0.4.0.1456.1.2 (QCP) ETSI defined certificate policy OID,
    • and provided this is ensured by the Member State Supervisory Body through a valid service status (i.e. “undersupervision”, “supervisionincessation”, “accredited” or “granted”) for that entry.
  • and IF “Sie” “Qualifications Extension” information is present, then in addition to the above default rule, those certificates that are identified through the use of “Sie” “Qualifications Extension” information, constructed as a sequence of filters further identifying a set of certificates, must be considered according to the associated qualifiers providing additional information regarding their qualified status, the “SSCD support” and/or “Legal person as subject” (e.g. certificates containing a specific OID in the Certificate Policy extension, and/or having a specific “Key usage” pattern, and/or filtered through the use of a specific value to appear in one specific certificate field or extension, etc.). These qualifiers are part of the following set of “Qualifiers” used to compensate for the lack of information in the corresponding certificate content, and that are used respectively:
  • to indicate the qualified certificate nature:
    • “QCStatement” meaning the identified certificate(s) is(are) qualified under Directive 1999/93/EC;
    • “QCForESig” meaning the identified certificate(s), when claimed or stated as qualified certificate(s), is (are) qualified certificate(s) for electronic signature under Regulation (EU) No 910/2014;
    • “QCForESeal” meaning the identified certificate(s), when claimed or stated as qualified certificate(s), is (are) qualified certificate(s) for electronic seal under Regulation (EU) No 910/2014;
    • “QCForWSA” meaning the identified certificate(s), when claimed or stated as qualified certificate(s), is (are) qualified certificate(s) for web site authentication under Regulation (EU) No 910/2014.
  • to indicate that the certificate is not to be considered as qualified:
    • “NotQualified” meaning the identified certificate(s) is(are) not to be considered as qualified; and/or
  • to indicate the nature of the SSCD support:
    • “QCWithSSCD” meaning the identified certificate(s), when claimed or stated as qualified certificate(s), have their private key residing in an SSCD, or
    • “QCNoSSCD” meaning the identified certificate(s), when claimed or stated as qualified certificate(s), have not their private key residing in an SSCD, or
    • “QCSSCDStatusAsInCert” meaning the identified certificate(s), when claimed or stated as qualified certificate(s), does(do) contain proper machine processable information about whether or not their private key residing in an SSCD;
  • to indicate the nature of the QSCD support:
    • “QCWithQSCD” meaning the identified certificate(s), when claimed or stated as qualified certificate(s), have their private key residing in a QSCD, or
    • “QCNoQSCD” meaning the identified certificate(s), when claimed or stated as qualified certificate(s), have not their private key residing in a QSCD, or
    • “QCQSCDStatusAsInCert” meaning the identified certificate(s), when claimed or stated as qualified certificate(s), does(do) contain proper machine processable information about whether or not their private key is residing in a QSCD;
    • “QCQSCDManagedOnBehalf” indicating that all certificates identified by the applicable list of criteria, when they are claimed or stated as qualified, have their private key is residing in a QSCD for which the generation and management of that private key is done by a qualified TSP on behalf of the entity whose identity is certified in the certificate; and/or
  • to indicate issuance to Legal Person:
    • “QCForLegalPerson” meaning the identified certificate(s), when claimed or stated as qualified certificate(s), are issued to a Legal Person under Directive 1999/93/EC.
     Note: The information provided in the trusted list is to be considered as accurate meaning that:
    • if none of the id-etsi-qcs 1 statement, QCP OID or QCP + OID information is included in an end- entity certificate, and
    • if no “Sie” “Qualifications Extension” information is present for the trust anchor CA/QC corresponding service entry to qualify the certificate with a “QCStatement” qualifier, or
    • an “Sie” “Qualifications Extension” information is present for the trust anchor CA/QC corresponding service entry to qualify the certificate with a “NotQualified” qualifier,
    then the certificate is not to be considered as qualified.
“Service digital identifiers” are to be used as Trust Anchors in the context of validating electronic signatures or seals for which signer's or seal creator's certificate is to be validated against TL information, hence only the public key and the associated subject name are needed as Trust Anchor information. When more than one certificate are representing the public key identifying the service, they are to be considered as Trust Anchor certificates conveying identical information with regard to the information strictly required as Trust Anchor information.

The general rule for interpretation of any other “Sti” type entry is that, for that “Sti” identified service type, the listed service named according to the “Service name” field value and uniquely identified by the “Service digital identity” field value has the current qualified or approval status according to the “Service current status” field value as from the date indicated in the “Current status starting date and time”.

Specific interpretation rules for any additional information with regard to a listed service (e.g. “Service information extensions” field) may be found, when applicable, in the Member State specific URI as part of the present “Scheme type/community/rules” field.

Please refer to the applicable secondary legislation pursuant to Regulation (EU) No 910/2014 for further details on the fields, description and meaning for the Member States' trusted lists.