How To Protect Your Computer From Being Hacked In European Security Policy

Transcription

1 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Report

2 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Bundesamt für Sicherheit in der Informationstechnik Postfach Bonn Tel.: digsig@bsi.bund.de Internet: Bundesamt für Sicherheit in der Informationstechnik 2006 Bundesamt für Sicherheit in der Informationstechnik 2

3 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» The French government in particular two agencies of the French Prime Minister has published a PKI standard under the name Politique de Référencement Intersectorielle de Sécurité Version 2, or for short PRISv2. On the other hand in Germany an industry consortium with support of the German government has published the PKI interoperability standard Industrial Signature Interoperability Standard MailTrusT, or for short ISIS-MTT. The purpose of the study is to compare these two sets of standards. The study was written by Hans-Joachim Knobloch, Secorvo Security Consulting GmbH and Natalie Mareth, Secorvo Security Consulting GmbH together with Dr. Ulrike Korte, Bundesamt für Sicherheit in der Informationstechnik. In addition we would like to thank Mr. Utz Gnaida, Bundesamt für Sicherheit in der Informationstechnik, for his comments. Bundesamt für Sicherheit in der Informationstechnik 3

4 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Bundesamt für Sicherheit in der Informationstechnik 4

5 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Inhaltsverzeichnis 1. Introduction 7 2. Respective Areas of Regulation Approach of PRISv Approach of ISIS-MTT Other relevant Standards and Policies Referenced Base Standards of PRISv2 and ISIS-MTT Conclusion of the general comparison Detailed Comparison Classification of Comparison Results Comparison of Certificate and CRL Profiles CA-Certificates EE-Certificates CRL-Profile Comparison of Certificate Policies European Bridge CA V-PKI ETSI TS EBGCA References Acronyms and important Vocabularies in PRISv Acronyms Vocabularies 52 Bundesamt für Sicherheit in der Informationstechnik 5

6 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Bundesamt für Sicherheit in der Informationstechnik 6

7 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» 1. Introduction The French government in particular two agencies of the French Prime Minister has published a PKI standard under the name Politique de Référencement Intersectorielle de Sécurité Version 2, or for short PRISv2. On the other hand in Germany an industry consortium with support of the German government has published the PKI interoperability standard Industrial Signature Interoperability Standard MailTrusT, or for short ISIS-MTT. The purpose of the study is to compare these two sets of standards, to assess their respective compatibility or incompatibility and to give technical recommendations for follow-up actions aimed at a harmonized further development of the PRISv2 and ISIS-MTT efforts. The results are presented in this report. As detailed in chapter 2 below, the main focus of PRISv2 is on PKI security and policy requirements whereas the main focus of ISIS-MTT is on profiling data interchange formats for interoperable PKI applications. Therefore additional certificate policies respectively policy requirement standards have been considered for comparison with PRISv2, in particular the policy requirements for members of the European Bridge-CA (EB-CA) and the policy of the German Verwaltungs-PKI (V-PKI). The study was initially carried out based on a draft version of PRISv2 ([1] to [7]). On 21 July 2005, the final version of PRISv2 ([8] to [17], dated 01 June 2005) was published on the ADAE web site. Differences between these two versions have been considered for the results presented below. 2. Respective Areas of Regulation 2.1 Approach of PRISv2 The Politique de Référencement Intersectorielle de Sécurité Version 2 (PRISv2) has been developed and published by two agencies of the French prime minister: Agence pour le Développement de l Administration Électronique (ADAE) together with Direction Centrale de la Sécurité des Systèmes d'information (DCSSI) It is primarily focused on the definition of three different security levels, referred to one star *, two star ** and three star ***, with *** being the highest security level, further differentiated according to the different trust services authentication, signature, confidentiality, time stamping and others as depicted in Figure 1. Bundesamt für Sicherheit in der Informationstechnik 7

8 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» *** Security Levels ** * Authent. Signature Confident. Timestamp others Trust Services Figure 1: PRISv2 security levels and trust services PRISv2 is comprised of the following documents: A motivating abstract ( note de cadrage ; [8], draft version was [1]). A Preamble ([9],draft version was [2]). Separate descriptions of trust services ( présentation du service ; currently published for authentication, signature and confidentiality, [12], [14] and [16]; draft version was [6] for confidentiality only) stating the reasoning behind PRISv2 w.r.t. the respective trust service, service specific regulations and details on security levels. Separate policy types for the different trust services ( politique de certification type ; currently published for authentication, signature and confidentiality, [13], [15] and [17]; draft version were [5] and [7] for authentication and confidentiality only) defining policy requirements in a structure according to RFC 3647, which can be used as a kind of policy templates by trust service providers. A joint document instantiating time variables referenced throughout the policy types ( variables du temps ; [10], draft version was [3]). Joint certificate, CRL and OCSP profiles referenced throughout the policy types ([11], draft version was [4]). These documents are to be complemented by Common Criteria protection profiles for the security devices and applications needed to implement the respective trust services and further complementary documents as shown in French language in Figure 2. Bundesamt für Sicherheit in der Informationstechnik 8

9 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Figure 2:PRISv2 document architecture (taken from [9]) 2.2 Approach of ISIS-MTT ISIS-MTT has been developed and published with support of the German government by an consortium comprised of two industry associations: TeleTrusT e.v., a non-profit organization for the promotion of trustworthiness of information and communication technology T7 e.v., a working group of German (and Austrian) trust centers ISIS-MTT is mainly focused on interoperability of PKI application with the explicit goal to provide interoperability even between different security levels (if acceptable as defined by the underlying policies). For that end ISIS-MTT attempts to cover the comprehensive set of all interoperability areas relevant for PKI applications using various trust services in practice, in particular Certificate and CRL profiles, Certificate management, Message formats (S/MIME and CMS), Operational Protocols (LDAP, OCSP and TSP), Certificate path validation, Cryptographic algorithms, Cryptographic token interface and XML signature and encryption profile, and to provide a consistent profiling throughout all these interoperability areas shown in Figure 3. Bundesamt für Sicherheit in der Informationstechnik 9

10 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Cert.Profile Cert. Mgt. Interoperability Areas Message Formats Protocols (LDAP,...) Token API & others Authent. Signature Confident. Timestamp others Trust Services Figure 3: ISIS-MTT interoperability areas and trust services ISIS-MTT version 1.1 is comprised of the following documents: An introduction ([18]) Eight core parts profiling base standards in the interoperability areas enumerated above ([19] to [26]). Conformance with the core parts is required for a product to be ISIS-MTT compliant. Two optional profiles, for which conformance is not generally required, ([27] and [28]). Conformance with optional profiles is not generally required from products. These documents are to be complemented by a test specification for testing the conformance of products with the ISIS-MTT specification, a freely available testbed implementation, a document defining the compliance criteria to be met by different types of products or services in order to obtain the ISIS-MTT Seal (compliance label) and further complementary documents. 2.3 Other relevant Standards and Policies Due to the different areas of regulation, some additional standards and policies were identified to be taken into account for the comparison. In addition to ISIS-MTT, the following German and European policies (or more precisely: policy requirements) are to be considered: the policy requirements for members of the European Bridge-CA (EB-CA; draft versions [30] and [31] of the revised requirements), the policy of the German Verwaltungs-PKI (V-PKI; [32] and naming concept [33]), the European Standard on policy requirements for certification authorities issuing public key certificates (ETSI TS ) and the Certification Practices Statement of European Bridge/Gateway CA Pilot for Public Administrations (EBGCA). In addition to PRISv2 the Cadre commun d interopérabilité des systèmes d information publics (CCI; [38]), which is a collection of interoperability standards for use in e-government Bundesamt für Sicherheit in der Informationstechnik 10

11 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» applications roughly comparable to the German SAGA document [39], will be considered in the survey of base standards below. Bundesamt für Sicherheit in der Informationstechnik 11

12 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» 2.4 Referenced Base Standards of PRISv2 and ISIS-MTT Table 1 summarizes the bases standards referenced for different technical areas in PRISv2 and ISIS-MTT 1.1 as well as by other relevant documents in the context of this study in France or Germany. Technical Area PRISv2 Base Standards ISIS-MTT 1.1 Base Standards Documentation of Certificate Policies RFC 3647 n/a Germany: Operation guidelines and regulations for Trust Service Providers ETSI TS v1.1.1 CWA CWA CWA PC 2 v2.2 N 972-1/SGDN/DCSSI ISO/IEC n/a Base Standards used in wider context in France or Germany RFC 2527 (V-PKI) RFC 3647 (EB-CA) Europe: RFC 2527 (EBGCA) RFC 3647 (EBGCA, ETSI TS ,) Europe: ETSI TS (EBGCA) ETSI TS (EBGCA) CWA (ETSI TS ) CWA (ETSI TS ) CWA (ETSI TS ) CWA (ETSI TS ) ISO/IEC (ETSI TS ) FIPS PUB (ETSI TS ) FIPS PUB (ETSI TS ) Bundesamt für Sicherheit in der Informationstechnik 12

13 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Technical Area PRISv2 ISIS-MTT 1.1 Base Standards used in wider Base Standards Base Standards context in France or Germany Qualification Criteria Certificate and CRL Format N 1591/SGDNDCSSI/SDR N 1549/SGDN/DCSSI/SDR X.509v3 RFC 3280 RFC 3739 ETSI TS v1.2.1 ETSI TS v1.1.1 n/a X.509 (1997) RFC 3280 RFC 3281 RFC 3039 RFC Certificate Management RFC 2797 ETSI TS v1.3.0 ETSI TS v0.1.1 RFC 2630 RFC 2511 RFC 2314 RFC 2315 RFC 2633 Exchange Format for Files RFC 3369 RFC 2634 TS v1.4.0 France (CCI): RFC 2510 RFC To be precise, the preceding Internet draft draft-ietf-pkix-sonof is referenced. Bundesamt für Sicherheit in der Informationstechnik 13

14 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Technical Area PRISv2 ISIS-MTT 1.1 Base Standards used in wider Base Standards Base Standards context in France or Germany Exchange Format for RFC 2633 RFC 3369 RFC 2634 TS v1.4.0 Exchange Format for XML-Documents REC-xmldsig-core REC-xmlenc-core ETSI TS v1.1.1 Directory Access RFC 2251 (with elements of RFC 1777) RFC 2256 RFC 2587 Online Status Validation RFC 2560 RFC 2560 Time Stamping (PRISv2 documents on time stamping are yet to be published) draft-ietf-pkix-ocspv2-02 RFC 3161 ETSI TS v1.2.1 France (CCI): RFC RFC 3369 RFC 3370 France (CCI): REC-xmldsig-core RFC 2807 RFC 3275 REC-xmlenc-core France (CCI): RFC RFC 2585 RFC 2587 Bundesamt für Sicherheit in der Informationstechnik 14

15 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Technical Area Cryptographic Algorithms and associated Data Formats PRISv2 Base Standards PKCS#1 v2.1 RFC 3279 N 1064 SGDN/DCSSI/SDS/AsTeC ISIS-MTT 1.1 Base Standards RFC 3279 PKCS#1 v1.5 PKCS#1 v2.0 RFC 2104 FIPS FIPS FIPS-197 ANSI X9.52 (and others) Cryptographic Token Interface PKCS#11 v2.01 (eventually to be replaced by PKCS#11 v2.11) Table 1: Base standards referenced in PRISc2 and ISIS-MTT 1.1 Base Standards used in wider context in France or Germany Germany: Declaration on appropriate algorithms for electronic signatures ([37]; annually published by RegTP/BNetzA;, developed with assistance of BSI) France (CCI): ISO 7816 Bundesamt für Sicherheit in der Informationstechnik 15

16 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» 2.5 Conclusion of the general comparison As a conclusion it can be said that, as shown in Figure 4, PRISv2 and ISIS-MTT do more supplement than oppose each other. The largest area of overlap between the two can be found in the Certificate and CRL profiles. Where there is an overlap, the referenced base standards are except for version differences largely the same 2. Security Levels *** ** * Cert.Profile Cert. Mgt. Interoperability Areas Message Formats Protocols (LDAP,...) Token API & others Authent. Signature Confident. Timestamp others Trust Services Figure 4: Mutual supplementation of PRISv2 and ISIS-MTT They are also associated with different and supplementing marketing statements to customers of service providers and product suppliers: PRISv2 provides horizontal comparability between suppliers of the same services: Trust service providers can advertise standardized services and security levels. Customers can choose between competing trust services at security levels fitting their needs. ISIS-MTT provides vertical interoperability between suppliers of complementary services: Customers can expect different complying products to interoperate in an intended application. Suppliers can affirm this by obtaining an ISIS-MTT seal for their product after passing standardized conformance tests. 2 One notable difference is that for certificate management, ISIS-MTT is based on the simple certificate management messages over CMS (SCMC; RFC 2797), whereas the cadre commun d interopérabilité not PRISv2 itself envisages the user of the competing certificate management protocol (CMP: RFC 2510). it is however unclear, how far the CCI recommendations have been implemented in practice. Bundesamt für Sicherheit in der Informationstechnik 16

17 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» v2 (PRISv2)» 3. Detailed Comparison This chapter presents a detailed comparison between PRISv2 on the one hand and ISIS-MTT 1.1 as well as the policy requirements of EB-CA, V-PKI, ETSI TS and EBGCA on the other hand in form of comparison charts. 3.1 Classification of Comparison Results The following charts present a step-by-step comparison of regulations stipulated in PRISv2 (always on the left half of the chart) and ISIS-MTT 1.1 as well as other German/European frameworks (on the right half of the chart). The result of each comparison step can be one of the following five conclusions, which correspond to the possible relations of two different sets in set theory: Congruence: regulations in both frameworks are identical Incompatibility: some regulations in each of the frameworks are mutually exclusive Left subset: PRISv2 is the stricter regulation; the German/European framework must be further restricted/profiled in order to be compatible Right subset: German/European framework is the stricter regulation; PRISv2 must be further restricted/profiled in order to be compatible Intersection: some regulations of both frameworks must be further restricted/profiled to be compatible The symbols shown above will be used in the following comparison charts to denote the respective comparison result. Bundesamt für Sicherheit in der Informationstechnik 17

18 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» 3.2 Comparison of Certificate and CRL Profiles The following comparison of PRISv2 and ISIS-MTT 1.1 certificate and CRL profiles is based on previous work [29], conducted in the context of the German Signature Alliance ( Signaturbündnis, see for more information about the Signature Alliance). There are indications that the Signature Alliance document [29] has been considered during the revision of the PRISv2 document from [4] to [11]. Several of the most important discrepancies between PRISv2 and ISIS-MTT certificate profiles mentioned in [29] have been resolved in the new version of the PRISv2 profile, in particular PRISv2 proprietary QC statements have been removed, the PrintableString format has been generally permitted as an alternative to UTF8String in the subject and issuer distinguished name and issues about the Basic Constraints extension in CA certificates have been clarified by emphasizing the clause that all RFC 3280 requirements hold in addition to the specific PRISv2 profiling. The most eminent remaining issues are the requirement for an ISO 6523 compliant identification number as organizationalunitname (OU) attribute in the naming of CAs and institutional end entity certificate holders and the accentuation of delta CRLs, in contrast to ISIS-MTT where an emphasis is in indirect CRLs but not on delta CRLs CA-Certificates Data Element PRISv2 Profile ISIS-MTT 1.1 Profile Comparison Result Version v3 v3 Serial Number as in RFC 3280 as in RFC 3280 Bundesamt für Sicherheit in der Informationstechnik 18

19 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» v2 (PRISv2)» Data Element PRISv2 Profile ISIS-MTT 1.1 Profile Comparison Result Issuer PrintableString or UTF8String format allowed, must comply with RFC 3739 and TS (C and O mandatory, O must be company name), OU mandatory, OU must be ISO 6523 compliant identification number (in France: SIREN) PrintableString or UTF8String format allowed, C and O mandatory, O must be company name Validity as in RFC 3280 as in RFC 3280 Subject see Issuer see Issuer Subject Public Key Info Algorithms: sha-1withrsaencryption dsa-with-sha1 ecdsa-with-sha1 Support for sha256withrsaencryption recommended Key Lengths at least 2048 resp. 256 bit Issuer Unique ID/Subject Unique ID forbidden forbidden Algorithms: sha-1withrsaencryption rsasignaturewithripemd160 dsa-with-sha1 ecdsa-with-sha1 SHA-2 currently only for XML signatures, sha256withrsaencryption and others are currently under discussion Key Lengths not specified Authority Key Identifier mandatory, non-critical, keyidentifier mandatory, non-critical, keyidentifier Subject Key Identifier mandatory, non-critical as in RFC 3280 mandatory, non-critical Key Usage mandatory, critical mandatory, critical, with keycertsign and optional crlsign (expected to become ) (in practice probably: ) Bundesamt für Sicherheit in der Informationstechnik 19

20 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Data Element PRISv2 Profile ISIS-MTT 1.1 Profile Comparison Result Certificate Policies Subject Alternative Names mandatory, critical, must comply with RFC 3739 optional, non-critical, must comply with RFC 3739 optional, optionally critical but recommended non-critical optional, optionally critical, FTP- /HTTP-/ LDAP-URLs Issuer Alternative Names like SubjectAltNames like Subject Alternative Names CRL Distribution Points Authority Info Access optional, non-critical, must comply with TS (HTTP- or LDAP-URL required) mandatory for OCSP, non-critical, must comply with RFC2560 optional, optionally critical, LDAP-URL mandatory and more stipulations mandatory for OCSP, non-critical, caissuer permitted Basic Constraints mandatory, critical as in RFC 3280 mandatory, critical further PKIX Extensions optional as in RFC 3280 some further profiling w.r.t. RFC 3280 Biometric Info optional, non-critical as in RFC 3280 optional, non-critical QC Statements optional, non-critical as in RFC 3280 or optional, optionally critical as in RFC 3739 OCSP No Check optional, non-critical as in RFC 3280 or optional, optionally critical as in RFC 2560 optional, optionally critical, statements from RFC 3739 and TS allowed further Extensions optional, non-critical as in RFC 3280 optional, non-critical Table 2: Comparison chart of PRISv2 and ISIS-MTT 1.1 profiles for CA certificates (or, depending on interpretation of PRISv2) optional, optionally critical (or, depending on interpretation of PRISv2) Bundesamt für Sicherheit in der Informationstechnik 20

21 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» v2 (PRISv2)» EE-Certificates Data Element PRISv2 Profile ISIS-MTT 1.1 Profile Comparison Result Version as for CA certificates as for CA certificates Serial Number as for CA certificates as for CA certificates Issuer as for CA certificates as for CA certificates Validity as for CA certificates as for CA certificates Subject PrintableString or UTF8String format allowed, must comply with RFC 3739 (CN or givenname/surname or pseudonym required), C, O and OU mandatory for enterprise or administration members, OU must be ISO 6523 compliant identification number (in France: SIREN) PrintableString or UTF8String format allowed, CN mandatory, pseudonym to be marked by CN suffix :PN, use of Gender permitted Subject Public Key Info as for CA certificates as for CA certificates (expected to become ) Issuer Unique ID/Subject Unique ID as for CA certificates as for CA certificates Authority Key Identifier as for CA certificates as for CA certificates Key Usage mandatory, critical, keyusagebits - for authentication: digitalsignature - for signature: contentcommitment - for confidentiality: keyencipherment or keyagreement, encipheronly, decipheronly mandatory, critical, keyusagebits depend on application Bundesamt für Sicherheit in der Informationstechnik 21

22 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Data Element PRISv2 Profile ISIS-MTT 1.1 Profile Comparison Result Certificate Policies as for CA certificates as for CA certificates Subject Alternative Names as for CA certificates as for CA certificates Issuer Alternative Names as for CA certificates as for CA certificates Subject Directory Attributes CRL Distribution Points Freshest CRL optional, non-critical, must comply with RFC 3739 optional, non-critical, PrintableString allowed, use of ISIS-MTT defined attribute nameatbirth permitted as for CA certificates as for CA certificates mandatory for delta-crls, noncritical, must comply with TS not covered Authority Info Access as for CA certificates as for CA certificates further PKIX Extensions as for CA certificates as for CA certificates Biometric Info as for CA certificates as for CA certificates QC Statements as for CA certificates as for CA certificates (or, depending on interpretation of PRISv2) OCSP No Check as for CA certificates as for CA certificates (or, depending on interpretation of PRISv2) further Extensions optional, non-critical as in RFC 3280 optional, non-critical Table 3: Comparison chart of PRISv2 and ISIS-MTT 1.1 profiles for end entity certificates Bundesamt für Sicherheit in der Informationstechnik 22

23 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» v2 (PRISv2)» CRL-Profile Data Element PRISv2 Profile ISIS-MTT 1.1 Profile Comparison Result Version v2 v2 Issuer as for CA certificates as for CA certificates This Update as in RFC 3280 as in RFC 3280 Next Update as in RFC 3280 as in RFC 3280 Revoked Certificates as in RFC 3280 as in RFC 3280 Reason Code mandatory if CA supports suspension, non-critical, crlreason unspecified permitted optional, non-critical, crlreason according to RFC 3280 Certificate Issuer optional as in RFC 3280 mandatory for indirect CRLs, critical, further profiling w.r.t. RFC 3280 further PKIX Entry Extensions optional as in RFC 3280 optional as in RFC 3280 further non-pkix Entry Extensions not covered not covered Authority KeyIdentifier as for CA certificates as for CA certificates Issuer Alternative Names as for CA certificates as for CA certificates CRL Number optional, non-critical optional, non-critical Delta CRL Indicator mandatory for delta CRLs, critical mandatory for delta CRLs, critical Freshest CRL as for EE certificates as for EE certificates further Extensions optional, non-critical as in RFC 3280 optional, non-critical Table 4: Comparison chart of PRISv2 and ISIS-MTT 1.1 profiles for CRLs Bundesamt für Sicherheit in der Informationstechnik 23

24 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» 3.3 Comparison of Certificate Policies One of the explicit goals of the PKIX policy framework (RFC 3647, formerly RFC 2527) is to facilitate the comparison of policy documents. A general experience made during this study was that it is indeed very helpful if both documents to be compared are structured according to RFC Nevertheless the authors of policy documents do sometimes present rather different issues and regulations under the same topic of the overall structure European Bridge CA The comparison of PRISv2 and European Bridge-CA member policy requirements ([30] and newer version in [31]) results in the conclusion, that only in some cases the profiles are congruent, especially when only level * in PRISv2 is required. Often PRISv2 is more detailed and EB-CA has to be further restricted, but in the majority of cases both Certificate Policies have to be further restricted to match each other. There is no requirement that leads to an incompatibility. As summary it can be noted, that EB-CA attaches great importance to documentation processes, what is nearly uncovered by PRISv2. On the other side PRISv2 gives detailed advisories for operational controls, facilities, management and technical security controls, whereas EB-CA only states general instructions in this points. Policy Element PRISv2 European Bridge CA Comparison Result 1.4 Usage of Certificates Authentication or Encryption or Digital signature (only one of these purposes, declaration required) 2.1 Directories CA has to provide a directory and certificate status service (CRL and optionally additional OCSP) declaration required not for signing certificates (except of CA-Certificates) CA has to provide a CRL CA should provide a directory Bundesamt für Sicherheit in der Informationstechnik 24

25 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» v2 (PRISv2)» Policy Element PRISv2 European Bridge CA Comparison Result 2.2 Publication of certification information 2.3 Time or frequency of publication 2.4 Access controls on repositories 3.1 Naming X.501 At least CP, CRL, root certificate CP and root certificate (in combination with 2.1: ) CP up-to-date, CRL mentioned in chapter 4.9 ***: strong access control **: strong access control for certificate state information, password otherwise *: password based pseudonym and anonym has to be marked for members of enterprises or administration, the SIREN number must be included DN has to be well-defined within the domain certificate objects may not be anonym 3.2 Initial Identity Validation detailed instructions for the initial check, including written form, distinguished in enterprise-, government- and private certificates CRL immediately, Changes in CP are to be provided to members before publication access control in proper form X.501 pseudonym and anonym has to be marked certificates must contain address DN has to be well-defined within the domain identification of ownership of a private key has to be regulated in Security Policy, identification at RA state-of-the-art key, key activation, name and may not be unverified requirements of integrity, authentication and confidentiality of Trusted Services have to be checked for *: Bundesamt für Sicherheit in der Informationstechnik 25

26 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Policy Element PRISv2 European Bridge CA Comparison Result 3.3 I&A for Re-key Requests regular renewal in proper way 3.4 I&A for Revocation Requests after Revocation process is identical to initial identification ***: formal verification (e.g. signature or 4-5 questions) ** : formal verification (e.g. 3-4 questions) *: verification due to basic information 4.1 Certificate Application has to be made by future owner, 4.2 Certificate Application Processing information provided: name, public key, identification documents Additional information for encryption only: demand for administration of the private key if available identification verifying evidences informing user about guidelines 4.3 Certificate Issuance *** and **: formally ***: verify relation between public key and future owner of certificate *: via after revocation reliable process for identification reliable verification should support identification of applicant and has to document the process, registry process has to be documented identification documentation distribution only for accepted demands documented process for *: Bundesamt für Sicherheit in der Informationstechnik 26

27 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» v2 (PRISv2)» Policy Element PRISv2 European Bridge CA Comparison Result 4.4 Certificate Acceptance *** with confirmation 4.5 Key Pair and Certificate Usage ** with confirmation, it is possible to define a period within the user has to reject the certificate after deliverance otherwise it will be implicitly marked as accepted * date of delivery only for one specific trust service, either authentication, signature or confidentiality publication within CA Defined process for receipt according to security policy guidelines for usage have to be provided only for the purposes named in the certificate 4.6 Certificate Renewal no certificate renewal without re-keying has to be documented 4.7 Certificate Re-key reasons: expired, revocation automatic or demanded by owner relation between owner and private key must stay constant well-defined process publication after renewal reasons : key compromise, certificate expired, key parameters expired announcement to user with defined process publication of new certificate 4.8 Certificate Modification not allowed reasons: name relation wrong, address changed documentation publication Bundesamt für Sicherheit in der Informationstechnik 27

28 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Policy Element PRISv2 European Bridge CA Comparison Result 4.9 Certificate Revocation and Suspension 4.12 Key Escrow and Recovery reasons: purpose of certificate, wrong usage, compromise of key, CA certificate revoked, an error occurred during the registration process concerned parties have to be informed certificate owners have to demand for revocation at once, if a reason occurred revocation demands with high priority have to be handled without delay the information about revocation has at least to be published in CRL it is recommended not to publish the reasons for revocation for encryption only: authentication and signature: key escrow forbidden encryption: key escrow allowed revocation has to take place if: compromise of key, relation between certificate and key no longer exists documentation required revocation as soon as possible after demand for revocation key escrow allowed if properly documented and currently technical state of art signing key should not be escrowed Bundesamt für Sicherheit in der Informationstechnik 28

29 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» v2 (PRISv2)» Policy Element PRISv2 European Bridge CA Comparison Result 5 Facility, Management, and Operational Controls detailed information about: physical controls procedural controls (roles) personnel controls audit logging procedures records archival key changeover termination of a CA or RA no detailed statements, CP should include requirements for the following cases: key changeover at CSP, compromise of the CA key, termination of a CA or RA no further information considering the subsections of chapter 5 6 Technical Security Controls detailed information about: 7 Certificate, CRL, and OCSP Profiles key generation (*** and ** supervised at least by 2 persons) private keys may not be archived management of key pairs (lifetime 1 to 3 years for EE keys, up to 10 years for CA keys) synchronization requirements on time stamping services detailed information in separate document (see comparison of certificate profiles with ISIS-MTT before) no detailed statements, CP should include requirements for the following cases: generation of key pairs, backup of the private key, expire dates for keys and certificates no further information considering the subsections of chapter 6 certificate extensions: KeyUsage and Basic Constraints critical name formats have to be documented and should comply with EB-CA Bundesamt für Sicherheit in der Informationstechnik 29

30 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Policy Element PRISv2 European Bridge CA Comparison Result 8 Compliance Audit and Other Assessment 9 Other Business and legal matters several rules, mostly defined in a separate document on the instantiation of certain variables mostly out of scope of PRIS except confidentiality guarantees should be proper no further information considering the subsections of chapter 8 CP should contain information about (according to legal facts): data protection period of validity individual notices and communications with participants underlying legislation miscellaneous provisions Table 5: Comparison chart of PRISv2 PC types and EB-CA policy requirements Bundesamt für Sicherheit in der Informationstechnik 30

31 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» v2 (PRISv2)» V-PKI Like in case of EB-CA presented in the previous chapter, V-PKI ([32]) and PRISv2 are hardly ever congruent, but in this case the range is even wider. For example V-PKI allows the certificate usage as well for encryption, authentication and advanced digital signature, whereas PRISv2 requires a restriction on one of this purposes. Furthermore the initial identity validation for security levels ** and * of PRISv2 are incompatible with V-PKI and the technical security controls of the two policies are contradictory. In all other cases compatibility can be achieved by restricting both policies in many details. Policy Element PRISv2 V-PKI Comparison Result 1.4 Usage of Certificates Authentication or Encryption or Digital signature (only one of these purposes, declaration required) 2.1 Directories CA has to provide a directory and certificate status service (CRL and optionally additional OCSP) 2.2 Publication of certification information 2.3 Time or frequency of publication 2.4 Access controls on repositories Encryption Authentication Advanced digital signature (simultaneous use permitted) Root-CA has to provide a CRL Root-CA has to provide a directory At least CP, CRL, root certificate CP, CRL and root certificate CP up-to-date, CRL mentioned in chapter 4.9 ***: strong access control **: strong access control for certificate state information, password otherwise *: password based CRL up-to-date, at least weekly publication not mentioned Bundesamt für Sicherheit in der Informationstechnik 31

32 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Policy Element PRISv2 V-PKI Comparison Result 3.1 Naming X.501 pseudonym and anonym has to be marked for members of enterprises or administration, the SIREN number must be included DN has to be well-defined within the domain certificate objects may not be anonym 3.2 Initial Identity Validation detailed instructions for the initial check, including written form, distinguished in enterprise-, government- and private certificates 3.3 I&A for Re-key Requests regular renewal in proper way after revocation process is identical to initial identification defined in separate VPKI-document [33], in accordance to X.509 individual person: appearance in person with identity card Legal person: at least appearance in person of one representative of the entity with identity card and: authorization prove of existence of the legal person declaration that no insolvency proceedings are in progress Group certificates: one person in charge, as in first case regular renewal with digitally signed request after revocation process is identical to initial identification for ***: ** and *: Bundesamt für Sicherheit in der Informationstechnik 32

33 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» v2 (PRISv2)» Policy Element PRISv2 V-PKI Comparison Result 3.4 I&A for Revocation Requests ***: formal verification (e.g. signature or 4-5 questions) ** : formal verification (e.g. 3-4 questions) *: verification due to basic information 4.1 Certificate Application has to be made by future owner, information provided: name, public key, identification documents Additional information for encryption only: demand for administration of the private key if available several possibilities: by telephone with password by fax with password mail signed CA has to apply at root-ca with: security policy self-declaration extract of commercial register declaration that no insolvency proceedings are in progress for ***: ** and *: 4.2 Certificate Application Processing identification verifying evidences informing user about guidelines identification verifying evidences including signed request 4.3 Certificate Issuance *** and **: formally ***: verify relation between public key and future owner of certificate *: certificate-reply Bundesamt für Sicherheit in der Informationstechnik 33

34 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Policy Element PRISv2 V-PKI Comparison Result 4.4 Certificate Acceptance *** with confirmation 4.5 Key Pair and Certificate Usage ** with confirmation, it is possible to define a period within the user has to reject the certificate after deliverance otherwise it will be implicitly marked as accepted * date of delivery only for one specific trust service, either authentication, signature or confidentiality confirmation within 5 working days authentication, encryption and signature 4.6 Certificate Renewal no certificate renewal without re-keying no certificate renewal without re-keying 4.7 Certificate Re-key reasons: expired, revocation automatic or demanded by owner 4.8 Certificate Modification not allowed not mentioned 4.9 Certificate Revocation and Suspension reasons: purpose of certificate, wrong usage, compromise of key, CA certificate revoked, an error occurred during the registration process concerned parties have to be informed certificate owners have to demand for revocation at once, if one case has arrived revocation demands with high priority have to be handled without delay the information about revocation has at least to be published in CRL it is recommended not to publish the reasons for revocation renew certificate by digital signed extension request reasons for obligatory revocation: notice of cancellation, request for revocation without stating the reason, compromise of key reasons for optional revocation: contained data no longer up to date, used algorithm seems to be weak, used hardware seems to be insecure, Ca does not satisfy obligations revocation at once after receipt of request, at least the next working day the information about revocation has to be published in CRL at once Bundesamt für Sicherheit in der Informationstechnik 34

35 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» v2 (PRISv2)» Policy Element PRISv2 V-PKI Comparison Result 4.12 Key Escrow and Recovery 5 Facility, Management, and Operational Controls authentication and signature: key escrow forbidden encryption: key escrow allowed detailed information about: physical controls procedural controls (roles) personnel controls audit logging procedures records archival key changeover termination of a CA or RA not supported (or, depending on interpretation) Root-CA has to fix in operational concept the process of documentation, backup, logging and recovery process of termination of CA further measures for Facility, Management and Operational Controls have to be declared in SP 6 Technical Security Controls detailed information about: 7 Certificate, CRL, and OCSP Profiles key generation (*** and ** supervised at least by 2 persons) private keys may not be archived management of key pairs (lifetime 1 to 3 years for EE keys, up to 10 years for CA keys) synchronization requirements on time stamping services detailed information in separate document (see comparison of certificate profiles with ISIS-MTT before) key generation in proper secure way algorithms according to BSIrecommendation are mandatory private key according to securityconcept archived detailed information in separate document Bundesamt für Sicherheit in der Informationstechnik 35

36 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Policy Element PRISv2 V-PKI Comparison Result 8 Compliance Audit and Other Assessment 9 Other Business and legal matters Validity Periods several rules, mostly defined in a separate document on the instantiation of certain variables mostly out of scope of PRIS except confidentiality guarantees 1 to 3 years for EE keys at most 10 years for CA not mentioned not mentioned Root certificate 5 years CA certificate 4 years User certificate 3 years SSL-Server certificates 1 year Key Change not mentioned Root-CA creates annually a new certificate because of validity Table 6: Comparison chart of PRISv2 PC types and V-PKI policy requirements ETSI TS In many respects, the PRISv2 policy types are a concrete implementation of the ETSI policy requirements ([34]). This is not surprising, since an earlier version of ETSI TS is one of the base standards of PRISv2. While the ETSI policy requirements often only say that there should be appropriate procedures defined, PRISv2 describes these procedures in detail. The requirements for revocation of a certificate are very typical in that respect. Another example are the required technical controls for key generation which are rather similar: Both standards refer to Common Criteria evaluated devices, however the PRISv2 requirements are more detailed and do exactly define the different roles during that process. Similar to the PRISv2 * to ***, ETSI TS supports the notion of different security levels (termed levels of service in [34]) by defining a Lightweight Certificate Policy (LCP), Normalized Certificate Policy (NCP) and Extended Normalized Certificate Policy (NCP+). Bundesamt für Sicherheit in der Informationstechnik 36

37 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» v2 (PRISv2)» In practice, the comparison of PRISv2 ant ETSI TS is somewhat cumbersome, because the ETSI standard is not structured according to RFC There is a cross reference given in the annex of TS , however this has apparently been added retroactively, so that the referenced sections often do not cover the respective issues concisely. Policy Element PRISv2 ETSI TS Comparison Result 1.4 Usage of Certificates Authentication or Encryption or Digital signature (only one of these purposes, declaration required) 2.1 Directories CA has to provide a directory and certificate status service (CRL and optionally additional OCSP) no constraints CA shall ensure that certificates are made available as necessary to subscribers, subjects and relying parties 2.2 Publication of certification information 2.3 Time or frequency of publication 2.4 Access controls on repositories At least CP, CRL, root certificate CP and CRL or online certificate status CP up-to-date, CRL mentioned in chapter 4.9 ***: strong access control **: strong access control for certificate state information, password otherwise *: password based NCP: CRL 24 h after revocation LCP: CRL 72 h after revocation CA system access is limited to properly authorized individuals Bundesamt für Sicherheit in der Informationstechnik 37

38 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Policy Element PRISv2 ETSI TS Comparison Result 3.1 Naming X.501 pseudonym and anonym has to be marked for members of enterprises or administration, the SIREN number must be included DN has to be well-defined within the domain certificate objects may not be anonym 3.2 Initial Identity Validation detailed instructions for the initial check, including written form, distinguished in enterprise-, government- and private certificates 3.3 I&A for Re-key Requests regular renewal in proper way 3.4 I&A for Revocation Requests after Revocation process is identical to initial identification ***: formal verification (e.g. signature or 4-5 questions) ** : formal verification (e.g. 3-4 questions) *: verification due to basic information DN has to be well-defined within the domain due to national laws signed agreement amongst others about: subscriber s obligations consent to subscribing data storage after Revocation process is identical to initial identification procedures have to be defined in CPS request shall be authenticated (almost ) Bundesamt für Sicherheit in der Informationstechnik 38

39 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» v2 (PRISv2)» Policy Element PRISv2 ETSI TS Comparison Result 4.1 Certificate Application has to be made by future owner, 4.2 Certificate Application Processing information provided: name, public key, identification documents Additional information for encryption only: demand for administration of the private key if available identification verifying evidences informing user about guidelines 4.3 Certificate Issuance *** and **: formally ***: verify relation between public key and future owner of certificate *: via 4.4 Certificate Acceptance *** with confirmation 4.5 Key Pair and Certificate Usage ** with confirmation, it is possible to define a period within the user has to reject the certificate after deliverance otherwise it will be implicitly marked as accepted * date of delivery only for one specific trust service, either authentication, signature or confidentiality has to be made by subscriber or subject Information provided: full name, date and place of birth, public key for entities or legal persons: existing registration information not precisely mentioned securely linked to the associated registration signed confirmation that the information held in the certificate is correct, but no explicit confirmation of receipt guidelines for usage have to be provided limitations have to be followed [NCP+] usage only with secure user devices for *: Bundesamt für Sicherheit in der Informationstechnik 39

40 Comparison of «ISIS-MTT 1.1» and «Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2)» Policy Element PRISv2 ETSI TS Comparison Result 4.6 Certificate Renewal no certificate renewal without re-keying renewal allowed, if relevant attributes have changed and the previously certified key is still considered to be secure 4.7 Certificate Re-key reasons: expired, revocation automatic or demanded by owner CA may offer service for renewal 4.8 Certificate Modification not allowed if relevant attributes have changed 4.9 Certificate Revocation and Suspension 4.12 Key Escrow and Recovery reasons: purpose of certificate, wrong usage, compromise of key, CA certificate revoked, an error occurred during the registration process concerned parties have to be informed certificate owners have to demand for revocation at once, if one case has arrived revocation demands with high priority have to be handled without delay the information about revocation has at least to be published in CRL it is recommended not to publish the reasons for revocation authentication and signature: key escrow forbidden encryption: key escrow allowed subject and subscriber shall be informed for signature forbidden, otherwise allowed Bundesamt für Sicherheit in der Informationstechnik 40