551399 - Request enabling email trust bit for Staat der Nederlanden Root CA - G2

Status: RESOLVED FIXED

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

Description

[Mark Janssen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.0.5) Gecko/2008122203 Firefox/3.0.5 (.NET CLR 3.5.30729)
Build Identifier: 

Note that bug #436056 has been approved for adding the Staat der
Nederlanden Root CA -G2 certificate to NSS, and enabling the websites and code signing trust bit. With this bug Staat der Nederlanden/PKIoverheid requests that the email trust bit be enabled for the Staat der Nederlanden Root CA -G2 certificate.


Reproducible: Always

Comment 1

[Mark Janssen]

See bug RESOLVED/FIXED bug #431085

>After significant discussion, it was determined that Staat der Nederlanden’s >new practice of only allowing the email address in the >SubjectAltName.rfc822Name field, means that the certs cannot be used for >S/MIME within the context of Mozilla products like Thunderbird.

The latest RFC regarding S/MIME is 5750 (http://tools.ietf.org/html/rfc5750).
Section 4.4.3 states that “Any email addresses present MUST be encoded using
the rfc822Name…”. To include the e-mail address in this field seems
appropriate.   

>We determined that the new root will not have the email trust bit enabled, >because in the context of Mozilla the certs issued under the new root cannot >be used for S/MIME. 

In addition as stated in the mozilla.dev.security.policy newsgroup:
“While, according to spec, certificates usable for S/MIME email may not be
required to include email addresses, our specific interest is how such
certificates are used in the context of Mozilla products like Thunderbird. If
email certificates cannot be used in the context of the Thunderbird model then,
from Mozilla's perspective, there is no point in accepting them for purposes of
email, even if they might be usable in other applications that support S/MIME.
One of our goals is to operate the root program in terms of minimizing risk.
One way that we can minimize risk is by not giving roots more trust than they
absolutely require. 

To summarize, to enable the email trust bit, the requirements in the Mozilla CA
Certificate policy must be met for the root and all of the sub-CAs, and the
email certificates should be usable within the Mozilla context/products (eg
Thunderbird).” 

With regard to the first requirement: “…, the requirements in the Mozilla CA
Certificate policy must be met for the root and all of the sub-CAs”:
The policy of PKIoverheid regarding the verification of Email Address
Ownership/Control is that 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. In our CP Part 3a it is
stated that: “If the e-mail address is included in the certificate 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.” 

The reason why PKIoverheid deprecated the use of an email address is because of
security concerns. Firstly, including an email address in a certificate
severely weakens the PKI model with regard to privacy. Secondly, including
email addresses in certificates can lead to spam attacks. 

With regard to the second requirement: “…and the email certificates should be
usable within the Mozilla context/products (e.g. Thunderbird).”:
Section 3 from RFC 5750 (http://tools.ietf.org/html/rfc5750#section-3) states
that ...”End-entity certificates MAY contain an Internet mail address…”
…..”Receiving agents MUST recognize and accept certificates that contain no
email address.”  ……”Receiving agents MUST check that the address in the From or
Sender header of a mail message matches an Internet mail address, if present,
in the signer's certificate, if mail addresses are present in the certificate.
A receiving agent SHOULD provide some explicit alternate processing of the
message if this comparison fails, which may be to display a message that shows
the recipient the addresses in the certificate or other certificate details. A
receiving agent SHOULD display a subject name or other certificate details when
displaying an indication of successful or unsuccessful signature verification.” 

The question is does Tbird comply with the requirements and recommendations as
stated in section 3 from RFC 5750. Especially the recommendation “A receiving
agent SHOULD provide some explicit alternate processing of the message if this
comparison fails, which may be to display a message that shows the recipient
the addresses in the certificate or other certificate details.” Does Tbird
comply with this recommendation? The answer is: yes it does.

See attachment 1 [details] [diff] [review]. In this situation a message is digitally signed. The sender
has installed the cert without an email address as described at
http://kb.mozillazine.org/Installing_an_SMIME_certificate. The only difference
is that the cert automatically is installed at “Web Sites” instead of “Other
People’s” within Tbird (because the email address is not included?). 

When the recipient receives the digitally signed message Tbird displays the
following message: 
“Although the digital signature is valid, it is unknown whether sender and
signer are the same person. The certificate used to sign the message does not
contain an email address. Please look at the details of the signature
certificate to learn who signed the message.” (Approximately the same message
will be displayed when the sender signs using a cert including another email
address than the email address the message was send from) 

This makes perfect sense. The recipient has to check the details in the
certificate itself to check the identity of the sender. For example: the
recipient can rely on a name or social security number all verified by the CA.
In general PKI, there is no need for an application to check the consistency
of, for example, an email address because the cert info itself is dominating.
Given the message “Although the digital signature………. signed the message.”
Tbird complies with the general PKI principal (the cert info is dominating) and
with the S/MIME standard.

See attachment 2 [details] [diff] [review]. Unfortunately it is not possible to encrypt a message with
Tbird using a cert without an email address. However it is possible to decrypt
a digitally signed and encrypted message with Tbird send from another email
client (e.g. Outlook). 

When the recipient receives the digitally signed and encrypted message than
Tbird displays the same message “Although the digital….. signed the message.”
Furthermore it states that the message is encrypted (with the public key of the
receiver). The message can be decrypted with the private key of the receiver
placed on the smart card (by placing the smart card in the reader and entering
the PIN). 

Summary:
-    It is possible to send and receive digitally signed messages in Tbird
using certs without an email address;
-    No risks are involved and no harm is done to end users. Tbird displays a
clear message when a certificate, that does not contain an email address, is
used to sign the message. Tbird complies with the general PKI principal (the
cert info is dominating) and with the S/MIME standard;
-    Encrypting a message with Tbird is not possible. Nevertheless it is
possible to decrypt a digitally signed and encrypted message send from another
email client. Again no risks are involved and no harm is done to end users.
Tbird again displays a clear message. 

So certs without an email address can be used in the context of Mozilla
products like Thunderbird. No risks are involved and no harm is done to end
users. IMO the issue that remains is “does PKIoverheid/Staat der Nederlanden
adequately verify the email addresses (in compliance with the Mozilla CA
Policy) that we do put into certs, when we do?”   

Finally one could argue “why does PKIoverheid/Staat der Nederlanden want to
have the email trust bit set if to their opinion Tbird can function, for the
most part, with certs without an email address”. There are 3 main
reasons/arguments:

At this moment two CSPs within the PKIoverheid (UZI-register and Defensie)
don’t include an email address in the certificate because of security concerns.
PKIoverheid shares these security concerns but at the same time recognizes the
fact that it is common practice to include email addresses in S/MIME
certificates because this is the default situation for most applications like
Tbird and Outlook. That is why the PKIoverheid policy states that the email
address is deprecated BUT permitted in the SubjectAltName.rfc822Name field.
Because other CSPs (ESG, DigiNotar and Getronics) within the PKIoverheid
hierarchy do include an email address, it is highly desirable that the email
trust bit is set for the Staat der Nederlanden Root CA - G2.

The second reason is that it is not possible with Tbird to send an encrypted
message using a cert without an email address. 

In addition to the former reason, if Tbird could be altered in a way as is
possible with MS Outlook
(http://support.microsoft.com/default.aspx?scid=kb;en-us;276597) than this
would enhance interoperability between different email clients. IMO this could
also be beneficial for the use and broader acceptance of Tbird. For example: it
is to be expected that the coming years more and more eID citizen cards will be
implemented in Europe. It is unlikely that certs distributed on those cards
will contain a personal email address of the citizen because of privacy
reasons. Furthermore if email addresses would be included than this would lead
to a lot of reissuing of certs because citizens tend to change their personal
email address. For that reason it would be desirable that Tbird could handle
certs without an email address the way MS Outlook does.

Regards
Mark

Comment 2

[Mark Janssen]

Attachment: Attachment 1

Comment 3

[Mark Janssen]

Attachment: Attachment 2

Comment 4

[Mark Janssen]

>For that reason it would be desirable that Tbird could handle certs without an >email address the way MS Outlook does.

See bug #189046

Comment 5

[Kathleen Wilson]

Accepting this bug, and starting the Information Gathering and Verification
phase:
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification

Comment 6

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 7

[Mark Janssen]

Attachment: Test root and Test subordinate CAs

Level 1, 2, 3 and 4 regarding the Test certs. These Test CAs have to be imported for testing the Test end-user certs (_AUT,_VRT, _HND)

Comment 8

[Mark Janssen]

Attachment: Test end-user certs

_AUT: authentication cert

_VRT: encryption cert

_HND: non-repudiation cert

Comment 9

[Kathleen Wilson]

Do these test certs chain up to the "Staat der Nederlanden Root CA - G2" root?

Comment 10

[Mark Janssen]

> Do these test certs chain up to the "Staat der Nederlanden Root CA - G2" root?

No, they don't.

Comment 11

[Kathleen Wilson]

I guess the statement in the info gathering doc "Please provide an example cert for email (S/MIME) use." should have been more clear to indicate that the example cert needs to chain up to the "Staat der Nederlanden Root CA - G2" root for which you wish to enable the email trust bit.

Comment 12

[Mark Janssen]

> ..the example cert needs to chain up to the "Staat der Nederlanden Root CA - G2" root..

This would mean that Mozilla has to sign a subscriber agreement with one of the PKIoverheid CSPs and that a face to face identification of the subject/individual (for example you) is necessary. This is not a realistic option.

However I don't think it is necessary that the example certs have to chain up to our Staat der Nederlanden Root CA - G2 root. In my opinion Mozilla wants to test if and how Tbird can work with certs without an e-mail address. 

The attached test certs/hierarchy (Root CA, sub CAs and end entity certs) are (more or less) technically identical to certs issued within our Staat der Nederlanden Root CA - G2 hierarchy by some PKIoverheid CSPs. 

If Tbird works with these test certs it will work with official certs which chain up to our Staat der Nederlanden Root CA - G2.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Mark, do you have a personal email cert that chains up the the SdN G2 root?
If so, can you attach a copy of your cert to this bug? (not the private key)
That would satisfy this request.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

er, it would satisfy this request, iff your cert has your email address in it.

Comment 15

[Kathleen Wilson]

> I don't think it is necessary that the example certs have to chain up
> to our Staat der Nederlanden Root CA - G2 root. In my opinion Mozilla 
> wants to test if and how Tbird can work with certs without an e-mail address.

I've always required that a test cert chaining up to the root be provided. However, I don't really need it until this request gets to the top of the queue for discussion. The queue is still several months long, and this request won't be added to the queue until the next item about CP/CPS/audit is ready.

> CP/CPS and Audit statements for externally operated sub-CAs.

The other information that I asked for in the Information Gathering document is links to the current CP/CPS documents and recent audit statements for each of the CSPs. If audits are currently in progress, then an estimated date of when the updated audit statement for each CSP will be available will be sufficient to move this request into the queue for discussion. The expectation being that recent audit statements will be provided before I start the public discussion for this request.

Comment 16

[Mark Janssen]

>Please provide links to the current CP/CPS document(s) for each CSP.
DigiNotar:
https://www.diginotar.nl/LinkClick.aspx?fileticket=KYQoXTpWkD4%3d&tabid=321
https://www.diginotar.nl/Portals/7/Voorwaarden/CPS%20DigiNotar%20PKIoverheid%20Services%20v1.2.2.pdf
  
GetronicsPinkRoccade:
http://www.pki.getronicspinkroccade.nl/website/files/Getronics_PKIoverheid_CPS_v4.5.pdf

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

ESG:
http://cps.csp4.eu/downloads/CPS_3.2.pdf

Defensie:
http://cps.dp.ca.mindef.nl/mindef-ca-dp-cps/CPS%20Certificatie%20Autoriteit%20Defensie%20v.1.2.pdf

>Please provide links to the most recent audit statements for each CSP.

As stated before the CSPs undergo annual audits based on the ETSI TS 101 456 requirements and additional requirements from PKIoverheid. These audits result in an audit report. These reports are of course company confidential and can not be published on the internet. In the case that a CSP receives a negative (non-conformity) annual audit report the ETSI certificate will be publically revoked by the auditor. 

At this moment all PKIoverheid CSPs are in the possession of a valid ETSI certificate. See below and attached.  

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

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

CIBG/UZI-register:
See attachment.

ESG:
http://www.de-electronische-signatuur.nl/downloads/ETS006.pdf

Defensie:
See attachment.

> Please provide an example cert for email (S/MIME) use.
See attachment.

A new CSP has been included within the PKIoverheid hierarchy. It is QuoVadis. 
URL: http://www.quovadisglobal.nl/nl-NL.aspx?sc_lang=en-GB

CPS: http://www.quovadisglobal.nl/Beheer/~/media/Files/Repository/QV_CPS_PKI_Overheid_V1_0.ashx

Audit: http://www.quovadisglobal.nl/~/media/Files/Files_NL/BSI_quovadis_certificate.ashx

CRL: http://crl.quovadisglobal.com/qvocag2.crl

OCSP: http://ocsp.quovadisglobal.com/ 
(test site: https://irisklic.delta.nl/) To let it work properly in FF you may have to download our intermediate cert (https://www.logius.nl/fileadmin/logius/product/pkioverheid/certificaten/staatdernederlandenorganisatieca-g2.crt) If all works well the web page will display the message "under construction".   

Domain Name Ownership / Control
See page 16 CPS: 
Dutch
"Bij SSL-certificaat: domeinnaam en eigenaarschap daarvan op basis van controle bij de Stichting Internet Domeinregistratie Nederland (SIDN) of Internet Assigned Numbers Authority."

English
"Concerning SSL certificates: domain name and ownership are verified at SIDN (the Foundation for Internet Domain Registration in the Netherlands) or Internet Assigned Numbers Authority."

Email Address Ownership / Control:
See page 16 CPS:
Dutch
"In het geval dat er een email-adres is opgenomen in het certificaat zal QuoVadis het e-mailadres verifiëren middels het zenden van een verificatie-mail naar dit mailadres met een reply-verzoek aan de eindgebruiker om ontvangst, en daarmee de geldigheid van het e-mailadres, te bevestigen."

English
"In the situation that an email address is included in the certificate  QuoVadis will verify the email address by sending a verification email to this address with a request to the end user to confirm the validity of the e-mail address."

Additional info:
QuoVadis does fully comply with all the PKIoverheid requirements. In addition: QuoVadis has not delegated parts of their process regarding the
organization and end-user identity check to third parties.  

Please let me know if you have any questions.

Regards
Mark

Comment 17

[Mark Janssen]

Attachment: End-user cert

Comment 18

[Mark Janssen]

Attachment: Intermediate certs

Comment 19

[Mark Janssen]

Attachment: ETSI certificate CSP Defensie

Comment 20

[Mark Janssen]

Attachment: ETSI certificate CSP UZI-register

Comment 21

[David E. Ross]

Regarding the confidentiality of the audit report cited in comment #16, the Mozilla policy requires (last bullet in item #6) that the certificate authority (CA) provide Mozilla with the auditor's attestation.  

For the public to place trust in the public-key infrastructure (PKI), the infrastructure must be public.  While private keys are of course held confidential, all else should be available for public inspection: CPs, CSPs, software, etc.  The "etc" should include reports by outside auditors regarding compliance by the CA with its own stated policies and procedures.

Comment 22

[Kathleen Wilson]

The CP, CPS, and ETSI Audit Certificates are publicly available as per the links given above. Mark was talking about the detailed audit reports, which we don't require CA's to post publicly. We ask CA's to post an auditor's statement of compliance to certain audit criteria, and the statement may be in the form of an ETSI Certificate (as is the case for each of the CSP's).

Comment 23

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 24

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about one week. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may sit in the discussion for
weeks. When there are not enough people contributing to the discussions ahead
of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 25

[Kathleen Wilson]

This request is near the top of the queue for public discussion, so I am re-reviewing the information.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

It looks like we need updated (and some new) information for the subordinate CAs.

For each subordinate CA please provide the information listed in the "Third-Party Public Subordinate CAs" section of
https://wiki.mozilla.org/CA:SubordinateCA_checklist

Comment 26

[Mark Janssen]

Attachment: ETSI certificate CSP UZI register

Comment 27

[Mark Janssen]

Attachment: ETSI certificate CSP Defensie

Comment 28

[Mark Janssen]

ETSI certificates:
 
Diginotar: 
http://diginotar.nl/LinkClick.aspx?fileticket=ARFojxrOqKY%3d&tabid=1259
 
UZI register:
See new attachment.
 
Defensie:
See new attachment.
 
The ETSI certificates from ESG, QuoVadis and Getronics are still valid. See attached Completed Information Gathering Document.


Renewed CPSs:

UZI register:
https://www.uzi-register.nl/pdf/20110224_CPS_UZI-register_4.2_Definitief.pdf
 
Defensie:
http://certs.ca.mindef.nl/CPS%20Certificatie%20Autoriteit%20Defensie%20v.2.0.pdf

Getronics
http://www.pki.getronicspinkroccade.nl/website/files/Getronics_PKIoverheid_CPS_v4.8.pdf    

CPSs from ESG, QuoVadis and Diginotar have not changed. See attached Completed Information Gathering Document.

Please let me know if you need more information.

Comment 29

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Thanks for the updates.

I'll post a comment in this bug when I start the discussion.

Comment 30

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Staat der Nederlanden to enable the email trust bit for the “Staat der Nederlanden Root CA - G2” root certificate which is already included in NSS.

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 [e-mail] 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 Request to Enable Email Trust Bit”

Please actively review, respond, and contribute to the discussion.

A representative of Staat der Nederlanden must promptly respond directly in the discussion thread to all questions that are posted.

Comment 31

[Kathleen Wilson]

This request has been evaluated as per the Mozilla CA Certificate 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 from Staat der Nederlanden to enable the email trust bit for the “Staat der Nederlanden Root CA - G2” root certificate which is already included in NSS.

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. The Dutch governmental PKI hierarchy consists of 2 roots, “Staat der Nederlanden Root CA” and “Staat der Nederlanden Root CA – G2”, both of which are included in NSS. The organization operating these roots is called Logius as of January 2010, it used to be called GBO.Overheid. Logius is the digital government service of the Netherlands Ministry of the Interior and Kingdom Relations (BZK).

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.

** Schedule of Requirements: http://www.logius.nl/producten/toegang/pkioverheid/aansluiten/programma-van-eisen/#c1618

** CPS of the Policy Authority PKI Overheid: http://www.logius.nl/fileadmin/logius/product/pkioverheid/documenten/CPS%20PA%20PKIoverheid%20-%20v3.3.pdf

** CP for CSPs: http://www.logius.nl/fileadmin/logius/product/pkioverheid/documenten/pve/PvE%20deel2%20v3.0.pdf

** CP Part 3a for employees of governmental organizations or commercial companies: 
http://www.logius.nl/fileadmin/logius/product/pkioverheid/documenten/pve/PvE%20deel3a%20v3.0.pdf

** CP Part 3b for SSL services of governmental organizations or commercial companies: 
http://www.logius.nl/fileadmin/logius/product/pkioverheid/documenten/pve/PvE%20deel3b%20v3.0.pdf

** CP Part 3c for personal use of civilians: http://www.logius.nl/fileadmin/logius/product/pkioverheid/documenten/pve/PvE%20deel3c%20v3.0.pdf

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

* Email: Email address verification is specified in CP Part 3a. If the e-mail address is included in the certificate the CSP must: a) let the subscriber agree on this by signing an agreement and; b) verify that the e-mail address belongs to the domain of the subscriber.
** The representative of Staat der Nederlanden also clarified that each of the CSPs only issue certs with email addresses that are within the CSP’s own domain: “each email address included is by the CSPs' very nature going to be within the DNS domain of the relevant company (which has been previously organizationally validated to own the given DNS domain). The requests must furthermore be routed through a pre-determined contact for that particular company, who signs etc.”

* 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. 

* EV Policy OID: Not requesting EV treatment. 

Section 15 [Certificate Hierarchy]. 
* This “Staat der Nederlanden  Authentication CA G1” root certificate has two internally-operated subordinate CAs: 1) a domain-CA for Government-Organization, 2) a domain-CA for Government-Citizen. These sub-CAs issue the subordinate CAs for the CSPs. Five CSPs of Staat der Nederlanden were evaluated during the root inclusion request in bug #436056, as per the attachment called “Summary of CSP Information”. There is one new CSP, QuoVadis. Here are links to the current ETSI Certificate and CP/CPS for each of the CSPs in this roots hierarchy.
** DigiNotar:
http://diginotar.nl/LinkClick.aspx?fileticket=ARFojxrOqKY%3d&tabid=1259 (expires: 2013.11.01)
https://www.diginotar.nl/LinkClick.aspx?fileticket=KYQoXTpWkD4%3d&tabid=321
https://www.diginotar.nl/Portals/7/Voorwaarden/CPS%20DigiNotar%20PKIoverheid%20Services%20v1.2.2.pdf
** GetronicsPinkRoccade:
https://www.pki.getronicspinkroccade.nl/website/files/Getronics%20-%20ETSI%20certificate%20by%20BSI.pdf.pdf (expires: 2011.11.01)
http://www.pki.getronicspinkroccade.nl/website/files/Getronics_PKIoverheid_CPS_v4.8.pdf
** CIBG/UZI-register:
https://bugzilla.mozilla.org/attachment.cgi?id=524145 (2013.11.22)
https://www.uzi-register.nl/pdf/20110224_CPS_UZI-register_4.2_Definitief.pdf
** ESG:
http://www.de-electronische-signatuur.nl/downloads/ETS006.pdf  (expires: 2012.06.29)
http://cps.csp4.eu/downloads/CPS_3.2.pdf
** Defensie:
https://bugzilla.mozilla.org/attachment.cgi?id=524146 (2014.02.28)
http://certs.ca.mindef.nl/CPS%20Certificatie%20Autoriteit%20Defensie%20v.2.0.pdf
** QuoVadis:
http://www.quovadisglobal.nl/~/media/Files/Files_NL/BSI_quovadis_certificate.ashx (expires: 2011.08.07)
http://www.quovadisglobal.nl/nl-NL.aspx?sc_lang=en-GB
http://www.quovadisglobal.nl/Beheer/~/media/Files/Repository/QV_CPS_PKI_Overheid_V1_0.ashx

* CRL:
** http://crl.pkioverheid.nl/RootLatestCRL-G2.crl
** http://crl.pkioverheid.nl/DomOrganisatieLatestCRL-G2.crl
** http://crl.pkioverheid.nl/DomBurgerLatestCRL-G2.crl
** In each CP, section 4.9.5: The maximum delay … of the revocation status information, for all relying parties available, is set at four hours. This requirement applies to all types of certificate status information (OCSP and CRL)

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

Section 8-10 [Audit].  Audits are performed annually by KPMG according to the WebTrust CA criteria, and the audit reports are posted in the cert.webtrust.org website.
https://cert.webtrust.org/SealFile?seal=1138&file=pdf (2010.12.31)
** The CSPs undergo regular audits based on the ETSI TS 101 456 requirements and additional requirements from PKIoverheid (as described in the CP).  Links to the ETSI 101 456 Certificate for each CSP are provided above.

Based on this assessment I intend to approve this request from Staat der Nederlanden  to enable the email trust bit for the “Staat der Nederlanden Root CA - G2” root certificate.

Comment 32

[Kathleen Wilson]

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 in Comment #31, and on behalf of Mozilla I approve this request from Staat der Nederlanden  to enable the email trust bit for the “Staat der Nederlanden Root CA - G2” root certificate.

I will file the NSS bug to effect the approved changes.

Comment 33

[Kathleen Wilson]

I have filed bug # 670790 against NSS for the actual changes.

Comment 34

[Kathleen Wilson]

Recently a new CSP has been included within the PKIoverheid hierarchy. 

CSP Name: Digidentity

URL: http://www.digidentity.eu/

CPS: http://www.digidentity.eu/downloads/CPS_v11_Certification_Practice_Statement_PKIo.pdf

Audit: http://www.digidentity.eu/downloads/ETS%20Digidentity.pdf

CRL:
http://pki.digidentity.eu/L4/burger/latestCRL.crl
http://pki.digidentity.eu/L4/sscd-mo/latestCRL.crl
http://pki.digidentity.eu/L4/sscd-digidentity/latestCRL.crl
http://pki.digidentity.eu/L4/services/latestCRL.crl
The CRL is updated and reissued every 4 hours.

OCSP: Will be available end of this year.

Verification of subscriber identity and email and domain ownership/control is on pages 11 and 12 of the CPS.

Website whose SSL cert chains up to this CSP's sub-CA: 
https://mijn.digidentity.eu/login

I have reviewed this information and confirm that it meets the requirements of https://wiki.mozilla.org/CA:SubordinateCA_checklist

Comment 35

[Kathleen Wilson]

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/

NOTE: CSP Getronics is now known as KPN Corporate Market. Because of this new CSP CAs (and Sub CA) are created.
https://www.logius.nl/fileadmin/logius/product/pkioverheid/certificaten/KPN_Corporate_Market_PKIoverheid_CA_-_Overheid_en_Bedrijven.crt
https://www.logius.nl/fileadmin/logius/product/pkioverheid/certificaten/KPN_Corporate_Market_CSP_Organisatie_CA_-_G2.crt
https://www.logius.nl/fileadmin/logius/product/pkioverheid/certificaten/Jus4096-2_KPN_CM_CSP_Justitie_CA_-_G2.cer

Comment 36

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #35)
> 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/


Recently a new CSP has been included within the PKIoverheid hierarchy. It is the Dutch Ministry of Infrastructure and the Enviroment (I&M).

General URL: http://www.government.nl/ministries/ienm 
Specific for the CSP: http://csp.minienm.nl/ and http://bct.csp.minienm.nl/
CPS: http://bct.csp.minienm.nl/minienm-bct-cps/minienm-bct-cps.pdf
Audit: http://bct.csp.minienm.nl/ETS021ILT.pdf

The Ministry of I&M does not issue certs for websites or SMIME. The Ministry of I&M only issue certs for personal use and certs for Taxi on-board computers. These certs have no involvement with browsers and/or email clients. The personal certs are used (by cabdrivers) to sign the data in the Taxi on-board computer. The certs for the Taxi on-board computers are used to encrypt data. The certs for the Taxi on-board computers are issued under our Sub Domain CA Autonome Apparaten: https://www.logius.nl/fileadmin/logius/product/pkioverheid/certificaten/Staat_der_Nederlanden_Autonome_Apparaten_CA_-_G2.cer

Comment 37

[Kathleen Wilson]

The CP and CPS documents have been updated.
"Most of the changes (mainly in our PvE part 3b) relate to the CABforum BRs which become effective as from 07/01/2012."

CPS: https://www.logius.nl/producten/toegang/pkioverheid/documentatie/cps/

CP documents: https://www.logius.nl/producten/toegang/pkioverheid/aansluiten/programma-van-eisen/

Comment 38

[Kathleen Wilson]

Attachment: ETSI certificate for CSP Ministry of Defense

ETSI Certificates for CSPs...

Digidentity: 
https://www.digidentity.eu/static/nl/privacy-veiligheid/ecert_pdf.pdf   

ESG: 
http://www.de-electronische-signatuur.nl/downloads/ETS%20006%202012-2015.pdf 

From Logius: "With this email I would like to inform you that the annual audit from our CSPs Ministry of Defence, Digidentity and ESG has recently been successfully completed. ... The party who performed the audit was KPMG on behalf of the BSI group."

Comment 39

[Kathleen Wilson]

I received the following in email from Mark regarding PKIoverheid:
--
I would like to inform you that the annual audit (2012) from our CSPs KPN Corporate Market BV, UZI-register/CIBG and QuoVadis has recently been successfully completed.

KPN Corporate Market BV: http://certificaat.kpn.com/files/ETSI/Getronics%20-%20ETSI%20certificate%20by%20BSI.pdf

UZI-register/CIBG: http://www.uziregister.nl/doc/pdf/ETSI%20certificaat_31197.pdf

QuoVadis: http://www.quovadisglobal.com/~/media/Files/Files_Global/ETS%20010%20eCertificate.ashx

The party who performed the audit was KPMG on behalf of the BSI group.
--

Reminder:
All Sub CAs (CSP CAs and their sub CAs) in this hierarchy can be found here: 
https://www.logius.nl/producten/toegang/pkioverheid/documentatie/certificaten-pkioverheid/csp-certificaten/

Comment 40

[Kathleen Wilson]

Updated ETSI certificate for ESG, one of Logius' Certificate Service Providers:

http://www.de-electronische-signatuur.nl/downloads/ETS006-2.pdf

The party who performed the audit was KPMG on behalf of the BSI group.

Comment 41

[Kathleen Wilson]

I received the following in email on December 5, 2013:
--
Hereby I would like to notify you that the following certificate service providers of PKIoverheid have passed their annual ETSI (point in time) audit successfully:

Ministery of Defense
Ministery of Infastructure and Environment
ESG
QuoVadis
KPN Corporate Market b.v.
CIBG

Note that CSP Digidenty is missing in this list. Their annual audit is currently being conducted. 

<snip>

The party who performed the audits was Assurist on behalf of the BSI group. Assurist is the company of the former senior manager and lead auditor for webtrust and ETSI of KPMG Netherlands. 
--

Reminder:
All Sub CAs (CSP CAs and their sub CAs) in this hierarchy can be found here: 
https://www.logius.nl/producten/toegang/pkioverheid/documentatie/certificaten-pkioverheid/csp-certificaten/

Comment 42

[Kathleen Wilson]

I received the following in email on May 7, 2014.
--
Hereby you receive an update of Logius PKIoverheid concerning the statement of attestation.

- The Policy Authority PKIoverheid has successfully passed the annual Webtrust audit for 2013:
http://cert.webtrust.org/SealFile?seal=1652&file=pdf
The audit was conducted by KPMG  on behalf of BSI.

- The CSP Digidentity passed the ETSI 101 456 audit in the end of 2013

- CSP Defensie passed the ETSI 101 456 audit successfully at the start of 2014

Both audits were conducted by Assurist on behalf of BSI (attached).
--

Comment 43

[Robert van de Rijt]

Attachment: ETSI CSP Defensie.pdf

ETSI certificate CSP Ministry of Defense

Comment 44

[Robert van de Rijt]

Attachment: ETSI CSP Digidentity