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


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.





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





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.




***

**

*

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.


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.





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



applications roughly comparable to the German SAGA document [39], will be considered in the survey of base standards below.


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)



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.



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




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



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.


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.



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




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: )




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



3.2.2 EE-Certificates


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




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



3.2.3 CRL-Profile


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



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



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


e-mail certificates must contain e-mail-address


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




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




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




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




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


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




8 Compliance Audit and Other Assessment

several rules, mostly defined in a separate document on the instantiation of certain variables

should be proper


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



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.


V-PKI

Comparison Result


or

Encryption

or

Digital signature


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



CRL up-to-date, at least weekly publication




*: password based

not mentioned



Policy Element PRISv2 V-PKI Comparison Result

3.1 Naming X.501





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

for ***:

** and *:


after revocation process is identical to initial identification

regular renewal with digitally signed request

after revocation process is identical to initial identification








several possibilities: by telephone with password by fax with password mail signed e-mail

for ***:

** and *:




CA has to apply at root-CA with: security policy self-declaration extract of commercial register declaration that no insolvency proceedings are in progress


identification

verifying evidences


identification

verifying evidences including signed request



*: E-Mail

certificate-reply






* date of delivery

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


renew certificate by digital signed extension request

4.8 Certificate Modification not allowed not mentioned 4.9 Certificate Revocation and Suspension



certificate owners have to demand for revocation at once, if one case has arrived




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







not supported (or , depending on interpretation)



physical controls


personnel controls


records archival

key changeover


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






key generation in proper secure way

algorithms according to BSI-recommendation are mandatory

private key according to security-concept archived



detailed information in separate document




8 Compliance Audit and Other Assessment


not mentioned



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+).



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.


ETSI TS 102 042

Comparison Result


or

Encryption

or

Digital signature


no constraints


CA shall ensure that certificates are made available as necessary to subscribers, subjects and relying parties


At least CP, CRL , root certificate CP and CRL or online certificate status



NCP: CRL 24 h after revocation LCP: CRL 72 h after revocation




*: password based

CA system access is limited to properly authorized individuals



Policy Element PRISv2 ETSI TS 102 042 Comparison Result

3.1 Naming X.501







due to national laws

signed agreement amongst others about: subscriber’s obligations consent to subscribing data storage




(almost )





procedures have to be defined in CPS

request shall be authenticated







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


identification

verifying evidences


not precisely mentioned



*: via E-Mail

securely linked to the associated registration



* date of delivery

signed confirmation that the information held in the certificate is correct, but no explicit confirmation of receipt

for *:



guidelines for usage have to be provided

limitations have to be followed

[NCP+] usage only with secure user devices




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


CA may offer service for renewal

4.8 Certificate Modification not allowed if relevant attributes have changed 4.9 Certificate Revocation and Suspension



certificate owners have to demand for revocation at once, if one case has arrived




subject and subscriber shall be informed




for signature forbidden, otherwise allowed






physical controls


personnel controls


records archival

key changeover


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 )






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






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


short instructions and rules, most often reference to CWA 14172



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




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



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.



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:


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



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


restrictions have to be declared

simultaneous assertion of digitalSignature and contentCommitment (nonRepudiation) key usage flags permitted



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


parison of « ISIS-MTT 1.1 » and « Politique de Référencement Intersectorielle de Sécurité v2 (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


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




[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


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




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