ANNEX

TECHNICAL SPECIFICATIONS FOR A COMMON TEMPLATE FOR THE ‘楾RUSTED LIST OF SUPERVISED/ACCREDITED CERTIFICATION SERVICE PROVIDERS‘�/span>

GENERAL REQUIREMENTS

1. Introduction

The purpose of the Common Template for Member States‘�‘楾rusted List of supervised/accredited Certification Service Providers‘�is to establish a common way in which each Member State provides information about the supervision/accreditation status of the certification services from Certification Service Providers (1) (CSPs) who are supervised/accredited by them for compliance with the relevant provisions of Directive 1999/93/EC. This includes the provision of historical information about the supervision/accreditation status of the supervised/accredited certification services.

This information is primarily aimed at supporting the validation of Qualified Electronic Signatures (QES) and Advanced Electronic Signatures (AdES) (2) supported by a Qualified Certificate (3) (4).

The mandatory information in the Trusted List must include, as a minimum, information on supervised/accredited CSPs issuing Qualified Certificates (QCs) (5) in accordance with the provisions laid down in Directive 1999/93/EC (Article 3(2) and (3), and Article 7(1)(a)), including, when this is not part of the QCs, information on the QCs supporting an electronic signature and whether or not the signature is created by a Secure Signature Creation Device (SSCD) (6).

Additional information on other CSPs not issuing QCs but providing services related to electronic signatures (e.g. CSP providing Time Stamping Services and issuing Time Stamp Tokens, CSP issuing non-Qualified certificates, etc.) may be included in the Trusted List at a national level on a voluntary basis provided they are either accredited/supervised in a similar way as the CSPs issuing QC or approved under a different national approval scheme. The national approval schemes may in some Member States differ from the supervision or voluntary accreditation schemes applicable for CSPs issuing QCs with regard to applicable requirements and/or the responsible organisation. The terms ‘榓ccredited‘�and/or ‘supervised‘�in the present specifications also cover the national approval schemes but additional information on the nature of any national schemes will be provided by Member States in their Trusted List, including clarification on the possible differences with the accreditation/supervision schemes applied to CSPs issuing QCs.

The Common Template relies on ETSI TS 119 612 v1.1.1 (7) (hereafter referred to as ETSI TS 119 612) that addresses the establishment, publication, location, access, authentication and integrity of such lists.

2. Structure of the Common Template for the Trusted List

The Common Template for a Member State Trusted List is structured according to ETSI TS 119 612 into the following categories of information:

In the context of a CSP issuing QCs, the structure of the Trusted List and in particular the service information component (as per point 4 above) allows for complementary information in service information extensions to compensate for those situations where insufficient (machine processable) information is available within the qualified certificate about its ‘榪ualified‘�status, its potential support by an SSCD and especially in order to cope with the additional fact that most of the (commercial) CSPs are using one single issuing Certification Authority (CA) to issue several types of end-entity certificates, both qualified and non-qualified.

In the context of certificate generation (CA) services, the number of service entries in the list for a CSP may be reduced where one or several upper CA services exist within the CSP‘檚 PKI (e.g. in the context of a hierarchy of CAs from a Root CA down to several issuing CAs) by listing such upper CA services and not the CA services issuing end-entity certificates (e.g. listing the CSP Root CA only). However in those cases, the status information applies to the whole hierarchy of CA services below the listed service and the principle of ensuring the unambiguous link between a CSPQC certification service and the set of certificates intended to be identified as QCs has to be maintained and ensured.

2.1. Description of information in each category

1. Trusted List Tag

2. Information on the Trusted List and its issuing scheme

The following information is part of this category:

3. Unambiguous identification information about every CSP supervised/accredited under the scheme

This set of information includes at least the following:

4. For each listed CSP, a sequence of fields holding unambiguous identification of a certification service provided by the CSP and supervised/accredited in the context of Directive 1999/93/EC

This set of information includes at least the following for each certification service from a listed CSP:

5. For each listed certification service, the historical information about his status

6. A signature computed for authentication purposes over all fields of the TL except the signature value itself

3. Guidelines for editing entries in the Trusted List

3.1. Status information on supervised/accredited certification services and their providers in a single list

The Trusted List of a Member State means the ‘楽upervision/Accreditation Status List of certification services from Certification Service Providers who are supervised/accredited by the referenced Member State for compliance with the relevant provisions of Directive 1999/93/EC‘�

Such a Trusted List is the single instrument to be used by the relevant Member State to provide information on the supervision/accreditation status of certification services and their providers:

When considering the definitions and provisions laid down in Directive 1999/93/EC, in particular with regard to the relevant CSPs and their supervision/voluntary accreditation systems, two sets of CSPs can be distinguished, namely the CSPs issuing QCs to the public (CSPQC), and the CSPs not issuing QCs to the public but providing ‘other (ancillary) services related to electronic signatures‘�

One single Trusted List must be established and maintained per Member State to indicate the supervision and/or accreditation status of those certification services from those CSPs that are supervised/accredited by the Member State. The Trusted List shall include at least those CSPs issuing QCs. The Trusted List may also indicate the status of other certification services supervised or accredited under a nationally defined approval scheme.

3.2. A single set of Supervision/Accreditation status values

In the Trusted List, the fact that a service is currently either ‘supervised‘�or ‘榓ccredited‘�is given by the value of its current status. In addition to that, a supervision or accreditation status can be positive (‘榰nder supervision‘� ‘榓ccredited‘� ‘supervision in cessation‘�, ceased (‘supervision ceased‘� ‘榓ccreditation ceased‘�, or even revoked (‘supervision revoked‘� ‘榓ccreditation revoked‘� and be set to the corresponding value. Throughout its lifetime, the same certification service may move from a supervision status to an accreditation status and vice versa (8).

Figure 1 below describes the expected flow, for one single certification service, between possible supervision/accreditation statuses:

Figure 1

Expected supervision/accreditation status flow for a single CSP service

When established in a Member State, a certification service issuing QCs must be supervised (by the Member State in which it is established) and may be voluntarily accredited. The status value of such a service when listed in a Trusted List must have one of the above depicted status values as ‘榗urrent status value‘�in accordance with its actual status and must change, when applicable, according to the status flow depicted above. However, ‘楢ccreditation ceased‘�and ‘楢ccreditation revoked‘�must both be ‘transit status‘�values when the corresponding CSPQC service is listed in the Trusted List of the Member State in which it is established, as such a service must be supervised by default (even when not or no longer accredited); when the corresponding service is listed (accredited) in another Member State than the one it is established in, these values may be final values.

Member States establishing or having established a nationally defined ‘榬ecognised approval scheme(s)‘�implemented on a national basis for the supervision of compliance of services from CSPs not issuing QCs with the provisions laid down in Directive 1999/93/EC and with possible national provisions with regard to the provision of certification services (in the sense of Article 2(11) of Directive 1999/93/EC) must categorise such approval scheme(s) under the following two categories:

Accordingly, a certification service not issuing QCs may be supervised or voluntarily accredited. The status value of such a service when listed in a Trusted List must have one of the above depicted status values as its ‘榗urrent status value‘�(see Figure 1) in accordance with its actual status and must evolve, when applicable, according to the status flow depicted above.

The Trusted List must contain information about the underlying supervision/accreditation scheme(s), in particular:

The last two sets of information are of critical importance for relying parties to assess the quality and security level of such supervision/accreditation systems applied at national level to CSPs not issuing QCs. When supervision/accreditation status information is provided in the Trusted List with regard to services from CSPs not issuing QCs, the aforementioned sets of information shall be provided at Trusted List level through the use of ‘楽cheme information URI‘�(clause 5.3.7 ‘�information being provided by Member States), ‘楽cheme type/community/rules‘�(clause 5.3.9 ‘�through the use of a text common to all Member States, and optional specific information provided by a Member State) and ‘楾SL policy/legal notice‘�(clause 5.3.11 ‘�a text common to all Member States referring to Directive 1999/93/EC, together with the ability for each Member State to add Member State specific text/references).

Additional ‘榪ualification‘�information defined at the level of national supervision/accreditation systems for CSPs not issuing QCs may be provided at the service level when applicable and required (e.g. to distinguish between several quality/security levels) through the use of ‘榓dditionalServiceInformation Extension‘�(clause 5.5.9.4) as part of ‘楽ervice information extensions‘�(clause 5.5.9). Further information on the corresponding technical specifications is provided in the detailed specifications in Chapter I.

Despite the fact that separate bodies of a Member State may be in charge of the supervision and accreditation of certification services in that Member State, it is expected that only one entry must be used for one single certification service and that its supervision/accreditation status must be updated accordingly.

3.3. Trusted List entries aiming at facilitating the validation of QES and AdESQC

The most critical part of the creation of the Trusted List is the establishment of the mandatory part of the Trusted List, namely the ‘楲ist of services‘�per CSP issuing QCs, in order to reflect correctly the exact situation of each QC-issuing certification service and to ensure that the information provided in each entry is sufficient to facilitate the validation of QES and AdESQC (when combined with the content of the end-entity QC issued by the CSP under the certification service listed in this entry).

The required information might include information other than the ‘楽ervice digital identity‘�of a single (Root) CA, in particular information identifying the QC status of certificates issued by such a CA service, and whether or not the supported signatures are created by an SSCD. The Body in a Member State that is designated to establish, edit and maintain the Trusted List must therefore take into account the current profile and certificate content in each issued QC, per CSPQC service covered by the Trusted List.

Ideally each issued QC should include the ETSI defined QcCompliance (9) statement when it is claimed that it is a QC and should include the ETSI defined QcSSCD statement when it is claimed that it is supported by an SSCD to generate eSignatures, and/or that each issued QC includes one of the QCP/QCP+ certificate policy Object Identifiers (OIDs) defined in ETSI EN 319 411-2 (10). The use by CSPs issuing QCs of different standards as references, the wide degree of interpretation of those standards as well as the lack of awareness of the existence and precedence of some normative technical specifications or standards has resulted in differences in the actual content of currently issued QCs (e.g. the use or not of those QcStatements defined by ETSI) and consequently are preventing the receiving parties from simply relying on the signatory‘檚 certificate (and associated chain/path) to assess, at least in a machine readable way, whether or not the certificate supporting an eSignature is claimed to be a QC and whether or not it is associated with an SSCD through which the eSignature has been created.

Completing the ‘楽ervice type identifier‘�(‘楽ti‘�, ‘楽ervice name‘�(‘楽n‘�, and ‘楽ervice digital identity‘�(‘楽di‘� fields of the service entry in the Trusted List with information provided in the ‘楽ervice information extensions‘�(‘楽ie‘� field allows for the full determination of a specific type of qualified certificate issued by a listed CSP certification service issuing QCs and provides information about whether or not it is supported by an SSCD (when such information is missing in the issued QC). A specific ‘楽ervice current status‘�(‘楽cs‘� information is associated with this entry. This is depicted in Figure 2 below.

Listing a service by just providing the ‘楽di‘�of a (Root) CA would mean that it is ensured (by the CSP issuing QCs but also by the Supervisory/Accreditation Body in charge of the supervision/accreditation of this CSP) that any end-entity certificate issued under this (Root) CA (hierarchy) contains enough ETSI defined and machine-processable information to assess whether or not it is a QC, and whether or not it is supported by an SSCD. In the event, for example, that the latter assertion is not true (e.g. there is no ETSI standardised machine-processable indication in the QC about whether it is supported by an SSCD), then by listing only the ‘楽di‘�of that (Root) CA, it can only be assumed that QCs issued under this (Root) CA hierarchy are not supported by any SSCD. In order to indicate that those QCs must be considered as supported by an SSCD, the ‘楽ie‘�field should be used (this also indicates that this information is guaranteed by the CSP issuing QCs and supervised/accredited by the Supervisory or Accreditation Body respectively).

Figure 2

Service entry for a listed CSP service issuing QCs in the Trusted List

General principles ‘�Editing rules ‘�CSPQC entries (listed services)

The present Trusted List common template technical specifications allow for the use of a combination of five main parts of information in the service entry:

3.4. Editing and usage guidelines for CSPQC services entries

The general editing guidelines are:

As a general default principle, for a listed CSP in the Trusted List there must be one service entry per single public key for a CA/QC type certification service, i.e. per Certification Authority (directly) issuing QCs. In some exceptional circumstances and carefully managed conditions, the Member State‘檚 Supervisory Body/Accreditation Body may decide to use, as the ‘楽di‘�of a single entry in the list of services from this listed CSP, the public key of a Root or Upper level CA within the CSP‘檚 PKI (e.g. in the context of a CSP‘檚 hierarchy of CAs from a Root CA down to several issuing CAs) instead of listing all sub-ordinate issuing CA services (i.e. listing a Certification Authority not directly issuing end-entity QCs but certifying a hierarchy of CAs down to CAs issuing QCs to end-entities). The consequences (advantages and disadvantages) of using such Root CA or Upper CA public key as ‘楽di‘�value in a Trusted List service entry must be carefully considered when implemented by Member States. Moreover, when using this authorised exception to the default principle, the Member State must provide the necessary documentation to facilitate certification path building and verification. As an example, in the context of a CSPQC using one Root CA under which several CAs are issuing QCs and non-QCs, but for which the QCs do contain only the QcCompliance statement and no indication of whether it is supported by an SSCD, listing the Root CA ‘楽di‘�only would mean, under the rules explained above, that none of the QC issued under this Root CA is supported by an SSCD. If there are QCs that are actually supported by an SSCD but with no machine processable statement indicating such support included in the certificates, it would be strongly recommended to make use of the QcSSCD statement in the QCs issued in the future. In the meantime (until the last QC not containing this information has expired), the Trusted List should make use of the ‘楽ie‘�field and associated ‘楺ualifications Extension‘� e.g. providing filtering information to identify set(s) of certificates through use of specific CSPQC defined OID(s) potentially used by the CSPQC to distinguish between different types of QCs (some supported by an SSCD and some not) and associating explicit ‘楽SCD support information‘�to those identified (filtered) set(s) of certificates through the use of ‘楺ualifiers‘�

The general usage guidelines for electronic signature applications, services or products relying on a Trusted List compliant with the present Technical Specifications are as follows:

A ‘楥A/QC‘欌�Sti‘�entry (similarly a CA/QC entry further qualified as being a ‘楻ootCA/QC‘�through the use of ‘楽ie‘�additionalServiceInformation Extension)

3.5. Services supporting ‘楥A/QC‘�services but not part of the ‘楥A/QC‘欌�Sdi‘�/span>

Certificate validity status services related to QCs and for which the certificate validity status information (e.g. CRLs and OCSP responses) is signed by an entity whose private key is not certified under a certification path leading to a listed CA issuing QCs (‘楥A/QC‘� shall be included in Trusted List by listing those certificate validity status services as such in the TL (i.e. with a service type ‘極CSP/QC‘�or ‘楥RL/QC‘�respectively) since these services can be considered as part of the supervised/accredited ‘榪ualified‘�services related to the provision of QC certification services. Of course, OCSP responders or CRL Issuers whose certificates are signed by CAs under the hierarchy of a listed CA/QC service are to be considered as ‘榲alid‘�and in accordance with the status value of the listed CA/QC service.

A similar provision can apply to certification services issuing non-qualified certificates (of a ‘楥A/PKC‘�service type).

The Trusted List shall include certificate validity status services when related location information for such services is not present in the end-entity certificates to which the certificate validity status services apply.

4. Definitions and abbreviations

For the purposes of the present document, the following definitions and acronyms apply:

Within the following chapters, the key words ‘楳UST‘� ‘楳UST NOT‘� ‘楻EQUIRED‘� ‘楽HALL‘� ‘楽HALL NOT‘� ‘楽HOULD‘� ‘楽HOULD NOT‘� ‘楻ECOMMENDED‘� ‘楳AY‘� and ‘極PTIONAL‘�are to be interpreted as described in RFC 2119 (12).

CHAPTER I

DETAILED SPECIFICATIONS FOR THE COMMON TEMPLATE FOR THE ‘楾RUSTED LIST OF SUPERVISED/ACCREDITED CERTIFICATION SERVICE PROVIDERS‘�/span>

The present specifications are relying on the specifications and requirements stated in ETSI TS 119 612 v1.1.1 (here after referred to as ETSI TS 119 612).

When no specific requirement is stated in the present specifications, requirements from ETSI TS 119 612 clauses 5 and 6 SHALL apply entirely. When specific requirements are stated in the present specifications, they SHALL prevail over the corresponding requirements from ETSI TS 119 612. In case of discrepancies between the present specifications and specifications from ETSI TS 119 612, the present specifications SHALL be the normative ones.

Scheme operator name (clause 5.3.4)

This field SHALL be present and SHALL comply with the specifications from TS 119 612 clause 5.3.4.

A country MAY have separate Supervisory and Accreditation Bodies and even additional bodies for whatever operational related activities. It is up to each Member State to designate the Scheme operator of the Member State Trusted List. It is expected that the Supervisory Body, the Accreditation Body and the Scheme Operator (when they appear to be separate bodies) will each of them have their own responsibility and liability.

Any situation in which several bodies are responsible for supervision, accreditation or operational aspects SHALL be consistently reflected and identified as such in the Scheme information as part of the Trusted List, including in the scheme-specific information indicated by the ‘楽cheme information URI‘�(clause 5.3.7).

Scheme name (clause 5.3.6)

This field SHALL be present and SHALL comply with the specifications from TS 119 612 clause 5.3.6 where the following name SHALL be used for the scheme:

‘楨N_name_value‘� ‘楽upervision/Accreditation Status List of certification services from Certification Service Providers, which are supervised/accredited by the referenced Scheme Operator‘檚 Member State for compliance with the relevant provisions laid down in Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures.‘�/p>

Scheme information URI (clause 5.3.7)

This field SHALL be present and SHALL comply with the specifications from TS 119 612 clause 5.3.7 where the ‘榓ppropriate information about the scheme‘�SHALL include as a minimum:

Additional Member State specific information about the scheme MAY be provided on a voluntary basis such as:

Scheme type/community/rules (clause 5.3.9)

This field SHALL be present and SHALL comply with the specifications from TS 119 612 clause 5.3.9 and SHALL include at least two URIs: