455878 - Add CA Disig root certificate into browser

Status: RESOLVED FIXED

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

Description

[Lubos]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: 

http://www.disig.eu/ca/cert/ca_disig.der

-----BEGIN CERTIFICATE-----
MIIEDzCCAvegAwIBAgIBATANBgkqhkiG9w0BAQUFADBKMQswCQYDVQQGEwJTSzET
MBEGA1UEBxMKQnJhdGlzbGF2YTETMBEGA1UEChMKRGlzaWcgYS5zLjERMA8GA1UE
AxMIQ0EgRGlzaWcwHhcNMDYwMzIyMDEzOTM0WhcNMTYwMzIyMDEzOTM0WjBKMQsw
CQYDVQQGEwJTSzETMBEGA1UEBxMKQnJhdGlzbGF2YTETMBEGA1UEChMKRGlzaWcg
YS5zLjERMA8GA1UEAxMIQ0EgRGlzaWcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQCS9jHBfYj9mQGp2HvycXXxMcbzdWb6UShGhJd4NLxs/LxFWYgmGErE
Nx+hSkS943EE9UQX4j/8SFhvXJ56CbpRNyIjZkMhsDxkovhqFQ4/61HhVKndBpnX
mjxUizkDPw/Fzsbrg3ICqB9x8y34dQjbYkzo+s7552oftms1grrijxaSfQUMbEYD
XcDtab86wYqg6I7ZuUUohwjstMoVvoLdtUSLLa2GDGhibYVW8qwUYzrG0ZmsNHhW
S8+2rT+MitcE5eN4TPWGqvWP+j1scaMtymfraHtuM6kMgiioTGohQBUgDCZbg8Kp
FhXAJIJdKxatymP2dACw30PEEGBWZ2NFAgMBAAGjgf8wgfwwDwYDVR0TAQH/BAUw
AwEB/zAdBgNVHQ4EFgQUjbJJaJ1yCCW5wCf1UJNWSEZx+Y8wDgYDVR0PAQH/BAQD
AgEGMDYGA1UdEQQvMC2BE2Nhb3BlcmF0b3JAZGlzaWcuc2uGFmh0dHA6Ly93d3cu
ZGlzaWcuc2svY2EwZgYDVR0fBF8wXTAtoCugKYYnaHR0cDovL3d3dy5kaXNpZy5z
ay9jYS9jcmwvY2FfZGlzaWcuY3JsMCygKqAohiZodHRwOi8vY2EuZGlzaWcuc2sv
Y2EvY3JsL2NhX2Rpc2lnLmNybDAaBgNVHSAEEzARMA8GDSuBHpGT5goAAAABAQEw
DQYJKoZIhvcNAQEFBQADggEBAF00dGFMrzvY/59tWDYcPQuBDRIrRhCA/ec8J9B6
yKm2fnQwM6M6int0wHl5QpNt/7EpFIKrIYwvF/k/Ji/1WcbvgAa3mkkp7M5+cTxq
EEHA9tOasnxakZzArFvITV734VP/Q3f8nktnbNfzg9Gg4H8l37iYC5oyOGwwoPP/
CBUz91BKez6jPiCp3C9WgArtQVCwyfTssuMmRAAOb54GvCKWU3BlxFAKRmukLyeB
EicTXxChds6KezfqwzlhA5WYOudsiCUI/HloDYd9Yvi0X/vF2Ey9WLw/Q1vUHgFN
PGO+I++MzVpQuGhU+QqZMxEA4Z7CRneC9VkGjCFMhwnN5ag=
-----END CERTIFICATE-----

CA Disig issue certificate for:

    * SSL-enabled servers,
    * digitally-signed and/or encrypted email
    * digitally-signed executable code objects

CA Disig does not issue Extended Validation certificates

CA Disig  issues Personal Certificates for end-entities that enable natural person or corporate bodies  to  take advantage of data and email  signing and encryption. CA Disig also issues Server certificates mainly for Web Servers and also for other types of servers that use SSL encryption. 

For more information please see our Certificate Policy  at  
http://www.disig.eu/_pdf/cp-disig.pdf  (available  only  in  Slovak 
language). 

CA Disig  issues certificates to general public and to  its business partners.  Identity of  every person  that  requests  certificate  is  verified at Registration Authority. CA Disig  is  also  official  Certificate  Authority  of  pan-European  project  NETC@RDS supported by the EU eTEN Programme. 
Certificates  issued  by  CA  Disig  can  contain  following  keyUsage  values: 
nonRepudiation,  digitalSignature,  keyEncipherment,  dataEncipherment  and 
following extendedKeyUsage values: clientAuth, emailProtection and serverAuth. 
Identity  of  every  person  that  requests  certificate  is  verified  at  Registration Authority. Natural person must provide  two valid  ID documents  (national  ID card, passport,  driving  license  etc.).  Requester  of  Server  certificate must  also  declare ownership of used domain name.  


CA  Disig  practice  was  audited  on  March  30,  2007  by  the  independent  team  of auditors as  is  required by national  legislation given by Article 25 of 215 Act of 15 March 2002 on electronic signature and on amendment of some acts as amended by Act No. 679/2004 Coll., Act No. 25/2006 Coll. and Act No. 275/2006 Coll. 

http://www.disig.sk/_pdf/Audit_report_CA_statement.pdf 

The audit team members were: 
Assoc. Professor Ladislav Hudec, PhD, CISA auditor (license no. 9921170) 
Mr. Jan Cesnak, CISA auditor (license no. 650230) 
Mr. Rastislav Machel, CISSP 





Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Kathleen Wilson]

Accepting this bug so I can proceed with the Information Gathering phase.

Comment 2

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Attached is the initial information gathering document which summarizes the information that has been gathered and verified. Within the document the items highlighted in yellow indicate where more information or clarification is needed. I will also summarize below.

1) Please provide a certificate hierarchy diagram and/or description.

a) Are there any internally operated subordinate CAs for this root? For internally-operated subordinate CAs the key is to confirm that their operation is addressed by the relevant CP/CPS, and that any audit covers them as well as the root.

b) Does this root have subordinate CAs that are operated by third parties? For the subordinate CAs that are operated by third parties, please provide a general description and explain how the CP/CPS and audits ensure the third parties are in compliance.

c) Has this root been used to cross-sign other CAs? If yes, please describe.

2) Please translate into English the sections/text from the CP that demonstrate 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;

3) For testing purposes, please provide a URL to a website whose certificate chains up to this root. Note that this can be a test site.

4) Please review the Problematic Practices as per 
http://wiki.mozilla.org/CA:Problematic_Practices. 
Please comment as to whether any of these are relevant. If relevant, provide further info.
Please translate relevant text from CP into English.

5) Do you have an audit from 2008?

Thanks,
Kathleen

Comment 3

[Lubos]

1.)	a.)	We have one Root CA, none subordinate CA
b.)	No
c.)	No


2.)	a.)	Websites (SSL/TLS)   	CP point 3.1.9

CMA (Certificate Management Authority)has to guarantee that the certificate issued for hardware or software component, that is able to use the certificate, that the component identity and the public key are bonded together.  For this reason the component has to be assigned to a specific person or to a person that is authorized to deal on behalf of a company, that is administrating the component. 

Person is obliged to provide following information  to CMA:
-	identification of component
-	public key of the component (part of certificate request)
-	authorization of component and its characteristics

Requirement for certificate that will use the domain name is, that the applicant has to prove that the second level domain is in his possesion.  This can be done by providing the declaration on word of honour 	that he is the owner of the domain and that he understands the consequencies for unathorized use of domain name provided.

In case of IP address reqistration authority is not investigating whether the applicant is authorized to use the provided IP address and if the IP address is part od address range assigned to applicant. The applicant is providing an declaration on word of honour that he is authorized to use the IP address provided and that he is aware of the consequences of unathorized use of the IP address.

b.)	Email (S/MIME) 	CP bod 3.1.8

Certificate applicant is signing the declaration on word of honour that the e- mail address used in certificate request is in his possesion. This declaration is a part of contract between CA and applicant.


c.) 	Code (CodeSigning)        

Applicant for the certificate presents: name of software component, URL and application description (this can be understood as the declaration on word of honour). Also he is signing the declaration on word of honour that the content of contract complies with the provided documents. 

3.)	https://kb.asseco.com

4.)	Relavant for us is only 1.3 Issuing end entity certificates directly from roots 

Further info: Our company is running only Root CA, because until now we have been providing a small number of certificate types. In the future we are planning to deploy a hierarchy of CA’s where there will be one Root CA and several Sub CA. Each of these Sub CA will be responsible for issuing a specific type of certificates. Audit has proven that security measures applied to protect our CA are more than sufficent. This was also one of the reasons that conviced company Microsoft to add our Root CA certificate into their store (MS update will be issued on November 25, 2008) . 


5.)	Yes we have audit from 2008. It was my mistake. I wrote bad date. The correct audit date reflect Audit Report statement. It’s date 31.5.2008

http://www.disig.sk/_pdf/Audit_report_CA_statement.pdf

Audit Type: ETSI TS 102 042

The audit team members were: 
Assoc. Professor Ladislav Hudec, PhD, CISA auditor (license no. 9921170) 
Mr. Jan Cesnak, CISA auditor (license no. 650230) 
Mr. Rastislav Machel, CISSP

Comment 4

[Lubos]

Attachment: Disig initial information gathering

Comment 5

[Kathleen Wilson]

Thank you for your thorough response. Please provide further information in regards to the following two items.

1) Mozilla policy is that when an audit report is provided by the CA, a Mozilla representative needs to independently contact the auditor to verify the authenticity of the audit report. For instance, I need to find the lead auditor online, verify that he is a CISA auditor, and contact him independently to ask him to confirm the authenticity of the audit report.

I have looked at the CISA/ISACA website information, and I have not found a way to locate Jan Cesnak. Perhaps you can help by telling me how you found this auditor? Is there a way to verify his CISA license online? Is there a way to find his contact information online?


2) In regards to section 7 of
http://www.mozilla.org/projects/security/certs/policy/
I am supposed to find text in the CP/CPS that demonstrates that reasonable measures are taken to verify the ownership of the domain name and email address. This is supposed to be action taken by the CA to do something to verify the information provided by the applicant.  Unfortunately, having the applicant sign on his honour does not satisfy this requirement. Is there anything in your CP/CPS or other relevant process documentation that provides policy guidelines about what the CA will do to verify the information provided by the applicant in regards to ownership of the domain name and email address?

Thanks,
Kathleen

Comment 6

[Kathleen Wilson]

I have received verification of Jan Cesnak's CISA certification. However, I have not been able to figure out how to independently contact him in order to verify the authenticity of the audit report as per Mozilla policy.

> From: Dept: Certification <[e-mail]>
> Date: Friday, November 14, 2008, 2:07 PM
> Thank you for your message. If you wish to find out whether 
> an individual is CISA certified or not, I can assist you with
> this. I have checked my records and can confirm that Mr. Jan
> Cesnak is CISA certified. 
>

Comment 7

[Lubos]

1.)You can locate Mr. Jan Cesnak on Slovak ISACA page (www.isaca.sk) specifically http://www.asint.sk/isaca/index.php?option=com_content&task=view&id=43&Itemid=56
Independently you can contact him on email address [e-mail]

2.)Domain name:
In our CPS for RA (Certificate Practice Statement for Registration Authority) is written:
Applicant shell proves to the Registration Authority that he is an owner of the domain for which he is requesting certificate. Ownership is established by written certification from authorized registry e.g. Slovak Top Level Domain Registry (www.sk-nic.sk) etc.
Registration Authority shell verify this written certification from independent source on Internet e.g www.sk-nic.sk for Slovak domain; www.eurid.eu for European domain etc.

Email address:
In our CPS for RA (Certificate Practice Statement for Registration Authority) is written:
Applicant shell send certificate request for a certificate to be used for digitally signing and/or encrypting email messages to the CA Disig registration authority (RA) via e-mail. Registration authority shell check if the request for particular applicant was sent from the same e-mail address as is inside his request. If there is difference RA may refuse issue certificate. In addition to this check, RA performs confirmation of the applicant’s e-mail address through an answer to e-mail address from which request was sent.

Comment 8

[Kathleen Wilson]

Thank you for the information.

I have sent email to Mr. Jan Cesnak.

The information that you provided for the domain name and email address is what I was looking for. Is the CPS for RA a publicly available document?  If yes, would you please provide the URL to it and the sections where this information can be found?

Comment 9

[Lubos]

CPS for RA is not publicly available document. But i can propose you link where you can see our CPS for RA (available only in Slovak language). After one week we remove this link

http://www.disig.sk/_pdf/cps_ra_cadisig_v2_0.pdf

domain name: page 26, section 3.1.9
email address: page 32, section 4.1.1.3 point 4 and 5

Comment 10

[David E. Ross]

"CPS for RA is not publicly available document."  This concerns me.  I thought all CPS documents should be available to the relying parties.  Since the relying parties are the general public accessing Internet services that use SSL, that means the documents should be public.

Comment 11

[Kathleen Wilson]

Here’s some clarification.

Disig’s CP is indeed a public document:
http://www.disig.eu/_pdf/cp-disig.pdf

The document under discussion at the moment is the “CPS for RA” which is their rules/process that their Registration Authorities must follow. Most of the CAs that I have been working with consider their agreements with their Registration Authorities to be internal information, and they don’t plan to post the RA details publicly. We don’t need to know every detail about their agreements with their Registration Authorities. We do need to have publicly available information showing that the Mozilla Policy requirements are met.

The particular item under discussion is in regards to section 7 of the Mozilla CA Certificate Policy.
http://www.mozilla.org/projects/security/certs/policy/
There needs to be publicly available text that demonstrates that reasonable measures are taken to verify the ownership of the domain name and email address.

In this case the relevant text resides in an internal document. The following options may be used to resolve this:
1) The relevant text could be copied from the “CPS for RA” into the public CP document. Or a summary of the relevant text could be added to the public CP document.
2) The relevant section of the “CPS for RA” could be published into a separate document and attached to Bugzilla.
3) A summary of the relevant section of the “CPS for RA” could be published into a separate document and attached to Bugzilla, such that any sensitive information is removed.

Comment 12

[Lubos]

The relevant text has been added to the public CP document. 

http://www.disig.eu/_pdf/cp-disig.pdf

domain name: page 27, section 3.1.9
email address: page 34, section 4.1.2 point 3 and 4

Comment 13

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 14

[Kathleen Wilson]

Assigning this bug back to Frank, as this completes the information gathering and verification phase.  

For information about the next phase (public discussion) please see
https://wiki.mozilla.org/CA:Schedule

One item of note:
This root does not have subordinate CAs. It issues end-entity certs directly.
From Disig: Our company is running only Root CA, because until now we have been providing a small number of certificate types. In the future we are planning to deploy a hierarchy of CA’s where there will be one Root CA and several Sub CA. Each of these Sub CAs will be responsible for issuing a specific type of certificates. Audit has proven that security measures applied to protect our CA are more than sufficient.

Comment 15

[Frank Hecker]

Re-assigning this bug to Kathleen Wilson, since she'll be the person actively working on it.

Comment 16

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Attaching an updated version of the Information Gathering Document in preparation for the public discussion phase, as per 
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Based on prior discussions, it is much preferred if the CP can be translated into English before the discussion begins.  Do you happen to have an English version of CP CA Disig? If not, could you run the CP through a translator and then clean up the text to make it clear/accurate, and attach the translated version to this bug?

For the email and websites certificates I was able to find the verification procedures in CP CA Disig.  However, the code signing trust bit has also been requested, and I could not find reference to code signing certs within the document. It could be that the translations of the words I tried were not correct. If you cannot provide an English version of the CP, then please provide translations of the sections that refer to code signing certs.

Also, when are you planning to have the next audit performed?

Comment 17

[Kathleen Wilson]

According to the queue for public discussion at
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
this request may enter public discussion in about two weeks. The process is
described at 
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

However, I will not be able to start the public discussion for this request
until someone from Disig has responded to my inquiries in Comment #16.

Comment 18

[Lubos]

Attachment: English version CA Disig Certification Policy

English version CA Disig Certification Policy

Comment 19

[Lubos]

We have contract for audit and completion date is till 30.7.2009

English version of CP is in attachment and reference to code signing is there too

Comment 20

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Updated the Information Gathering Document based on the English version of the CP.

Comment 21

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Disig to add the CA Disig root certificate to NSS 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 [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 “Disig Root Inclusion Request”

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

Comment 22

[Kathleen Wilson]

The first round of discussion for this request is now closed.

Below is a summary of the concerns that were raised during the discussion, and the corresponding action items.  Follow-up on these action items should be posted directly in this bug.  After I have confirmed that all of these action items have been addressed, I will start a new discussion thread to have the second round of discussion about this request.

1) CPS not publicly available.
In many cases the CP does not appear to provide sufficient details. It appears that the CPS and the relying party agreements are not publicly available.

ACTION: It is requested that Disig either make the CPS publicly available or make the RPA publicly available (whichever provides the most detail about the verification procedures, and is audited) and provide the corresponding link.

2) Root issues certs directly
It is noted that the CA Disig root certificate does not have subordinate CAs.  However, as per previous discussions, this alone does not prevent a root certificate from being included.

ACTION: None

3) Ownership of Domain Name
The procedures for verifying the ownership/control of the domain name for Slovak domains appear to sufficiently satisfy section 7 of the Mozilla CA policy.  However, it does not appear that the verification of ownership/control of the domain name is sufficient for non-Slovak domains: “As concerning server certificate request from outside Slovakia we are requiring written statement from the applicant that he is an owner of the domain (the same as for Slovak domain).” There does not appear to be a process of confirming the authenticity of the statement, such as comparing it to a different source of data (e.g. WHOIS).

ACTION: The additional explanation provided in this discussion in regards to verification of ownership/control for Slovak domains should be added to the CP/CPS (an audited, publicly available document).

ACTION: The CP/CPS (an audited, publicly available document) needs to be updated to satisfy the Mozilla CA policy in regards to verification of the ownership/control of the domain name for non-Slovak domains.

4) IP Address
From CP: “In the case of registered IP addresses RA will not investigate whether the body -  the applicant for a certificate for the server uses the registered IP address legitimately…” Disig has stated that this section within the CP is obsolete.

ACTION: Disig to fix the section about IP address.

5) Ownership of Email Address
There was much discussion about Disig’s procedures for verifying certificates to be used for email (S/MIME). It has been pointed out that the procedures, even when described in detail, do not prove that the certificate subscriber has ownership/control of the email address to be included in the certificate. Kathleen added a section called “Verifying Email Address Control” to the Recommended Practices wiki page.

ACTION: Disig to either update their practices in regards to verification of control of the email address, or decide not to request enablement of the email trust bit at this time. Note that for this issue, updating the practices will include both the update to the CP/CPS as well as an audit to confirm the changes in process have been made.

6) RA Requirements and Controls
The questions about requirements for RAs, and how they are controlled/audited appear to not have been answered sufficiently.  

ACTION: Disig to provide a publicly available and audited document that states the RA requirements, especially in regards to verification procedures relating to section 7 of the Mozilla CA Policy. 

ACTION: Disig to provide further information about the audit requirements for RAs, and how it is verified/controlled that the RAs follow the procedures as outlined by Disig documentation.

Comment 23

[Lubos]

Attachment: Audit Report

Comment 24

[Lubos]

1)	CPS not publicly available.
In many cases the CP does not appear to provide sufficient details. It appears that the CPS and the relying party agreements are not publicly available.

ACTION: It is requested that Disig either make the CPS publicly available or make the RPA publicly available (whichever provides the most detail about the verification procedures, and is audited) and provide the corresponding link.

CORRECTIVE ACTION: 
CA Disig Certification Practice Statement (CPS) is publicly available on the Disig web site http://www.disig.sk/_pdf/cps_ra_cadisig.pdf



2) Root issues certs directly
It is noted that the CA Disig root certificate does not have subordinate CAs. However, as per previous discussions, this alone does not prevent a root certificate from being included.

ACTION: None

CORRECTIVE ACTION: None



3) Ownership of Domain Name
The procedures for verifying the ownership/control of the domain name for Slovak domains appear to sufficiently satisfy section 7 of the Mozilla CA policy.  However, it does not appear that the verification of ownership/control of the domain name is sufficient for non-Slovak domains: “As concerning server certificate request from outside Slovakia we are requiring written statement from the applicant that he is an owner of the domain (the same as for Slovak domain).” There does not appear to be a process of confirming the authenticity of the statement, such as comparing it to a different source of data (e.g. WHOIS).

ACTION: The additional explanation provided in this discussion in regards to verification of ownership/control for Slovak domains should be added to the CP/CPS (an audited, publicly available document).

CORRECTIVE ACTION: 
Article 3.1.9 of CA Disig CP and CPS was modified in the following way:
“The existence of a domain and its owner has been verified through WHOIS services provided by the web top level domain sponsoring organization (e.g. for domain ".sk" is the sponsoring organization SK-NIC - www.sk-nic.sk; for domain ".eu" is the sponsoring organization EURid vzw/asbl established in Belgium for the domain ".com" is sponsoring organization VeriSign Global Registry Services based in the U.S.).
Full domain name will be verified by sending an e-mail which will contain secret information to some unforeseeable e-mail accounts for the domain listed in the record obtained from the WHOIS service.
An applicant for a certificate for the domain shall send back verification information as proof of ownership of the domain within specified period of time sufficient for sending email.
In the event that there is no e-mail address respectively there is no response from expected e-mail addresses because it does not exist, RA must take further steps to verify domain ownership for example use published contact data of domain registrar.
If from the data obtained from the above sources is not possible to reliably determine that the applicant is the owner of the domain or person acting on behalf of the owner of the domain, RA refuses to issue a certificate to that request.”

CA Disig also issued detailed manual for its registration authorities how to proceed in verification of ownership/control of domain.

ACTION: The CP/CPS (an audited, publicly available document) needs to be updated to satisfy the Mozilla CA policy in regards to verification of the ownership/control of the domain name for non-Slovak domains.

CORRECTIVE ACTION: The CP/CPS was updated and the same process as described above is used also for non-Slovak domains. Registration authorities are obliging exploit WHOIS services of top domain sponsoring organization which are listed at http://www.iana.org/domains/root/db/.


4) IP Address
From CP: “In the case of registered IP addresses RA will not investigate whether the body - the applicant for a certificate for the server uses the registered IP address legitimately…” Disig has stated that this section within the CP is obsolete.

ACTION: Disig to fix the section about IP address.

CORRECTIVE ACTION: This paragraph was withdraw from CP.


5) Ownership of Email Address
There was much discussion about Disig’s procedures for verifying certificates to be used for email (S/MIME). It has been pointed out that the procedures, even when described in detail, do not prove that the certificate subscriber has ownership/control of the email address to be included in the certificate. Kathleen added a section called “Verifying Email Address Control” to the Recommended Practices wiki page.

ACTION: Disig to either update their practices in regards to verification of control of the email address, or decide not to request enablement of the email trust bit at this time. Note that for this issue, updating the practices will include both the update to the CP/CPS as well as an audit to confirm the changes in process have been made.

CORRECTIVE ACTION: 
CP and CPS were modified in the following way:
(CP) Article 4.1.1. “Request for a certificate for signing and encryption of electronic mail shall be send to the relevant RA in advance electronically from e-mail address which is included in the request for certificate in the field „E-mail“. E-mail addresses of RA CA Disig are available on the Disig web site”

(CP) Article 4.1.2 Item 1:
”Request for issuance of personal certificates for signing and encryption of electronic mail must be send electronically to the appropriate RA from addresses, which is included in the request in the field E-mail.”

(CP) Article 4.1.2 Item 3:
“RA must verify whether electronically transmitted certificate request was sent by the applicant from the same e-mail address, which is located in the certificate request. In the case of the differences observed may refuse to issue the certificate”

(CP) Article 4.1.2 Item 4”
“In connection with the verification of an e-mail address in the request for certificate which is used to sign electronic messages (extension "Secure Email (1.3.6.1.5.5.7.3.4)") perform RA worker verification checks of e-mail addresses in the request for a certificate, via the responds to the e-mail, from which request was send. Verification is carried out so that to the e-mail address is sending a mail message containing secret unpredictable information (authentication information). An applicant for a certificate shall send back to the CA Disig verification information as evidence of control of the e-mail addresses. The answer shall be send within a specified period of time sufficient for sending email. In case that the verification of e-mail address runs unsuccessfully, CA Disig refuses to issue the certificate.”

(CPS) Article 4.1.1.1
“Send electronically certificate request to the RA - RA e-mail addresses are available on the Disig website (see 1.4). Certificate request decided for signing and encryption of electronic mail extension "Secure Email (1.3.6.1.5.5.7.3.4)” shall be send from an e-mail address specified in the certificate request.”

(CPS) Article 4.1.1.2
“Note: Customer must be able to identify on the RA RequestId indication value (as numeric string proceeded by the string "disigweb" that uniquely identifies the generated certificate request) of the certificate request. Application for a certificate for signing and encryption of electronic mail shall be send to the RA electronically in advance (see 4.1.1.1).”


(CPS) Article 4.1.1.2 Item 1
“RA staff verify if electronically sent certificate request from an applicant (it is compulsory for certificates with extension “Secure Email (1.3.6.1.5.5.7.3.4)"), was sent from the same e-mail addresses, what is in the certificate request. If the differences observed refuses to issue the certificate.”

(CPS) Article 4.1.1.2 Item 12
“In the case when certificate request sent in advance contains the same e-mail address as from which it was sent, the RA staff shall verify validity of this e-mail address. Verification is carried out so that to the e-mail address is sending a mail message containing secret unpredictable information (authentication information). An applicant for a certificate shall send back to the CA Disig verification information as evidence of control of the e-mail addresses. The answer shall be send within a specified period of time sufficient for sending email. In case that the verification of e-mail address runs unsuccessfully, CA Disig refuses to issue the certificate. Detailed procedure is described in the RA working manuals and is also subject to the initial training of RA staff.”

CA Disig also issued detailed working manual for its registration authorities how to proceed in verification of ownership/control of e-mail address.


6) RA Requirements and Controls
The questions about requirements for RAs, and how they are controlled/audited appear to not have been answered sufficiently.  

ACTION: Disig to provide a publicly available and audited document that states the RA requirements, especially in regards to verification procedures relating to section 7 of the Mozilla CA Policy. 

CORRECTIVE ACTION: 
CA Disig issued detailed manual for its registration authorities how to proceed in verification of ownership/control of domain.

CA Disig also issued detailed working manual for its registration authorities how to proceed in verification of ownership/control of e-mail address.

ACTION: Disig to provide further information about the audit requirements for RAs, and how it is verified/controlled that the RAs follow the procedures as outlined by Disig documentation.

CORRECTIVE ACTION: 
The scope of compliance audit performed during November 2009 was extending to include Mozilla root inclusion requirements.
Audit report statement is in attachment.

Comment 25

[Kathleen Wilson]

Thank you for the updated information, CP, CPS, and Audit Statement. I have reviewed the information and used Google Translate to confirm the updates in the CP and CPS.

When audit statements are provided by the company requesting CA inclusion rather than having an audit report posted on the website such as cert.webtrust.org, the Mozilla process requires doing an independent verification of the authenticity of audit statements that have been provided.
Is http://www.scientia.sk/ the correct url for the website of the auditing organization?
Do the three auditors that are listed in the audit report work at Scientia? If so, do they have sicentia.sk email addresses?

Comment 26

[Lubos]

The audit was performed under the contract with Scientia company, working in the field of information security and has worked closely with a number of CISA and CISSP auditors.

Due to the specific audit area, an responsible, experienced and independent auditor Mr. Machel (CISSP) was contracted, to perform the security audit with help of Mr. Mach (MCSE) – employee of Scientia company.
Contact information: 
[e-mail]
[e-mail]

Mr. Spal (CISA), as an employee under review Disig company, which operates the CA, worked in audit team just as a formal participant in order to supervise the conduct of the audit. He did not active participate on security audit performance.

Comment 27

[Kathleen Wilson]

I have received email from Mr. Mach of Scientia confirming the authenticity of the attached audit statement.  However, The audit statement had a slight error on the last page, so Mr. Mach is contacting the lead auditor to fix this. They will send an updated audit soon.

Comment 28

[Kathleen Wilson]

Attachment: Audit Report

Updated audit report sent to me by Mr. Mach of Scientia.

Comment 29

[Kathleen Wilson]

Attachment: Final Information Gathering Document

Updated to reflect changes made (CPS and audit) as per the action items resulting from the first public discussion.

Comment 30

[Kathleen Wilson]

I am now opening the second public discussion period for this request from Disig to add the CA Disig root certificate to NSS 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 [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 “Disig Root Inclusion Request Round 2”

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

Note: For the time being, Google Groups is not working correctly for Mozilla discussions. Please either use a newsreader like Thunderbird, and/or subscribe to the mozilla.dev.security.policy newsgroup by email.

Comment 31

[Kathleen Wilson]

The second 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 CA Disig root certificate to NSS and enable all three trust bits. 

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Disig, 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]. Disig appears to provide a service relevant to Mozilla users: It is a public CA located in Slovakia with customers across Central and Eastern Europe.

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 Certification Practice Statement and the Certificate Policy. Both of these documents are in Slovak, and version 3.4 of the CP has been translated into English.

CA Disig CPS (Slovak – version 4.0): http://www.disig.sk/_pdf/cps_ra_cadisig.pdf 
CA Disig CP (Slovak – version 4.0): http://www.disig.eu/_pdf/cp-disig.pdf 
CA Disig CP (English – version 3.4): https://bug455878.bugzilla.mozilla.org/attachment.cgi?id=384717

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

* Email: According to section 4.1 in version 4.0 of both the CP and CPS the Disig RA verifies that the email address that the applicant uses to send the certificate request is the same email address to be included in the certificate. The RA also sends email to the address to be included in the certificate, and the applicant must respond appropriately within a specified amount of time.

* SSL: According to section 3.1 in version 4.0 of both the CP and CPS the existence of a domain and its owner are verified through WHOIS services provided by the web top level domain sponsoring organization (e.g. for domain ".sk" is the sponsoring organization SK-NIC - www.sk-nic.sk; for domain ".eu" is the sponsoring organization EURid vzw/asbl established in Belgium for the domain ".com" is sponsoring organization VeriSign Global Registry Services based in the U.S.). Full domain name will be verified by sending an e-mail which will contain secret information to some unforeseeable e-mail accounts for the domain listed in the record obtained from the WHOIS service. An applicant for a certificate for the domain shall send back verification information as proof of ownership of the domain within specified period of time.

* Code: CP Section 3.1.9 states that for code signing certs the component has to be assigned to a specific person or to a person that is authorized to deal on behalf of a company that is administrating the component.  The RA has to verify the identity of the person and organization in accordance with the requirements of CP sections 3.1.7 and 3.1.8.

Section 8-10 [Audit]. Section 8-10 [Audit]. 
* A recent audit performed by an independent team, including a CISSP-certified auditor and an auditor from Scientia (http://www.scientia.sk/) has been attached to this bug and the authenticity of the audit report has been confirmed. In addition to the audit based on the ETSI TS 102 042 criteria, the audit report states that there was additional focus on the updates to the CP and CPS in regards to verification of ownership/control of domain name and email address of certificate subscribers

Section 13 [Certificate Hierarchy]. 
* This CA Disig root certificate has no subordinate CAs. The root signs end-entity certificates directly.

Other: 
* NextUpdate for the CRL for end-entity certs is 24 hours.
* OCSP is not provided.

Based on this assessment I am inclined to approve this request to add the CA Disig root certificate to NSS, and enable the websites, email, and code signing trust bits.

Comment 32

[Kathleen Wilson]

To the representatives of Disig: Thank you for your cooperation and your
patience.

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

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

* CA Disig (web sites, email, code signing)

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

Comment 33

[Kathleen Wilson]

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

Comment 34

[Kathleen Wilson]

Attachment: Audit Report 2010

Comment 35

[Kathleen Wilson]

Attachment: Audit Statement 2011