Closed Bug 436056 Opened 16 years ago Closed 14 years ago

Add second Staat der Nederlanden root certificate

Categories

(CA Program :: CA Certificate Root Program, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mark.janssen, Assigned: kwilson)

References

Details

(Whiteboard: In NSS 3.12.6 and Firefox 3.6.2)

Attachments

(7 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; nl; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: 

We (The Government of the Netherlands (represented by GBO.Overheid)) contacted Frank Hecker (On Mon, May 19, 2008) about adding a second root certificate of the Dutch governmental PKI for acceptance in the Mozilla CA Certificate List. The Government of the Netherlands (Staat der Nederlanden) is already since 2005 an approved member on the Mozilla CA Certificate List (http://hecker.org/mozilla/ca-certificate-list). Our current root (Staat der Nederlanden Root CA) is based on the SHA-1 algorithm with 2048 bit RSA. This root has already been distributed. The second root (Staat der Nederlanden Root CA - G2) is based on the SHA-256 algorithm with 4096 bit RSA.

Some relevant information:

1.	Company name and address

GBO.Overheid
P.O. Box 84011
2508 AA The Hague

2.	Company Web page address (URL)

http://gbo.overheid.nl/english/
http://www.pkioverheid.nl/english
		
3.	What is the business purpose of the certificates issued from the root certificate(s)?

The Dutch governmental PKI is the Public Key Infrastructure designed for trustworthy electronic communication within and with the Dutch government. To reach this goal a national PKI certificate hierarchy has been created. The national PKI hierarchy consists of 2 roots (1 based on SHA-1 and 1 based on SHA-256) and 4 domains. Each having several Certificate Service Providers (CSP's) underneath. 
	
4.	To whom will you issue certificates? For example, to the general public, or to members of a certain organization (please specify).

The CSPs (commercial and governmental organisations) issue several types of certificates (e.g. authentication, encryption, non-repudiation, service (SSL)) to end-users. End-users can be governmental organisations, companies and civilians. The PKIoverheid does not issue certificates directly to end-users, the PKIoverheid only issues certificates to CSP's. The Ministry of Interior and Kingdom Relations (represented by GBO.Overheid) is the owner of the PKIoverheid. GBO.Overheid supports the Dutch Minister of Interior and Kingdom Relations with the management and control of the PKI system.

5.      General types of certificates

The CSP's issue personal certificates for the electronic signature (in
accordance with the European Directive on Electronic Signatures),
authentication and encryption. These certificates can be used for e-mail but e.g. also for other applications (e.g. signing and encrypting a PDF and authenticating to a website). The CSP's also issues non-personal certificates to organisations. These organisations can use these certificates for authentication and encryption purposes (e.g. objectsigning, SSL, e-mailserver signing). 

CSP's do not issue certificates to be used for Code signing and Extended Validation.

6.	Provide a pointer to your Certification Practices Statement (URL).

The PKIoverheid has developed a Schedule of Requirements (Certificate Policy). The Schedule of Requirements (only in Dutch!) can be found at: http://www.pkioverheid.nl/voor-certificaatverleners/programma-van-eisen/programma-van-eisen-2008/ The parts 3a, b, c are the certificate policies (CP). In the other parts specific requirements (for instance regarding interoperability) are stated. 

Each CSP within the PKIoverheid has its own Certification Practice Statement. At this moment DigiNotar (www.diginotar.nl), GetronicsPinkRoccade (http://www.getronicspinkroccade.nl/) and ESG (http://www.de-electronische-signatuur.nl/cms/) act as commercial CSP’s within the PKIoverheid. Their Certification Practice Statements can be found at http://www.diginotar.nl/Portals/7/Voorwaarden/CPS%20DigiNotar%20PKIoverheid%20domein%20overheid%20v1.2.2.pdf and http://www.pki.getronicspinkroccade.nl/website/files/Getronics_PinkRoccade_PKIoverheid_CPS_v4.0.pdf and http://www.de-electronische-signatuur.nl/downloads/CPS_080213.pdf. 

The governmental organisations CIBG (http://www.cibg.nl/) and Defensie (Ministry of Defence) (http://www.mindef.nl/en/) act as non-commercial CSP’s. The Certification Practice Statement of CIBG can be found at http://www.uziregister.nl/Images/CPS%20UZI-register_3.3%20def__tcm38-17194.pdf. The Certification Practice Statement of Defensie is not yet publicised. 

The Certification Practice Statement of the Policy Authority PKIoverheid can be found at: http://www.pkioverheid.nl/fileadmin/PKI/CPS_PA_PKIoverheid_2.6.pdf.
	
7.	List any third-party audits your CA practice has undergone.

Information about the yearly WebTrust audit PKIoverheid commenced by KPMG can be found here https://www.pkioverheid.nl/over-pkioverheid/webtrust/ and here http://www.cpawebtrust.org/abtseals.htm

8.	CRL distribution point.

Can be found here: http://crl.pkioverheid.nl/


Reproducible: Always

Steps to Reproduce:
1.
2.
3.



Q:
Which exact section contains an undertaking to confirm that the applicant has control of the email address before issuing them an email certificate? 

A:
PKIoverheid does not issue certificates directly to end-users, PKIoverheid only issues certificates to CSP's. Therefore detailed information about verifying e-mail addresses of end users can not be found in the CP of PKIoverheid but can only be found in the CPS of the CSP’s. 

In the CP part 3a (personal certificates for the electronic signature, authentication and encryption) of PKIoverheid (http://www.pkioverheid.nl/fileadmin/PKI/PvE_deel3a_v1.1.pdf) one can find requirements for CSP’s which relates to verifying the identity and e-mail address of the applicant: 

1. CP part 3a (Certificate Policy - Domein Overheid en Bedrijven) page 33 (SubjectAltName.rfc822Name) does not recommend the use of an e-mail adress for applicants.    

Translation:
SubjectAltName.rfc822Name

A= Not Recommended

Dutch:
Mag worden gebruikt voor het e-mail adres van de certificaathouder, ten behoeve van applicaties die het e-mail adres nodig hebben om goed te functioneren.
English:
Can be used for the e-mail adress of the applicant, for applications that need the e-mail adress to function properly.   

Dutch:
Voor PKIoverheid certificaten in domein Overheid en Bedrijven wordt het gebruik van e-mail adressen afgeraden, omdat e-mail adressen van certificaathouders vaak wisselen en bovendien privacygevoelig zijn (spam).
English:
The use of e-mail addresses for PKIoverheid certificates within the domain Government and Companies is not recommended, because e-mail addresses of applicants change a lot and it can harm the privacy of the applicants (spam).  

2. CP part 3a (Certificate Policy - Domein Overheid en Bedrijven) page 40 under 3.2.3 (“Authenticatie van persoonlijke identiteit” means “Authentication of personal identity”)  declares that the CSP is responsible for the verification of the identity of the applicant in accordance with ETSI 101 456 paragraph 7.3.1(a, c, d, e, h). 

Q:
Which exact section contains an undertaking to confirm that the application has control of a domain name before issuing them an SSL certificate?

A:
PKIoverheid does not issue SSL certificates directly to end-users, PKIoverheid only issues certificates to CSP's. Therefore detailed information about confirming that the application has control of a domain name can not be found in the CP of PKIoverheid but can only be found in the CPS of the CSP’s.

In the CP part 3b (non-personal certificates to organisations (SSL)) of PKIoverheid (http://www.pkioverheid.nl/fileadmin/PKI/PvE_deel3b_v1.1.pdf) one can find requirements for CSP’s which relates to the FQDN.

1.	CP part 3b page 32 under Subject.commonName declares that the subscriber is responsible for the correctness of the FQDN. 

Subject.commonName

V = required

Dutch:
Naam die de service of server identificeert.
English:
Name that identifies the service or server

RFC 3739, ETSI TS 102 280, PKIo
UTF8String

Dutch:
De abonnee dient aan te tonen dat de organisatie deze naam mag voeren. Als de service een DNS naam heeft moet deze in de commonName vermeld worden als “fully-qualified domain name” (zie de definitie in deel 4). Een certificaat wat bijvoorbeeld voor pkioverheid.nl wordt aangevraagd, is niet geldig voor secure.pkioverheid.nl.
Het is niet toegestaan in dit attribuut wildcards te gebruiken.
English:
The subscriber has to demonstrate that the organisation may carry this name. If the service has a DNS (Domain Name System) than this should be mentioned in the commonName as “fully-qualified domain name” (FQDN). For example if a certificate is requested for pkioverheid.nl than the certificate is not valid for secure.pkioverheid.nl.
It is not allowed to use wildcards within this attribute. 

General information:
Before being allowed as a CSP in the hierarchy of the PKIoverheid the CSP has to prove that it complies with ETSI TS 101 456 (standard for issuing qualified certificates in accordance with the EU-directive on electronic signatures) and the Dutch law on electronic signatures. The CSP needs also to provide a certificate from the Chamber of Commerce and has to sign a contract with the Dutch Ministry of Interior and Kingdom Relations. 

Requests for personal and non-personal certificates can in principle only be done by subscribers and not directly by end-users. Every CSP has a contract with several subscribers. In this contract (this is also mentioned in the CPS’s) is stated that the subscriber is responsible for the accuracy and completeness of the request and for the correct use of the certificate. When a subscriber does not fulfill his obligations than the CSP can withdraw the certificate.
I'm confirming and accepting this bug. It will be put in the queue for processing CA applications; at this time I cannot give an estimate of exactly when we will be able to consider it.

However I do want to confirm the following: Based on the above comment, in order to determine whether the Staat der Nederlanden CA complies with our current policy we will have to evaluate each of the CSPs. It appears that the following is a complete list of the current CSPs:

* DigiNotar (www.diginotar.nl)
* GetronicsPinkRoccade (http://www.getronicspinkroccade.nl/)
* ESG (http://www.de-electronische-signatuur.nl/cms/)
* CIBG (http://www.cibg.nl/)
* Defensie ((http://www.mindef.nl/en/)

Is this correct?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
That is correct. 

I will look into the problem as described in bug 431085.  
Summary: Second root certificate of the Dutch governmental PKI for acceptance in the Mozilla CA Certificate List → Add second Staat der Nederlanden root certificate
Depends on: 431085
No longer depends on: 430185
Accepting this bug so I can proceed with the information-gathering and verification phase of this request.
Assignee: hecker → kathleen95014
For the Staat der Nederlanden Root CA - G2 root that you are requesting to be added to the Mozilla store, please provide the certificate details as per
https://wiki.mozilla.org/CA:Information_template

Once that information is recieved, I can add this request to the pending list at
http://www.mozilla.org/projects/security/certs/pending/

Then we will proceed with reviewing the CP/CPSs and audits for the root and the CSPs. Below is a summary of the information we will need to gather -- I will need your help, because I can only read English and the open source translator tools don't work well enough for this task.

It is best if the CP/CPS and audit statements are translated into English. 

Here is the information that needs to be found and provided for each CSP:

1) The text (in English) in the CP/CPS that demonstrates that reasonable measures are taken to verify the following information for end-entity certificates chaining up to this root, as per section 7 of http://www.mozilla.org/projects/security/certs/policy/.
a)for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;
b)for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf; 
c) for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf;

2) Requirements (technical and contractual) for subordinate CAs in regards to whether or not subordinate CAs are constrained to issue certificates only within certain domains, and whether or not subordinate CAs can create their own subordinates.

3) Determine if there are SSL certs chaining up to this root that are only DV. Eg the Organization is not verified, only the domain name is verified.

4) Review the CP/CPS for potentially problematic practices, as per http://wiki.mozilla.org/CA:Problematic_Practices. When found, provide the text (in English) from the CP/CPS that confirms or denies the problematic practice. Provide further info when a potentially problematic practice is found.

5) Provide a publishable statement or letter from an auditor that meets the requirements of sections 8, 9, and 10 of http://www.mozilla.org/projects/security/certs/policy/

6) Provide information about the CRL update frequency for end-entity certificates. There should be a statement in the CP/CPS to the effect that the CRL for end-entity certs is updated whenever a cert is revoked, and at least every 24 or 36 hours.

7) Provide the OCSP Responder URL (if applicable), and information about maximum time until the OCSP responder is updated to reflect end-entity revocation.

Thanks,
Kathleen
Hello Kathleen,

I have read your questions. I will do my best to answer them on short notice.

KR
Mark
Hello Kathleen,

See below for my answers.

BR
Mark Janssen

CA DETAILS 
CA Company/Organization Name:
GBO.Overheid

Website:
http://gbo.overheid.nl/english/
http://www.pkioverheid.nl/english/

General nature (e.g., commercial, government, academic/research, nonprofit):
From January 2006 the Dutch governmental shared service organization for ICT (GBO.Overheid) has been responsible for the management and ongoing development of a number of ICT services for all government agencies. GBO.Overheid also develops shared standards to facilitate electronic messaging among government agencies, citizens and companies. GBO.Overheid is a telling example how the Dutch government improves its electronic services to these user groups. ICT security, integrity and continuity need to be guaranteed in order to be successful. PKIoverheid is one of the services from GBO.Overheid. PKIoverheid is the name of the Public Key Infrastructure (PKI) designed for safe electronic communication with and within the Dutch government. PKI certificates guarantee high-level security to information sent on through the Internet by
government agencies. They can be used for safeguarding websites (SSL), submitting valid electronic signatures, high-level authentication at a distance and message encryption. 

Primary geographical area(s) served:
The Netherlands 

Number and type of subordinate CAs;
Two subordinate domain-CAs (a domain-CA for Government-Organization and a domain-CA for Government-Citizen) are created underneath and signed by our Staat der Nederlanden Root CA – G2.

At this moment no CSP or subordinate CA, created underneath and signed by a CSP, is active yet underneath our 2nd root Staat der Nederlanden Root CA – G2. Based on our current root Staat der Nederlanden Root CA, I expect that around 6 subordinate CA’s, created underneath and signed by a CSP, will be created before the end of 2010. 

Audit Type (WebTrust, ETSI etc.):
WebTrust

Auditor:
KPMG

Auditor Website:
http://www.kpmg.com/Global/Pages/default.aspx

Audit Document URL(s):
https://cert.webtrust.org/ViewSeal?id=683

URL of certificate hierarchy diagram:
The certificate hierarchy diagram can be found in our CPS, page 8 at http://www.pkioverheid.nl/fileadmin/PKI/CPS_PA_PKIoverheid_v3.0.pdf 

CERTIFICATE DETAILS 
Certificate Name:
Staat der Nederlanden Root CA – G2

End entity certificate issuance policy, i.e. what you plan to do with the root:
The CSPs (commercial and governmental organizations) issue several types of certificates (e.g. authentication, encryption, non-repudiation, service (SSL)) to end-users. End-users can be employees (or in the case of service/SSL certificates: a server) within governmental organizations or employees working at commercial companies ((or in the case of service/SSL certificates: a server). In theory end-users can also be civilians. However, so far no certificates have been issued directly to civilians and this will probably not happen in the coming years.  

Certificate HTTP URL (on CA website): 
http://www.pkioverheid.nl/fileadmin/PKI/PKI_certifcaten/staatdernederlandenrootca-g2.crt

Version:
V3

SHA1 Fingerprint:
59 af 82 79 91 86 c7 b4 75 07 cb cf 03 57 46 eb 04 dd b7 16

Modulus Length (a.k.a. "key length"):
4096 bit RSA

Valid From (YYYY-MM-DD):
2008-03-26

Valid To (YYYY-MM-DD):
2020-03-25

CRL HTTP URL:
http://crl.pkioverheid.nl/

CRL issuing frequency for end-entity certificates:
The issuing frequency is once every 4 hours. For further details see my answer on question 6.

OCSP URL:
Not applicable for our root. For further details see my answer on question 7.
   
Class (domain-validated, identity/organisationally-validated or EV):
identity/organisationally-validated

EV policy OID(s) (if applicable):
Not applicable. Within the hierarchy of PKIoverheid no certificates are issued to be used for Extended Validation. 

Certificate Policy URL:
Our CP is only meant for CSPs within the hierarchy of PKIoverheid who issue certificates to end-users.

Certificates for personal use issued to employees working in governmental organizations or commercial companies http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3a_v1.2.pdf 
Certificates for services (e.g. SSL) issued to governmental organizations or commercial companies
http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3b_v1.2.pdf 
Certificates for personal use issued to civilians
http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3c_v1.2.pdf 

CPS URL:
http://www.pkioverheid.nl/fileadmin/PKI/CPS_PA_PKIoverheid_v3.0.pdf

List one or more Trust Bits to enable, choices are Websites (SSL/TLS), Email (S/MIME), and/or Code (code/document signing):
Websites, Email and Code.

URL of website using certificate chained to this root (if applying for SSL):
Not yet applicable. The reason for this is that no (SSL) end-entity certificates have been issued yet underneath the Staat der Nederlanden Root CA - G2.  
 
Certificate Hierarchy description and/or diagram:
The certificate hierarchy diagram can be found in our CPS, page 8 at http://www.pkioverheid.nl/fileadmin/PKI/CPS_PA_PKIoverheid_v3.0.pdf

List or description of subordinate CAs operated internally:
Two subordinate domain-CAs (a domain-CA for Government-Organization and a domain-CA for Government-Citizen) are created underneath and signed by our Staat der Nederlanden Root CA – G2.

At this moment no CSP or subordinate CA, created underneath and signed by a CSP, is active yet underneath our 2nd root Staat der Nederlanden Root CA – G2. Based on our current root Staat der Nederlanden Root CA, I expect that around 6 subordinate CA’s, created underneath and signed by a CSP, will be created before the end of 2010. 

List or description of subordinate CAs operated by third parties:
Not applicable.

List root CAs that have issued cross-signing certificates for this root CA:
Not applicable. 

SHORT INTRODUCTION

PKIoverheid
The Dutch governmental PKI (hereafter PKIoverheid) is the name for the Public Key Infrastructure designed for trustworthy electronic communication within and with the Dutch government. To reach the latter goal a national PKI certificate hierarchy has been realised. This hierarchy consists of 2 roots and 4 domains. The CSPs (commercial and governmental organizations) issue several types of certificates (e.g. authentication, encryption, non-repudiation, service (SSL)) to end-users. End-users can be employees (or in the case of service/SSL certificates: a server) within governmental organizations or employees working at commercial companies ((or in the case of service/SSL certificates: a server). In theory end-users can also be civilians. However, so far no certificates have been issued directly to civilians and this will probably not happen in the coming years.

The PKIoverheid does not issue certificates directly to end-users, the PKIoverheid only issues certificates to CSPs. The Ministry of Interior and Kingdom Relations is the owner of the PKIoverheid. The Policy Authority PKIoverheid supports the Dutch Minister of Interior and Kingdom Relations with the management and control of the PKI system.

The PKIoverheid hierarchy consists of a root based on the SHA-1 algorithm (Staat der Nederlanden Root CA) and two subordinate domain-CAs (a domain-CA for Government-Government and Government-Business and a domain-CA for Government-Citizen), with several CSPs underneath, and of a root based on the SHA-256 algorithm (Staat der Nederlanden Root CA – G2) and two subordinate domain-CAs (a domain-CA for Government-Organization and a domain-CA for Government-Citizen).

Classification
Both our roots and our 4 domains have been evaluated by the Dutch General Intelligence and Security Service and are classified as Stg. Confidentieel (Nato Confidential).
The private key of both our roots and our 4 domains are held at a location which is classified by the Dutch General Intelligence and Security Service as Stg. Geheim (Nato Secret). So Mozilla customers can have full confidence that the private key of our roots and 4 domains will not be compromised. 

Subscribers 
As stated before: CSPs only issue certificates to end-users working within governmental organizations or end-users working at commercial companies.
   
CSPs will always conclude a contract with (a representative of) a subscriber before issuing any end-entity certificate. This means that a request for a certificate always takes place by (a representative of) a subscriber. So it is not possible that an employee from a government organization or commercial company can directly request a certificate from a CSP. Furthermore (the representative of) the subscriber is responsible for the accuracy and completeness of the request for a certificate. 

The only exception is the CSP Defensie. They only issue certificates to their own employees. So the conclusion of a contract with a subscriber is not applicable here.   

Before a CSP may provide a certificate to (a representative of) a subscriber they have to verify that the subscriber:
1.	is an existing organization and;
2.	provides an organization name, to be included in the certificate, which is accurate and complete.

This is stated in our CP:
-	part 3a; in paragraph 3.2.1 and 3.2.2. on page 8 and nr. 3.2.3 on page 40 and;
-	part 3b; in paragraph 3.2.2.1 and 3.2.2.2 on page 9.

When the subscriber is a natural person (civilian) the CSP has to verify that the name, which will be included in the certificate, is complete and correct, including surname, first name, initials or other forename(s)(if applicable).

This is stated in our CP:   
-	part 3c; in paragraph 3.2.3.1 on page 8.

In addition the CSPs also have to verify the identity of an end-user.

In the CPSs of the CSPs is described how the verification of the identity of (the representative of) the subscriber and the verification of the identity of the end-user takes place. See below. Exception to this is the situation if the subscriber is a natural person (CP part 3c). This can not be found in the CPSs of the CSPs because so far no certificates have been issued directly to civilians and this will probably not happen in the coming years.  

Identity validation check and organizational validation check
CSP DigiNotar
CPS: 
In paragraph 4.3 on page 20 and 21 it is stated that the Registration Authority (in the case of DigiNotar that is a solicitor) will verify the surname, first name, date of birth, birth place, ID number, Location ID Issuance and the validity of the ID (of the representative) of the subscriber. 

Furthermore the RA will verify, on the basis of The Dutch Trade Register (http://www.kvk.nl/english/traderegister/default.asp) whether the (representative of) subscriber may represent the organization, whether the name of the organization is true and whether the address of the organization is correct. 

In paragraph 4.9 on page 23 it is stated that DigiNotar checks the identity of the end-user. Evidence of the identity is checked by the RA on the basis of physical appearance of the end-user. 

CPS services: 
In paragraph 4.4.1 on page 20 and 21 and in paragraph 4.10 on page 23 the same description is included as in the regular CPS from DigiNotar (see above).

CSP Getronics
CPS:
In paragraph 3.2.2 on pages 16 and 17 it is stated that a (representative of a) subscriber has to fill in a form to become registered as a subscriber. 
This form can be found here: http://www.pinkroccadecsp.nl/website/files/PKIoverheid%20-%20Abonnee%20Registratie.doc) 
CSP Getronics will then verify whether the (representative of) subscriber may represent the organization, whether the name of the organization is true and whether the address of the organization is correct.  

Regarding the verification the CSP Getronics will use The Dutch Trade Register or, if it is a government organization, the constitution. This is stated in the form on page 2. 

In addition CSP Getronics will verify the ID (of the representative) of the subscriber. They verify the surname, first name, date of birth, birth place, ID number, Location ID Issuance, the validity of the ID, the signature and the photo (of the representative) of the subscriber.
The subscriber will receive a message when all the information is in order.

In paragraph 4.2.2.1 on page 26 and 27 it is stated that Getronics checks the identity of the end-user. Evidence of the identity is checked by the RA (in the case of Getronics that is an employee of GWK Travelex (http://www.travelex.com/nl/Default.asp?content=&lang=ENG)) on the basis of physical appearance of the end-user. 
 
CSP ESG
CPS:
In paragraph 2.3 on page 9 it is stated that (a representative of) a subscriber has to fill in a form. In this form (the representative of) the subscriber has to fill in the registration number of The Dutch Trade Register (KvK nummer). The form can be found here:
http://www.de-electronische-signatuur.nl/downloads/reg_formulieren/OCD.pdf 

The form and the supplied information are checked by a Local Registration Authority (LRA). 

In the same paragraph of the CPS from ESG it is stated that ESG checks the identity of the end-user. Evidence of the identity is checked by the LRA on the basis of physical appearance of the end-user. 

A list of LRAs used by CSP ESG can be found here:
http://www.de-electronische-signatuur.nl/cms/nl/lrao-partneroverzicht.html 

CSP CIBG/UZI-register
CPS:
In paragraph 3.2.2 and 3.2.3 on page 17, 18 and 19 it is stated that CSP CIBG/UZI-register will verify the surname, first name, ID number and the validity of the ID (of the representative) of the subscriber.

Furthermore the CSP CIBG/UZI-register will verify, on the basis of The Dutch Trade Register whether the (representative of) subscriber may represent the organization, whether the name of the organization is true and whether the address of the organization is correct. 

In paragraph 3.2.3 on page 20 it is stated that CIBG/UZI-register checks the identity of the end-user. Evidence of the identity is checked on the basis of physical appearance of the end-user. 

CSP Defensie
CPS:
In paragraph 3.2.2 it is stated that only the system used for HRM purposes within the Ministery of Defense organization (PeopleSoft that is) can be used to request a certificate. It is not possible to request a certificate without the use of the PeopleSoft system.

In paragraph 3.2.3 on page 15 it is stated that CSP Defensie checks the identity of the end-user. Evidence of the identity is checked on the basis of physical appearance of the end-user. 

So all CSPs perform an extensive identity validation check and organizational validation check regarding the (representative of the) subscriber and the end-user.

Use and inclusion of the PKIoverheid G2 root
Since 9/15/2008 our Staat der Nederlanden Root CA – G2 is included in Mac OS X (version 10.5.5). In February 2009 our Staat der Nederlanden Root CA – G2 will be included in the Microsoft Root Certificate Program. GBO.Overheid considers it important that our G2 root will also be included in the Mozilla CA Certificate List. For Mozilla, this means an opportunity to increase the use of e.g. Firefox within the Dutch government (consists of about 1 million civil servants) and within the Dutch society. E.g. around 6.5 million Dutch civilians use DigiD http://www.digid.nl/english for their transactions with governmental agencies. The DigiD website is secured with a PKIoverheid SSL certificate. A substantial number of the Dutch civilians use Mozilla Firefox. So it would be highly desirable if our Staat der Nederlanden Root CA – G2 is included in the Mozilla CA Certificate List with the result that the Root is trusted in Firefox.       

I hope and expect that my answers lead to an (early) inclusion in the Mozilla CA Certificate List.

ANSWERS
The PKIoverheid consist of 2 roots: 
1.	Staat der Nederlanden Root CA;
2.	Staat der Nederlanden Root CA - G2.

The Staat der Nederlanden Root CA is already included in the Mozilla CA Certificate List. This means that my answer to your questions mainly apply to our 2nd root Staat der Nederlanden Root CA - G2. Nevertheless, my answer also applies to our 1st root Staat der Nederlanden Root CA.

As stated in this bug there are 5 CSPs within the PKIoverheid hierarchy:
* DigiNotar (http://www.diginotar.com/)
* GetronicsPinkRoccade (http://www.pinkroccadecsp.nl/website/index.php?docid=414)
* ESG (http://www.de-electronische-signatuur.nl/cms/en)
* CIBG/UZI-register (http://www.cibg.nl/)
* Defensie ((http://www.mindef.nl/en/)

Below the url’s of the CPSs of the CSPs:

CSP DigiNotar
CPS: https://www.diginotar.nl/Portals/7/Voorwaarden/CPS%20DigiNotar%20PKIoverheid%20domein%20overheid%20v1.2.3.pdf
CPS services: https://www.diginotar.nl/Portals/7/Voorwaarden/CPS%20DigiNotar%20PKIoverheid%20Services%20v1.2.2.pdf

CSP Getronics
http://www.pinkroccadecsp.nl/website/files/Getronics_PinkRoccade_PKIoverheid_CPS_v4.2.pdf 
 
CSP ESG
http://www.de-electronische-signatuur.nl/downloads/CPS_080213.pdf 

CSP CIBG/UZI-register
https://www.uzi-register.nl/pdf/20081001_CPS_UZI-register_4.1d.pdf

CSP Defensie
http://cps.dp.ca.mindef.nl/mindef-ca-dp-cps/CPS%20Certificatie%20Autoriteit%20Defensie%20v.1.2.pdf
 
As requested I will provide the information for each CSP when applicable.

1) The text (in English) in the CP/CPS that demonstrates that reasonable measures are taken to verify the following information for end-entity certificates chaining up to this root, as per section 7 of http://www.mozilla.org/projects/security/certs/policy/.
a) for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf.

Answer 1a:
In the CP part 3b PKIoverheid one can find requirements for CSPs which relates to the FQDN. CP part 3b page 31 underneath the attribute Subject.commonName declares that the subscriber is responsible for the correctness of the FQDN.

“The subscriber has to demonstrate that the organization may carry this name. If the service has a DNS (Domain Name System) than this should be mentioned in the commonName as “fully-qualified domain name” (FQDN). For example if a certificate is requested for pkioverheid.nl than the certificate is not valid for secure.pkioverheid.nl.”

CSP DigiNotar
CPS services:
No statement is made in the CPS services from CSP DigiNotar about the verification of a domain name. However in the application form for PKIoverheid SSL certificates the subscriber has to fill in who is the domain owner. In paragraph 2 of the form it is stated that “a proof of ownership of the domain name of the organization is required. The subscriber has to fulfil this request by handing over evidence of this ownership which can be obtained at www.domain-registry.nl” (English: http://www.domain-registry.nl/ace.php/c,728,122,,,,Home.html) (aka SIDN).

The application form can be found here:
https://www.diginotar.com/Portals/7/Aanvraagformulier/Aanvraagformulier%20PKIoverheid%20Services%20certificaat%20SSL%20V4.1.pdf

CSP Getronics
CPS:
In paragraph 3.2.3.2.2 on page 20 it is stated that “the subscriber has to provide evidence about the identifier (aka the domain name) of the server. Getronics will then assess if the supplied evidence is accurate and complete”.
   
CSP ESG
At this moment the CSP ESG does not issue server certificates (e.g. SSL certificates). They only issue certificates for personal use (authentication, encryption and non-repudiation) to end users.     

CSP CIBG/UZI-register
CPS:
In paragraph 3.2.3 on page 21 it is stated that “At the request of 
server certificates UZI Register will verify the records of the  
SIDN (aka www.domain-registry.nl more info can be found here: http://www.sidn.nl/ace.php/c,728,122,,,,Home.html) or the Internet Assigned Numbers Authority(IANA)) whether the subscriber is the owner of the domain name.”    

CSP Defensie
The CSP Defensie does not issue server certificates (e.g. SSL certificates). They only issue certificates for personal use (authentication, encryption and non-repudiation) to end users.     

b)for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf.

Answer 1b:
CP part 3a page 33 (SubjectAltName.rfc822Name) does not recommend the use of an email address for applicants: “The use of email addresses for PKIoverheid certificates within the domain
Government and Companies is not recommended, because email addresses of applicants change a lot and it can harm the privacy of the applicants (spam).”

Nevertheless some CSPs include an email address. This is sometimes necessary for authentication (access control) purposes within government organizations or commercial companies.  

In the CPSs of the CSPs DigiNotar, Getronics and ESG no real statement is made about the verification of the email address of the end-user. However, as described above each CSP performs an extensive identity validation check and organizational validation check. So there can be absolutely no doubt that the employee is working within that specific organization and that the employee is the one who he/she claims to be. This means that the CSP can trust the submitted email address on the application form which is signed by (the representative of) the subscriber and the end-user.  

CSP CIBG/UZI-register
CPS:
In paragraph 7.1.3 on page 46 it is stated that “the email address is not included within the certificate profile for the UZI-register.”    

CSP Defensie
CPS:
Paragraph 9.4.2 on page 47 and 48 describes which attributes are included in the certificates issued by the CSP Defensie. The attributes are: surname, initials, name, employee number, public encryption key, public authentication- and signing key. So no email address is included in the certificate.   

c) for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf;

Answer 1c:
Each CSP performs an extensive identity validation check and organizational validation check. So there can be absolutely no doubt the entity submitting the certificate signing request is the same entity referenced in the certificate. This means that the CSP can trust the submitted CSR which is signed by (the representative of) the subscriber.  

2) Requirements (technical and contractual) for subordinate CAs in regards to whether or not subordinate CAs are constrained to issue certificates only within certain domains, and whether or not subordinate CAs can create their own subordinates.

Answer 2:
Sub-CAs within the PKIoverheid who issue end-entity certificates can only be created underneath and signed by CSPs within the PKIoverheid hierarchy. So Sub-CAs can only issue certificates within the same domains as where the CSPs issue their certificates. Sub-CAs can not create their own subordinates. The only reason that a CSP within the PKIoverheid creates a Sub-CA is to differentiate between the different usages of certificates. This means that, if applicable, a Sub-CA is created for certificates meant for personal use (authentication, encryption and non-repudiation) and a Sub-CA for certificates meant for services (e.g. SSL).      

Before a CSP can create a Sub-CA they have to have permission from the Policy Authority (PA) of PKIoverheid, as is stated in our CP part 3a and 3c in paragraph 9.12.2.2 on page 25 and in part 3b in paragraph 9.12.2.2 on page 27. The PA grants its permission by assigning a separate OID for the Sub-CA.  

3) Determine if there are SSL certs chaining up to this root that are only DV. Eg the Organization is not verified, only the domain name is verified.

Answer 3:
This is not applicable within the PKIoverheid hierarchy. See my comments underneath the heading “Identity validation check and organizational validation check”.  

4) Review the CP/CPS for potentially problematic practices, as per
http://wiki.mozilla.org/CA:Problematic_Practices. When found, provide the text (in English) from the CP/CPS that confirms or denies the problematic practice.
Provide further info when a potentially problematic practice is found.

Answer 4:
Long-lived DV certificates: 
Not applicable within the PKIoverheid hierarchy. See my comments underneath the heading “Identity validation check and organizational validation check”.
 
Wildcard DV SSL certificates: 
Not applicable within the PKIoverheid hierarchy. CP part 3b page 31 underneath Subject.commonName declares that “It is not allowed to use wildcards within this attribute”.
 
Delegation of Domain / Email validation to third parties:  
The CSPs DigiNotar, Getronics and ESG have delegated parts of their process regarding the organization and end-user identity check to third parties. Nevertheless when a CSP within the PKIoverheid hierarchy uses a RA or LRA for e.g. an identity check than this process will also be included in the audit.

Issuing end entity certificates directly from roots: 
Not applicable within the PKIoverheid hierarchy. As stated before the PKIoverheid does not issue certificates directly to end-users, the PKIoverheid only issues certificates to CSPs. The CSPs (commercial and governmental organizations) issue several types of certificates (e.g. authentication, encryption, non-repudiation, service (SSL)) to end-users. The certificate hierarchy diagram can be found in our CPS, page 8 at http://www.pkioverheid.nl/fileadmin/PKI/CPS_PA_PKIoverheid_v3.0.pdf

Allowing external entities to operate unconstrained subordinate CAs:
Not applicable within the PKIoverheid hierarchy. 

Distributing generated private keys in PKCS#12 files: 
Not applicable within the PKIoverheid hierarchy. Subscribers generate their own key pairs (PKCS#10).
Furthermore the CSPs may not archive or make a back-up from the private key of the subscriber. This is stated in our CP:
CP part 3a and 3b in paragraph 6.2.4.2.1 and 6.2.5.1 on page 20.
CP part 3c in paragraph 6.2.4.2.1 and 6.2.5.1 on page 18.

Certificates referencing hostnames or private IP addresses: 
Not applicable within the PKIoverheid hierarchy.
Our CP part 3b on pages 31 describes that the “Subject” field has to contain an Distinguished Name (DN). In addition the Subject.commonName field has to contain the fully-qualified domain name (FQDN). 

OCSP Responses signed by a certificate under a different root: 
Not applicable within the PKIoverheid hierarchy. The requirements regarding the OCSP are described in our CP part 3b. On page 39 regarding the “Issuer” field it is stated that “An OCSPSigning certificate must be issued within the hierarchy of the PKIoverheid”.
 
CRL with critical CIDP Extension: 
I have read the remarks on this issue. In our CP it is stated that use of the issuingDistributionPoint attribute is optional. Only the CSP ESG uses this attribute. We will inform them about Mozilla’s recommendation.  

5) Provide a publishable statement or letter from an auditor that meets the requirements of sections 8, 9, and 10 of
http://www.mozilla.org/projects/security/certs/policy/

Answer 5:
Information about the yearly WebTrust audit PKIoverheid commenced by KPMG can be found here:
https://cert.webtrust.org/ViewSeal?id=683

The CSPs within the PKIoverheid hierarchy also have to comply with the ETSI TS 101 456 standard. This is audited annually by the auditor. When a CSP uses a RA or LRA for e.g. an identity check than this process will also be included in the audit. PKIoverheid has a number of additional requirements for the CSPs which are also annually reviewed by the auditor. An additional key requirement is that the CRL and OCSP update frequency for end-entity certificates has to take place at least every 4 hours. If a CSP does not comply with this requirement they are not allowed to issue certificates within the PKIoverheid hierarchy.      

Below you will find the ETSI certificates from the CSPs.

CSP DigiNotar:
http://www.diginotar.nl/Portals/7/ETSI/Certificate.pdf

CSP Getronics
https://www.pki.getronicspinkroccade.nl/website/files/Getronics%20-%20ETSI%20certificate%20by%20BSI.pdf.pdf

CSP ESG
http://www.de-electronische-signatuur.nl/downloads/BSI%20Certificaat.pdf 

CSP CIBG/UZI-register
Not published. See attachment.

CSP Defensie
Not published. See attachment.

6) Provide information about the CRL update frequency for end-entity
certificates. There should be a statement in the CP/CPS to the effect that the CRL for end-entity certs is updated whenever a cert is revoked, and at least every 24 or 36 hours.

Answer 6:
CP Part 3a and 3c in paragraph 4.9.5.1 (Tijdsduur voor verwerking intrekkingsverzoek) on page 11 indicates that the CRL and OCSP update frequency for end-entity certificates has to take place at least every 4 hours. The same statement is made in CP Part 3b in paragraph 4.9.5.1 (Tijdsduur voor verwerking intrekkingsverzoek) on page 13.

This information can also be found in the CPSs of the CSPs:

CSP DigiNotar
CPS: 
In paragraph 5.6.8 on page 32 it is stated that “The Revocation status information is updated at least every half hour.”
CPS services: 
In paragraph 5.7.7 on page 33 it is stated that “The Revocation status information is updated at least every half hour.”

CSP Getronics
CPS:
In paragraph 4.9.6 on page 32 it is stated that “CRL issuance frequency is once every four hours” 
 
CSP ESG
CPS:
In paragraph 4.1.2.2 on page 15 it is stated that “The CRL is renewed every 4 hours.”

CSP CIBG/UZI-register
CPS:
In paragraph 4.10 on page 31 it is stated that “UZI-register issues a new CRL every 3 hours”

CSP Defensie
CPS:
In paragraph 4.9.7 on page 23 it is stated that “The CRL is issued once every 4 hours”  

7) Provide the OCSP Responder URL (if applicable), and information about maximum time until the OCSP responder is updated to reflect end-entity revocation.

Answer 7:
CSP DigiNotar
http://validation.diginotar.nl/

CSP Getronics
http://ocsp.pinkroccade.com/

CSP ESG
http://pks.esg4.eu/ocspesgnl

CSP CIBG/UZI-register
http://ocsp.uzi-register.nl

CSP Defensie
http://ocsp.dp.ca.mindef.nl

CP Part 3a and 3c in paragraph 4.9.5.1 (Tijdsduur voor verwerking intrekkingsverzoek) on page 11 indicates that the CRL and OCSP update frequency for end-entity certificates has to take place at least every 4 hours. The same statement is made in CP Part 3b in paragraph 4.9.5.1 (Tijdsduur voor verwerking intrekkingsverzoek) on page 13.

This information can also be found in most of the CPSs of the CSPs:

CSP DigiNotar
CPS: 
In paragraph 5.5.3 on page 26 it is stated that “the OCSP validation information is at least equal to, and as current as the information provided on the basis of CRL validation”.
CPS services: 
In paragraph 5.6.2 on page 27 and 28 it is stated that “the OCSP validation information is at least equal to, and as current as the information provided on the basis of CRL validation”.

CSP Getronics
In paragraph 4.9.8 on page 32 it is stated that “the OCSP validation information is as current as the information provided on the basis of CRL validation but it can be more accurate than the information that is communicated through the CRL. This is only the case if a withdrawal of a certificate has taken place and the regular renewal of the CRL has not yet taken place”.
    
CSP ESG
In the CPS from ESG no real statement is made about the update frequency from the OCSP. Nevertheless ESG has to comply with the requirement as described in the CP. Furthermore the auditor will check this during the annual audit (see my answer on question 5). The auditor has stated that ESG meets the additional requirements from PKIoverheid.

CSP CIBG/UZI-register
In paragraph 4.9.9 on page 31 it is stated that “the OCSP validation information is as current as the information provided on the basis of CRL validation but it can be more accurate than the information that is communicated through the CRL. This is only the case if a withdrawal of a certificate has taken place and the regular renewal of the CRL has not yet taken place”.

CSP Defensie
In the CPS from Defensie no real statement is made about the update frequency from the OCSP. Nevertheless Defensie has to comply with the requirement as described in the CP. Furthermore the auditor will check this during the annual audit (see my answer on question 5). The auditor has stated that Defensie meets the additional requirements from PKIoverheid.

I hope that I have answered your questions sufficiently. Please let me know if you have any additional questions.
Attached file Summary of CSP Information (obsolete) —
Thank you for the thorough information.

I have attached the following two documents:

1) 436056-InfoGathering.pdf
This is a summary of the information gathered and verified as per https://wiki.mozilla.org/CA:How_to_apply

2) 436056-subCA-review.pdf
This is a summary of the information about the CSPs as per
https://wiki.mozilla.org/CA:SubordinateCA_checklist

I have also update the entry on the pending list:
http://www.mozilla.org/projects/security/certs/pending/#Staat%20der%20Nederlanden

And added this request to the queue for public discussion at
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Please review the attached summaries and the entry in the pending list to ensure their accuracy and completeness. Let me know if you would like me to make any changes to this information.

There are three items that I recommend taking action on before this request gets into public discussion.

1) You have stated that in the CPSs of the CSPs DigiNotar, Getronics and ESG no real statement is made about the verification of the email address of the end-user. However, each application form is signed by the representative of the government organization or commercial company of the end-user. Each CSP performs an extensive identity validation check and organizational validation check. So there can be absolutely no doubt that the employee is working within that specific organization and that the employee is the one who he/she claims to be. This means that the CSP can trust the submitted email address on the application form.

However, this issue has been raised before. As sated in bug 431085: “Bug 369357 comment 37 suggests that Staat der Nederlanden does not verify that the subscriber (Subject) has access/control to the email address(es) that it puts into certs, yet it's CA certs are trusted for email. At least one other person concurs with that assessment. So Mozilla needs to review that CA's practices to see if they comply with Mozilla's policy for email trust, and consider what action to take if they do not.”

This has been a sticking point for CA inclusion requests, and may turn out to be an issue if it goes into public discussion as is. It is recommended that your CSPs add information about how they verify the ownership of the email address to their CPS’s, such that they meet section 7 of http://www.mozilla.org/projects/security/certs/policy/. It would also be of great help if you could add such requirements to the PKIoverheid CP/CPS.

2) A couple of the CSPs are not very clear in their CPS about actions taken to verify the ownership of domain name. It would help if they could have them update their CPS to meet section 7 of http://www.mozilla.org/projects/security/certs/policy/. It would also be of great help if you could add such requirements to the PKIoverheid CP/CPS.

3) We will need to have a link to a website (can be a test site) whose SSL cert chains up to this new root.
Kathleen,

Thanks for you response. 

I have reviewed the documents 436056-InfoGathering.pdf and 436056-subCA-review.pdf. It seems to me that they are accurate and complete. 
 
Regarding the entry on the pending list: 
The (correct) link to Audit Report and Management Assertions (https://cert.webtrust.org/ViewSeal?id=6830) doesn't work. I recommend using the direct link to our audit report: http://cert.webtrust.org/SealFile?seal=683&file=pdf

I would change the link to "Description of PKI Overheid" in http://www.pkioverheid.nl/english/

Regarding your recommendations:
1. Okay. I have read your comments and suggestions regarding this subject in (another) bug 324126. More specific comments 55 and 57. Regarding your comments/suggestions I have the following questions:
Do I understand it correctly that it is not necessary to specify IN DETAIL in the CPSs, of the CSPs, HOW the e-mail address of an end-user is verified? Will Mozilla consider it sufficient that we include a requirement in our CP/CPS which states that the CSPs have to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate? Furthermore does Mozilla consider it sufficient that the three CSPs include a statement in their CPSs which states that the ownership/control of the e-mail address is subject to independent verification supported by internal/external audited procedures?

It may take some time to change the CP/CPSs. Does Mozilla consider it sufficient that (in the meantime) a letter from the independent auditor of the CSPs (BSI Management, PwC) is transmitted which states that the verification of the ownership/control of the e-mail address is executed adequately and that there can be no doubt that the entity submitting the request, controls the email account associated with the email address referenced in the certificate?

2. We will add this requirement(s) to our CP. 
The CSPs ESG and Defensie don't issue server certificates which include a domain name (FQDN). CSPs DigiNotar and CIBG verify information in whois registries. So the only CSP which gives a problem is Getronics. Am I correct?

3. Okay. As stated before no (SSL) end-entity certificates have been issued yet under our G2 root. Microsoft has tested the chaining with our sub CA domain certificate (https://www.pkioverheid.nl/fileadmin/PKI/PKI_certifcaten/staatdernederlandenorganisatieca-g2.crt). Is it also possible for Mozilla to use this certificate for test purposes?        
        
BR
Mark Janssen
I have updated the entry on the pending list as per your recommendations.

>> Do I understand it correctly that it is not necessary to specify IN DETAIL in the CPSs, of the CSPs, HOW the e-mail address of an end-user is verified? 

I don’t think the description of how the e-mail address is verified needs to be in great detail. It should be sufficient to say something at the level of: the email address is provided by the representative of a company/organization with an existing agreement, and the RA verifies the domain of the email address is that of the company/organization.

>> Will Mozilla consider it sufficient that we include a requirement in our CP/CPS which states that the CSPs have to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate? 

Yes, this level of statement should be sufficient in your CP/CPS. It is needed to ensure that future CSPs will also meet this requirement.

>> It may take some time to change the CP/CPSs. 

The queue for public discussion is rather long, so it will take 2 to 3 months before this request gets into public discussion. Is that sufficient time?

>> Does Mozilla consider it sufficient that (in the meantime) a letter from the independent auditor of the CSPs (BSI Management, PwC) is transmitted which states that the verification of the ownership/control of the e-mail address is executed adequately and that
there can be no doubt that the entity submitting the request, controls the email account associated with the email address referenced in the certificate?

This would be sufficient, but may not be necessary as per my previous answer.

>>  So the only CSP which gives a problem is Getronics. Am I correct?

Yes.

>>  Microsoft has tested the chaining with our sub CA domain certificate
(https://www.pkioverheid.nl/fileadmin/PKI/PKI_certifcaten/staatdernederlandenorganisatieca-g2.crt).
Is it also possible for Mozilla to use this certificate for test purposes? 

I think so.
(In reply to comment #13)
> I don’t think the description of how the e-mail address is verified needs 
> to be in great detail. It should be sufficient to say something at the 
> level of: the email address is provided by the representative of a company/ 
> organization with an existing agreement, and the RA verifies the domain of 
> the email address is that of the company/organization.

But that's not sufficient, is it?  I have an email address in the comcast.net
domain because I am a customer.  Should I be able to get an SSL cert for a 
server in Comcast's domain because I am a customer?
(In reply to comment #13)
Thank you for clear answers. 

We will include a statement in our CP which states that the CSPs have to take reasonable measures to verify that the entity submitting the request, controls the email account associated with the email address referenced in the certificate. In addition we will include a statement that the CSPs have to use a whois like http://www.domain-registry.nl or http://www.iana.org/ when verifying a domain name. As noted all applicable CSPs already execute the domain name verification in this way. Except Getronics isn't very clear about this in their CPS. We will inform them about this omission and they will alter their CPS on this subject.   

(In reply to comment #14)
The described possibility in this comment differs on two aspects with regard to the process of issuing end-entity certificates within the PKIoverheid hierarchy: 
1. Issuing;
2. Subscriber/end user relationship.
 
1. 
As stated before: CSPs within the PKIoverheid hierarchy only issue certificates to end-users working within governmental organizations or end-users working at commercial companies. In theory end-users can also be civilians. However, so far no certificates have been issued directly to civilians and this will probably not happen in the coming years. 

CSPs will always conclude a contract with (a representative of) a subscriber (often a CEO or a director from a company or organization) before issuing any end-entity certificates. This means that a request for a certificate always takes place by (a representative of) a subscriber (after an extensive identity validation check and organizational validation check, see comment #8). So it is not possible that an employee (an end-user) from a government organization or commercial company can directly request a certificate from a CSP. In the presented example a certificate is requested directly by the end user. 

Furthermore when the certificate is delivered the subscriber and end-user have to verify if the certificate is accurate and complete.  

2.
In addition to my comment above: comment #14 is about a supplier/customer relationship. However within the PKIoverheid hierarchy there is always a supplier(CSP)/employer(subscriber)/employee (end-user)relationship. An employer is, in many ways, responsible for the conduct of its employees. An employee must abide by the rules of the company or organization. So the risk of fraud is significantly less than in the supplier/customer situation. 

To my opinion the current issuing process of PKIoverheid certificates, combined with the inclusion of a statement in the CPSs of the CSPs that "the RA verifies the domain of the email address is that of the company/organization", will give adequate safeguards that the e-mail address in the certificate is under the control of the entity submitting the request.
> We will include a statement in our CP which states that the CSPs have to take
> reasonable measures to verify that the entity submitting the request, controls
> the email account associated with the email address referenced in the
> certificate. In addition we will include a statement that the CSPs have to use
> a whois like http://www.domain-registry.nl or http://www.iana.org/ when
> verifying a domain name. As noted all applicable CSPs already execute the
> domain name verification in this way. Except Getronics isn't very clear about
> this in their CPS. We will inform them about this omission and they will alter
> their CPS on this subject.

Has this been completed?  Are there new urls to the updated documents?

Would you please provide the English translations for the sections pertaining to verification procedures for identity/organization, domain ownership, email ownership, and code signing certs?

> Test website

Previously you had indicated that no (SSL) end-entity certificates have been issued yet underneath the Staat der Nederlanden Root CA - G2.  

Now that we are nearing the public discussion phase, would you please provide a test website whose SSL cert chains up to this root?
Just last week (on July 14th) the Staat der Nederlanden Root CA - G2 has signed 2 CSP CAs. These CSP CAs are now able to issue SSL certs under our G2 Root. As soon as this has occurred I will provide you with the URL for testing purposes. I expect this to happen within a couple of weeks.

With regard to the inclusion of the statements:
Currently I am working on this together with some other changes to our CP and CPS. I expect the new version of our CP and CPS to be published after the holiday season (early September).
Any update in regards to Comment #17?

This is the next request in the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
So we should finalize this information this week.
With regard to the inclusion of the statements in our CP:
Publication of our revised CP (and CPS) is slightly delayed and now scheduled for week 42. If that is a very big problem then I can publish the specific statements on our webpage which include the current changes with regard to our CP. See: http://www.pkioverheid.nl/voor-certificaatverleners/programma-van-eisen/actuele-wijzigingen/ (in Dutch) On this webpage all changes are published which are approved by PKIoverheid and automatically will be included in the next version of our CP. Publication on this website means that all the CSPs within the PKIoverheid hierarchy have to comply with these changes as from the date of publication. Please let me know if Mozilla can wait until week 42 or that an immediate publication on our webpage, where all our current changes are published, is desirable.

Regarding a SSL certificate for testing purposes:
Contrary to my expectations no end entity SSL certificate has been issued yet under our G2 root. Nevertheless as I stated in Comment #12 Microsoft has tested the chaining to our root certificate with our sub CA domain certificate https://www.pkioverheid.nl/fileadmin/PKI/PKI_certificaten/staatdernederlandenorganisatieca-g2.crt On my question if it is also possible for Mozilla to use this certificate for test purposes you answered in Comment #13 "I think so". Please confirm that Mozilla can use our sub CA domain certificate for testing purposes.
> Publication of our revised CP (and CPS) is slightly delayed and 
> now scheduled for week 42. 

I think it’ll be best to wait for your updated CP/CPS before starting the public discussion. I’ll move your request down in the queue so that it should be back up at the top near the week of October 12.

Will the next WebTrust CA audit be based on the new version of the CP/CPS?

> Regarding a SSL certificate for testing purposes:
> Contrary to my expectations no end entity SSL certificate has been issued yet
> under our G2 root. Nevertheless as I stated in Comment #12 Microsoft has tested
> the chaining to our root certificate with our sub CA domain certificate
> https://www.pkioverheid.nl/fileadmin/PKI/PKI_certificaten/staatdernederlandenorganisatieca-g2.crt
> On my question if it is also possible for Mozilla to use this certificate for
> test purposes you answered in Comment #13 "I think so". Please confirm that
> Mozilla can use our sub CA domain certificate for testing purposes.

Yes, I believe so, though a website is preferred so we can do additional testing. If you do happen to be able to provide a website before this request goes into discussion that would be great. Otherwise, we’ll proceed with using this subCA to test chaining.
On October 14th a new version of our CP has been published. The previous version was 1.2. The new version is 2.0. You can find the new version of our CP at this link: http://www.pkioverheid.nl/voor-certificaatverleners/programma-van-eisen/programma-van-eisen-2009/   

On page 36 from our CP "PvE deel 3a" (http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3a_v2.0.pdf) the following requirement has been included: 
In Dutch:
Als het e-mail adres wel in het certificaat wordt opgenomen MOET de CSP:
- de abonnee hiervoor akkoord laten tekenen en;
- controleren of het e-mail adres behoort tot het domein van de abonnee.

English translation:
If the e-mail address is included in the certificate then the CSP MUST: 
- let the subscriber agree on this by signing an agreement and;
- verify that the e-mail address belongs to the domain of the subscriber.

On page 31 from our CP "PvE deel 3b" (http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3b_v2.0.pdf) the following requirement has been included: 
In Dutch:
De CSP MOET bij erkende registers (Stichting Internet Domeinregistratie Nederland (SIDN) of Internet Assigned Numbers Authority (IANA)) controleren of de abonnee de eigenaar is van de domeinnaam.   

English translation:
The CSP MUST verify at a recognized institution (Stichting Internet 
Domain Registration Netherlands (SIDN) or Internet Assigned Numbers Authority (IANA)) whether the subscriber is the owner of the domain name.

Our CP part 3a is about certificates for personal use. Our CP part 3b is about certificates for non-personal use like SSL.  

The new version of our CP has been approved by the Ministry of the Interior and Kingdom Relations and applies from October 14th.

On your question if the next WebTrust CA audit will be based on the new CP: 
Our CSPs undergo a annually audit based on the ETSI TS 101 456 requirements and additional requirements from PKIoverheid (as described in our CP). The next audit will be based on the new CP including the new requirements as described above.

Unfortunately up to this moment no end entity SSL certificate has been issued yet under our G2 root. This may change at the beginning of next week. One of our CSPs is in the process of implementing a SSL certificate on a website. As soon as this has taken place I will provide you immediately with the url of this website.

Awaiting your reply.
Was CP Part 3c (for personal use of civilians) updated? Are those certs only used for digital signatures?  Can they be used for email (S/MIME)?  If yes, was anything added in regards to verifying the ownership/control of the email address to be included in the cert?
Two more questions:

1) I have noted that the Code Signing trust bit is also requested; however I have not noted where code signing certs are documented in the CPS or CP documents.  Would you please point me to that information?

2) In regards to the Potentially Problematic Practice about CRLs with critical CIDP extension
https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension
I had noted:
“Only the CSP ESG uses this attribute. We will inform them about Mozilla’s recommendation.”
Has this been resolved?
1. CP Part 3c
Frankly I considered CP Part 3c out of scope because as I stated in Comment #8 at this moment no certs are issued to civilians. Furthermore no CSP CA certificate has been created under our Domain CAs "Staat der Nederlanden Burger CA" and "Staat der Nederlanden Burger CA - G2".

So on your question: "Are those certs only used for digital signatures? Can they be used for email (S/MIME)?" I can only answer theoretically: yes the are.    

However PKIoverheid does not allow the email address to be included in the Subject.emailAddress field. The email address is deprecated but permitted in the SubjectAltName.rfc822Name field. It only may be used to support certain applications (legacy implementations) who need the email address (according to RFC 5280 page 25). This is sometimes necessary for (legacy) applications within companies and governmental organizations. Therefore it is applicable with regard to our CP part 3a. But it will not be necessary for the use of certs issued to civilians.      
 
So if any CSP should create a CSP CA cert under our Domain CA "Burger" then it will not be necessary to include a e-mail address in the cert.

2. Code signing
I assume that this concerns the following requirement from the Mozilla CA Certificate Policy (v1.2): "for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf"

Our CP part 3b is here applicable. Again I would like to refer to my description at Comment #8: 
CSPs will always conclude a contract with (a representative of) a subscriber
before issuing any end-entity certificate. This means that a request for a
certificate always takes place by (a representative of) a subscriber. So it is
not possible that an employee from a government organization or commercial
company can directly request a certificate from a CSP. Furthermore (the
representative of) the subscriber is responsible for the accuracy and
completeness of the request for a certificate.

Before a CSP may provide a certificate to (a representative of) a subscriber
they have to verify that the subscriber:
1.    is an existing organization and;
2.    provides an organization name, to be included in the certificate, which
is accurate and complete.

This is stated in our CP:
-    part 3b; in paragraph 3.2.2.1 and 3.2.2.2 on page 9.

In addition in paragraph 3.2.3.1, 3.2.3.2 and 3.2.3.3 requirements are described about the verification of the identity of the person (= certificaatbeheerder) who may act on entity's behalf. This certificaatbeheerder (in English Certificate Manager) is the ONLY person who may act as a representative of the subscriber/on entity's behalf. In paragraph 3.2.3.1 it is stated that the CSP has to perform a face-to-face verification with regard to the identity of the Certificate Manager. In paragraph 3.2.3.2 it is stated that the CSP may only verify the identity of the Certificate Manager using a document based on the Dutch law for identification ("Wet identificatie bij dienstverlening") e.g a passport. Finally the subscriber/entity has to hand over to the CSP:
- proof of the full name (surname etc.) of the Certificate Manager;
- proof of date and place of birth of the Certificate Manager;
- proof that the Certificate Manager may receive a cert on behalf of the subscriber/entity/organization. 
This is described in paragraph 3.2.3.3.

3. CRL ESG
This is resolved. See the new/adjusted CRL: http://crl.csp4.eu/esgcag2.crl

Please let me know if you have any more questions.
Attachment #361605 - Attachment is obsolete: true
Attachment #361603 - Attachment is obsolete: true
Whiteboard: Information Confirmed Complete
I am now opening the first public discussion period for this request from Staat der Nederlanden to add the “Staat der Nederlanden Root CA - G2” root certificate and enable all three trust bits.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “Staat der Nederlanden Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.
Whiteboard: Information Confirmed Complete → In public discussion
Depends on: 527542
The public comment period for this request is now over. 

This request has been evaluated as per sections 1, 5 and 15 of the official CA policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request to add the “Staat der Nederlanden Root CA - G2” root certificate and enable all three trust bits. 

* Enablement of the email trust bit is not included. Staat der Nederlanden may file a new bug to request enablement of the email trust bit.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by the Staat der Nederlanden, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy].  Staat der Nederlanden appears to provide a service relevant to Mozilla users: It is the Netherlands national government CA.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list. The main documents of interest are the CPS and CP parts a, b, and c. These documents are in Dutch. English translations of certain sections have been provided and verified using Google Translate, and have been included in the Summary of Information Gathered and Verified document that has been attached to this bug.

* CPS of the Policy Authority PKI Overheid
http://www.pkioverheid.nl/fileadmin/PKI/CPS_PA_PKIoverheid_v3.0.pdf
* CP Part 3a for employees of governmental organizations or commercial companies
http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3a_v2.0.pdf
* CP Part 3b for SSL services of governmental organizations or commercial companies 
http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3b_v2.0.pdf
* CP Part 3c for personal use of civilians
http://www.pkioverheid.nl/fileadmin/PKI/pve/PvE_deel3c_v2.0.pdf

Section 7 [Validation]. Staat der Nederlanden appears to meet the minimum requirements for subscriber verification, as follows:

* Email: Not applicable; the email trust bit will not be included as part of this request.

* SSL:  Domain Name Verification is specified in CP Part 3b. CSPs within the PKIoverheid hierarchy verify, on the basis of The Dutch Trade Register (http://www.kvk.nl/english/traderegister/default.asp) whether the subscriber may represent the organization, whether the name of the organization is true and whether the address of the organization is correct. At the request of SSL certificates CSPs verify the records of the SIDN (aka www.domain-registry.nl) or the Internet Assigned Numbers Authority (IANA) whether the subscriber is the owner of the domain name. CSPs within the PKIoverheid only issue certificates to organizations operating within the Netherlands.

* Code: Verification procedures for Code Signing certificates are described in CP part 3b. CSPs within the PKIoverheid hierarchy perform an extensive identity validation check and organizational validation check regarding the subscriber (governmental organization or commercial company) and the end-user. 

Section 8-10 [Audit]. Staat der Nederlanden was audited within the past year by KPMG, using the WebTrust CA criteria. https://cert.webtrust.org/ViewSeal?id=683. This G2 root is included in the audit report. The CSPs are also audited annually. Links to their (ETSI TS 101 456) audits are provided in the Summary of CSP Information document attached to this bug.

Section 13 [Certificate Hierarchy]. The PKIoverheid issues two internally operated subordinate CAs, which issue subordinate CAs to CSPs. The CSPs are commercial and governmental organizations. 
** Each CSP has to prove that it complies with ETSI TS 101 456 and the Dutch law on electronic signatures. 
** CSPs must conclude a contract with a representative of a government organization or commercial company before issuing end-entity certificates. 
** The only reason that a CSP within the PKIoverheid creates a Sub-CA is to differentiate between the different usages of certificates. This means that, if applicable, a Sub-CA is created for certificates meant for personal use (authentication, encryption and non-repudiation) and a Sub-CA for certificates meant for services (e.g. SSL). Before a CSP can create a Sub-CA they must have permission from the Policy Authority (PA) of PKIoverheid, as is stated in CP Part 3a and 3c in paragraph 9.12.2.2 and in Part 3b in paragraph 9.12.2.2. The PA grants its permission by assigning a separate OID for the Sub-CA.

Other: 
* CRL:.All of the CSPs provide CRL. 
* OCSP: All of the CSPs provide OCSP.  Currently 3 of the CSPs issue SSL certs.
* The CP indicates that the CRL and OCSP update frequency for end-entity certificates has to take place at least every 4 hours.

Based on this assessment I intend to approve this request to add the “Staat der Nederlanden Root CA - G2” root certificate and enable the Websites and Code Signing trust bits.
To the representatives of Staat der Nederlanden: Thank you for your cooperation and your patience.

To all others who have commented on this bug or participated in the public discussion: Thank you for volunteering your time to assist in reviewing this CA request.

As per the summary and recommendation in Comment #29, and on behalf of the Mozilla project I approve this request from Staat der Nederlanden to include the following root certificate in Mozilla, with trust bits set as indicated:

* Staat der Nederlanden Root CA - G2 (web sites, email, code signing)

I will file the NSS bug to effect the approved changes.
Whiteboard: In public discussion → Approved - awaiting NSS
Correction: 
* Staat der Nederlanden Root CA - G2 (web sites, code signing)
Depends on: 529874
I have filed bug 529874 against NSS for the actual changes.
From Bug #529874:

> To prevent misunderstandings GBO.Overheid is called Logius since January 11
> this year: http://www.logius.nl/english/ Please change this in your
> administration. Many thanks. 

Mark, 
Please let me know how this affects the information and links of the entry on the pending page:
http://www.mozilla.org/projects/security/certs/pending/#Staat%20der%20Nederlanden
Kathleen,

The information itself is not affected. However with the introduction of the new name Logius a new website has been created. This means that almost all the links to the documents have been changed. The changes are as follows: 

Document	Description of PKI Overheid (English)
New link: http://www.logius.nl/english/products/
 
Document	Certification Practice Statement of the Policy Authority PKI Overheid (Dutch)
New link: http://www.logius.nl/fileadmin/logius/product/pkioverheid/documenten/CPS%20PA%20PKIoverheid%20v3.2.pdf
 
Document	CP for CSPs (Dutch)
New link: http://www.logius.nl/fileadmin/logius/product/pkioverheid/documenten/pve/PvE%20deel2%20v2.1.pdf
 
Document	Certificate Policy Part 3a for employees of governmental organizations or commercial companies (Dutch)
New link: http://www.logius.nl/fileadmin/logius/product/pkioverheid/documenten/pve/PvE%20deel3a%20v2.1.pdf

Document	Certificate Policy Part 3b for SSL services of governmental organizations or commercial companies (Dutch)
New link: http://www.logius.nl/fileadmin/logius/product/pkioverheid/documenten/pve/PvE%20deel3b%20v2.1.pdf

Document	Certificate Policy Part 3c for personal use of civilians (Dutch)
New link: http://www.logius.nl/fileadmin/logius/product/pkioverheid/documenten/pve/PvE%20deel3c%20v2.1.pdf

Document	Schedule of Requirements (Dutch)
New link: http://www.logius.nl/producten/toegang/pkioverheid/aansluiten/programma-van-eisen/#c1618 

Please let me know if you have any questions.

Regards,
Mark
Thanks for the new links. I have updated the pending page:
http://www.mozilla.org/projects/security/certs/pending/#Staat%20der%20Nederlanden
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS → In NSS 3.12.6 and Firefox 3.6.2
As the PKIoverheid hierarchy is updated, I am adding comments to bug #551399.

All Sub CAs (CSP CAs and their sub CAs) can be found here: 
https://www.logius.nl/producten/toegang/pkioverheid/documentatie/certificaten-pkioverheid/csp-certificaten/
Attached file ETS 043.pdf
Attached file ETS 029.pdf
Hello Kathleen,

The Logius/PKIoverheid website has been updated and as a result some of the links mentioned by Mark in his post are outdated. The correct links for the CP and CPS should be in Salesforce but for full disclosure I'll mention them below:

Document	Description of PKI Overheid (English)
New link: https://www.logius.nl/languages/english/pkioverheid/

Document	Certification Practice Statement of the Policy Authority PKI Overheid (Dutch)
New link: https://cps.pkioverheid.nl/CPS_PA_PKIoverheid_Reguliere_Root_v3.9.pdf 

(the most current version of the CPS can Always be found by visiting https://cps.pkioverheid.nl) 

Document
Apologies, somehow I commited the previous comment. Continuing:

Certificate policies for the different types of certificates can be found on the aforementioned general description URL https://www.logius.nl/languages/english/pkioverheid/.

A list of (sub)CA certificates can be found on https://cert.pkioverheid.nl (Dutch) 

Please let me know if you have any questions.

Regards,

Jochem
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: