Last Comment Bug 518098 - Add E-ME root certificate
: Add E-ME root certificate
Status: ASSIGNED
CA Action Items -- update cert, brand...
:
Product: mozilla.org
Classification: Other
Component: CA Certificates (show other bugs)
: other
: All All
: -- enhancement (vote)
: ---
Assigned To: Kathleen Wilson
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-22 05:35 PDT by Andris Veinbergs
Modified: 2012-07-06 05:37 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
audit letter (175.87 KB, application/pdf)
2009-09-22 05:49 PDT, Andris Veinbergs
no flags Details
Initial Information Gathering Document (21.01 KB, application/pdf)
2009-09-24 12:44 PDT, Kathleen Wilson
no flags Details
E-ME answer (77.50 KB, application/msword)
2009-09-25 04:29 PDT, Andris Veinbergs
no flags Details
test cer + chain (4.09 KB, application/octet-stream)
2009-09-25 04:30 PDT, Andris Veinbergs
no flags Details
Infrastructure certificates (54.50 KB, application/msword)
2009-09-29 02:53 PDT, Andris Veinbergs
no flags Details
Updated Information Gathering Document (104.38 KB, application/pdf)
2009-09-29 13:57 PDT, Kathleen Wilson
no flags Details
audit letter mozilla (163.89 KB, application/pdf)
2009-10-14 00:31 PDT, Andris Veinbergs
no flags Details
answer2 (95.50 KB, application/msword)
2009-10-14 00:45 PDT, Andris Veinbergs
no flags Details
certificate selling procedeure (208.50 KB, application/vnd.ms-excel)
2009-10-14 00:47 PDT, Andris Veinbergs
no flags Details
CPS (Certification Practis Statment) (1.58 MB, application/pdf)
2010-04-27 04:24 PDT, Andris Veinbergs
no flags Details
new CPS (Certification Practis Statment) (1.64 MB, application/pdf)
2010-06-16 00:38 PDT, Andris Veinbergs
no flags Details
CP (1.23 MB, application/pdf)
2010-08-05 05:17 PDT, Andris Veinbergs
no flags Details
updated cps (1.63 MB, application/pdf)
2010-09-08 23:19 PDT, Andris Veinbergs
no flags Details
Completed Information Gathering Document (116.17 KB, application/pdf)
2010-09-10 11:25 PDT, Kathleen Wilson
no flags Details
KPMG letter regarding webtrust audit (41.66 KB, application/pdf)
2011-02-17 00:16 PST, Karlis Malnieks
no flags Details
Auditor letter regarding anual webtrust audit and its results. (53.47 KB, application/pdf)
2011-06-09 03:28 PDT, Karlis Malnieks
no flags Details
Completed Information Gathering Document (134.82 KB, application/pdf)
2012-01-17 10:18 PST, Kathleen Wilson
no flags Details
Audit letter (190.02 KB, application/octet-stream)
2012-05-17 04:57 PDT, E-ME Root
no flags Details
2012 Audit Statement (85.94 KB, application/pdf)
2012-05-29 13:13 PDT, Kathleen Wilson
no flags Details

Description Andris Veinbergs 2009-09-22 05:35:13 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; lv; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: Other

  CA Details

CA Company/Organization Name: State Joint - Stock company Latvia State Radio $ Television Centre, Latvia, Riga, Erglu Str. 7

Website:
http://www.e-me.lv
http://www.lvrtc.lv 

One Paragraph Summary of CA Company/Organization, including the following:

The main function is to provide electronic document law enforcement in Latvia! 
Our root certificate issues policy certificate. Policy certificate issues Issuing certificates. At the moment we have one Issuing certificate. This certificate is issuing qualified certificate, client certificate authentication, smart card login certificate, SSL certificate, domain controller certificate.
   
Audit Type (WebTrust, ETSI etc.): ETSI TS 101 456
Auditor: KPMG Baltics
Auditor Website: http://www.kpmg.lv/index.thtml/
Audit Document URL(s): not public avaible, i can attach file somewhere or send on e-mail
Certificate Details

Certificate Name: E-ME SSI (RCA)
Summary Paragraph, including the following:

    root certificate issues policy certificate. Policy certificate issues Issuing certificates. At the moment we have one Issuing certificate. This certificate is issuing qualified certificate, client certificate authentication, smart card login certificate, SSL certificate, domain controller certificate.

Diagram and/or description of certificate hierarchy:

    * Number and type of subordinate CAs 1
    * List or description of subordinate CAs operated internally 1
    * List or description of subordinate CAs operated by third parties 0
    * List root CAs that have issued cross-signing certificates for this root CA 0

Certificate HTTP download URL (on CA website): http://info.e-me.lv/en/atbalsts/CA_sertif/
Version: V3
SHA1 Fingerprint: c9 32 1d e6 b5 a8 26 66 cf 69 71 a1 8a 56 f2 d3 a8 67 56 02 
Public key length (for RSA, modulus length) in bits:  4096
Valid From (YYYY-MM-DD): 2009-05-19
Valid To (YYYY-MM-DD):2027-05-19
CRL HTTP URL: http://info.e-me.lv/en/atbalsts/atsauktie_sertif/
Root CA certificate revocation list:
http://www.eme.lv/cdp/E-ME%20SSI%20(RCA).crl

Policy CA certificate revocation list:
http://www.eme.lv/cdp/E-ME%20PSI%20(PCA).crl

Issunig CA certificate revocation list:
http://www.eme.lv/cdp/E-ME%20SI%20(CA1).crl

CRL issuing frequency for end-entity certificates: 12 hours
OCSP URL: http://ocsp.eme.lv/responder.eme
Class (domain-validated, identity/organisationally-validated or EV): http://www.iana.org/assignments/enterprise-numbers (32061)
EV policy OID(s) (if applicable): 1.3.6.1.4.1.32061.1.1.1
Certificate Policy URL: http://info.e-me.lv/en/pakalpojumi/dokumentacija/lvrtc_policies_and_regulations.html
CPS URL: http://info.e-me.lv/en/pakalpojumi/dokumentacija/lvrtc_policies_and_regulations.html
List one or more Trust Bits to enable, choices are Websites (SSL/TLS), Email (S/MIME), and/or Code (code/document signing): SSL, Code signing, document signing, authentification, 
URL of website whose SSL certificate chains to this root (if applying for SSL): http://info.e-me.lv/en/atbalsts/CA_sertif/CA_for_developers.html

Reproducible: Always
Comment 1 Andris Veinbergs 2009-09-22 05:49:18 PDT
Created attachment 402071 [details]
audit letter
Comment 2 Kathleen Wilson 2009-09-24 10:42:33 PDT
Thank you for your interest in including this root certificate in Mozilla. I am accepting this bug, and I will proceed with the information gathering and verification phase as described in https://wiki.mozilla.org/CA:How_to_apply.

Would you please explain the relation of LVRTC, LP, and E-ME?
Is VAS Latvian Radio and Television Centre (LVRTC) the owner/operator of the root listed in this bug?
Is VAS Latvian Post (LP) the owner/operator of the root in bug #412747?
What sort of organization is E-ME, and how does it fit into the picture?
Comment 3 Kathleen Wilson 2009-09-24 12:44:05 PDT
Created attachment 402638 [details]
Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
verified for this request. The items highlighted in yellow indicate where
further information or clarification is needed. Please review the full document for accuracy and completeness.
Comment 4 Andris Veinbergs 2009-09-25 04:29:24 PDT
Created attachment 402818 [details]
E-ME answer

some answer on questions!
Comment 5 Andris Veinbergs 2009-09-25 04:30:25 PDT
Created attachment 402819 [details]
test cer + chain
Comment 6 Andris Veinbergs 2009-09-25 04:43:40 PDT
LP -> Latvian Post
First CA was made by LP caled VAS "Latvijas Pasts". Also LP has created brend name e-me. This brend name has been asigned to Certification Service Proveder department.
with Regulations issued by the Cabinet of Ministers this CA have moved to another organization called LVRTC
Old root,policy,issunig CA is not stoped they are workin, but with them we could issu any certificates because in certificates is written isud by "Latvijas Pasts" (LP)
So we created new CA in brend name e-me, and If there will come onother regulation issued by the Cabinet of Ministers we could keep this name!
Comment 7 Kathleen Wilson 2009-09-25 11:16:24 PDT
Thank you for the updates and clarifications.

I added this request to the pending list:
http://www.mozilla.org/projects/security/certs/pending/#VAS%20LVRTC

For the name of the company, should we use VAS LVRTC? Or E-ME?

> VAS Latvian Post

Is bug #412747 obsolete? If yes, can we close that bug?  Note that no one has responded to my request for further information about that root, which I posted last December.

> Trust Bits
Note that there are only three trust bits that can be enabled: Websites, Email, and Code Signing.

> Test website
> For testing purposes, please provide a URL to a website whose SSL certificate chains up to 
> this root. Note that this can be a test site. 
>> I have attached test *.pem file

Please put the test SSL cert into a test website, and provide the url to the test website. I will then perform some tests from my Firefox installation. This test url will also be used in the public discussion, and then again for testing of the actual code changes after approval.

> Audit
Thanks, I will contact the auditor.

> Domain Name Ownership/Control (required for enablement of the SSL trust bit)
>> Document availed only in Latvian

Please provide translations into English of 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. Please also list the corresponding document(s) and section or page numbers containing the original text.
All documents supplied as evidence should be publicly available and must be addressed in any audit. Any substantial omissions submitted afterwards may need to be confirmed by auditor, at Mozilla's discretion.

> Email Address Ownership/Control (required for enablement of the Email trust bit)
>> Document availed only in Latvian

Please provide translations into English of the sections of the CP/CPS documents that describe the procedures for verifying that the email account associated with the email address in the cert is owned/controlled by the subscriber. Please also list the corresponding document(s) and section or page numbers containing the original text.
All documents supplied as evidence should be publicly available and must be addressed in any audit. Any substantial omissions submitted afterwards may need to be confirmed by auditor, at Mozilla's discretion.

> Identity of Code Signing Subscriber (required for enablement of the Code Signing trust bit)

Please provide the specific document(s) and section or page numbers where the procedures for code signing certs are described.

> Potentially Problematic Practices

Please review the list of Potentially Problematic Practices (http://wiki.mozilla.org/CA:Problematic_Practices). Identify the ones that are and are not applicable. For the ones that are applicable, please provide further information and CP/CPS translations where applicable.
Comment 8 Andris Veinbergs 2009-09-29 02:52:50 PDT
Latvian Post
bug #412747 is not obsolete! I had information that this bug have closed!
Can we complete this bug?

LVRTC
Test site!
https://www.eme.lv/csp-web/certsearch.aspx?lang=LAT 

SSL, Code Signing, E-mail signing
main document in latvian!
http://info.e-me.lv/lv/dokumenti/eme_dokumentacija/E-ME_CPS_IC_CPS_v1.doc 
	
I have translated paragraph 3 and attached the document in Annex
Before you read them you need to know. We issue certificates to organizations or persons who have entered into a contract with us! 
So all information in certificates we get from contracts!


i have read Potentially Problematic Practices, but i can identify any problematic practices, can you maybe point to them!
Comment 9 Andris Veinbergs 2009-09-29 02:53:41 PDT
Created attachment 403450 [details]
Infrastructure certificates

Infrastructure certificates
Comment 10 Kathleen Wilson 2009-09-29 13:57:23 PDT
Created attachment 403577 [details]
Updated Information Gathering Document

> Latvian Post bug #412747 is not obsolete! 
> I had information that this bug have closed!
> Can we complete this bug?

I would be happy to continue processing that inclusion request, as soon as someone provides the information that I asked for in my comment on 2008-12-02. Please see the bug, which is still open.

> LVRTC Test site!

Thanks.

> SSL, Code Signing, E-mail signing main document in latvian!
> http://info.e-me.lv/lv/dokumenti/eme_dokumentacija/E-ME_CPS_IC_CPS_v1.doc 

In the updated Information Gathering document I have provided Google Translations of parts of this document, which is the CPS for Infrastructure Certs, which is for SSL, Code Signing, and Domain Controller certificates.

This document describes the verification of the identity of the individual and organization. However, I did not find any text about procedures to verify that the domain referenced in an SSL cert is owned/controlled by the subscriber. This is a show-stopper in regards to enabling the Websites trust bit.

The procedures for Qualified Certs for signatures and Non-Qualified Certs for secure authentication are described in the CPS of the Issuing CA: http://info.e-me.lv/lv/dokumenti/eme_dokumentacija/E-ME_CPS_ICA_SN_ISI_v1.doc. This document is in English.
Section 3.2.4.1, Non Verified Information: The Subject’s e-mail address is not verified during the initial registration (called "non verified Subscriber information").
Perhaps I’m not understanding, but it looks to me like there is no verification of the ownership/control of an email address to be included in a certificate. This is a problem if the Email trust bit is to be enabled for this root. Do you want to proceed with only enabling the Websites and Code Signing trust bits?

> i have read Potentially Problematic Practices, but i can identify any
> problematic practices, can you maybe point to them!

At the bottom of the updated Information Gathering document is a section describing the relevancy of each Potentially Problematic Practice.  Please review the information that I have gathered, and correct or clarify where needed.
Comment 11 Andris Veinbergs 2009-10-01 23:46:32 PDT
we have little problem raised because of the audit opinion of the certification. our company auditor can not answer to your e-mail because it comes from the public network e-mail address. can you send reqwest for the opinion over the Corporation's e-mail?
Comment 12 Andris Veinbergs 2009-10-02 00:54:03 PDT
we have little problem raised because of the audit opinion of the certification. our company auditor can not answer to your e-mail because it comes from the public network e-mail address. can you send reqwest for the opinion over the Corporation's e-mail?
Comment 13 Kathleen Wilson 2009-10-05 11:26:55 PDT
I now have a mozilla email address:  kwilson@mozilla.com

I have re-sent the request to the auditor.
Comment 14 Andris Veinbergs 2009-10-06 01:18:44 PDT
our Auditor started preparing "Hold Harmless" letter. what adress does it must contain, (mozilla main address)
Comment 15 Kathleen Wilson 2009-10-07 12:22:45 PDT
> mozilla main address
Mozilla Corporation
650 Castro Street
Suite 300
Mountain View, CA, 94041-2021
USA
Comment 16 Andris Veinbergs 2009-10-14 00:31:46 PDT
Created attachment 406186 [details]
audit letter mozilla

audit letter adresed to mozilla corportaion! 
today we are sending to you letter. this letter contains from our company and auditor signed written opinion!
be sure to recive it on adress:
Mozilla Corporation
650 Castro Street
Suite 300
Mountain View, CA, 94041-2021
USA
also we need you to sign this letter and send us back one orginal!
Comment 17 Andris Veinbergs 2009-10-14 00:45:19 PDT
Created attachment 406188 [details]
answer2

contains some information!
Comment 18 Andris Veinbergs 2009-10-14 00:47:06 PDT
Created attachment 406189 [details]
certificate selling procedeure

contains domain validation, organization validation and so on!
Comment 19 Kathleen Wilson 2009-10-15 12:23:46 PDT
Thank you for the information.

> audit letter adresed to mozilla corportaion! 
> today we are sending to you letter. this letter contains from our company and
> auditor signed written opinion!
> also we need you to sign this letter and send us back one orginal!

This will be a problem. I am not authorized to sign agreements on behalf of Mozilla. This is the first time I’ve ever been asked to sign a Hold Harmless letter from an auditor in regards to Mozilla’s root inclusion program.  Other KPMG audit statements that have been provided can be found on
http://www.mozilla.org/projects/security/certs/included/
and
http://www.mozilla.org/projects/security/certs/pending/

Please see if you can get a statement from the auditor that does not require the Hold Harmless agreement.  Perhaps they can include all of their caveats directly in the statement? The WebTrust CA audit statements from KPMG usually have significant caveats directly in their statement.

> We have certificate selling procedure I have attached! 
> Sheet1 tasks 14,15,16,17 and sheet2 issuance of certificate security checklist!

Here’s what I get using Google Translation of Certificate Selling Procedure, Sheet1:
--
14: Record contract and the contents of Annex operator tool
15: Electronically notify the contact person for the contract that it can begin to apply for a qualified certificate (indicating the application site, as well as to inform, that can apply for a mobile operator services (transferred to the mobile operator contact information) (standard e-mail template). Done electronically (e-mail) request for a certificate of production safety supervisor
16: Production of the certificate and sent electronically?? PN client to act as a template is entered in the certificate no. And the number of
17: Upon receipt of PN, either electronically or in fact sign electronically? to sign and send LVRTC SPD assistant
--

It’s not clear to me what this means. Is this the process for issuing SSL certificates?  Does it include sending a query-response email to the contact person at the domain to be referenced in the certificate?

Here’s what I get using Google Translation of Certificate Selling Procedure, Sheet2:
--
The assessment of the following things are checked: 
x) The service contract between the service provider and client; 
x) domain ownership using the Latvian public and the world's available resources; 
x) If necessary, the company's proxy; 
x) the correctness of the certificate utility; 
x) Does the certificate can not be used in the creation of harmful activities.
--

The statement “domain ownership using the Latvian public and the world's available resources” is on the right track, but is still not enough information.  For example, what sorts of available resources are used, and how is the information that is retrieved from those resources used to verify that the certificate subscriber owns/controls the domain name?

This information needs to be part of a public and audited document, such as the CPS for SSL certs. I think it would be OK if this information is added to the CPS for SSL certs now, with the understanding that it is clarifying the description of the existing procedure, and the updated description will be part of all future audits. Is it reasonable for you to update your CPS for SSL certs?
Comment 20 Andris Veinbergs 2009-10-15 23:41:44 PDT
	
There is a possibility that the letter can be signed by any other person representing your company. Our company policy does not allow existing exceptions to the formal procedure for the provision of views!



As example we can check latvian domain name in publicly avaible wb site! http://www.nic.lv/?lang=en 

Somtimes also we need to write offical letter to NIC or IANA or other organizations to verify domain names!

In next Infrastructure Certificate CPS update i will also include these assessments. 
Is it okey if next update will be publicated in next few months, in this year?
Comment 21 Kathleen Wilson 2009-10-21 14:02:11 PDT
> Hold Harmless agreement

I have sent an internal Mozilla request to find out what to do about this.  It may take a while to get the appropriate reviews and a decision.

> In next Infrastructure Certificate CPS update i will also include these
> assessments. Is it okey if next update will be publicated in next 
> few months, in this year?

Yes, that should be fine, as long as it is done before this request reaches the top of the queue for public discussion. Please post into this bug when the CPS has been updated.

I have added this request to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Comment 22 Kathleen Wilson 2009-11-03 10:01:06 PST
I just got off the phone with the auditor from KPMG. It turns out that the Hold Harmless agreement is only needed if Mozilla wants to receive the full audit statement/report. 

The Audit Letter that has been attached to this bug states when the audit was performed, and that the audit carried out under Latvian legislation is equivalent to the ETSI TS 101 456 criteria.

The auditor confirmed that the recent audit did include the root in this request. Additionally, items that were noted in the previous audit of the E-ME infrastructure/processes had been addressed and were confirmed to be resolved in this recent audit.

I believe this is sufficient information, and that we do not need to receive the full audit report. Therefore, the Hold Harmless agreement does not need to be signed.
Comment 23 Andris Veinbergs 2009-11-12 04:21:54 PST
so we are waiting to close public discusion!

	
when can we expect to be included trusted root list?
Comment 25 telnov 2010-02-09 01:09:59 PST
For my mind, the information provided by E-ME is fully describing the root certificate, E-ME CA structure and policies. Policies are available on the Internet for public reading and commenting. E-ME CA auditor is a well-known company (KPMG) and auditor's statement (2009) was qualified and in general positive.

I can't see any reasons for not including the E-ME root certificate into Mozilla's root store.
Comment 26 David E. Ross 2010-02-13 11:17:56 PST
To all those who are impatient for this certificate to be approved and implemented for Gecko-based products:

The presence of a root certificate in the NSS database used by Gecko-based products indicates that users can place some degree of trust in the use of that certificate for secure Web browsing.  For that trust to be valid, the certificate authority owning the root certificate must undergo some scrutiny, which takes time.

The timeline for such scrutiny is described at <https://wiki.mozilla.org/CA:Schedule>, which also shows the current queue for the public discussion that is part of the process.  This request is in the queue, but 7 other requests are ahead of this one.  Because the public discussion depends on volunteers, only a few requests can be in public discussion at one time.  

Further expressions of the need for haste will not speed the process.  Any shortcuts or other measures to hasten the process can only weaken the trust users have in the overall certificate database.

Those who are anxious for these root certificates -- those who already trust them and who have no patience with the Mozilla process for scrutinizing certificate authorities -- can download and install the root certificates themselves.  The links are at <http://www.mozilla.org/projects/security/certs/pending/#VAS LVRTC>.

When downloaded, open the Certificate Manager at the "Authorities" tab and select the Import button.  On SeaMonkey, the Certificate Manager is reached from the menu bar via [Edit > Preferences > Privacy & Security > Certificates]. Since I don't use Firefox, I don't know the path of navigation there.
Comment 27 KM 2010-03-01 09:41:55 PST
I'm using this CA for a while and so far there was no problems. Latvia is small country therefor you can't expect big activity in public discussion. I don't see any reasons not to include E-ME root CA in the Mozilla root CA list. As described above, the KPMG is well-known auditor company therefor it's audit report should be enough to do the thing.
Comment 28 Kathleen Wilson 2010-04-01 14:24:28 PDT
Andris, In comment #20 you indicated that the Infrastructure Certificate CPS would be updated to clarify the domain verification procedures (see comment #19). Please post the URL to the updated document here in this bug.
Comment 29 Kathleen Wilson 2010-04-07 16:03:14 PDT
Andris, Please post an update in this bug.
Comment 30 Andris Veinbergs 2010-04-27 04:22:00 PDT
We've created a new document that describes the application, issuance processes for all types of certificates. Text is simultaneously translated into English, but if there is uncertainty give a message!
Comment 31 Andris Veinbergs 2010-04-27 04:24:57 PDT
Created attachment 441762 [details]
CPS (Certification Practis Statment)
Comment 32 Kathleen Wilson 2010-04-27 11:55:55 PDT
It appears that your website has recently changed.  Please provide new links to the new versions of the documents on your website to replace the links in
http://www.mozilla.org/projects/security/certs/pending/#VAS%20LVRTC
Document	LVRTC Policies and Regulations
Document	Download links for the root and intermediate CAs
Document	Certificate Policy (English)
Document	CPS of Root CA (English)
Document	CPS of Policy CA (English)
Document	CPS of Issuing CA (English)
Document	CPS of Infrastructure Certificates (Latvian)
Comment 33 Kathleen Wilson 2010-05-07 14:11:45 PDT
In the pending page I changed the entry from VAS LVRTC to E-ME, so the link is now:
http://www.mozilla.org/projects/security/certs/pending/#E-ME

Please provide the updated links to the documents listed in Comment #32, so that I can update the entry on the pending page, and get this request ready for public discussion.
Comment 34 Andris Veinbergs 2010-05-09 22:02:23 PDT
LVRTC Policies and Regulations
http://info.e-me.lv/?page_id=756


Download links for the root and intermediate CAs
http://info.e-me.lv/?page_id=62

LVRTC E-ME certificate policy eng   http://info.e-me.lv/wp-content/uploads/2010/01/50SP00.09.11_1014_E-ME_CP_SP_v-2-1_LAT_ENG.edoc 

E-ME CPS of Root, policy, issuing   http://info.e-me.lv/wp-content/uploads/2010/01/50SP00.09.11_434_E-ME_SN_v.1.0_LAT_ENG.edoc
Comment 35 Andris Veinbergs 2010-05-09 22:04:56 PDT
for LVRTC E-ME Policies and Regulations
is also links
http://info.e-me.lv/?page_id=230
Comment 36 Kathleen Wilson 2010-05-10 13:44:15 PDT
I am not able to open either of these:

LVRTC E-ME certificate policy eng  
http://info.e-me.lv/wp-content/uploads/2010/01/50SP00.09.11_1014_E-ME_CP_SP_v-2-1_LAT_ENG.edoc 

E-ME CPS of Root, policy, issuing  
http://info.e-me.lv/wp-content/uploads/2010/01/50SP00.09.11_434_E-ME_SN_v.1.0_LAT_ENG.edoc

When I try opening with MS Word I get an error that the file is corrupt and cannot be opened.

Which document replaces the link that I had for "CPS of Infrastructure Certificates (Latvian)"?  This document was important because it had the procedures for the SSL and Code Signing certs.
Comment 37 Andris Veinbergs 2010-05-10 22:03:18 PDT
we have created new document called E-ME CPS, there is included SSL, Code Signing, Domain controler certificates and docoment is avaiable in english at site: 

http://info.e-me.lv/wp-content/uploads/2010/01/50SP00.09.11_434_E-ME_SN_v.1.0_LAT_ENG.edoc

format edoc means it is digitaly signed with EU qualified certificate, you can open it by downloading application on link:
http://info.e-me.lv/wp-content/uploads/2010/02/PostCSP.ESigner.2.0.71.0.msi 

or upload and verify in link:

http://info.e-me.lv/?page_id=205
Comment 38 Kathleen Wilson 2010-05-11 14:25:16 PDT
Well, I tried downloading the documents and the uploading them into http://info.e-me.lv/?page_id=205

I got the error: Your current operating system “Mac OS X” can not open this file!

Then I had to Force Quit my Firefox browser.
Comment 39 Kathleen Wilson 2010-05-17 11:05:11 PDT
If I'm understanding correctly, then the documents of interest are as follows:

CPS (English):  http://info.e-me.lv/wp-content/uploads/2010/01/50SP00.09.11_434_E-ME_SN_v.1.0_LAT_ENG.edoc
This document includes information about SSL, Code Signing, and Domain Controller certificates.

Certificate Policy (English): http://info.e-me.lv/wp-content/uploads/2010/01/50SP00.09.11_1014_E-ME_CP_SP_v-2-1_LAT_ENG.edoc   

Certificate Selling Procedure: https://bugzilla.mozilla.org/attachment.cgi?id=406189

Is the document that you attached in Comment #31 the same as http://info.e-me.lv/wp-content/uploads/2010/01/50SP00.09.11_434_E-ME_SN_v.1.0_LAT_ENG.edoc ?
Comment 40 Andris Veinbergs 2010-05-17 21:55:38 PDT
Yes, you understand correct

comment 31 is the same document, but newer version!
Comment 41 Kathleen Wilson 2010-05-18 13:23:55 PDT
In Comment 19, 20, and 21 it was indicated the further information about domain verification procedures would be added to the next Infrastructure Certificate CPS update.

I am not able to find that information in the attached document
https://bugzilla.mozilla.org/attachment.cgi?id=441762

What am I missing?
Comment 42 Kathleen Wilson 2010-06-14 11:40:58 PDT
Andris, This request is next in the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

However, I will not be able to start the discussion until I am able to find the text in the appropriate CP/CPS document describing the procedures for verifying that the certificate subscriber owns/controls the domain name to be included in the certificate, as per section 7 of http://www.mozilla.org/projects/security/certs/policy/.
Please see https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership

Please point me to this information in the appropriate CP or CPS as soon as possible.
Comment 43 Andris Veinbergs 2010-06-16 00:38:14 PDT
Created attachment 451522 [details]
new CPS (Certification Practis Statment)

I have created new document, i would like to know is it okay for start public discusion!
Comment 44 Kathleen Wilson 2010-06-16 10:49:03 PDT
The newly attached document, 
https://bugzilla.mozilla.org/attachment.cgi?id=451522, 
is called “Certification Service provider E-ME Certification Practice Statement”.

According to my notes, this root does not have sub-CAs that are operated by third parties. My notes say: “As per E-ME policy requirements, this root will have only one Policy sub-CA, which is operated by E-ME. The Policy CA can sign many Issuing sub-CAs. There is currently one Issuing CA, which is operated by E-ME.  All future Issuing CAs will also be operated by E-ME.”

I don’t believe this matches the text in the attached document. In section 3.3 it looks like a Trusted CA Certificate is provided to a Trusted CA via a key ceremony. Then my interpretation is that the Trusted CA takes the Trusted CA Certificate on computer readable media to their organization.  Thus, my interpretation is that there are or will be sub-CAs operated by third parties. Am I not understanding this correctly?

Please see https://wiki.mozilla.org/CA:SubordinateCA_checklist. Using the terminology in this wiki page, please explain which of the four possible combinations apply to the hierarchy of this root.

Also I’m still not finding text to satisfy the Mozilla CA Certificate Policy requirements in regards to verification of ownership/control of the domain name to be included in the certificate. Please see https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
The information satisfying this requirement needs to be in a public-facing and audited document. (Note that I cannot open the .edoc documents on your website, so if the information is in one of those, the document will need to be attached to this bug as a .pdf)
Comment 45 Andris Veinbergs 2010-06-16 22:57:33 PDT
1. it is process how we issue sub-CA, because each CA is separate from another!

2. we use In-house public subordinate CAs

3. ownership domain control, see section 3.2.3.  (Web Site (SSL) certificates is carried out following checks)
Comment 46 Kathleen Wilson 2010-06-17 15:11:13 PDT
Thank you for the clarification. Now my understanding is that you use the term "Certification Service Provider (CSP)" to refer to E-ME operating the full hierarchy under this root. And E-ME may subcontract end-entity certificate registration to RAs.

> 3. ownership domain control, see section 3.2.3.  
> (Web Site (SSL) certificates is carried out following checks)

The full text that I find in the document is:
" Web Site (SSL) certificates is carried out following checks:
* Domain Clearance home using network resources;
* Certifikate request verification of a contract;
* Review of good practice standards (such as the internal domain is *. int)."

This is not sufficient information to satisfy section 7 of the Mozilla CA Certificate Policy. Please see Comment #19, Comment #20, and Comment #21.
There needs to be public-facing and audited documentation (such as in the CP or
CPS) about steps that must be taken by the CSP/RA to verify that the SSL certificate subscriber owns/controls the domain name to be included in the
certificate. There should be sufficient information about what public resources the data is retrieved from, and how that data is used to verify the ownership/control of the domain name to be included in the certificate.

> Certificate Policy (English, .edoc):
> http://info.e-me.lv/wp-content/uploads/2010/01/50SP00.09.11_1014_E-ME_CP_SP_v-2-1_LAT_ENG.edoc

Please attach a .pdf version of this CP to this bug.
Comment 47 Andris Veinbergs 2010-08-05 05:15:32 PDT
pdf of Certificate Policy
Comment 48 Andris Veinbergs 2010-08-05 05:17:07 PDT
Created attachment 463125 [details]
CP

Certificate Policy
Comment 49 Kathleen Wilson 2010-08-09 14:41:41 PDT
Thank you for the pdf version of the CP.

Please point me to the documentation of E-ME’s process for verifying that the SSL certificate subscriber owns/controls the domain name to be included in the certificate.

https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership

Comment #19: The statement “domain ownership using the Latvian public and the world's available resources” is on the right track, but is still not enough information.  For example, what sorts of available resources are used, and how is the information that is retrieved from those resources used to verify that the certificate subscriber owns/controls the domain name? 

Comment #20: As example we can check latvian domain name in publicly avaible wb site! http://www.nic.lv/?lang=en   Somtimes also we need to write offical letter to NIC or IANA or other organizations to verify domain names!  In next Infrastructure Certificate CPS update i will also include these assessments.  Is it okey if next update will be publicated in next few months, in this year?

Comment #21: Yes, that should be fine, as long as it is done before this request reaches the top of the queue for public discussion. Please post into this bug when the CPS has been updated.
Comment 50 Andris Veinbergs 2010-08-16 22:43:55 PDT
i will update cps with your asked information in september.

Comment #20: As example we can check latvian domain name in publicly avaible wb
site! http://www.nic.lv/?lang=en   Somtimes also we need to write offical
letter to NIC or IANA or other organizations to verify domain names!  In next
Infrastructure Certificate CPS update i will also include these assessments. 
Is it okey if next update will be publicated in next few months, in this year?
Comment 51 Andris Veinbergs 2010-09-08 23:19:29 PDT
Created attachment 473411 [details]
updated cps

we have created new cps, where is also domain verification utc. 
is this document now ok?
Comment 52 Kathleen Wilson 2010-09-10 11:25:05 PDT
Created attachment 474133 [details]
Completed Information Gathering Document

Updated the Information Gathering Document according to the updated CPS.

I'll post a comment in this bug when I start the discussion.
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Comment 53 Kathleen Wilson 2010-09-30 10:05:58 PDT
I am now opening the first public discussion period for this request from E-ME to add the “E-ME SSI (RCA)” root certificate.

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

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

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

The discussion thread is called “E-ME Root Inclusion Request”

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

A representative of E-ME must promptly respond directly in the discussion thread to all questions that are posted.
Comment 54 Andris Veinbergs 2010-10-04 04:08:33 PDT
OK
Comment 55 Kathleen Wilson 2010-10-28 13:01:43 PDT
I am closing the first discussion of this root inclusion request for two reasons:

1) No representative of the CA has responded in the discussion to questions posted. Email communication with me is insufficient. The CA needs to be actively involved in the discussion of their request.

2) It appears that the representative of E-ME who made the inclusion request is no longer working at E-ME. E-ME needs to provide a representative who is currently associated with the organization operating this root.
Comment 56 Karlis Malnieks 2011-02-17 00:15:12 PST
I am writing regarding e-me root certificate inclusion in Mozilla trusted root list. As I understang there was problem, with responce from our company and therefor discution was closed. Is it possible to re-open discussion and update your contact person from Andris Veinbergs to me – Karlis Malnieks. Presently,  I am the manager of IT services at Certification services department. If there are any questions or jobs for me please do not hesitate and contact with me. I'm attaching the newest KPMG webtrust audit letter.
Comment 57 Karlis Malnieks 2011-02-17 00:16:45 PST
Created attachment 513057 [details]
KPMG letter regarding webtrust audit
Comment 58 Kathleen Wilson 2011-02-17 14:27:32 PST
Karlis, before we re-open the discussion of this request, would you please review the attached Completed Information Gathering Document for accuracy? Please post corrections/updates in this bug. 

Also, please confirm that the test website (as per the document) works correctly within the Firefox browser with OCSP enforced (after importing the root cert). Or provide a new url to a website whose SSL cert chains up to this root.
Comment 59 Karlis Malnieks 2011-02-20 12:06:07 PST
Atached documents seems to be OK and up to date. 
The test url still works: https://www.eme.lv/csp-web/certsearch.aspx?lang=LAT
Or you can trie one of these: 
https://www.eme.lv/csp-web/certupload.aspx?lang=LAT
https://vidis.vid.gov.lv/Alr_user/Pages/Login.aspx
Comment 60 Kathleen Wilson 2011-03-03 13:54:08 PST
As per Mozilla practices, I'll have to contact KPMG to confirm the authenticity of the attached audit document.
(https://bugzilla.mozilla.org/attachment.cgi?id=513057)

Is Andris Brieze still the correct person to contact at KPMG Baltics?


CPS section 3.2.3.1 says:
"Web Site (SSL) certificates is carried out following checks:
- Domain Clearance home using network resources (Http://www.nic.lv/?lang=en (Latvian), http://www.iana.org/domains/ (World));
- Certifikate request verification of a contract;
- Review of good practice standards"

What does "Domain Clearance home using network resources" mean? Exactly what steps does the RA have to take to complete this?

Since domain validation is delegated to third parties, I think the requirements need to be more clear in the CPS about the actions that the RA must take to confirm that the certificate subscriber owns/controls the domain name to be included in the certificate.
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
Comment 61 Andris Veinbergs 2011-04-04 23:54:47 PDT
As per Mozilla practices, I'll have to contact KPMG to confirm the authenticity
of the attached audit document.
(https://bugzilla.mozilla.org/attachment.cgi?id=513057)

Is Andris Brieze still the correct person to contact at KPMG Baltics?

What does "Domain Clearance home using network resources" mean? Exactly what
steps does the RA have to take to complete this?

Since domain validation is delegated to third parties, I think the requirements
need to be more clear in the CPS about the actions that the RA must take to
confirm that the certificate subscriber owns/controls the domain name to be
included in the certificate.
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership Collapse All Comments
Expand  

Domain verification is not transferred to third parties, domain ownership verification of the CA security officer in person, using policies, procedures. After the certificate request for CA security officer with the policies set down the web site domain ownership, if the request came from a company that is in this web site, then the certificate is issued if this is not the CA Security Officer in person contact with the company and asked to approve the certificate request and then be issued a certificate!
Comment 62 Karlis Malnieks 2011-05-27 03:20:32 PDT
Question about Domain Clearance home using network resources is answered above by Andris Veinbergs, whitch is our Outsorced Security consultant.

About Andris Brieze - no he is no longer present at KPMG Baltics. His place took:
Girts Kronbergs 
KPMG Baltics SIA
Vesetas iela 7, LV-1013
Rīga, Latvija
gkronbergs@kpmg.com

Right now we just accomlished our regular audit and I will send monday updated auditors letter.

Is there something else what we need to provide to keep process ongoing?
Comment 63 Karlis Malnieks 2011-06-09 03:28:13 PDT
Created attachment 538227 [details]
Auditor letter regarding anual webtrust audit and its results.
Comment 64 Karlis Malnieks 2011-06-09 03:30:00 PDT
Please find above atached auditor letter. And please give respond if there is something else you need to keep process ongoing?
Comment 65 Kathleen Wilson 2011-06-17 11:13:08 PDT
I have a couple concerns about this root inclusion request.

From the first discussion
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/55423fe6dc8a6aa3#
"I am closing this discussion for two reasons:
1) No representative of the CA has responded in the discussion to questions posted. Email communication with me is insufficient. The CA needs to be actively involved in the discussion of their request.
2) It appears that the representative of E-ME who made the inclusion request is no longer working at E-ME. E-ME needs to provide a representative who is currently associated with the organization operating this root."

Having a root included in NSS is not a one-time effort. After a CA has a root included in NSS, it is expected that the CA will continue to be aware of ongoing discussions and updates to the Mozilla CA Certificate Policy. The CA is required to send regular updated audits to Mozilla. The CA is required to update their policies as the Mozilla CA Certificate Policy is updated.

Concern #1) In my opinion E-ME has not demonstrated that they are sufficiently staffed to maintain the level of involvement and expertise required to have a root included in NSS. The person who was initially working on this root inclusion request disappeared during the discussion of this request, and we found later that it was due to a personnel change. Now this person is again helping with this request as a consultant. What other regularly employed expertise does E-ME have in regards to running a root that is to be included in NSS? How is Mozilla to be assured of E-ME's continued, active involvement in the program?

Concern #2)  According to the Mozilla CA Certificate Policy: "We will determine which CA certificates are included in software products distributed through mozilla.org, based on the benefits and risks of such inclusion to typical users of those products." and "We require that all CAs whose certificates are distributed with our software product ... provide some service relevant to typical users of our software products"
I do not yet understand why this root needs to be included in NSS. How will such inclusion benefit typical Mozilla users? Please describe the types of Mozilla users who are likely to encounter your root certificate as relying parties while web browsing (HTTPS servers doing SSL), sending/receiving email to their own MTA (SMTPS, IMAPS servers doing SSL), sending/receiving S/MIME email (S/MIME email certs), etc. Have you considered having your root cross-signed by a root already included in NSS, rather than having your root directly included?
Comment 66 E-ME Root 2011-07-29 02:49:18 PDT
Hello, we fully understand your concerns and can ensure that we satisfy your concerns.

About E-ME – we are the only national level qualified certification services provider in Latvia. That means we meet all the requirements determined by the Europe Union – we have qualified and sufficient stuff to provide such services. Our enterprise is state joint and there for there can’t be doubt of E-ME involvement in services. Our state law regulation determinate that qualified certification services provider should do annual CA audits and we will provide you its results annually.

About concerns of Mozilla benefits of including E-ME root certificate in Mozilla: 
1.	Our root certificate is already included in Microsoft root store and clients using government provided services are recommended to use Internet explorer not Firefox although Firefox is widely used in our country by user.
2.	Our clients are such organizations as The Treasury of Latvia (http://www.kase.gov.lv/?object_id=6416 ), State Revenue Service (http://www.vid.gov.lv/default.aspx?tabid=4&hl=2 ), State Regional Development Agency and others which provide public services.
3.	E-ME qualified certificates will be included in national level Electronic Identification Cards (eID), which due to regulations is valid in all European Union.
4.	We are providing such certificate services as: SSL, Authentification, Signing, Code Signing, Domain Controller and other infrastructure certificates. And we are developing the new services as well. 

About the future process organization: There is and always will be some changes in stuff, in enterprise structure as enterprise is continuously evaluating. There for I have made and add to discussion new e-mail address which will be from now the official address of enterprise for such kind of communication: root@lvrtc.lv. I will provide that always someone are checking discussions and provide our answers and concerns to you or anybody else.

About our enterprise: we are State Joint Stock Company Latvia State Radio and Television Center. Our business activities are: terrestrial broadcasting of radio and television programmes, telecommunication services and providing certification services (E-ME).
Comment 67 E-ME Root 2011-07-29 02:55:22 PDT
Additional information and official contacts:
SJSC Latvia State Radio and Television Center
Adress: Erglu street 7, Riga, Latvia, Post Index: LV-1012
VAT: LV40003011203
Phone: +371 67108704, +371 67315300
e-mail: lvrtc@lvrtc.lv
Comment 68 Kathleen Wilson 2011-07-29 13:54:40 PDT
Thank you for the clarification. I will proceed with processing this request.

I need to communicate with the auditor to confirm the authenticity of the audit statement that was provided in Comment #63. Is gkronbergs@kpmg.com still the person at KPMG to contact?
Comment 69 Kathleen Wilson 2011-07-29 14:50:54 PDT
Is my understanding of the following two documents correct?

CP: http://info.e-me.lv/wp-content/uploads/2010/01/E-ME_CP_SP_v2-3_LAT_ENG.pdf
This document basically says that the verification procedures are documented in the subordinate CA's CPS, which is approved by E-ME. 

CPS: http://info.e-me.lv/wp-content/uploads/2010/01/E-ME_SN_v1_3_LAT_ENG.pdf
This document applies only to the issuance of subordinate CA certificates. Each issuing subordinate CA will have its own CPS regarding the issuance of end-entity certificates.


Is there a CP/CPS document that all issuing subordinate CAs must follow which describes the minimum procedures for verifying subscriber data for SSL certs and code signing certs?  Please see
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
and
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Identity_of_Code_Signing_Certificate_Subscriber


Please also see https://wiki.mozilla.org/CA:SubordinateCA_checklist
and provide the relevant information.
Comment 70 E-ME Root 2011-08-08 22:48:05 PDT
Yes, you could communicate with our auditors from KPMG. gkronbergs@kpmg.com still the person with whom you could ask any question regarding our auditors results.
Comment 71 E-ME Root 2011-08-09 01:20:19 PDT
Answer to Comment 69

All necessary information you could find in this document:

http://info.e-me.lv/wp-content/uploads/2010/01/E-ME_SN_v1_3_LAT_ENG.pdf

Yes, both documents are correct.
Comment 72 E-ME Root 2011-08-12 03:17:11 PDT
Hello, Katleen!

Did you find all necessary information or we need to explain more in deatails?
Comment 73 E-ME Root 2011-08-12 03:18:59 PDT
Hello, Kathleen!

Did you receive all necessary information or we need to explain in deatails?
Comment 74 Kathleen Wilson 2011-08-12 11:13:59 PDT
I have reviewed this document
http://info.e-me.lv/wp-content/uploads/2010/01/E-ME_SN_v1_3_LAT_ENG.pdf

section 3.2: "This section states requirements for the verification of the identity of E-ME CSP Trusted Certification Authority Applicants. The requirements for PKI entities subordinated to a Trusted CA are stated in the corresponding Trusted CA Certification Practice Statement."

Where is the policy governing the verification of domain ownership/control for end-entity certificate subscribers? There needs to be a policy that applies to the practices for all subCAs' issuance of end-entity certs.
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership

Where is the policy governing the verification of identity, organization, and authority for end-entity code signing subscribers? There needs to be a policy that applies to the practices for all subCAs' issuance of end-entity certs.
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Identity_of_Code_Signing_Certificate_Subscriber
Comment 75 E-ME Root 2011-08-15 06:40:09 PDT
We will look through our policies and ww will provide this information as soon as possible.
Comment 76 Kathleen Wilson 2011-08-15 09:04:13 PDT
(In reply to Karlis Malnieks from comment #63)
> Created attachment 538227 [details]
> Auditor letter regarding anual webtrust audit and its results.

I have exchanged email with gkronbergs@kpmg.com, and Girts has confirmed that this statement was provided by KPMG.
Comment 77 E-ME Root 2011-08-25 00:40:23 PDT
(In reply to Kathleen Wilson from comment #74)
> Where is the
> policy governing the verification of domain ownership/control for end-entity
> certificate subscribers? There needs to be a policy that applies to the
> practices for all subCAs' issuance of end-entity certs.
> https://wiki.mozilla.org/CA:
> Recommended_Practices#Verifying_Domain_Name_Ownership

Where is the policy
> governing the verification of identity, organization, and authority for
> end-entity code signing subscribers? There needs to be a policy that applies
> to the practices for all subCAs' issuance of end-entity certs.
> https://wiki.mozilla.org/CA:
> Recommended_Practices#Verifying_Identity_of_Code_Signing_Certificate_Subscrib
> er

We have updated our policies and added your necessary information in our CA CPS. Please find our latest CPS: http://info.e-me.lv/wp-content/uploads/2011/08/E-ME-SN-v1_9-LatEng.pdf 
Answer on your questions you could find in section 4.1.3.1
Comment 78 E-ME Root 2011-09-05 04:37:51 PDT
Kathleen,

Did you have a time to look our new policy? Did you find all necessary information?
Comment 79 David E. Ross 2011-09-10 11:16:35 PDT
Where do you state how you protect your system against malware (e.g., viruses)?   

Where do you state your internal password controls?  Examples:  Do you require a different password for each distinct login?  Does anyone have all passwords, or do you limit passwords to different individuals according to their responsibilities?
Comment 80 E-ME Root 2011-09-16 04:37:49 PDT
(In reply to David E. Ross from comment #79)
> Where do you state how you protect your system against malware (e.g.,
> viruses)? 
  Our responsible person of security who can answer to this question is ill and not at the work already several week, so we can't answer properly to this question. When he will be back we will answer as fast as possible.

But to the other questions we can answer as follows:
> 
> Where do you state your internal password controls?  Examples:  Do you
> require a different password for each distinct login?  Does anyone have all
> passwords, or do you limit passwords to different individuals according to
> their responsibilities?

We do have separate logins for service accounts and service administrators. Access to the racks is only possible under the dual control (two keys required to open the rack doors). Two categories of users have all passwords: security officer and IS administrator. But for critical services (like CA service), we do use additional control mechanism by implementing HSM cryptographic devices (operations with this service only possible under dual control + using at least two HSM smartcards + HSM smartcard password is only known to one person this card belongs to).
Comment 81 Kathleen Wilson 2011-09-20 14:04:00 PDT
Please review the CA Communication that was sent on September 8, and is available here: https://wiki.mozilla.org/CA:Communications

Please add a comment to this bug to provide your response to the action items listed in the CA Communication. For more information about action items #1 and #3, please see items #6 and #7 of
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
Comment 82 E-ME Root 2011-09-26 02:03:10 PDT
(In reply to Kathleen Wilson from comment #81)
> Please review the CA Communication that was sent on September 8, and is
> available here: https://wiki.mozilla.org/CA:Communications
> 
> Please add a comment to this bug to provide your response to the action
> items listed in the CA Communication. For more information about action
> items #1 and #3, please see items #6 and #7 of
> https://wiki.mozilla.org/CA:
> Information_checklist#Verification_Policies_and_Practices

We would like to give you our answers to your discussion.

1. We have PKI internal and outward audit annually. In Latvia we have Electronic document law which states that we have to do this audit every year. This year our audit has made by audit company KPMG. This includes all third party RAs. Third party CAs is not participating in our services. Besides, all the year round we have IS monitoring (SCOM). 
2. Our Root is not cross-signed with some other certificate.
3. We are using multi-factor authentification. To reach certificate issuance process all users have own account in local net (in work area) and authentification is made by users name and password. Further to reach IS (information system) authorization is done by smart card. The procedure how to reach IS recourses are described in our internal documentation - Security rules for users.
4. We are not providing automatic issuance of certificates. All requirements are processing manually, that’s mean every requirement is approved separately.
5. E-ME is using third party RA only for acceptance of application form for qualified and authentification certificates. All accepted application forms manually and separately is processing by E-ME main Office. If the application form correspond to all criteria, certificate production and issuance is allowed. Third party RA don’t accept the application forms for infrastructure certificates (SSL, domain certificate, Code signing certificates and others), this is done by E-ME main Office without third parties involvement. We (by ourselves) are concluding the agreement, processing application and issuing the certificates.
Comment 83 E-ME Root 2011-09-26 02:06:05 PDT
(In reply to E-ME Root from comment #82)

We would like to add that we will be able to shut down certificate issuance quicqly if we are alerted of intrusion
Comment 84 E-ME Root 2011-09-26 03:42:02 PDT
(In reply to David E. Ross from comment #79)
> Where do you state how you protect your system against malware (e.g.,
> viruses)?   

We would like to answer to this question as well. 
Our Certificate Policy point 4.6.6.1 states that we have to protect our system from viruses. We are protecting our system from viruses with anti-virus program McAfee and we have Security protection document - Dangerous software detection and destruction procedure, which describes how anti-virus program works. For our auditors this document is sufficient and we are not receive any comments from our auditor point of view.
Comment 85 Kathleen Wilson 2011-09-28 11:24:10 PDT
> 3. We are using multi-factor authentification. To reach certificate issuance
> process all users have own account in local net (in work area) and
> authentification is made by users name and password. Further to reach IS
> (information system) authorization is done by smart card. The procedure how
> to reach IS recourses are described in our internal documentation - Security
> rules for users.


Is certificate issuance only done from within IS resources?
Comment 86 E-ME Root 2011-10-03 04:36:27 PDT
In reply to Kathleen Wilson from comment #85)
> > 3. We are using multi-factor authentification. To reach certificate issuance
> > process all users have own account in local net (in work area) and
> > authentification is made by users name and password. Further to reach IS
> > (information system) authorization is done by smart card. The procedure how
> > to reach IS recourses are described in our internal documentation - Security
> > rules for users.
> 
> 
> Is certificate issuance only done from within IS resources?

Yes for infrastructure certificates.
Comment 87 E-ME Root 2011-10-28 04:43:49 PDT
Hello Kathleen,

We would like to know how is going your procedures. When we could restart and continue our discussion?
Comment 88 E-ME Root 2011-11-07 06:13:27 PST
Hello,

As our discussion stuck due to Digi Notar event but our customer don't understand why we have so long discussions with you and they are not very patient, we would like to ask you one question:

It goes about any technical possibility (extension, add-on) to ensure manual import of the root certificate into browser’s root certificates store by user launching additional script/program. Would the browser accept such manual operation by an extension?



We would be very glad of any answer from your side.

Thank you,

E-ME root
Comment 89 Kathleen Wilson 2011-11-07 14:05:08 PST
(In reply to E-ME Root from comment #88)
> It goes about any technical possibility (extension, add-on) to ensure manual
> import of the root certificate into browser’s root certificates store by
> user launching additional script/program. Would the browser accept such
> manual operation by an extension?


Yes, it is technically possible to write a Firefox add-on that imports a root certificate and sets the trust bits. I don't know how to do this, but I'm sure that a smart developer will be able to figure it out.
Comment 90 E-ME Root 2012-01-16 04:52:24 PST
Hello,

We would be very glad to find out when you expect to reopen the discussion regarding root certificates.

E-ME root
Comment 91 Kathleen Wilson 2012-01-17 09:18:47 PST
(In reply to E-ME Root from comment #90) 
> We would be very glad to find out when you expect to reopen the discussion
> regarding root certificates.

I will work on this request this morning, and try to get the discussion started today.
Comment 92 Kathleen Wilson 2012-01-17 10:18:04 PST
Created attachment 589229 [details]
Completed Information Gathering Document
Comment 93 Kathleen Wilson 2012-01-17 11:06:06 PST
I am now opening the second public discussion period for this request from E-ME to add the “E-ME SSI (RCA)” root certificate, and to enable the websites and code signing trust bits.

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

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

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

The discussion thread is called “Second Discussion for E-ME Root Inclusion Request”

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

A representative of E-ME must promptly respond directly in the discussion thread to all questions that are posted.
Comment 94 Kathleen Wilson 2012-03-20 14:48:03 PDT
Please post a comment in this bug containing E-ME's response to the action items of the recent CA Communication:
https://wiki.mozilla.org/CA:Communications#February_17.2C_2012
Comment 95 Kathleen Wilson 2012-03-27 16:35:07 PDT
The discussion of this request is now closed. There are three action items that need to be completed and confirmed before this request may move into the approval phase.

1) Action E-ME: Create a new root certificate to address the concerns about the Issuer field, making sure that the “O” clearly and correctly represents the CA. Note that the brand name of E-ME is being changed to eParaksts.lv. Their current plan is to set the Issuer to:
CN= eParaksts.lv SSI(RCA) 
O= State Joint Stock Company "Latvijas Valsts radio un televizijas centrs" 
C= LV

2) Action E-ME: Update policy documentation to reflect the new brand and root certificate, complete a new audit, and provide a new test website.

3) Action E-ME: Respond in the bug to the recent CA Communication.
https://wiki.mozilla.org/CA:Communications#February_17.2C_2012

After I have confirmed the completion of these actions, I will recommend approval of this request to add the E-ME’s “eParaksts.lv SSI(RCA)” root certificate and turn on the websites and code signing trust bits.
Comment 96 E-ME Root 2012-03-30 05:44:40 PDT
(In reply to Kathleen Wilson from comment #95)
> The discussion of this request is now closed. There are three action items
> that need to be completed and confirmed before this request may move into
> the approval phase.
> 
> 1) Action E-ME: Create a new root certificate to address the concerns about
> the Issuer field, making sure that the “O” clearly and correctly represents
> the CA. Note that the brand name of E-ME is being changed to eParaksts.lv.
> Their current plan is to set the Issuer to:
> CN= eParaksts.lv SSI(RCA) 
> O= State Joint Stock Company "Latvijas Valsts radio un televizijas centrs" 
> C= LV
> 
> 2) Action E-ME: Update policy documentation to reflect the new brand and
> root certificate, complete a new audit, and provide a new test website.
> 
> 3) Action E-ME: Respond in the bug to the recent CA Communication.
> https://wiki.mozilla.org/CA:Communications#February_17.2C_2012
> 
> After I have confirmed the completion of these actions, I will recommend
> approval of this request to add the E-ME’s “eParaksts.lv SSI(RCA)” root
> certificate and turn on the websites and code signing trust bits.

We will try to answer to CA communication next week. As we said, we have audit process right now and not so much resources to read carrefully this discussion.
Comment 97 E-ME Root 2012-04-02 04:39:20 PDT
E-ME answers to the recent CA Communication.
https://wiki.mozilla.org/CA:Communications#February_17.2C_2012

Action #1 – A
Action #2 – N/A
Action #3 – N/A
Action #4 – Confirmed
Action #5 – IP
Comment 98 Justin Dolske [:Dolske] 2012-04-15 19:45:20 PDT
Comment on attachment 473411 [details]
updated cps

Attending to unassigned reviews, seems this bug is already on the proper track without explicit review of this PDF needed. Kathleen, if this is wrong please feel free to reflag for review as appropriate.
Comment 99 E-ME Root 2012-05-08 23:52:22 PDT
We finish our annual audit process. Next week our auditors will send the audit letter in english. Than we will attach it to this bug.
Comment 100 E-ME Root 2012-05-17 04:57:37 PDT
Created attachment 624707 [details]
Audit letter

Please see the letter from our Auditor. The letter is signed by digital signature, that you could check and open here:

https://www.eparaksts.lv/en/Assistance/check-an-edocument/

If you don't accept electronic documents, please tell us. We will ask to our auditor to sign and send as PDF document.
Comment 101 E-ME Root 2012-05-17 05:11:01 PDT
Please also update the bug with status to actions #1 and #2 in
https://bugzilla.mozilla.org/show_bug.cgi?id=518098#c95

actions #1 - This will be set until July 1. Everything is in progress
actions #2 - Audit is done, all policy documentation is change in Latvian, we will involve the translator for english version, when it will be done we will send you the links to the documents.
After 1st July we will provide a new test website.

As we remember last time after Auditor letter you ask us to send the Auditor contacts. If you need to communicate with our auditor you could contact - Girts Kronbergs, gkronbergs@kpmg.com
Comment 102 Kathleen Wilson 2012-05-29 13:13:13 PDT
Created attachment 628079 [details]
2012 Audit Statement
Comment 103 Kathleen Wilson 2012-05-30 10:14:59 PDT
(In reply to Kathleen Wilson from comment #102)
> Created attachment 628079 [details]
> 2012 Audit Statement

From Girts at KPMG: "I confirm that the audit statement at your provided link is the one KPMG issued after completion of annual accreditation audit"
Comment 104 E-ME Root 2012-07-06 05:37:58 PDT
We would like to inform you that we are working on several systems improvements accroding your baseline and european baselines. The improvement that we need to do according your requests have to be change together with others and can't be done seperately. We will inform you further for our action and terms when it will be change.

Thank you for understanding,

E-ME root

Note You need to log in before you can comment on or make changes to this bug.