Figure 4 - Staat der Nederlanden G2/G3 naming scheme

For other provisions regarding the way in which identification and authentication take place within PKIoverheid, please refer to the relevant Certification Practice Statements of the PKIoverheid Trust Service Providers.

3.1.2 Need for names to be meaningful

There are no other provisions in this respect for the certificate services by the PA.

3.1.3 Pseudonyms

The use of pseudonyms or anonymous certificates is not permitted.

3.1.4 Rules for interpreting various name forms

The name of the TSP CA that is to be included in the Subject.OrganisationName field of the TSP CA certificate is taken from the extract in the National Trade Register (NHR) ^[6] and entered as an exact match.

3.1.5 Uniqueness of names

All certificates issued under this CPS, contain a unique subject field (DistinguishedName).

3.1.6 Recognition, authentication and role of trademarks

The PA assumes the correctness of the name of organizations as listed in the Dutch Trade Register of the Chamber of Commerce.

3.2 Initial Identity Validation

3.2.1 Initial Registration Process

For the requirements laid down in relation to the initial registration process, see the PKIoverheid Programme of Requirements, part 2.

3.2.2 Authentication of organizational identity

Based on the application form and the evidence that is supplied, the PA verifies,

· That the TSP is an existing organization listed in the National Trade Register (NHR) or an organisational entity that forms part of an existing organization listed in the NHR. If a government organization is not listed in the NHR, the Staatsalmanak^[7] is consulted;

· That the name of the organization and country name registered by the TSP to be incorporated in the certificate are correct and complete and that the applicant is authorised to represent the organization;

· The presence of the relevant registration information of the prospective TSP, with the corresponding evidence (excerpt from the Chamber of Commerce, etc.). The excerpt must be original and must not be older than 13 months.

Note: If the participating party has existed for less than three years and does not appear in the latest version of the registration sources listed above, the identity and validity of the prospective TSP may be established using a parent company or ministry that is registered in the NHR or the Staatsalmanak.

3.2.3 Authentication of individual identity

Upon initial admittance to the PKIoverheid framework, the PA verifies the listed personal data of the authorised representative of the TSP using an identity document issued under art. 1 of the Compulsory Identification Act, limited to the following documents:

· A valid travel document referred to in the Passport Act (Paspoortwet);

· A valid driving licence issued on the basis of the Road Traffic Act (Wegenverkeerswet), under article 107 of the Road Traffic Act (Wegenverkeerswet) 1994.

3.3 Identification and Authentication for Re-key Requests

Often, a TSP is already part of PKIoverheid when a new TSP CA has to be created under a new generation of the regular root. It is also possible that a TSP that is already part of PKIoverheid, wishes to issue certificates under a new domain or a different root. In that case, an abbreviated procedure can be applied for the identification validation, because the TSP CA is already known to the PA and has been admitted to PKIoverheid.

It is then sufficient for the PA to verify whether the organization name and name of the country provided in the Naming document/CSR is still correct. This can be verified as follows:

1. By online consultation of the NHR to verify whether the TSP CA is an existing organization;

2. By online consultation of a database such as Dunn & Bradstreet, which is kept up-to-date and which is considered to be a trustworthy source.

In addition, the PA must verify that the application came from the actual TSP. An application can be submitted in two ways:

1. The authorised representative can send an application form by email and electronically sign this using a PKIoverheid certificate^[8];

2. The authorised representative can sign an application form and send this by post.

In the second case, the registered authorised representative of the TSP CA should also be contacted by the PA to verify the application. For purposes of verification, identifying details of the contact person or organization can be requested.

This identification verification by the PA is recorded and archived in the TSP CA file.

3.4 Identification and Authentication for Revocation Requests

A request for revocation of a certificate can be submitted by the TSP CA. When a request for revocation is made, the reasons for this must always be given. In consultation with the parties involved, it will be examined to what extent the request can be complied with, as revocation of a TSP CA means that the underlying certificates will no longer be valid.

Identification and authentication of the party submitting the request to revoke the TSP CA can take place as follows:

· A request by email to the PA, where the request is signed digitally with a qualified electronic signature;

· A request by signed letter;

In both cases, the PA will contact the authorised representative of the TSP CA by telephone to establish whether the request for revocation is genuine. For purposes of verification, identifying details of the contact person or organization can be requested.

4 Certificate Life-Cycle Operational Requirements

4.1 Scope

Within the PKI for the government, different types of certificates are defined at four levels, which are:

· Root certificate (Staat der Nederlanden Root CA – Gx

· Domain certificate (Staat der Nederlanden Domein <name> - Gx;

· TSP certificate;

· End user certificate.

The root certificate, the domain certificates and the TSP certificates can only be used to verify the issuer's signature and are issued by the Policy Authority. These certificates may not be used for other purposes. The end user certificate is issued by the TSPs.

This CPS relates to the trustworthiness of the Policy Authority's services, therefore this paragraph only covers the procedures relating to root, domain and TSP certificates.

4.2 Certificate Application

The root certificate, the domain certificates and TSP certificates are created by the Policy Authority, at the instruction of the Ministry of the Interior and Kingdom Relations.

The instruction to create TSP CA certificates is by means of a request (PKCS#10) to this end by a TSP. For more information, see PKIoverheid PoR part 2.

For TLS (EV) certificates issued under the PKIoverheid hierarchy by TSP’s, each TSP (issuing CA) has a specific CAA identifier, which can be found in their respective CPS documents. Besides TSP specific CAA records, a CAA issue record with the value “pkioverheid.nl” or “www.pkioverheid.nl” permits issuance for all TSP’s who issue PKIoverheid TLS (EV) certificates.

4.2.1 Methodology with regard to creating certificates

The root certificate, the domain certificates and TSP certificates are created and/or signed during special creation ceremonies. A certified external IT auditor acts as witness during the creation ceremonies of the Staat der Nederlanden Root CA and Staat der Nederlanden <Domain> CA. A certified Webtrust auditor is also present as witness during the signing of the TSP CAs. For every key ceremony, a detailed script is produced which lists all tasks to be carried out. This main purpose of this script is to prevent any input errors during the ceremony. A creation ceremony takes place in accordance with the script in the presence of independent witnesses. The identity of the persons present is verified using the valid documents referred to under article 1 of the Compulsory Identification Act (“Wet op de identificatieplicht”)^[9].

The creation and/or signing key ceremonies take place in a similar manner for all of the listed types of certificates, where the certificate users is either the PA or the TSP. During the ceremony, the following steps take place:

1. building the computer system;

2. installing and configuring the PKI software;

3. activating the Hardware Security Module (HSM), where several shareholders each introduce part of the activation data;

4. generating the key pairs (only applicable to Root and Domain CAs);

5. generating certificates for each key pair;

6. dismantling the computer system and

7. securing the computer system and the critical components.

The Policy Authority does not generate the key pair for a (prospective) TSP but only creates certificates based on a CSR (PKCS10) file supplied by the TSP in a thrustworthy manner

4.3 Certificate Issuance

The requirements which a TSP must fulfil when issuing the certificates are formulated in part 3 (Certificate Policies) of the Programme of Requirements. The way in which a TSP implements these requirements must be defined by the TSP itself in a Certification Practice Statement (CPS). The description of the services by TSPs therefore falls outside the scope of the specification of this CPS.

There is no separate CP for the issuance of certificates by the PA, as the PA does not issue end user certificates. The measures that the PA has taken to guarantee the trustworthiness of the CA certificates to be issued by the PA are described in this CPS.

4.3.1 CA Actions during Certificate Issuance

The Policy Authority only issues CA certificates (excluding certificates used for revocation status services like OCSP). Issuance of any certificate is only possible by human intervention. Chapter 5.2 describes this process in more detail.

4.4 Certificate Acceptance

The script associated with the creation ceremonies also contains the procedure for ascertaining the accuracy and accepting the certificates that are created. Also listed in the script are the names of the people involved. The PA establishes the accuracy of the certificates. The TSP then accepts the TSP certificates.

4.5 Key Pair and Certificate Usage

The Staat der Nederlanden Root CA, Staat der Nederlanden <Domain> CAs and the TSP CAs certificates are primarily used to verify the issuer's signature and are issued by the PA. These certificates are also used for CRL signing and issuance of OCSP signing certificates (G3 hierarchy only). The G2 hierarchy predates the BRG and doesn’t use OCSP services on the root and first intermediate (domain) CA level. These certificates may not be used for other purposes. The end user certificates are issued by the TSPs.

4.6 Certificate Renewal

Certificates have to be renewed when (part of) the information that forms the basis of the certificate changes or is out of date. For example, if the name of a TSP as included in the certificate changes or if the strength of a cryptographic algorithm is deemed insufficient and a stronger cryptographic algorithm is needed.

Certificate Renewal (the process where the existing key pair is maintained and the maximum validity period of a certificate is extended) is not applied within PKIoverheid.

The time of (routine) renewal of certificates is related to the lifecycle of certificates and signing keys. For the relying party, during the term of an end user certificate, it must also be possible to verify the validity of the certificate. When an end user certificate is verified, the validity of the aforementioned certificates of issuing TSPs is also verified. Therefore the TSP certificate, the domain certificate and the root certificate will have to be valid during the course of the validity period of an end user certificate.

Once every five years, the PA will generate new signing keys (for root and domains) and issue new certificates (root certificate and domain certificates). The new signing keys replace the previous versions; the original certificates will continue to exist alongside the new certificates. The original certificates can be used to verify certificates that are issued under the original root.

The signing keys of a TSP have to be renewed at the time at which the lifespan of the parent certificate (TSP certificate, domain certificate or root certificate) expires, minus the term of validity of the end user certificate. Taking this required verification period into account, a TSP has to create new signing keys (or arrange for these to be created) and also submit a request to the PA to create the new TSP certificate.

This request is the first step of the internal procedure of TSP certificate renewal. This procedure broadly comprises the following steps:

· Submission of an application form to renew a TSP CA under the new root by the authorised representative of the TSP;

· Verification of the validity of the request by the PA;

· Validation of the data in the application form;

· Submission of the Naming Document for the new TSP CA certificate by the TSP;

· Verification of the Naming Document by the PA;

· Submission of the Certificate Signing Request (CSR) by TSP for Test TSP CA;

· Creation of a Test TSP CA certificate by the technical administrator of the root;

· Verification Test of TSP CA certificate by the PA and TSP;

· Submission of a Certificate Signing Request (CSR) by TSP for Production TSP CA;

· Instruction from the PA to the technical administrator of the root for the creation of a new TSP CA certificate;

· Execution of a creation ceremony of new TSP CA certificate by the technical administrator of the root;

· Verification by PA of new TSP CA certificate;

· Handover by PA of new TSP CA certificate to the TSP;

· Discharge of the technical administrator of the root/domain CA by PA.

4.7 Certificate Re-key

Certificate Re-key is not applied within the central hierarchy of PKIoverheid.

4.8 Certificate Modification

Certificate Modification is not applied within the central hierarchy of PKIoverheid

4.9 Certificate Revocation and Suspension

Revocation of a domain certificate or a TSP certificate will be considered if the signing key belonging to the certificate is compromised or suspected to be compromised. The TSP is considered to be compromised if unauthorised access is gained to this signing key or when carriers of the private key are stolen or lost. To effect this, the PA keeps records of incidents and/or other events that can lead to revocation of a domain certificate or a TSP certificate. All messages are registered by the PA and are dealt with.

The PA considers compromise of the signing key to be an emergency. Should an emergency occur, the emergency plan will take effect and all relevant parties will immediately be informed. The emergency plan is discussed in paragraph 5.7 of this CPS.

Prior to revocation of a root certificate, a domain certificate or a TSP certificate and the keys associated with this certificate, a careful assessment process is followed. The emergency team will perform this assessment and will initiate any activities that may ensue from this, or arrange for these to be initiated.

If a TSP no longer fulfils the conditions for participation in the PKI for the government, the PA can revoke the relevant TSP certificate. The revocation of a certificate can be effectuated within one day. The PA informs the TSP prior to the certificate being revoked.

In the event of the revocation of a domain certificate, the PA can inform the child CAs (TSPs).

The decision to a domain certificate will be accompanied by a decision on whether or not a new certificate will be issued to replace the revoked certificate.

The revocation of a domain certificate or a TSP certificate always leads to ad-hoc publication of the relevant modified CRL. The revocation of certificates and the issue of CRLs takes place in accordance with a pre-prepared script. The new CRL will be published a maximum of 24 hours after revocation of a domain or TSP CA..

Certificate suspension is notsupported within PKIoverheids.

4.10 Certificate Status Services

4.10.1 Operational characteristics of the Certificate Status Service

The validity of certificates can be consulted using the published CRL which is available through the electronic repository (see 2.1). For the CRLs, the PA uses the X.509 version 2 format.

As well as the publication of the CRL, the PA also offers an Online Certificate Status Protocol (OCSP) service for the G3 root certificate and the G3 domain organization services. The OCSP service is normally updated every 12 hours. An OCSP response from this service remains valid for up to 7 days. In the event of the revocation of a G3 Domain or TSP CA certificate, the OCSP service is updated ad-hoc. The OCSP service supports the GET method for requesting a response.

With regard to its CRL and OCSP services, the TSP retains appropriate server capacity, meaning a response time will be guaranteed of 10 seconds or less under normal circumstances.

During the lifetime of the aforementioned CA, the status of revoked certificates will remain available on the CRL and through OCSP.

4.10.2 Certificate Status Service availability

The CRL and OCSP are available 24 hours a day, 7 days a week.

The maximum period of time within which the availability of the revocation status information (the status of a revoked certificate) has to be restored is four hours.

4.10.3 Optional attributes of the certificate status service

No further provisions for the certificate services of TSP.

4.11 End of Subscription

If the Ministry of the Interior and Kingdom Relations decides to end the PKIoverheid service, the following actions will be undertaken:

1. All involved parties (subscribers, cross-certifying CAs, TSPs and relying parties) of the PKIoverheid service shall be informed six months before the service ends.

2. All certificates that are issued after announcement of termination of the service has been communicated SHALL NOT contain a NotAfter date which is later than the planned termination date of PKIoverheid.

3. When the service ends, all certificates that are still valid SHALL be revoked.

4. On the termination date, PKIoverheid ceases to distribute certificates and CRLs.

4.11.1 Transfer of PKIoverheid (non RFC3647)

If the Ministry of the Interior and Kingdom Relations decides to transfer the PKIoverheid service to a different organization, all involved parties (subscribers, Application Software Suppliers, parent CAs and relying parties) of the PKIoverheid service will be informed of this transfer at least 3 months in advance. The new organization will transfer the provisions from this CPS to its own CPS.

4.12 Key Escrow and Recovery

The PA PKIoverheid has cloned the key pairs of the root and domain certificates and they are stored at the Disaster Recovery site of PKIoverheid.

5 Management, Operational, and Physical Controls

This CPS contains a high-level description of the security measures taken by the PA.

The PA has implemented control measures in order to prevent loss, theft, damage or compromise of infrastructural assets and disruption of activities. The physical set-up is made up of various layers which require separate access control, each layer requiring a higher level of security. A series of measures have also been taken to protect against fire, natural disasters, failure of supporting facilities (such as electricity and telecommunication facilities), the risk of collapse, leakages, etc.

5.1 Physical Security Controls

The secured environment of the root of the PKI for the government is set up based on the requirements formulated in the WebTrust Program for Certification Authorities, the Civil Service Information Security Classified Information Decree (Voorschrift Informatiebeveiliging Rijksdienst voor Bijzondere Informatie (VIR-BI))

5.2 Procedural Controls

Specific processes and procedures have been implemented to handle incidents and emergencies,.

The Policy Authority performs a system-wide risk analysis annually and describes the control measures taken to mitigate and/or reduce the risks within the system. A risk analysis is also performed when there are significant changes in internal or external factors.

In addition, every year a risk analysis is performed on the technical management of the central hierarchy of PKIoverheid.

The computer systems for the production environment are solely used for the purpose of PKIoverheid CA operations. Separate systems have been set up to test or accept new or modified software and/or hardware. Apart from this separation of hardware, procedures are in force that ensure that all employees respect the principle of a strict separation between the test and the production environment.

The responsibilities of the PA are allocated between different functions and persons. The software checks the segregation of duties and enforces this. Generally, it is ensured that the implementation of security tasks and of regulation and verification take place independently of the implementation of production tasks. More PKI-specific measures are taken in respect of producing the key material and certificates. The PA can only generate key material and certificates in the simultaneous presence of various key holders. Each key holder only has access to part of the activation data that is required to be able to use the signing key. When producing and publishing CRLs, this so-called N out of M principle is also applied[10]. Other conditions are:

· The CA systems are stand-alone systems, without external network links;

· During operational use, CA systems are situated in a secure room that can only be accessed by persons authorised to do so;

· After use, the CA system along with all peripheral equipment and key parts are stored in a safe that is located in the aforementioned secure room;

· The CA systems are operated by a key manager, who works strictly according to the scripts and under the constant observation of a witness. Depending on the ceremony, this is an independent external witness and/or a representative of the PA. Any deviations from the script will be meticulously recorded;

· From the very start (retrieving CA systems and key parts) to the end (storing CA systems and key parts), the entire ceremony is video recorded and saved. The recordings are stored and are available for playback for the Webtrust Auditor.

· During the ceremony, the partial activation keys are in the possession of the relevant key holders. The distribution of the activation keys between the key carriers is such that a specific activity cannot be carried out by the technical administrator without at least 2 civil servants being present. The N out of M principle means that several activation keys and key holders are required. This way access to the CA Private key is only possible by persons in a trusted role using at least dual control.

· A request for certification (signing or revocation) is presented by the PA to the technical administrator, signed by the general director of Logius.

5.3 Personnel Security Controls

The PA shall ensure that trusted personnel have no conflicting interests, in order to safeguard the impartiality of the activities of the PA. If this is considered necessary, the PA will only take on people in positions of trust when, based on security screening performed by the General Intelligence and Security Service (AIVD) or by the Dutch Military Intelligence and Security Service (MIVD).

The PA employs personnel who have the required expertise, experience and qualifications for the relevant positions.

5.4 Audit Logging Procedures for security audits

For the purpose of auditing, the PA keeps computer log files on the changes in the CA systems that form part of the technical infrastructure of the top of the hierarchy and that are of importance for the trustworthiness of the services. Examples of this are creating accounts, installation of software, back-ups, closing and (re)starting the system, hardware changes and securing audit-log files.

All activities of the PA relating to generating keys and producing certificates and CRLs are logged in such a way that retrospective reconstruction of the system operations is possible.

During every key ceremony, the log files of the CA systems are checked to confirm that no unauthorized changes have been made to these systems.

5.5 Records Archival

After each key ceremony, a full secure backup of the CA system (including database) is created. The back-ups are stored offsite. With this mechanism the PA makes sure that at least 7 years of log files are kept at all times.The PA archives relevant records relating to certificates issued by the PA, for a period of seven years after expiry of the certificate. This includes the documents relating to procedures carried out when creating and revoking the certificates and documents/files required in order to ascertain the validity of root certificate, domain certificates or TSP certificates at a specific point in time. The archived documents are stored by the PA in a secure manner.

The public keys of the root certificate, the domain certificates and the CRL certificates are archived as part of the corresponding certificates.

Once the validity of the TSP certificate has expired, the PA shall save, for a period of at least 7 years, all information relating to the application and revocation, if applicable, of the TSP certificate and all information used to verify the identity of the TSP and the Authorized Representative

5.6 Key Changeover

Keys of TSP CAs may not be reused once the term of validity has expired, or once the corresponding certificate has been revoked. When certificates are renewed, the key pair is also renewed.

5.7 Compromise and Disaster Recovery

The PA puts provisions in place to safeguard the continuity of its services in such a way that possible disruptions are kept to a minimum. This includes maintaining critical services, including offering the revocation management service, the revocation status service and providing certificate status information through the usual channels.

The provisions that the PA has put into place include the use of redundant systems, Intrusion Detection Systems and back-ups.

In anticipation of potential emergencies that may arise within the PKI for the government, the PA has prepared an emergency plan. Described in this plan are the measures to resolve an emergency as quickly as possible. The emergency plan therefore outlines how an emergency team will immediately be convened, with certain authorities and resources, which will take appropriate action.

Several parties are active within the PKI for the government (Ministry of the Interior and Kingdom Relations, PA, TSPs and the technical administrator of the root). Any of these parties can have an emergency, which can potentially have an impact on other parts of the PKIoverheid system. To be able to act in a coordinated manner in the event of an emergency, the emergency plans of the various parties are coordinated with one another.

To be properly prepared for potential emergencies and to limit the impact of an emergency the PA's emergency plan is tested periodically, at least annually. The coordination and communication with the involved parties from the PKIoverheid system are then also tested.

6 Technical Security Controls

6.1 Key Pair Generation and Installation

The key pairs of the PA are generated during the various creation ceremonies. For this, only stand-alone computer systems are used. These computer systems are not connected to a network; all communication between systems takes place through media such as USB stick or smartcard. Because the generation and the use of the signing key of the PA takes place occasionally, the computer systems are only used for this purpose. For the majority of the time, the critical components of the computer systems are stored in a safe.

The signing keys of the G2 and above have the following key lengths:

TSP sub-CA certificates 4096 bit RSA keys^[11]

TSP certificates 4096 bit RSA keys

Domain certificates 4096 bit RSA keys

Root certificate 4096 bit RSA keys

OCSP certificates 4096 bit RSA keys

6.2 Private Key Protection and Cryptographic Module Engineering Controls

The active signing keys of the PA are always located in the secure housing of a cryptographic module (HSM) which meets the following:

1. the requirements laid down in the standard FIPS PUB 140-2 level 3 or higher, or;

2. a trustworthy system that (as a minimum) is certified in accordance with ISO 15408 at evaluation guarantee level EAL 4+ or equivalent security criteria.

All actions with the signing keys of the PA take place in accordance with pre-defined procedures. The people who must be present when these actions are being performed are appointed beforehand. The signing keys of the PA can only be unlocked for use when these people are present.

Under no circumstances are the signing keys of the PA passed on to a third party for storage.

If the signing keys are taken out of service at the end of the life time, for security reasons, these signing keys will not be archived. The signing keys are destroyed in an appropriate manner, to prevent them from being reused.

6.3 Other Aspects of Key Pair Management

As described in section 4.12, the private keys of the CA managed by the PA are stored on the DR location with the same (technical) security controls as the operational private keys.

For certificates of the G2 hierarchy, the following term of validity applies:

TSP sub-CA certificates 12 years minus 3 days TSP certificates 12 years minus 2 days

Staat der Nederlanden <Domain> CA – G2 12 year minus 1 day

Staat der Nederlanden Root CA – G2 12 years

As from the G3 hierarchy, the following term of validity applies:

TSP certificates 15 years minus 2 days

Staat der Nederlanden <Domain> CA 3 15 years minus 1 day

Staat der Nederlanden Root CA –3 15 years

OCSP Responder certificates 14 months

6.4 Activation data

Activation data for the information systems, such as passwords and PIN codes are, like the partial keys, stored in separate seal bags in separate compartments in the PKIoverheid safe.

6.5 Computer Security Controls

The PA computer systems used to manage and access a CA private key can only be accessed by authorised members of staff. Software-based checks are incorporated in the systems which are taking care of access control. The software checks the authorisation of the staff member before the relevant actions can take place on the computer system. The actions performed on the computer systems are logged in such a way that, at a later stage, it can be ascertained which staff member performed which actions. The logs that are kept are verified during every key ceremony.

The computer systems of the PA referred to, are implemented in such a way that only the essential actions can be performed. All unnecessary components, such as additional software installed with the OS, are removed. The computer systems are stand-alone and airgapped systems, therefore provisions relating to network security do not apply.

Only the separate directory server for publishing the CRL and certificates is connected to a public network. This connection has extra security, in the form of a firewall.

Measures have also been taken to detect unauthorised and/or failed attempts to access the systems in a timely manner.

The PA ensures that the cryptographic hardware and software used by the PA to sign certificates can never be modified unnoticed. This is monitored throughout the entire lifecycle of the cryptographic hardware and software.

6.6 Life Cycle Security Controls

The hardware and software used in the central hierarchy for the key management is classified by the NBV^[12] at level “Staatsgeheim confidentieel”^[13]. If any changes are made to the information systems, another evaluation is performed.

After extensive testing, CA systems are taken in production and maintained by the technical administrator. Software updates are carefully implemented after consultation with and in the presence of employees of the PA PKIoverheid.

6.7 Network Security Controls

The Staat der Nederlanden Root CA is offline. The Staat der Nederlanden <Domain> CA is also offline. The CRLs described in this in CPS are provisioned online by means of the Certificate Status Service. The technical administrator of the Staat der Nederlanden Root CA of Logius has taken measures to safeguard the stability, the trustworthiness and the security of the network. This includes, for example, measures to regulate data traffic and to prevent unwanted data traffic, as well as the inclusion of firewalls in order to guarantee the integrity and exclusivity of the network. Measures have also been taken to detect unauthorised and/or failed attempts to access the systems in a timely manner.

The Certificate Status Services are part of the annual Webtrust audit. In addition, every year Certificate Status Services undergoes a penetration test. This is carried out by an external IT security company.

6.8 Time-stamping

The PA does not support a timestamping service as part of its services.

7 Certificate and CRL profiles

7.1 Certificate Profile

Appendices D and F contain an overview of the content of the fields of the G2 and G3 root certificate and of the domain certificates.

The PA validates all the information to be listed in a TSP CA certificate that is supplied by the TSP in question, like the OrganisationName and LocalityName. This information will be verified according to guidelines established in BRG 3.2.2.2. The PA allows only unique common names for newly signed TSP CAs. See also the Programme of Requirements part 2 for more information about this subject.

7.2 CRL profiles

The CRLs comply with the X.509v2 standard for public key certificates and CRLs.

The CRLs of Root CAs are valid for one year. This is also the case for the CRLs of the domain CAs.