Comparison of « ISIS-MTT 1.1 » and « Politique de ...
Transcript of Comparison of « ISIS-MTT 1.1 » and « Politique de ...
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) » Report
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 2
Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: 0228 99 9582 0 +49 228 99 9582-0 E-Mail: [email protected] Internet: http://www.bsi.bund.de © Bundesamt für Sicherheit in der Informationstechnik 2006
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
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
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 7
2.1 Approach of PRISv2 7
2.2 Approach of ISIS-MTT 9
2.3 Other relevant Standards and Policies 10
2.4 Referenced Base Standards of PRISv2 and ISIS-MTT 12
2.5 Conclusion of the general comparison 16
3. Detailed Comparison 17
3.1 Classification of Comparison Results 17
3.2 Comparison of Certificate and CRL Profiles 18
3.2.1 CA-Certificates 18 3.2.2 EE-Certificates 21 3.2.3 CRL-Profile 23 3.3 Comparison of Certificate Policies 24
3.3.1 European Bridge CA 24 3.3.2 V-PKI 31 3.3.3 ETSI TS 102 042 36 3.3.4 EBGCA 44
4. References 49
5. Acronyms and important Vocabularies in PRISv2 51
5.1 Acronyms 51
5.2 Vocabularies 52
Bundesamt für Sicherheit in der Informationstechnik 5
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
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
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 8
***
**
*
Secu
rity
Leve
ls
Trust ServicesAuthent. Signature Confident. Timestamp others
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.
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
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 10
Trust ServicesAuthent. Signature Confident. Timestamp others
Interoperability Areas
Cert.Profile
Cert. Mgt.
Message
Formats
Protocols
(LDAP, ...)
Token API
& others
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 102 042) 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
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 11
applications roughly comparable to the German SAGA document [39], will be considered in the survey of base standards below.
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
Base Standards used in wider context in France or Germany
Documentation of Certificate Policies RFC 3647 n/a Germany:
RFC 2527 (V-PKI)
RFC 3647 (EB-CA)
Europe:
RFC 2527 (EBGCA)
RFC 3647 (EBGCA, ETSI TS 102 042,)
Operation guidelines and regulations for Trust Service Providers
ETSI TS 102 042 v1.1.1
CWA 14167-1
CWA 14167-2
CWA 14167-4
PC2 v2.2
N° 972-1/SGDN/DCSSI
ISO/IEC 15408
n/a Europe:
ETSI TS 101 456 (EBGCA)
ETSI TS 102 042 (EBGCA)
CWA 14167-1 (ETSI TS 102 042)
CWA 14167-2 (ETSI TS 102 042)
CWA 14167-3 (ETSI TS 102 042)
CWA 14167-4 (ETSI TS 102 042)
ISO/IEC 15408 (ETSI TS 102 042)
FIPS PUB 140-1 (ETSI TS 102 042)
FIPS PUB 140-2 (ETSI TS 102 042)
Bundesamt für Sicherheit in der Informationstechnik 12
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 N° 1591/SGDNDCSSI/SDR
N° 1549/SGDN/DCSSI/SDR
n/a
Certificate and CRL Format X.509v3
RFC 3280
RFC 3739
ETSI TS 101 862 v1.2.1
ETSI TS 102 280 v1.1.1
X.509 (1997)
RFC 3280
RFC 3281
RFC 3039 RFC 37391
ETSI TS 101 862 v1.3.0
ETSI TS 102 280 v0.1.1
Certificate Management RFC 2797
RFC 2630
RFC 2511
RFC 2314
RFC 2315
RFC 2633
France (CCI):
RFC 2510
RFC 2511
Exchange Format for Files RFC 3369
RFC 2634
TS 101 733 v1.4.0
1 To be precise, the preceding Internet draft “draft-ietf-pkix-sonof3039-04” is referenced.
Bundesamt für Sicherheit in der Informationstechnik 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
Exchange Format for E-Mail RFC 2633
RFC 3369
RFC 2634
TS 101 733 v1.4.0
France (CCI):
RFC 2632 - 2634
RFC 3369
RFC 3370
Exchange Format for XML-Documents REC-xmldsig-core-20020212
REC-xmlenc-core-20021210
ETSI TS 101 903 v1.1.1
France (CCI):
REC-xmldsig-core-20020212
RFC 2807
RFC 3275
REC-xmlenc-core-20021210
Directory Access RFC 2251 (with elements of RFC 1777)
RFC 2256
RFC 2587
France (CCI):
RFC 2251 – 2256
RFC 2585
RFC 2587
Online Status Validation RFC 2560 RFC 2560
draft-ietf-pkix-ocspv2-02
Time Stamping (PRISv2 documents on time stamping are yet to be published)
RFC 3161
ETSI TS 101 861 v1.2.1
Bundesamt für Sicherheit in der Informationstechnik 14
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 15
Technical Area PRISv2 Base Standards
ISIS-MTT 1.1 Base Standards
Base Standards used in wider context in France or Germany
Cryptographic Algorithms and associated Data Formats
PKCS#1 v2.1
RFC 3279
N°1064 SGDN/DCSSI/SDS/AsTeC
RFC 3279
PKCS#1 v1.5 PKCS#1 v2.0
RFC 2104
FIPS-186-2
FIPS-180-2
FIPS-197
ANSI X9.52
(and others)
Germany:
Declaration on appropriate algorithms for electronic signatures ([37]; annually published by RegTP/BNetzA;, developed with assistance of BSI)
Cryptographic Token Interface PKCS#11 v2.01 (eventually to be replaced by PKCS#11 v2.11)
France (CCI):
ISO 7816
Table 1: Base standards referenced in PRISc2 and ISIS-MTT 1.1
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 16
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 same2.
Trust ServicesAuthent. Signature Confident. Timestamp others
Interoperability Areas
Cert.Profile
Cert. Mgt.
Message
Formats
Protocols
(LDAP, ...)
Token API
& others
***
**
*
Secu
rity
Leve
ls
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.
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 102 042 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
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 http://www.signaturbuendnis.de/ 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.
3.2.1 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
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 102 280 (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
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
(expected to become )
Issuer Unique ID/Subject Unique ID forbidden forbidden
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
(in practice probably: )
Bundesamt für Sicherheit in der Informationstechnik 19
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 mandatory, critical, must comply with RFC 3739
optional, optionally critical but recommended non-critical
Subject Alternative Names optional, non-critical, must comply with RFC 3739
optional, optionally critical, FTP-/HTTP-/ LDAP-URLs
Issuer Alternative Names like SubjectAltNames like Subject Alternative Names CRL Distribution Points optional, non-critical,
must comply with TS 102 280 (HTTP- or LDAP-URL required)
optional, optionally critical,
LDAP-URL mandatory and more stipulations
Authority Info Access mandatory for OCSP, non-critical, must comply with RFC2560
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
optional, optionally critical, statements from RFC 3739 and TS 101 862 allowed
(or , depending on interpretation of PRISv2)
OCSP No Check optional, non-critical as in RFC 3280
or optional, optionally critical as in RFC 2560
optional, optionally critical (or , depending on interpretation of PRISv2)
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
Bundesamt für Sicherheit in der Informationstechnik 20
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) » v2 (PRISv2) »
3.2.2 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
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 optional, non-critical, must comply
with RFC 3739 optional, non-critical, PrintableString allowed,
use of ISIS-MTT defined attribute nameAtBirth permitted
CRL Distribution Points
as for CA certificates as for CA certificates
Freshest CRL mandatory for delta-CRLs, non-critical, must comply with TS 102 280
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
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) » v2 (PRISv2) »
3.2.3 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
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 3647. Nevertheless the authors of policy documents do sometimes present rather different issues and regulations under the same topic of the overall structure.
3.3.1 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)
declaration required
not for signing certificates (except of CA-Certificates)
2.1 Directories CA has to provide a directory and certificate status service (CRL and optionally additional OCSP)
CA has to provide a CRL
CA should provide a directory
Bundesamt für Sicherheit in der Informationstechnik 24
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
At least CP, CRL , root certificate CP and root certificate (in combination with 2.1: )
2.3 Time or frequency of publication
CP up-to-date, CRL mentioned in chapter 4.9
CRL immediately, Changes in CP are to be provided to members before publication
2.4 Access controls on repositories
***: strong access control
**: strong access control for certificate state information, password otherwise
*: password based
access control in proper form
for *:
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
X.501
pseudonym and anonym has to be marked
e-mail certificates must contain e-mail-address
DN has to be well-defined within the domain
3.2 Initial Identity Validation detailed instructions for the initial check, including written form, distinguished in enterprise-, government- and private certificates
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 e-mail may not be unverified
requirements of integrity, authentication and confidentiality of Trusted Services have to be checked
Bundesamt für Sicherheit in der Informationstechnik 25
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
after Revocation process is identical to initial identification
after revocation reliable process for identification
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
reliable verification
for *:
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
should support identification of applicant and has to document the process,
registry process has to be documented
4.2 Certificate Application Processing
identification
verifying evidences
informing user about guidelines
identification
documentation
4.3 Certificate Issuance *** and **: formally
***: verify relation between public key and future owner of certificate
*: via E-Mail
distribution only for accepted demands
documented process
Bundesamt für Sicherheit in der Informationstechnik 26
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
** 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
publication within CA
Defined process for receipt according to security policy
4.5 Key Pair and Certificate Usage
only for one specific trust service, either authentication, signature or confidentiality
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
relation between owner and private key must stay constant
well-defined process
publication after renewal
4.7 Certificate Re-key reasons: expired, revocation
automatic or demanded by owner
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, e-mail address changed
documentation
publication
Bundesamt für Sicherheit in der Informationstechnik 27
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
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
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
4.12 Key Escrow and Recovery
for encryption only:
authentication and signature: key escrow forbidden
encryption: key escrow allowed
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
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:
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
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
7 Certificate, CRL, and OCSP Profiles
detailed information in separate document (see comparison of certificate profiles with ISIS-MTT before)
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
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
several rules, mostly defined in a separate document on the instantiation of certain variables
should be proper
no further information considering the subsections of chapter 8
9 Other Business and legal matters
mostly out of scope of PRIS except
confidentiality
guarantees
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
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) » v2 (PRISv2) »
3.3.2 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)
Encryption
Authentication
Advanced digital signature
(simultaneous use permitted)
2.1 Directories CA has to provide a directory and certificate status service (CRL and optionally additional OCSP)
Root-CA has to provide a CRL
Root-CA has to provide a directory
2.2 Publication of certification information
At least CP, CRL , root certificate CP, CRL and root certificate
2.3 Time or frequency of publication
CP up-to-date, CRL mentioned in chapter 4.9
CRL up-to-date, at least weekly publication
2.4 Access controls on repositories
***: strong access control
**: strong access control for certificate state information, password otherwise
*: password based
not mentioned
Bundesamt für Sicherheit in der Informationstechnik 31
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
defined in separate VPKI-document [33], in accordance to X.509
3.2 Initial Identity Validation detailed instructions for the initial check, including written form, distinguished in enterprise-, government- and private certificates
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
for ***:
** and *:
3.3 I&A for Re-key Requests regular renewal in proper way
after revocation process is identical to initial identification
regular renewal with digitally signed request
after revocation process is identical to initial identification
Bundesamt für Sicherheit in der Informationstechnik 32
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
several possibilities: by telephone with password by fax with password mail signed e-mail
for ***:
** and *:
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
CA has to apply at root-CA with: security policy self-declaration extract of commercial register declaration that no insolvency proceedings are in progress
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
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
** 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
confirmation within 5 working days
4.5 Key Pair and Certificate Usage
only for one specific trust service, either authentication, signature or confidentiality
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
renew certificate by digital signed extension request
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
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
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
authentication and signature: key escrow forbidden
encryption: key escrow allowed
not supported (or , depending on interpretation)
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
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:
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
key generation in proper secure way
algorithms according to BSI-recommendation are mandatory
private key according to security-concept archived
7 Certificate, CRL, and OCSP Profiles
detailed information in separate document (see comparison of certificate profiles with ISIS-MTT before)
detailed information in separate document
Bundesamt für Sicherheit in der Informationstechnik 35
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
several rules, mostly defined in a separate document on the instantiation of certain variables
not mentioned
9 Other Business and legal matters
mostly out of scope of PRIS except
confidentiality
guarantees
not mentioned
Validity Periods 1 to 3 years for EE keys
at most 10 years for CA
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
3.3.3 ETSI TS 102 042
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 102 042 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 102 042 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
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 102 042 is somewhat cumbersome, because the ETSI standard is not structured according to RFC 3647. There is a cross reference given in the annex of TS 102 042, 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 102 042
Comparison Result
1.4 Usage of Certificates Authentication
or
Encryption
or
Digital signature
(only one of these purposes, declaration required)
no constraints
2.1 Directories CA has to provide a directory and certificate status service (CRL and optionally additional OCSP)
CA shall ensure that certificates are made available as necessary to subscribers, subjects and relying parties
2.2 Publication of certification information
At least CP, CRL , root certificate CP and CRL or online certificate status
2.3 Time or frequency of publication
CP up-to-date, CRL mentioned in chapter 4.9
NCP: CRL 24 h after revocation LCP: CRL 72 h after revocation
2.4 Access controls on repositories
***: strong access control
**: strong access control for certificate state information, password otherwise
*: password based
CA system access is limited to properly authorized individuals
Bundesamt für Sicherheit in der Informationstechnik 37
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) »
Policy Element PRISv2 ETSI TS 102 042 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
DN has to be well-defined within the domain
3.2 Initial Identity Validation detailed instructions for the initial check, including written form, distinguished in enterprise-, government- and private certificates
due to national laws
signed agreement amongst others about: subscriber’s obligations consent to subscribing data storage
3.3 I&A for Re-key Requests regular renewal in proper way
after Revocation process is identical to initial identification
after Revocation process is identical to initial identification
(almost )
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
procedures have to be defined in CPS
request shall be authenticated
Bundesamt für Sicherheit in der Informationstechnik 38
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 102 042 Comparison Result
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
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
4.2 Certificate Application Processing
identification
verifying evidences
informing user about guidelines
not precisely mentioned
4.3 Certificate Issuance *** and **: formally
***: verify relation between public key and future owner of certificate
*: via E-Mail
securely linked to the associated registration
4.4 Certificate Acceptance *** with confirmation
** 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
signed confirmation that the information held in the certificate is correct, but no explicit confirmation of receipt
for *:
4.5 Key Pair and Certificate Usage
only for one specific trust service, either authentication, signature or confidentiality
guidelines for usage have to be provided
limitations have to be followed
[NCP+] usage only with secure user devices
Bundesamt für Sicherheit in der Informationstechnik 39
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) »
Policy Element PRISv2 ETSI TS 102 042 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
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
subject and subscriber shall be informed
4.12 Key Escrow and Recovery
authentication and signature: key escrow forbidden
encryption: key escrow allowed
for signature forbidden, otherwise allowed
Bundesamt für Sicherheit in der Informationstechnik 40
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 102 042 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
CA shall ensure that administrative an management procedures correspond to recognized standards
further information about: personnel controls (expert knowledge, disciplinary sanctions for violation), security roles physical controls(limited access, avoid loss, damage and compromise) operational controls (systems have to be secure and correctly operated)’termination of CA documentation and recording
(almost )
6 Technical Security Controls detailed information about:
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
key generation in controlled circumstances, at least dual control, used algorithm shall be recognized by industry as being fit
suitable time before expiration of certificate CA should generate new key
storage and archiving allowed, if environment physically secured
lifetime of keys appropriate to used algorithms
Bundesamt für Sicherheit in der Informationstechnik 41
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) »
Policy Element PRISv2 ETSI TS 102 042 Comparison Result
7 Certificate, CRL, and OCSP Profiles
detailed information in separate document (see comparison of certificate profiles with ISIS-MTT before)
certificates shall include: identification of CA and a country subject or pseudonym provision for a specific attribute of the signatory to be included if relevant public key validity serial number electronic signature of CA limitations on the scope of use limits on the value of transactions
8 Compliance Audit and Other Assessments
several rules, mostly defined in a separate document on the instantiation of certain variables
short instructions and rules, most often reference to CWA 14172
9 Other Business and legal matters
mostly out of scope of PRIS except
confidentiality
guarantees
mostly out of scope except
financial responsibility
privacy
Certificate practice statement not mentioned structure provided
CA not required to publish all details
Life cycle management of cryptographic hardware
not mentioned CA shall ensure:
not tampered with during shipment
not tampered with while stored
controlled by two trusted employees
functioning correctly
private keys stored are destroyed upon device retirement
Bundesamt für Sicherheit in der Informationstechnik 42
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 102 042 Comparison Result
Secure user device preparation
not mentioned NCP+: The CA shall ensure that if it issues to the subject secure user device this is carried out securely
Table 7: Comparison chart of PRISv2 PC types and ETSI TS 102 042 policy requirements
Bundesamt für Sicherheit in der Informationstechnik 43
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) »
3.3.4 EBGCA
The EBGCA is the bridge CA for the IDA (Interchange of Data between Administrations) programme of the EU. Its CPS ([35]) governs the provision of certificates within EBGCA itself, i.e. for signing trust service lists and secure communications within the project. It is therefore only of marginal interest for the comparison at hand.
The remarks below refer to the EBGCA CP recommendations document ([36]), which presents an approach for the classification of the policies of EBCGA members. The result of this classification process is intended to be included in the members’ entries in the Trust Service Provider Status List (TSL) that will be issued by EBGCA. The main building blocks of this classification process, which will be described in more detail below, are:
• a set of seven policy categories that can be the result of the classification,
• a “trust matrix” for matching a given policy with the potential policy categories based on a few key criteria and
• a set of requirements and recommendations based on the structure of an extended Policy Disclosure Statement (PDS) of the respective EBGCA member.
The EBGCA policy requirements are directly derived from ETSI TS 101 456 and TS 102 042. The EBGCA recommendations distinguish between seven categories of certificate policies, derived from ETSI TS 101 456 (QCP, QCP Public, QCP+, augmented QCP) and ETSI TS 102 042 (NCP+, NCP, LCP):
• QCP: Qualified Certificate Policy (non-public, private community) • QCP Public: Qualified Certificate Policy, for certificates issues to the public • QCP Public with SSCD (QCP+): Qualified Certificate Policy, for certificates issues to the public, using SSCD • “Augmented” QCP : QCP+ with additional requirements specified by the RFC 3647, which allows easier mapping to international harmonization • NCP+ (NCP with SSCD) : Normalized Certificate Policy, using SSCD • NCP : Normalized Certificate Policy • LCP : Lightweight Certificate Policy
The trust level associated with the LCP category is roughly comparable to PRISv2 *, NCP/NCP+ to ** and QCP to ***.
The trust matrix, as shown in Table 8, defines, on a very generic level, requirements to participant CAs that are to be used as criteria for assigning a given policy to one of the policy categories, which in turn determine the associated trust level.
Bundesamt für Sicherheit in der Informationstechnik 44
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) » v2 (PRISv2) »
Criteria Augm. QCP QCP+ QCP QCP (N-P) NCP+ NCP LCP
ETSI TS OID reference
1456.1.1 1456.1.2 2042.1.2 2042.1.1 2042.1.3
Mandatory Use of SSCD
yet unclear yes yes
Key-Backup forbidden forbidden forbidden forbidden
No Publication of Certificate Status info
yes
No face-to-face registration
yes
Usage not limited to electronic signature
yet unclear yes yes yes
Table 8: EBCGA “Trust Matrix” (cited from annex II of [36], OIDs corrected)
A step-by-step comparison of PRISv2 and EBGCA is difficult, because the EBGCA Policy classification is based on a Policy Disclosure Statement (PDS) document, extended by including topics from the annexes of the EU directive on electronic signatures, items from the RFC 3647 policy framework, and elements of RFC 3739 has mostly formal requirements to policies, in particular a CP has to contain:
Policy Element PRISv2
EBGCA
Comparison Result
1. CA contact info no specific requirements on contact info,
must be documented in specific certification policy
Name of issuing CA (Root / Issuing CA)
Country of Operation
Bundesamt für Sicherheit in der Informationstechnik 45
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) »
Policy Element PRISv2 EBGCA Comparison Result
2.a. Claimed certificate type and usage
One of the three security levels *, ** or ***
One of the seven categories explained above; other levels of assurance can be aligned with this list
2.b. Subject/entity validation procedures
detailed instructions for the initial check, including written form, distinguished in enterprise-, government- and private certificates
Identification :
Physical Identification (Direct, face-to-face) or
Using means acquired though direct Physical Identification or
E-mail validation or
Others :
Validation of Identity information :
Based on external source with legal value or
Based on external source without official legal value or
Other external sources or
Own declaration of subject
3.a. Certificate usage Authentication
or
Encryption
or
Digital signature
(only one of these purposes, declaration required)
restrictions have to be declared
simultaneous assertion of digitalSignature and contentCommitment (nonRepudiation) key usage flags permitted
Bundesamt für Sicherheit in der Informationstechnik 46
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) » v2 (PRISv2) »
Policy Element PRISv2 EBGCA Comparison Result
3.b. Reliance Limits permitted and prohibited applications directly derived from certificate usage
declaration of allowed and not allowed applications
declaration of retaining period (less then 30 years, 30 years or longer then 30 years)
4.a. Obligations of subscribers, formal
Subscriber obligations to be declared in issuance confirmation (***), in the specific certification policy or in a subscriber contract (** and *),
several requirements in different parts of the policy type document
must be documented, no specific requirements
4.b. Obligations of subscribers, technical
subscribers must use evaluated devices (*** and **) or CA must check for the use of secure devices or inform subscribers clearly about suitable devices (*)
must be properly declared
for SSCD devices, specify the level of evaluation
5. Certificate status checking obligations of relying parties
relying parties should check certificate status – the means to use is at their discretion
relying party shall:
- check validity of certificate using (Web-site, CRL via HTTP or LDAP or OCSP)
- take account of usage limitations
- other precautions (if applicable)
6. Limited warranty and disclaimer/Limitation of liability
no specific requirements must be declared
amount in €
7. Applicable agreements, CPS, CP, …
there has to be a specific CP repository available via HTTP
URL should be included in certificates
Bundesamt für Sicherheit in der Informationstechnik 47
parison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) »
Bundesamt für Sicherheit in der Informationstechnik 48
Policy Element PRISv2
EBGCA
Comparison Result
8. Privacy Policy no specific requirements, French trust service providers must adhere to French privacy legislation
must be documented, no specific requirements
9. Refund Policy no specific requirements must be documented, no specific requirements
10. Applicable law, complaints and dispute resolution
French legislation is applicable for French TSPs
no specific requirements on dispute resolution
Contact-details and procedure for complaints and dispute resolution (URL)
11. CA and repository licenses, trust marks and audit
not directly mentioned
indirectly, approval of a trust service according to PRISv2 is kind of a license or trust mark
Accreditation/Supervision as Qualified CA or
Licenses or Seals according to other schemes / standards or
other independent audits
Table 9: Comparison chart of PRISv2 PC types and EBGCS policy recommendations
Com
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) »
4. References
[1] ADAE/DCSSI: PRIS – Note de cadrage de la politique de référencement intersectorielle de sécurité, Version Projet v2, 15/06/2004
[2] ADAE/DCSSI: PRIS – Préambule, Version Projet v2, 15/06/2004.
[3] ADAE/DCSSI: PRIS – Politiques de Certification Types - Variables de temps, Version Projet v2 0.4, 30/09/2004
[4] ADAE/DCSSI: PRIS – Politiques de Certification Types - Profils de certificats, de LCR et OCSP, Version Projet v2 0.5, 12/10/2004
[5] ADAE/DCSSI: PRIS – Service d'Authentification - Politique de Certification Type, Version Projet v2 0.5, 27/09/2004
[6] ADAE/DCSSI: PRIS – Service de confiance "Confidentialité" - Présentation du service, Version Projet v2 0.1-D01, 14/02/2005
[7] ADAE/DCSSI: PRIS – Service de Confidentialité - Politique de Certification Type, Version Projet v2 0.1-D01, 14/02/2005
[8] ADAE/DCSSI: PRIS – Note de cadrage de la politique de référencement intersectorielle de sécurité, Version v2.0, 01/06/2005, OID 1.2.250.1.137.2.2.1.2.1.2
[9] ADAE/DCSSI: PRIS – Préambule, Version v2.0, 01/06/2005, OID 1.2.250.1.137.2.2.1.2.1.1
[10] ADAE/DCSSI: PRIS – Politiques de Certification Types - Variables de temps, Version v2.0, 01/06/2005, OID 1.2.250.1.137.2.2.1.2.1.3
[11] ADAE/DCSSI: PRIS – Politiques de Certification Types - Profils de certificats / LCR / OCSP et algorithmes cryptographiques, Version v0.8, 01/06/2005, OID 1.2.250.1.137.2.2.1.2.1.4
[12] ADAE/DCSSI: PRIS – Service de confiance "Authentification", Version v2.0, 01/06/2005, OID 1.2.250.1.137.2.2.1.2.1.5
[13] ADAE/DCSSI: PRIS – Service d'Authentification - Politique de Certification Type, Version v2.0, 01/06/2005, OID 1.2.250.1.137.2.2.1.2.2.1
[14] ADAE/DCSSI: PRIS – Service de confiance "Signature", Version v2.0, 01/06/2005, OID 1.2.250.1.137.2.2.1.2.1.6
[15] ADAE/DCSSI: PRIS – Service de Signature - Politique de Certification Type, Version v2.0, 01/06/2005, OID 1.2.250.1.137.2.2.1.2.2.2
[16] ADAE/DCSSI: PRIS – Service de confiance "Confidentialité", Version v2.0, 01/06/2005, OID 1.2.250.1.137.2.2.1.2.1.7
[17] ADAE/DCSSI: PRIS – Service de Confidentialité - Politique de Certification Type, Version v2.0, 01/06/2005, OID 1.2.250.1.137.2.2.1.2.2.3
[18] TeleTrusT/T7: ISIS-MTT Specification - Introduction, Version 1.1, 16 March 2004
[19] TeleTrusT/T7: ISIS-MTT Specification – Part 1: Certificate and CRL Profiles, Version 1.1, 16 March 2004
[20] TeleTrusT/T7: ISIS-MTT Specification – Part 2: PKI Management, Version 1.1, 16 March 2004
[21] TeleTrusT/T7: ISIS-MTT Specification – Part 3: Message Formats, Version 1.1, 16 March 2004
[22] TeleTrusT/T7: ISIS-MTT Specification – Part 4: Operational Protocols, Version 1.1, 16 March 2004
[23] TeleTrusT/T7: ISIS-MTT Specification – Part 5: Message Formats, Version 1.1, 16 March 2004
[24] TeleTrusT/T7: ISIS-MTT Specification – Part 6: Cryptographic Algorithms, Version 1.1, 16 March 2004
Bundesamt für Sicherheit in der Informationstechnik 49
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 50
[25] TeleTrusT/T7: ISIS-MTT Specification – Part 7: Cryptographic Token Interface, Version 1.1, 16 March 2004
[26] TeleTrusT/T7: ISIS-MTT Specification – Part 8: XML Signature and Encryption Profile, Version 1.1, 16 March 2004
[27] TeleTrusT/T7: ISIS-MTT Specification – Optional Profile: SigG Profile, Version 1.1, 16 March 2004
[28] TeleTrusT/T7: ISIS-MTT Specification – Optional Profile: Optional Enhancements to the SigG Profile, Version 1.1, 16 March 2004
[29] Signaturbündnis: ISIS-MTT 1.1 / PRISv2 – Vergleich der Zertifikats- und Sperrlistenprofile, Version 0.9, 10.03.2005
[30] TeleTrusT: Zertifikatsrichtlinie für Mitglieder der European Bridge-CA, Entwurf Version 0.97b , 30.06.2005
[31] TeleTrusT: Zertifikatsrichtlinie für Mitglieder der European Bridge-CA, Entwurf Version 0.97f , 21.07.2005
[32] BSI: V-PKI – Sicherheitsleitlinien der Wurzelzertifizierungsinstanz der Verwaltung, Version 3.2, 09.01.2003
[33] BSI: V-PKI – Namensregeln und -formate, Version 1.3, 25.11.2002
[34] ETSI ESI: TS 102 042 – Policy requirements for certification authorities issuing public key certificates, V1.2.2, 2005-06
[35] Certipost: European Bridge/Gateway CA Pilot – Certification Practice Statement, Draft V1.0, 11-01-05
[36] Certipost: European Bridge/Gateway CA Pilot – CP Recommendations & Trust Matrix, Draft V1.0, 12-01-05
[37] Entwurf: Geeignete Algorithmen zur Erfüllung der Anforderungen nach § 17 Abs. 1 bis 3 SigG vom 22. Mai 2001 in Verbindung mit Anlage 1 Abschnitt I Nr. 2 SigV vom 22. November 2001, Bonn, 10.08.2004
[38] ADAE: CCI – Le cadre commun d’interopérabilité des systèmes d’information publics - Dossier d’introduction, Version v2.1, Septembre 2003
[39] KBSt: SAGA – Standards und Architekturen für E-Government-Anwendungen, Version 2.0, Dezember 2003
Comparison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (PRISv2) »
5. Acronyms and important Vocabularies in PRISv2
5.1 Acronyms
Acronym French meaning German (or English) translation or transliteration
AC Autorité de Certification Zertifizierungsstelle (CA)
ADAE Agence pour le Développement de l’Administration Electronique
AE Autorité d'enregistrement Registrierungsstelle (RA)
AFNOR Association Française de Normalisation
AH Autorité d’Horodatage Zeitstempeldienst (Time Stamping Authority, TSA)
CC Critères Communs Common Criteria
CCI Cadre Commun d’Interopérabilité des systèmes d’information publics
CEN Comité Européen de Normalisation
CISSI Commission Interministérielle pour la SSI
DN Distinguished Name
DPC Déclaration des Pratiques de Certification
Certification Practice Statement (CPS)
ETSI Institut Européen des Normes de Télécommunication
FEROS Fiche d'Expression Rationnelle des Objectifs de Sécurité des systèmes d'information
ICG Infrastructure de Gestion de Clés Public-Key Infrastruktur
LAR Liste des certificats d’AC révoqués Sperrliste (ARL)
LCR Liste des certificats révoqués Sperrliste (CRL)
MC Mandataire de certification Zertifizierungsbeauftragter (Erbringer von Registrierungsdienstleistungen innerhalb eines Unternehmens oder einer Behörde im Auftrag der RA)
OC Opérateur de Certification
OID Object Identifier
SGDN / DCSSI
Secrétariat Général de la Défense Nationale / Direction Centrale de la Sécurité des Systèmes d’Information
PC Politique de Certification Certificate Policy
Bundesamt für Sicherheit in der Informationstechnik 51
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 52
Acronym French meaning German (or English) translation or transliteration
PRIS Politique de Référencement Intersectorielle de Sécurité
PSC Prestataire de Service de Certification
Zertifizierungsdiensteanbieter
PSCo Prestataire de Service de Confiance Trustcenter
PSCE Prestataire de Service de Certification électronique
Zertifizierungsdiensteanbieter
PP Profil de Protection Protection Profile
RSA Rivest Shamir Adelman
SP Service de Publication Verzeichnisdienst
SSI Sécurité des Systèmes d’Information Informationssicherheit
URL Unique Resource Locator
5.2 Vocabularies
French German (or English) translation
bi-clé Schlüsselpaar
carte à puce Chipkarte
certificat racine Wurzelzertifikat
dispositif Gerät (Device)
échéance Ablaufdatum, Gültigkeitsdatum
exigence Anforderung
fonction de hachage Hashfunktion
horodatage Zeitstempel
lecteur de carte à puce Chipkartenleser
logiciels Software
pare feu Firewall
personne morale juristische Person
personne physique natürliche Person
porteur Zertifikatsinhaber (Subscriber)
prestation de service Dienstleistung
qualifiants Bezeichner
séquestre de clé Key escrow
utilisateur Relying party