693273 - Request to add CA "Digidentity" to Mozilla

Status: RESOLVED WONTFIX

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

Description

[Bas Kemp]

Our company has recently introduced a new service - digtal signing of electronic documents. This involves issuing certificates, something we've been doing for a while already, but this time we need to use our own root CA rather than the PKIOverheid-certificates (controlled by the Dutch government) we've been using so far. 

Certificate name: Digidentity CA

Company information:

Adress: 		Digidentity BV
			Waldorpstraat 17p
			2521 CA Den Haag

URL: 		http://www.digidentity.eu

Contacts:	Bas Kemp, project manager ([e-mail], tel. [phone])
			Marcel Wendt, CTO ([e-mail], tel. [phone])
			

Number of roots to be submitted: 1 (Digidentity CA)

Information on our root certificates: 
Digidentity offers a Digital Document Signing service as well as a SSL service. For these applications we will need to have our CA included in all major web browsers.

Certificates will be issued to three types of users: the general public, corporations and governmental entities. The latter can include entire organizations as well as persons involved with these organizations. 

The following EKU's will be included in the Certificates:

1.3.6.1.4.1.34471.1.2.3.1 
1.3.6.1.4.1.34471.1.2.3.2 
1.3.6.1.4.1.34471.1.2.3.3
1.3.6.1.4.1.34471.1.2.5.1
1.3.6.1.4.1.34471.1.2.5.2 
1.3.6.1.4.1.34471.1.2.5.3
1.3.6.1.4.1.34471.1.2.5.4 
1.3.6.1.4.1.34471.1.2.5.5 
1.3.6.1.4.1.34471.1.2.5.6
1.3.6.1.4.1.34471.1.2.5.7

The identity of the requestor will be confirmed in one of multiple ways, depending on the type of service they require. For non-qualified use, a copied ID will suffice. For qualified (or legally binding) use, customer will be identified face-to-face.

Our CPS can be found at the following URL: https://www.digidentity.eu/downloads/Certification%20Practice%20Statement%20L3.pdf (Dutch)

Digidentity's CA practices have been audited by the British Standards Institute and found to comply with the standards of ETSI TS 101 456 for the following scope:
Regsitration Service
Certificate Generation Service
Revocation Management Service
Revocation Status Service
Dissemination Sewrvice
Subject Device Provisioning Service.

Our BSI certificate (number ETS 015) can be validated online at https://pgplus.bsigroup.com/cert/default.asp?certnumber=ETS+015&crdate=27%2F01%2F2011&certtemplate=cemea_en

Including our root-CA will provide Mozilla-users with the ability to use and verifiy Digidentity-accredited documents, contracts and deeds. Also, they will be able to access SSL secured websites using the certificates we issue to our partners (up to 400,000 websites). 

The necessary technical information will follow shortly.

Kind regards,

Bas Kemp
Digidentity

Comment 1

[Kathleen Wilson]

I hope to begin Information Verification soon, and I will update this bug again at that time.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 2

[Bas Kemp]

Hi Kathleen,

Could you please tell me what - if any - information I will need to provide for you to expedite this change? I see "information incomplete" was added to this bug's whiteboard....

Comment 3

[Kathleen Wilson]

The checklist of information that needs to be provided is here:
https://wiki.mozilla.org/CA:Information_checklist

A description of Mozilla's CA Certificate Inclusion Process is here:
https://wiki.mozilla.org/CA

Comment 4

[Bas Kemp]

    Name: Digidentity L3 Root CA - G2
    Website URL: http://www.digidentity.eu
    Organizational type: Company
    Primary market / customer base:
Digidentity BV caters to (mostly dutch) companies, governmental entities and consumers. 
          
 Impact to Mozilla Users
FireFox users will be able to access websites with Digidentity issued certificates
     
   Mozilla CA certificate policy:
Digidentity will be selling certificates to one of the Netherlands' largest webhosting providers (400,000+ websites), NOT to the owners of websites themselves
    CA Contact Information
        CA Email Alias: [e-mail]
        CA Phone Number: [phone]
        Title / Department: CTO, Security Officer 

Technical information about each root certificate

    Certificate Name
Digidentity L3 Root CA - G2
    Certificate Issuer Field
        Digidentity BV
    Certificate Summary
        This root certificate is used for issuing SSL, personal authentication and signing certificates. 
    Root Certificate URL
        http://pki.digidentity.eu/validatie 
    SHA1 fingerprint:
F1 38 A3 30 A4 EA 98 6B EB 52 0B B1 10 35 87 6E FB 9D 7F 1C

    Valid from 2011-04-29
    Valid to 2031-11-10
     
    Certificate Version (should be 3)
        X.509v3
    Certificate Signature Algorithm 
        RSA-4096 bits
    Test website URL -- https://pki.digidentity.eu/validatie
            
    Certificate Revocation Lists (CRLs)
        pki.digidentity.eu/ L3 /root/latest.crl
        The value that nextUpdate is set to in the CRLs for end-entity certificates.
4 hours
        The sections of your CP/CPS documentation that state the requirements about frequency of updating CRL.
Section 1.4
        Note the CA/Browser Forum's EV guidelines: CRLs MUST be updated and reissued at least every seven days, and the nextUpdate field value SHALL NOT be more ten days
        You must test your CRLs by importing them into the Firefox browser.
No errors found
        The OCSP URI that is in the AIA of your subscriber certificates.
??????        
The maximum time elapsing from the revocation of an end entity or CA certificate until OCSP responders are updated to reflect that revocation.
4 hours      

  The sections of your CP/CPS specifying availability and update requirements for the OCSP service.
Section 1.4       

     CA/Browser Forum's EV Guidelines Section 26(b): “If the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it MUST update that service at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.” 
        You must test that your OCSP service is compatible with the Firefox browser.
           Tested and confirmed
    Requested Trust Bits
        State which of the three trust bits you are requesting to be enabled for this root. One or more of:
Solely:            Websites (SSL/TLS)

    SSL Validation Type
        Indicate the levels of SSL validation that are used for certificates within this root's hierarchy. One or more of:
DV and OV

CA Hierarchy information for each root certificate

The information listed in this section must be provided for each root certificate to be included in Mozilla, or whose metadata is to be modified.

If Mozilla accepts and includes your root certificate, then we have to assume that we also accept any of your future sub-CAs and their sub-CAs. Therefore, the selection criteria for your sub-CAs and their sub-CAs will be a critical decision factor. As well as the documentation and auditing of operations requirements that you place on your sub-CAs and their sub-CAs.

    CA Hierarchy
       - Please see section 1.14 of our CPS for a schematic

The 7 sub-CAs in our root comprise the following:
- Digidentity L3 Organisatie: used for identifying organisations
          - Machtigingonline: dedicated for use with the Staat der Nederlanden      
            PKI-infrastructure (qv.)
          - Digidentity L3 Services: used for signing and SSL
- Digidentity L3 Burger: used for identifying natural persons
          - L3 SSCD CA: Used for creating "virtual smartcards"
- L3 Extended Validation: used for EV SSL
          - Digidentity L3 EV SSL CA - G2: Used for Digidentity specific 
            web-services.


                It might also include subordinate CAs operated for the benefit of specific third parties. In this case note that we do not require that the CA submit a complete customer list; rather we are interested in the general type and nature of the third-party arrangements. 
    Sub CAs Operated by 3rd Parties
       N/A
           Cross-Signing
       N/A
     
    Technical Constraints or Audits of Third-Party Issuers
     N/A
            
          
Verification Policies and Practices

We rely on publicly available documentation and audits of those documented processes to ascertain that the CA takes reasonable measures to confirm the identity and authority of the individual and/or organization of the certificate subscriber.

If the CP/CPS documents are not in English, then the portions of those documents pertaining to verification of the certificate subscriber must be translated into English. For all of the items listed below, provide both a pointer to the original document (and section or page number of the relevant text) as well as the translated text.

    Documentation: CP, CPS, and Relying Party Agreements
       CPS is to be found at http://pki.digidentity.eu/validatie.
    Audits
            ETSI TS 101 456 (see https://pgplus.bsigroup.com/cert/default.asp?certnumber=ETS+015&crdate=27%2F01%2F2011&certtemplate=cemea_en)

            If the information is available from the auditor's (or other third-party's) web site or from another authoritative web site (for example, webtrust.org for WebTrust reports), please provide the URL where the information can be found.
            If you provide the information yourself (e.g., it is hosted on your own web site), please provide us with contact information for the auditor (or other third party).
            Otherwise please ask the auditor (or other third party) to contact us directly and provide us the audit report(s) or other information. 
        The audit should not be more than a year old. If it is, then provide an estimate of when the updated audit report will be available. While ETSI Certificates may be valid for 3 years, it is our expectation that there is an annual renewal/review process for the ETSI Certificate to remain valid.

Audit will be done every year

        Government CAs
N/A

    SSL Verification Procedures

        If you are requesting to enable the Websites (SSL/TLS) trust bit...
            URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying that the domain referenced in an SSL cert is owned/controlled by the subscriber.

SEe CPS, section 1.11 and beyond

                Recommended Practices for Verifying Domain Name Ownership 
All checks are face-to-face
                Potentially Problematic Practices in regards to Email Address Prefixes -- The list that the CA uses must either match or be a subset of the list in this wiki page. 
            Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks in 2011).
High-profile websites are filtered out.

                Specify the procedure for additional verification of a certificate request that is blocked. 
We will not be issuing certs automatically. DNS checks, as well as checks with the hosting provider will take place to verify ownership etc. If a request is blocked, all involved parties will be notified personally.

            If OV verification is performed, then provide URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying the identity, existence, and authority of the organization to request the certificate.
Section 1.11 and beyond

                There should be a description of the types of resources that are used to confirm the authenticity of the information provided by the certificate subscriber, what data is retrieved from public resources, and how that data is used for verification of the entity referenced in the certificate. 
We use DNS, Chamber of Commerce and other publicly accessible records. Also, since we will not be providing SSL certificates directly (only through the hosting company i referred to earlier) we will have access to their database.

            If EV verification is performed, then provide URLs and section/page number information pointing directly to the sections of the CP/CPS documents that pertain to EV and describe the procedures for verifying the ownership/control of the domain name, and the verification of identity, existence, and authority of the organization to request the EV certificate.

N/A

    Email Address Verification Procedures
        If you are requesting to enable the Email (S/MIME) trust bit...
N/A

    Code Signing Subscriber Verification Procedures

N/A

    Network Security
        Confirm that you have done the following, and will do the following on a regular basis:
            Check for mis-issuance of certificates, especially high-profile domains.
Multiple checks (automatic and manual) in place.

            Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.
Yearly ISO 27001 audit

            Ensure Intrusion Detection System and other monitoring software is up-to-date.
As above

            Confirm that you will be able to shut down certificate issuance quickly if you are alerted of intrusion. 
As above


Please note: an english translation of our CPS will be following shortly.

Comment 5

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been verified.

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

Comment 6

[Vinod]

Attachment: Second Ca Information Document

We have updated the document. Can you please have a look into the document and inform us about your findings.

Thanks in advance!

Cheers,
Vinod

Comment 7

[Kathleen Wilson]

Thanks for the info. Here's what I'm waiting for:
- Root Cert download URL
- English translation of CPS

Comment 8

[Vinod]

Attachment: Digidentity CPS

Hi Karthleen

Hereby I send you the englissh version of the CPS.

And Root Cert download URL is as followed:
https://www.digidentity.eu/static/nl/downloads/downloads.html#3

Hope to hear from you.

Many thanks,

Vinod

Comment 9

[Kathleen Wilson]

Attachment: Updated CA Information Document

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

Comment 10

[Vinod]

(In reply to Kathleen Wilson from comment #9)
> Created attachment 623816 [details]
> Updated CA Information Document
> 
> The items highlighted in yellow indicate where further information or
> clarification is needed. Please review the full document for accuracy and
> completeness.

Hi Kathleen, 
My answer on the first remark highlighted in yellow is:
-Where is it Documented? I don't know where you could find it.
-What form of multi-factor authentication is used? Smartcard PKI 

My answer on the second remark highlighted in yellow is:
-Can anyone outside of Digidentity directly cause the issuance of SSL certs? No

Is it possible for you to highlight it again in yellow if some things are still missing? Hope to hear from you again.

Many thanks in advance,
Vinod

Comment 11

[Kathleen Wilson]

(In reply to Vinod from comment #10)
> My answer on the first remark highlighted in yellow is:
> -What form of multi-factor authentication is used? Smartcard PKI 

Is a Smartcard required for authentication into every account that can directly cause the issuance of a certificate? Is this documented someplace, such as in your CPS?

Comment 12

[Kathleen Wilson]

Closing this bug because there has been no response from the CA in over a year.