Interoperable Qualified Certificate Profiles

Transcription

1 Study on Cross-Border Interoperability esignatures of (CROBIES) Interoperable Qualified Certificate Profiles A report to the European Commission from SEALED, time.lex and Siemens Disclaimer The views expressed in this document are purely those of the writer and may not, in any circumstances, be interpreted as stating an official position of the European Commission. The European Commission does not guarantee the accuracy of the information included in this study, nor does it accept any responsibility for any use thereof. Reference herein to any specific products, specifications, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favouring by the European Commission. All care has been taken by the author to ensure that s/he has obtained, where necessary, permission to use any parts of manuscripts including illustrations, maps, and graphs, on which intellectual property rights already exist from the titular holder(s) of such rights or from her/his or their legal representative. FINAL REPORT Editing company: Date: 31/07/2010 Version: 1.0 SEALED sprl, VAT : BE RPM: Tournai 12, rue de la Paix, B-7500 Tournai olivier.delos@sealed.be, sylvie.lacroix@sealed.be

2 Document information Title: Project reference: Document archival code: CROBIES Work Package 3 Interoperable Qualified Certificate Profiles CROBIES INFSO-CROBIES-FINALREPORT-WP3-SEALED _v1 Version control Version Date Description / Status Responsible V0.1 29/05/2010 Draft Final Report ODO, SLR, HGR V1.0 31/07/2010 Final Report ODO References Reference Title [1] The European Directive 1999/93/EC of the European Parliament and the Council of the 13 December 1999 on a Community framework for electronic signatures. O.J. L 13, , p.12. [2] Study on the standardisation aspects of esignature. A study for the European Commission (DG Information Society and Media) by SEALED, DLA Piper and Across communications, 22/11/2007. [3] Commission Decision 2003/511/EC on the publication of reference numbers of generally recognised standards for electronic signature products in accordance with Directive 1999/93/EC of the EP and the Council. OJ L , p.45. [4] Communication from the Commission to the Council, the European Parliament, the European Economic and Social Committee and the Committee of the Regions on an Action Plan on e- signatures and e-identification to facilitate the provision of cross-border public services in the Single Market, COM(2008)798 of [5] Directive 2006/123/EC of the European Parliament and Council of on services in the internal market, OJ L376 of [6] Commission Decision 2010/425/EU of 28 July 2010 amending Decision 2009/767/EC as regards the establishment, maintenance and publication of trusted lists of certification service providers supervised/accredited by Member States (OJ L 199 of ). [7] Mandate M460, Standardisation Mandate to the European Standardisation Organisations CEN, CENELEC and ETSI in the field of Information and Communication Technologies applied to electronic signatures, 7 January Definitions and Acronyms Please refer to the Head Document for definitions and acronyms used throughout the present report. Date : 31/07/2010 Page 2 /23

3 Table of Contents 1 INTRODUCTION CROBIES Executive Summary Target audience PROBLEM STATEMENT BACKGROUND INFORMATION ON CURRENT QUALIFIED CERTIFICATE PROFILES Advanced electronic signatures Qualified Certificates as defined in the esignature Directive 1999/93/EC Qualified Certificate Profiles as defined in the standardisation framework Qualified Electronic Signatures PROPOSAL FOR AN INTEROPERABLE QUALIFIED CERTIFICATE PROFILE Introduction Proposed Qualified Certificate profile RECOMMENDATIONS Date : 31/07/2010 Page 3 /23

4 Interoperable Qualified Certificate Profiles 1 Introduction 1.1 CROBIES The CROBIES study looks at esignature interoperability in general, but specifically in the context of cross-border use. While considering a consistent global and long term approach in proposed improvements at the legal, technical and trust levels, CROBIES is also focusing on quick wins that could substantially improve the interoperability of electronic signatures. The CROBIES Study concentrates in particular on the following aspects through related work packages and their associated reports: WP1. The proposal for a common model for supervision and accreditation systems of certification service providers (CSPs) issuing QCs (and other services ancillary to electronic signatures); WP2. The establishment of a Trusted List of supervised/accredited Certification Service Providers (in particular issuing QCs); WP3. Interoperable profiles of qualified certificates issued by supervised/accredited CSPs in Member States; WP4. A proposed framework for interoperable Secure Signature Creation Devices (SSCDs); and WP5. A proposed model for providing guidelines and guidance for cross-border and interoperable implementation of electronic signatures. The global overview of the CROBIES study and of its approach is to be found in the Head Document of the study. The study is part of the Action Plan on e-signatures and e- identification to facilitate the provision of cross-border public services in the Single Market adopted by the European Commission on which aims at facilitating the provision of cross-border public services in an electronic environment. Readers are suggested to read this Head Document prior to reading the present report. 1.2 Executive Summary CROBIES WP3 ( Interoperable Qualified Certificate Profile ) aims at providing recommendations on how to improve the provision, in both machine processable and human readable ways, of information on the qualified status of a certificate and on the indication that the electronic signatures supported by a Qualified Certificate (QC) are created by a secure signature creation device (SSCD) as defined per Directive 1999/93/EC [1]. Improvement in the provision and registration policy requirements on certificate s subject identity and related information is out of the scope of the present report but is addressed in other studies and initiatives on this particular topic (e.g. STORK, CWA 16036) 2. 1 COM(2008) 798, 2 However the present report relays some recommendation on the use of unique identifiers for legal and natural persons. Date : 31/07/2010 Page 4 /23

5 Work done in the context of Work Package 3 (WP3) is closely connected to the work done in the context of Work Package 2 on Trusted Lists. Digital certificates being the primary source of information to validate an electronic signature (together with the electronic signature itself), the present WP3 report analyses and provides an overview of what should be the common Interoperable Qualified Certificate profile, including a common way of indicating the information necessary for interoperable validation of QES as well as AdES QC. It aims at contributing to the improvement of the soundness and stability of the Trust framework with regards to the provision of Qualified Certificates (QC) and the validation of Qualified Electronic Signatures (QES) and Advanced Electronic Signatures supported by Qualified Certificates (AdES QC ). This analysis results in a proposal on implementation steps for the setting up of such an interoperable Qualified Certificate Profile to provide an interoperable source of trusted information on certificates used in support of QES and AdES QC in the context of the completion/validation of cross border electronic signatures. 1.1 Target audience The present report is mainly addressed to Member State policy makers and Supervisory Bodies in charge of the appropriate supervision of certification service providers established on their territory and issuing qualified certificates, as well as to those similar Supervisory and/or Accreditation Bodies in charge of the approval, supervision, and/or accreditation of any type of CSP providing services ancillary to electronic signatures, e.g. issuing certificates or providing other services related to electronic signatures for which a national approval scheme is in place. The present report is also addressed to the ESO s to support their work in the context of the esignature Mandate M460 [7], and to any interested electronic signature stakeholder or third party. 2 Problem statement Besides the actions outlined in Work Packages 2 and 5 3, the practical cross-border use of Qualified Electronic Signatures (QES) and Advanced Electronic Signatures supported by a Qualified Certificate (AdES QC ) could be further facilitated at the receiving side through common minimum information to be contained in the Qualified Certificate (QC). The first piece of trustworthy information to start with for a receiving party validating an electronic signature, is, besides the signature itself, the signatory s certificate (chain) supporting it. The data contained in the certificate should allow the validation of the fact that the certificate is indeed a QC and whether it is supported by a Secure Signature Creation Device (SSCD) in case of a QES. Then as a second source of trust, the Trusted List [6] of the Member State in which the certification authority (CA) issuing the signatory s certificate is supervised/accredited should be used by the receiving party to receive the confirmation of the supervised/accredited status of this certification service, if it is unknown to him. 3 WP2 is focusing on the proposal and implementation of a common template for Member States' national Trusted Lists of supervision/accreditation status of certification services (including the issuance of QCs) from Certification Services Providers which are supervised/accredited by Member States for compliance with the provisions laid down in Directive 1999/93/EC. WP5 is addressing practical implementation issues for cross-border use of electronic signatures. Date : 31/07/2010 Page 5 /23

6 Unfortunately, at this stage relying on the signatory s certificate (chain) may not be enough to get the needed data, or it may be too complicated to do so (not machine processable, even if manually feasible), due to a number of differences in current requirements and practices linked to the issuance and use of QC in Member States. This includes differences in the actual content of QC issued by CSPs issuing QCs, varying legal requirements for QC profiles, the use of different standards and the wide degree of interpretation of those standards as well as the unawareness of the existence and precedence of some normative technical specifications or standards 4. Today, when issued QCs do not contain the required machine processable information allowing relying parties to assess whether the certificate is issued as a claimed QC or whether it is supported by an SSCD or not, national Trusted Lists must compensate this lack of information through the use of specific extensions 5. In order to simplify the use of the Trusted Lists (i.e. limiting their use to the confirmation of the supervision/accreditation status of the CSP service having issued QCs) and to make sure the rest of the data needed for the validation of a QES or AdES supported by a QC is available in the QC supporting the signature, a set of common data in the QC profile for cross-border purposes should be used. The following sections describe this set of common data for the QC (i.e., the Interoperable QC Profile ). It could be implemented through a gradual migration process without the need to change the existing qualified certificates (which could still be used until the end of their validity period). 3 Background information on current Qualified Certificate Profiles In order to validate that a received signature is indeed a QES or AdES QC, the receiving party has to check if it is created in accordance with the definition and requirements of the esignature Directive (1999/93/EC), namely that it is: - an Advanced Electronic Signature (AdES), - supported by a Qualified Certificate (QC) meeting the requirements of Annex I of Directive 1999/93/EC and provided by a Certification Service Provider (CSP) who fulfils the requirements laid down in Annex II of this Directive. Furthermore, in order to validate that the received signature is a QES, the receiving party additionally has to check that it is: - supported by a Secure Signature Creation Device (SSCD) meeting the requirements of Annex III of Directive 1999/93/EC. 3.1 Advanced electronic signatures Verifying that an electronic signature is an AdES in the context of PKI-based digital signatures consists in cryptographically verifying the basic public key cryptographically 4 See section 3.3 of the present document. 5 See [6] for further details. Date : 31/07/2010 Page 6 /23

7 generated digital signature according to the algorithm used to generate it (e.g., RSA-with- SHA1, RSA-with-SHA256, ECDSA-with-SHA256 for the most used ones). Depending on the specific use case, recommended or required additional steps in the verification process consist in: - Obtaining, and associating to the received electronic signature, a trusted time (e.g. time-stamp) as closely 6 related to the generation or reception time of the received electronic signature, - Validating the supporting certificate and the whole certificate chain (i.e., the certificate(s) from the CA hierarchy having issued the signatory certificate) by collecting information about the validity status of those certificates and learning about the certification policy information associated to the signatory certificate, - Obtaining some trusted time-stamps on this validation material, providing trusted upper boundary for the first verification time, - Obtaining additional special nested time-stamps (archive time-stamps) computed on both the signature plus validation data (e.g., directly incorporated in its structure) in order to counter the apparition of weaknesses on algorithms or cryptographic material in the future. It should be noted that the need for implementing the above latter two steps will depend on the foreseen and expected signature life-time (e.g. ephemeral, short term, long term) in function of the actual use case that will require (or not) the initial verification to consolidate the signature by capturing information that will support its subsequent verification. ETSI CAdES 7, XAdES 8 and PAdES 9 specifications provide a standardised structure for creating and validating advanced (qualified) electronic signatures according to the above principles Qualified Certificates as defined in the esignature Directive 1999/93/EC As defined by Directive 1999/93/EC [1], a Qualified certificate (QC) means a certificate (i.e. an electronic attestation which links signature-verification data to a person and confirms the 6 The trusted time indication needs to be as close as possible to the time when the signature was created in order to reduce the risk of repudiating signature creation. 7 ETSI TS : ETSI Technical Specification Electronic Signatures and Infrastructures (ESI): CMS Advanced Electronic Signatures (CAdES). 8 ETSI TS : ETSI Technical Specification Electronic Signatures and Infrastructures (ESI): XML Advanced Electronic Signatures (XAdES). 9 A formal liaison has been established between ETSI TC/ESI and ISO formally to cross-refer and integrate ISO with ETSI signature format standards TS , TS , TS and TS The first goal of the liaison is to establish the PDF Advanced Electronic Signature (so-called PAdES) as an ETSI TS and subsequently to introduce CAdES and XAdES signature formats into the ISO standard. The second goal is to use the appropriate parts of ETSI TS series as technical specifications that precede the approval of a new version of the ISO standard because a TS can be maintained more swiftly. For information, ETSI TS series is broken down as follows: - Part 1: PAdES Overview - a framework document for PAdES - Part 2: PAdES Basic - Profile based on ISO Part 3: PAdES Enhanced - PAdES-BES and PAdES-EPES Profiles - Part 4: PAdES Long Term - PAdES-LTV Profile - Part 5: PAdES for XML Content - Profiles for XAdES signatures of XML content in PDF files 10 Additional information on procedures for electronic signature verification could be found in ETSI TS ( Procedures for electronic signature verification ) and ETSI TS ( Long-term signature certificate verification and certification path building and verification ) once those standards will be finalised. Date : 31/07/2010 Page 7 /23

8 identity of that person) which meets the requirements laid down in Annex I and is provided by a certification-service-provider who fulfils the requirements laid down in Annex II. According to Annex I of [1], Qualified Certificates must contain: a) an indication that the certificate is issued as a qualified certificate; b) the identification of the certification-service-provider and the State in which it is established; c) the name of the signatory or a pseudonym, which shall be identified as such; d) provision for a specific attribute of the signatory to be included if relevant, depending on the purpose for which the certificate is intended; e) signature-verification data which correspond to signature-creation data under the control of the signatory; f) an indication of the beginning and end of the period of validity of the certificate; g) the identity code of the certificate; h) the advanced electronic signature of the certification-service-provider issuing it; i) limitations on the scope of use of the certificate, if applicable; and j) limits on the value of transactions for which the certificate can be used, if applicable. The standardization framework established in the context of Directive 1999/93/EC through the European Electronic Signature Standardisation Initiative (EESSI) resulted in standards and technical specifications related to the issuing and profile of Qualified Certificates. 3.3 Qualified Certificate Profiles as defined in the standardisation framework As identified by the 2007 study on the standardisation aspects of esignatures [2], while there exists a specific set of standards and technical specifications related to Qualified Certificates, the lack of clear guidance in the use and precedence of those documents has resulted in some confusion in the market leading to interoperability issues when validating (crossborder) QES or AdES supported by QC. In particular the content of the currently implemented Qualified Certificates in the EU market is such that relying on the signatory s certificate (chain) may not be enough to get the needed data to validate the fact that a certificate supporting a received esignature is indeed a (claimed) QC issued by a (claimed) CSP issuing QCs and whether or not the esignature has been created by an SSCD, or it may be too complicated (not machine processable, even if manually feasible). This is due to a number of differences in current requirements and practices linked to the issuance and use of QC in Member States including: - Differences in the actual content of QC issued by CSPs issuing QCs, - Varying legal requirements for QC profiles, - The use of different standards and the wide degree of interpretation of those standards as well as Date : 31/07/2010 Page 8 /23

9 - The unawareness of the existence and precedence of some normative technical specifications or standards. When considering the existing European and International standards on Qualified Certificate Profiles, the following precedence of specifications should apply (considering the hierarchy of requirements starting with those from the first document on top of Figure 1 below, then the second, third, etc.): - ETSI TS defining an X.509v3 Certificate Profile for Certificates issued to Natural Persons and covering as part of its specifications some specifications applicable to qualified certificates by adding some requirements on top of the next two technical specifications, being; - ETSI TS defining a qualified certificate profile by simply adding some specific requirements on top of the next technical specifications 12, being; - RFC defining a qualified certificate profile but at a more general scope than the specific esignature Directive context, this document adding some requirements on top of the next technical specifications, being; - RFC defining an X.509 certificate and certificate revocation list profile; this document adding some requirements on top of the next technical specifications, being; - ITU-T Recommendation X.509 ISO/IEC defining the X.509 Public Key and attribute certificate framework. ETSI TS X.509 v3 Certificate Profile for Certificates issued to Natural Persons Adds additional requirements to & is based on ETSI TS Qualified Certificate Profile Adds additional requirements to & is based on RFC 3739 (obsoletes RFC 3039) Qualified Certificate Profile Adds additional requirements to & is based on RFC 5280 (obsoletes RFC 3280, 4325, 4630) Certificate & CRL Profile Adds additional requirements to & is based on ITU-T Recommendation X ISO/IEC Figure 1 The above listed standards, their precedence, the summary of their requirements and their adoption by Member States as compliance criteria with regards to a QC profile is described in Annex 1 of the present document. The use by CSPs issuing QCs of different standards as reference, the wide degree of interpretation of those standards as well as the unawareness of the existence and precedence of some normative technical specifications or standards have resulted in differences in the actual content of currently issued QC and consequently preventing relying parties to rely on the sole signing certificate (chain) to assess whether or 11 ETSI TS : Qualified Certificate profile. Latest version in force: v1.3.3 ( ). 12 This refers namely to the machine processable statements, so-called qcstatements, allowing indication in the certificate content of claimed compliance of the certificate with provisions laid down in Annexes I and II of Directive 1999/93/EC and whether the signature has been created by an SSCD in compliance with the provisions of its Annex III. Note that ETSI defined certificate policy Object Identifier (OID) QCP and QCP+ may not only be used in issued QC by CSP for claiming compliance with Policy requirements for certification authorities issuing qualified certificates defined in so-titled ETSI TS but for the same purposes of indication claimed compliance with qualified certificate requirements and support by SSCD. 13 RFC 3739 (obsoletes RFC 3039): IETF Internet X.509 Public Key Infrastructure: Qualified Certificate Profile. 14 RFC 5280 (obsoletes RFC 3280): IETF Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile. Date : 31/07/2010 Page 9 /23

10 not the certificate supporting an esignature is claimed to be a QC and whether or not it is associated to an SSCD through which the esignature has been created. 3.4 Qualified Electronic Signatures When verifying a QES (i.e. an AdES is supported by a QC and an SSCD), the first source of trustworthy information about the fact that the received electronic signature is indeed supported by a QC and has been generated by a SSCD is the signatory certificate supporting the received signature. Certification Service Providers issuing QCs (CSP QC ) have several means to incorporate such claims into certificates they issue either directly or indirectly (by reference), namely: - By using ETSI TS extension for Qualified Certificates Statements qcstatements extension (defined in RFC 3739) allowing CSPs issuing QCs to indicate, in the issued certificate, one or more of the following statements: o QcCompliance statement claiming that the certificate is issued as a Qualified Certificate according to Annex I and II of Directive 1999/93/EC as implemented in the law of the country in which the CA is established; o statement regarding limits on the value of transactions for which the certificate can be used, if applicable; o statement indicating the duration of the retention period during which registration information is archived; o QcSSCD statement claiming that the private key associated with the public key in the certificate resides within an SSCD according to Annex III of Directive 1999/93/EC. - By identifying a certificate policy in the Certificate Policies extensions, as defined in RFC 5280, clearly expressing that the issuer intentionally has issued the certificate as a Qualified Certificate and that the issuer claims compliance with Annex I and Annex II of Directive 1999/93/EC. Such identified (or referenced) certificate policies can either be defined by the CSP issuing QCs, or be defined by a reference to a standard (e.g., ETSI TS ) or combine both CSP QC and standardised policies. - By completing one or both above methods with a human readable user notice text providing as clearly noticeable information as possible. Such user notice, when used by the CSP issuing QCs must be consistent with the provided machine processable information about limitations of use, about the statement that the certificate is qualified and/or that the associated private key is supported by a SSCD. 4 Proposal for an Interoperable Qualified Certificate Profile 4.1 Introduction The proposal for the minimum data to be contained in the QC, while ensuring efficient interoperability in particular in the context of cross-border use cases, must be in line with the requirements of Directive 1999/93/EC and based on the existing standards. This expected target for the QC profile should make it clear, considering both human readable and machine processable information, that the certificate is a claimed QC and whether or not it claims to be associated to an SSCD for the creation of AdES. It must also be based on a profile with as small a margin for interpretation as possible to avoid implementation divergences. Date : 31/07/2010 Page 10 /23

11 Dependent on whether the QC is to be used with or without the support of a SSCD, the following minimum data for a proposed common interoperable and cross-border profile for QC could include: - Issuer and Authority Key unambiguous identification information; - Subject and Subject Key unambiguous and unique identification information; - The following qualified certificate statements: o QcCompliance stating that the certificate is a QC o QcSSCD (only for the support of QES) stating the support of an SSCD; - The use of at least one Certificate Policy OID referring to a CPS/CP document also available in English and completed in the certificate by an as discernable as possible user notice text. The support of respectively the ETSI TS QCP+ certificate policy in the context of the support of QES, or the ETSI TS QCP certificate policy is strongly recommended 15 ; - A mandatory support of OCSP certificate status checking services (SHALL), as an alternative and back-up solution CRL-based validity status checking services MAY be provided additionally; - A key usage exclusively restricted to nonrepudiation (contentcommitment) when supporting a QES or an AdES supported by a QC; - The rest of the certificate content is ruled by the following standardisation deliverable: ETSI TS X.509 v3 Certificate Profile for Certificates Issued to Natural Persons. 16 The detailed specifications of the proposed common interoperable and cross-border profile for QC are described in the next section. The following issues and attention points should be further addressed when further elaborating and finalising the Interoperable QC Profile with relevant stakeholders, i.e. mainly the ESOs (notably through standardisation Mandate M460 [7]) and the Member States: - QC issued to Legal person versus QC issued to Natural Persons: While the esignature Directive seems to focus on Natural Persons as subjects of the QC 17, there is a need to consider Legal Persons as well 18. The (electronic) signature of Legal persons is in place in the legislation of some Member States (e.g. ES, EE) as the notion of person is interpreted differently according to national legislations. No standardisation deliverable is currently covering profile requirements for QC issued to Legal Persons. Without prejudice for Member State national legislations to recognise or not electronic signatures of legal persons, it is recommended that standardisation 15 ETSI : Electronic Signature and Infrastructures (ESI) ; Policy requirements for certification authorities issuing qualified certificates. 16 This ETSI TS standardisation deliverable relies on ETSI TS Qualified Certificate Profile, RFC 3739 (obsoletes RFC 3039) IETF Internet X.509 Public Key Infrastructure: Qualified Certificate Profile, RFC 5280 (obsoletes RFC 3280) IETF Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile. In case of discrepancies between these documents (namely RFC 3739, RFC 5280), ETSI is the normative one. In case of discrepancies between ETSI and the proposed QC profile, the proposed QC profile shall be the normative one. 17 The subject of a certificate is referred to as the signatory in Directive 1999/93/EC. 18 Actually Directive 1999/93/EC only refers to person with regards to signatories. Person may however be interpreted differently in Member States laws, either referring to natural persons only or to natural and legal persons. Date : 31/07/2010 Page 11 /23

12 recast of (qualified) certificate profile in the context of mandate M460 [7] shall specifically cover both legal and natural persons. - Identification of the Issuing CA (and underlying CSP) having issued the QC and Identification of the Subject of the QC: Proper and unique identification of both the issuing CA (as part of a CSP QC organisation having final responsibility and liability for the issuing and life-cycle management of the issued QC) and of the subject of the QC is of major importance. Method(s) to establish and use appropriate direct or indirect unique identifiers should be commonly defined and adopted in the context of the QC profile. This issue is likely to require appropriate liaison with the Large Scale Pilot STORK and related standardisation initiatives like CWA RFC 5280 expected use of X.509 Certificate Policies extension versus actual use of this field Section 6 of RFC 5280 actually indirectly ruling the content and use of the X.509 CertificatePolicies extension is one of the most complex, badly written and difficult to understand specifications that can be found. Actually this section 6 is related to the verification algorithm of signatures, not to the profile of the certificate even if it has expected indirect effect on it through RFC 5280 section (ruling the use of certificate policy extension in certificates), and for this one the restriction imposed on the use of certificate policies are poorly defined in RFC Actually CSPs have broken the RFC 5280 s expected use of this CertificatePolicies extension willing that to be standard wise considered as a valid certificate policy, the same certificate policy OID must be present in the whole CA certificate chain from the (end-entity) certificate in which it is included up to a Trusted Anchor. It is a matter of fact that this technical constraint and concept of CertificatePolicies field as to be considered as input for certification path validation was definitely not implemented by most of the EU CSPs with regards to the replication of Certificate Policy OIDs in the certification chain. Additionally, it is clear that in most, if not all, of the chains supporting the QC issued in the EU, the ETSI QCP or QCP+ policies (respectively and ) could never be considered as valid as they are quasi only used in end-user certificates and not in supporting CAs certificates. This is the case also for most of the OIDs used for distinguishing different policies or CPS s. These OIDs are not duplicated in certificates in the chain but only included in the end-user certificates to which they apply and when used in a CA certificate they have to be considered as ruling the subordinate certificates. However, basically all of the CSPs (at least those issuing QCs) did adopt the concept of certificate policies and use such policy information terms in end-entity certificates to indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used as defined in RFC 5280, clause Those CSPs are writing CPS and CP s according to the relevant standards (e.g. RFC 3647, ETSI TS , ETSI TS with regards respectively to the ToC and policy requirements with regards to CSP issuing qualified certificates or non-qualified certificates) and referring in issued certificates to those policies that are applicable, valid and in due force when relying on such certificates. The rule that those CSPs are implementing is that issued certificates do include references to the applicable (and valid) CPS or CP that are ruling the issuance of those certificates. 19 CWA 16036: Cyber-Identity - Unique Identification Systems For Organizations and Parts Thereof. Date : 31/07/2010 Page 12 /23

13 The interoperability issue is only due to the fact that the rules for validating certificate policies when validating electronic signatures as defined in 1999 do not reflect today s reality in the 2010 market To sum up, when a rule was so badly written, badly understood and in practice so badly implemented by most of the CSPs compared to what seems to have been wished by the standard, then it may be time to question the validity and relevance of such a rule compared to the market situation. If updating RFC 5280 for alignment with market reality with regards to requirements related to the use of the CertificatePolicies extension would turn out to be intractable, the most appropriate solution may be to create another extension that could be used by CSP as they are using it to indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used but without being intended to be used in certification path validation. 4.2 Proposed Qualified Certificate profile Within the present section, 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 In the QC profile proposed below, all certificate fields and extensions SHOULD, where applicable, comply with ETSI TS In case of discrepancies between the proposed profile and other standards, the present proposed profile would be the normative one. 22 Common Minimum Requirements for QC Profile supporting Qualified Electronic Signatures Base Certificate Presence Critical Value Version MUST SHALL be ITU-T X.509 v3 certificate signaturealgorithm AlgorithmIdentifier MUST SHALL be specified according to RFC 3279 and its successors, and/or ETSI TS and its sucessors. Issuer MUST 1. SHALL be specified according to ETSI TS and ETSI The identity of the issuer SHALL be specified using an appropriate subset of the following attributes: countryname (ETSI TS : The specified country SHALL be the country in which the issuer of the certificate is established) organizationname, organizationalunitname, (multiple instances may be present) stateorprovincename, localityname, commonname, serialnumber, and domaincomponent. Additional attributes MAY be present but they SHOULD NOT be necessary to identify the issuing organization. The attributes countryname and organizationname SHALL be present. The organizationname attribute SHALL contain the full registered name of the certificate issuing organization and countryname SHALL contain the country within which the issuing organization is registered. A specific extended subset of the set of the above attributes recommended by ETSI TS is recommended to be made mandatory and further explicitly defined with regards to their semantic. This specification work 20 IETF RFC 2119: "Key words for use in RFCs to indicate Requirement Levels". 21 ETSI TS : X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons. 22 UTF8String text coding to be used whenever possible and applicable. Date : 31/07/2010 Page 13 /23

14 should be done in liaison with STORK and similar initiatives. 2. serialnumber SHOULD be present and when present it is RECOMMENDED that it is implemented according to a meta-identification based scheme ensuring interoperability between identification schemes used by different business registers currently in place and in line with national regulations on the use of such identifiers, following, as recommended in CWA 16036, an IBAN-like set-up of world-wide unique identifiers consisting in a standardised composition of existing schemes meaning that no new identification schemes have to be invented and implemented. This scheme SHOULD also allow identifying uniquely the technical issuing CA. Subject MUST 1. SHALL be specified according to ETSI TS with pseudonym added as part of the listed attributes from which an appropriate subset constitute the Subject field. If the attribute pseudonym is present, it must not be combined with surname and/or givenname attributes. If the pseudonym is present in the commonname attribute field, then the word PSEUDONYM must be appended after or before the given pseudonym. A specific subset of the set of attributes recommended by ETSI TS is recommended to be made mandatory (e.g. country name) and further explicitly defined with regards to their semantic (e.g. country name referring to the nationality of the subject). This specification work should be done in liaison with STORK and similar initiatives. 2. serialnumber: SHOULD be present and when present it is RECOMMENDED that it is implemented according to a meta-identification based scheme ensuring interoperability between identification schemes used by different business registers currently in place and in line with national regulations on the use of such identifiers, following, as recommended in CWA 16036, an IBAN-like set-up of world-wide unique identifiers consisting in a standardised composition of existing schemes meaning that no new identification schemes have to be invented and implemented. While focusing on organisation and parts thereof, CWA recommendations could be applied to identification of both legal and natural persons. In one serialnumber field must be indicated only one reference on physical person s identity. A method of physical person s identity determination MUST be in accordance with the legislation of the country within which the certificate Issuer is established and registered. 3. The serialnumber field with the reference on physical person s identity must contain only such information which was verified in a registration process during qualified certificate issuance. Standard Extensions Presence Critical Value CertificatePolicies MUST SHOULD NOT (or new extension not intended to be used in certificate path validation as defined in RFC 5280 section 6) 1. SHALL include at least one certificate policy identifier in the Certificate Policies extensions, as defined in clause from RFC 5280, clearly expressing that the issuer intentionally has issued the certificate as a Qualified Certificate and that the issuer claims compliance with Annex I and Annex II of Directive 1999/93/EC. 2. CPS and/or CP s referred to in this filed through the use of oid that are provided in language other than English SHALL be translated and provided Date : 31/07/2010 Page 14 /23

15 in English as well. 3. [CASE 1 - QC supporting QES]: When Issuer claim compliance with ETSI TS QCP+ certificate policy, the QCP+ OID SHALL be included. Compliance with ETSI TS QCP+ is RECOMMENDED. [CASE 2 - QC supporting AdES]: When Issuer claim compliance with ETSI TS QCP certificate policy, the QCP OID SHALL be included. Compliance with ETSI TS QCP is RECOMMENDED. Qualified Certificate Statement qcstatement 4. A User Notice Text SHALL be used to indicate in an as discernable way as possible the fact that the issued certificate is a Qualified Certificate whose private key associated to the certified public key is supported by an SSCD and is aimed to be used exclusively to create QES. An English translation SHOULD be additionally provided in order to facilitate crossborder use and EU wide usability. MUST MAY 1. SHALL contain OID id-etsi-qcs-qccompliance: stating that issued certificate is a Qualified certificate according to Annex I and II of Directive 1999/93/EC, as implemented in the law of the country where the Issuer is established. 2 [CASE 1 - QC supporting QES]: SHALL contain OID id-etsi-qcs-qcsscd stating that the private key associated with the public key resides within an SSCD. [CASE 2 - QC supporting AdES]: SHALL NOT contain OID id-etsi-qcs- QcSSCD. 3. MAY contain: - OID id-etsi qcs-qclimitvalue indicating limits on the value of transactions for which the certificate can be used; 4. SHALL[SHOULD] contain - OID id-etss-qcs-qcretentionperiod indicating the duration of the retention period during which the registration information is archived. ( 23 ) keyusage MUST CRITICAL The key usage combination SHALL be limited to nr bit (bit1 set) only or nr+ds bits (bit 1 and bit 0 set). This means that the non-repudiation bit (bit 1) SHALL be set 24. Of these alternatives it is RECOMMENDED to use the nr bit (bit 1) only (for security reasons). authoritykeyidentifier MUST Non-critical SHALL be specified according to RFC subjectkeyidentifier MAY Non-critical SHALL be specified according to RFC crldistributionpoints MUST Non-critical As per ETSI TS Private Extensions Include Critical Value AuthorityInfoAccess MUST Non-critical OCSP certificate status checking MUST be supported. The opportunity and relevance of defining additional Qualified Certificate Statements (OIDs) in addition to the already defined qcstatements defined by ETSI in ETSI TS will be 23 It MAY be interesting to assess the need for a newly defined qcstatement regarding the notification to subject and relying parties of any significant limitation of liability indicated by the Issuer, if applicable, and if legally valid in the law of the country within which it is established (e.g., requirements of consumer legislation). An additional qcstatement SHOULD be defined for indication whether the certificate subject is a Legal person. 24 This nonrepudiation bit has been renamed contentcommitment. Date : 31/07/2010 Page 15 /23

16 further analysed. This may include for example the use of a qcstatement that should be used by CSPs issuing QCs to indicate whether the QC is issued to a Natural or Legal Person, when applicable. 5 Recommendations CROBIES study team strongly recommends that the above proposal for an Interoperable QC Profile shall be taken into account and addressed in the context of execution of Mandate M460 [7] with the aim: To recast the set of standards related to certificate profile into a clear set of consistent and complete requirements; To address (qualified) certificates issued to natural and legal persons; To address all the above specific recommendations related to the proposed profile. CROBIES study team strongly recommends that European Standardisation Organisations executing mandate M460, in particular in the context of this Interoperable QC Profile, shall include Member States supervisory bodies as client stakeholders for completion of the related standardisation work. CROBIES study team strongly recommends that Member States supervisory bodies will actively and decide on a common position on this particular topic and provide common input to the ESOs. Date : 31/07/2010 Page 16 /23

17 Annex 1 - Relevant standards: summary and their requirements The following Figure illustrates the precedence between the different relevant EU standardisation deliverables with regard to the profile of Qualified Certificates issued to natural persons. It also indicates to which standards the different EU Member States refer to in the context of the formal requirements of compliance for QC in their national legislation or through the establishment of CSP QC supervision scheme. (Qualified) Certificate Profile related standards No formal mapping to any standard ETSI TS X.509 v3 Certificate Profile for Certificates issued to Natural Persons European esignature Directive 1999/93/EC ETSI (& below ): 3 MS (IT, PL, SK) + DE (optional Nat.Std) Requirements from MS Law / Supervision Scheme Directive requirements only: 9 MS (AT, DE, EE, ES, GR, LT, LV, MT, SI) + LI, NO Adds additional requirements to & is based on ETSI TS Qualified Certificate Profile Adds additional requirements to & is based on ETSI : 2 MS (CZ, FR) ETSI (& below ): 8 MS (BE, BG, FI, FR, HU, LU, NL, RO) + IS, NO (recom.) ETSI TS QCP, QCP+ certificate policies ETSI TS NCP, NCP+ certificate policies LCP certificate policy RFC 3739 (obsoletes RFC 3039) Qualified Certificate Profile Adds additional requirements to & is based on RFC 5280 (obsoletes RFC 3280, 4325, 4630) Certificate & CRL Profile Adds additional requirements to & is based on ITU-T Recommendation X ISO/IEC RFC 5280 (& below ): 1 MS (SE) Indicates entry point is the displayed hierarchy for MS requirements National Standard: 6 MS FR: PRIS V2, CP & CP Pro IT: CNIPA std FI: FINEID S2 DK: DS844 (not available?) SK: NSA-QCF DE (optional): ISIS-MTT Not applicable: 3 MS (CY, IE, UK) Unknown: 1 MS (PT) Figure 2 The following sections provide, for information purposes, the summary of the specific existing requirements from the three main standards underlying the QC profile. When available, national standards are usually based on existing EU standards as indicated in red and underlined in the above Figure The following ETSI specifications below are the existing specifications and provided for information purposes. Those specifications are recommended to be updated in accordance with the recommendations of the present report. 25 The horizontal arrows indicate which level of the expected requirements hierarchy the listed Member States is considered as the entry point of the (qualified) certificate profile requirements in national legislation or in supervision/accreditation scheme. Nine Member States refers to Directive 1999/93/EC requirements only. Six Member States have specific national standards for such requirements. Date : 31/07/2010 Page 17 /23

18 ETSI TS X.509 v3 Certificate Profile for Certificates Issued to Natural Persons These technical specifications define a common profile for ITU-T Recommendation X.509 based certificates issued to natural persons. Their scope is to provide a certificate profile, which will allow actual interoperability of certificates issued for the purposes of QES, peer entity authentication and data authentication. This profile depends on the Internet standards RFC 5280 and RFC 3739 for generic profiling of ITU-T Recommendation X.509, and depends on the ETSI standard TS to define implementation of requirements defined by Directive 1999/93/EC Annexes I and II. ETSI TS requires that all certificate fields and extensions SHALL, where applicable, comply with RFC 5280, RFC 3739 and TS with the amendments specified in ETSI TS When no specific requirements is stated for a particular field or extension, this means that no specific requirements apply except for those stated by RFC 5280, RFC 3739 and TS In case of discrepancies between ETSI TS and the named standards above, the ETSI TS document is the normative one. Summary of ETSI TS certificate profile requirements Basic certificate fields Version SHALL be ITU-T X.509 v3 certificates Signature algorithm SHALL be specified according to RFC 3279 and ETSI TS (sha1withrsaencryption still recommended for interoperability). Issuer Identity of Issuer SHALL be specified using an appropriate subset of the following attributes: countryname (SHALL country within which CSP is registered), organizationname (SHALL full registered name), organizationalunitname, (multiple instances may be present) stateorprovincename, localityname, commonname, serialnumber, and domaincomponent. Additional attributes MAY be present but they SHOULD NOT be necessary to identify the issuing organization. Subject The subject field SHALL contain an appropriate subset of the following attributes: domaincomponent, countryname, commonname, surname, givenname, serialnumber, title, organizationname, organizationalunitname, stateorprovincename, and localityname. Other attributes may be present but SHALL NOT be necessary to distinguish the subject name from other subject names within the issuer domain. SHALL contain at least either commonname or surname&givenname (choice). Subject public key info SHALL be included according to RFC 3279 and ETSI TS (strongly recommended to use rsaencryption for interoperability) X.509 v2 Issuer & SHALL not be present Subject Unique Identifier Standard certificate extensions Authority Key Identifier SHALL be present, containing a key identifier for the issuing CA s public key. Key Usage In cases where a certificate is intended to be used to validate commitment to signed content, such as electronic signatures on agreements and/or transactions, then the key usage combination SHALL be limited to nr bit (bit1 set) only or nr+ds bits (bit 1 Date : 31/07/2010 Page 18 /23