Closed Bug 394419 Opened 17 years ago Closed 15 years ago

Add secomtrust EV Root CA

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: h-kamo, Assigned: kwilson)

References

Details

(Whiteboard: Approved)

Attachments

(5 files)

CA Hierarchy Diagram
(deleted), application/vnd.ms-powerpoint
Details
Updated CA Hierarchy Diagram
(deleted), application/vnd.ms-powerpoint
Details
Completed Information Gathering Document
(deleted), application/octet-stream
Details
Completed information gathering document (PDF format)
(deleted), application/pdf
Details
2016-Audits-English.pdf
(deleted), application/pdf
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1)
Build Identifier: IE6.0.2900.2180

We would like you to embed our Root CA called "Security Communication EV RootCA1".
The information is as follows.

CA Details
----------
CA Name:
Security Communication EV RootCA1
Website: 
One Paragraph Summary of CA, including the following:
- General nature (e.g., commercial, government,academic/research, nonprofit):
Commercial
- Primary geographical area(s) served
Japan
- Number and type of subordinate CAs Audit Type (WebTrust, ETSI etc.):
Auditor:
KPMG
Auditor Website:
http://www.kpmg.com/
Audit Document URL(s):
None
Readiness Audit Report is avaiable upon request 
URL of certificate hierarchy diagram:
Diagram is available upon request

Certificate Details
-------------------
(To be completed once for each certificate; note that we only 
include root certificates in the store, not intermediates.)

Certificate Name:
Security Communication EV RootCA1
Summary Paragraph, including the following:
- End entity certificate issuance policy,
i.e. what you plan to do with the root Certificate HTTP URL (on CA website):
　https://repository.secomtrust.net/EV-Root1/
Version:
3
SHA1 Fingerprint:
FEB8 C432 DCF9 769A CEAE 3DD8 908F FD28 8665 647D
Modulus Length (a.k.a. "key length"):
2048bits
Valid From (YYYY-MM-DD):
2007-06-06
Valid To (YYYY-MM-DD):
2037-06-06
CRL HTTP URL:
http://repository.secomtrust.net/EV-Root1/EVRoot1CRL.crl
CRL issuing frequency for end-entity certificates:
1year
OCSP URL:
None
Class (domain-validated, identity/organisationally-validated or EV):
EV
Certificate Policy URL:
https://repository.secomtrust.net/EV-Root1/
CPS URL:
https://repository.secomtrust.net/EV-Root1/EVRoot1CPS.pdf
Requested Trust Indicators (email and/or SSL and/or code):
All is desiable.
URL of website using certificate chained to this root (if applying for SSL):
https://repo2.secomtrust.net/ev.gif









Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Please let us know if you need more information.
We request you to embed this Root CA now, and please deal with the EV arrangement at a later date.



I confirm that this is an enhancement request.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: Request to add to the default set a Root CA → Add secomtrust EV Root CA
(In reply to comment #0)
> CA Name:
> Security Communication EV RootCA1

Are you sure this is the name of your CA? I would have expected the CA Name to be something like "SECOM Trust Systems Co., Ltd".

> Audit Document URL(s):
> None
> Readiness Audit Report is avaiable upon request 

I'm requesting :-) But it needs to be made available from the auditor's website (either that, or they need to state in some other public and verifiable way that you have passed the audit).

You haven't said which of our accepted audit types (see our policy, section X) it was...

> URL of certificate hierarchy diagram:
> Diagram is available upon request

I'm requesting :-)

> 3
> SHA1 Fingerprint:
> FEB8 C432 DCF9 769A CEAE 3DD8 908F FD28 8665 647D
> Modulus Length (a.k.a. "key length"):
> 2048bits
> Valid From (YYYY-MM-DD):
> 2007-06-06
> Valid To (YYYY-MM-DD):
> 2037-06-06
> CRL HTTP URL:
> http://repository.secomtrust.net/EV-Root1/EVRoot1CRL.crl
> CRL issuing frequency for end-entity certificates:
> 1year

Is this correct for _end_entity_ certificates?

Gerv
Status: NEW → ASSIGNED
Priority: -- → P2
Regarding CA name, this "Security Communication EV RootCA1" is Common Name of certificate issued by root CA. We believe this is no problem for the name commonly meant for the name of CA.
If you have something defferenct meant for CA, please let us know.
It is more clear that if you give us examples you have already embedded.
Regarding audit, we have passed "WebTrust Extended Validation Audit" and can give you the official signed letter provided by KPMG. How can we give you the letter on PDF file?
Regarding certificate hierarchy diagram, how can we give the PDF file to you?
Regarding your question for end entity certificates, those information we gave you was "Security Communication EV RootCA1".
CRL Distribution Point is for the certificate issued from "Security Communication EV RootCA1".
If you need the information for end entity certificate, we can give you but this should be one of the example we issue. (because the information is different for each end entity certificate)
In case of misunderstanding each other for this, it is helpful to understand if you see our certificate hierarchy diagram.

Thank you very much for your concern.




(In reply to comment #4)
> Regarding CA name, this "Security Communication EV RootCA1" is Common Name of
> certificate issued by root CA. We believe this is no problem for the name
> commonly meant for the name of CA.
> If you have something defferenct meant for CA, please let us know.
> It is more clear that if you give us examples you have already embedded.
> Regarding audit, we have passed "WebTrust Extended Validation Audit" and can
> give you the official signed letter provided by KPMG. How can we give you the
> letter on PDF file?
> Regarding certificate hierarchy diagram, how can we give the PDF file to you?
> Regarding your question for end entity certificates, those information we gave
> you was "Security Communication EV RootCA1".
> CRL Distribution Point is for the certificate issued from "Security
> Communication EV RootCA1".
> If you need the information for end entity certificate, we can give you but
> this should be one of the example we issue. (because the information is
> different for each end entity certificate)
> In case of misunderstanding each other for this, it is helpful to understand if
> you see our certificate hierarchy diagram.
> Thank you very much for your concern.
Assignee: gerv → hecker
Status: ASSIGNED → NEW
Please deal with the EV arrangement for the following 2 Root CAs already embedded on Firefox.
OU=Security Communication RootCA1
OU=ValiCert Class 1 Policy Validation Authority

As you may know that "Security Communication EV RootCA1" is not embedded on Firefox yet.

Thank you for your concern.
I just spoke with Mr. Kamo and asked him to supply the additional information requested by Gerv in Comment 3.
Attached file CA Hierarchy Diagram (deleted) — 
Password to open the file is secomev2007.
Accepted audit type is "WebTrust for Certification Authorities—Extended
Validation Audit Criteria" 
Because of the file size, we could not attach the Webtrust for EV readiness
audit report, thus we will send it to Mr.Hecker.
Regarding your question for end entity certificates, those information we gave
you was "Security Communication EV RootCA1".
CRL Distribution Point is for the certificate issued from "Security
Communication EV RootCA1".
If you need the information for end entity certificate, we can give you but
this should be one of the example we issue. (because the information is
different for each end entity certificate)
In case of misunderstanding each other for this, it may be helpful for you to
understand if you see our "CA Hierarchy Diagram" sent to you just before this
comment.
Thank you very much for your concern.
Please note that the Report of Independent CPA is here:

https://cert.webtrust.org/SealFile?seal=599&file=pdf

I have attached the KPMG evaluation here:

http://people.mozilla.com/~gen/secomtrust/SECOM-WTEV-Report.pdf 
Frank, please let us know if there is any other information you require for the evaluation of this cert.  Thank you in advance!
Accepting this bug.
Status: NEW → ASSIGNED
Whiteboard: EV
I am resuming work on this application; my apologies for the delay in processing it. I have one question to begin: SECOM Trust has asked for this root CA certificate to be marked as "trusted" for use with SSL certificates, email certificates (i.e., for signed or encrypted email), and code signing certificates. Does SECOM Trust actually issue certificates for email use or code signing use from the Security Communication EV RootCA1 hierarchy? Section 3.2.3 of the Certificate Policy document appears to say that "The CA is not issuing certificates of individuals". (I don't read Japanese; I'm using Google Translate.)

The EV guidelines do not apply to email certificates or code signing certificates; at present EV is relevant only for SSL certificates. If Security Communication EV RootCA1 and its subordinate CAs issue only EV SSL certificates then we can mark the root CA certificate as trusted only for SSL use; this would make it faster to evaluate this application.
Attached file Updated CA Hierarchy Diagram (deleted) — 

    
    

    
  
Please refer to the attached file for more detail information.
Security Communication EV RootCA1 and its subordinate CA issues only EV SSL certificates.
Security Communication RootCA1 is for not only for server authentication
(SSL certificates) but also client authentication, code signing and encrypted email.
Right now, Security Communication EV RootCA1 is only for EV SSL certificates.
In the future, we have plan to construct another CAs for code signing and etc.
What is going to happen when we construct code signing CA under Security Communication EV RootCA1 for example?
Are you going to mark Security Communication EV RootCA1 as trusted for code signing?
Thank you for your concern.


    
    

    
  
Independent of approval process, for technical testing purposes: Could you please supply an https:// URL to an example SSL server (customer or demo) that uses a server cert issued (directly or through intermediates) by this root? Should you request multiple roots to be enabled for EV, please provide one example URL for each root. Thank you.

    
    

    
  
(In reply to comment #15)
> Please refer to the attached file for more detail information.

Thank you for this information; it is very helpful.

> Security Communication EV RootCA1 and its subordinate CA issues only EV SSL
> certificates.

If this is the case then at present the Security Communication EV RootCA1 certificate needs to be marked for SSL use, but it does not need to be marked for email or object signing use. I will change the SECOM Trust entry in the pending list to reflect this.

> Security Communication RootCA1 is for not only for server authentication
> (SSL certificates) but also client authentication, code signing and encrypted
> email.

Understood. As I understand it, this root CA certificate is already in Firefox and already has the correct settings. Is this correct?

> Right now, Security Communication EV RootCA1 is only for EV SSL certificates.
> In the future, we have plan to construct another CAs for code signing and etc.
> What is going to happen when we construct code signing CA under Security
> Communication EV RootCA1 for example?

You can submit a separate request later to have the Security Communication EV RootCA1 root certificate marked for use with object signing. (I promise to do a better job of responding to such a request in a timely manner.) Does the current CPS for Security Communication EV RootCA1 mention object signing certificates, and contain information about how they are issued? If not, then you should revise the CPS before you submit a request to have Security Communication EV RootCA1 marked for object signing use.

If your current CPS for Security Communication EV RootCA1 does indeed have information about issuing object signing certificates, then I will consider marking the root CA cert for object signing use. However before I do this I will  have to get English translations of the parts of the CPS that discuss object signing certificates.


    
    

    
  
<Secom comments>
Our comments for your comment #17 is as follows.
Please refer to <Secom reply>.
Thank you very much for your concern.

> Please refer to the attached file for more detail information.

Thank you for this information; it is very helpful.

> Security Communication EV RootCA1 and its subordinate CA issues only EV SSL
> certificates.

If this is the case then at present the Security Communication EV RootCA1
certificate needs to be marked for SSL use, but it does not need to be marked
for email or object signing use. I will change the SECOM Trust entry in the
pending list to reflect this.

<Secom reply>
Security Communication EV RootCA1 certificate needs to be marked for SSL use only at present, it does not need to be marked for another use.

> Security Communication RootCA1 is for not only for server authentication
> (SSL certificates) but also client authentication, code signing and encrypted
> email.

Understood. As I understand it, this root CA certificate is already in Firefox
and already has the correct settings. Is this correct?

＜Secom reply＞
Yes, this is correct.

> Right now, Security Communication EV RootCA1 is only for EV SSL certificates.
> In the future, we have plan to construct another CAs for code signing and etc.
> What is going to happen when we construct code signing CA under Security
> Communication EV RootCA1 for example?

You can submit a separate request later to have the Security Communication EV
RootCA1 root certificate marked for use with object signing. (I promise to do a
better job of responding to such a request in a timely manner.) Does the
current CPS for Security Communication EV RootCA1 mention object signing
certificates, and contain information about how they are issued? If not, then
you should revise the CPS before you submit a request to have Security
Communication EV RootCA1 marked for object signing use.

If your current CPS for Security Communication EV RootCA1 does indeed have
information about issuing object signing certificates, then I will consider
marking the root CA cert for object signing use. However before I do this I
will  have to get English translations of the parts of the CPS that discuss
object signing certificates.

<Secom reply>
Our CPS/CP for Security Communication EV RootCA1 describes that the certificates use for server authentication and encription of data on the internet.

Thank you for your concern.

    
    

    
  
Could you please let us know what the current status is.
Thank you for your concern.

    
    

    
  
According to http://www.mozilla.org/projects/security/certs/pending/ 
as of this date, the status of this request is: Information confirmed complete	
Whiteboard: EV → EV Information confirmed complete

    
    

    
  
Thank you for "Inforimation confirmed complete". 
We checked with Firefox3 beta4, however the address bar has not changed for green yet.
It seems same as GlobalSign, CyberTrust and Comodo.
Is this all right to see at the next beta will be released?
Thank you very much for your concern.





    
    

    
  
Could you please let us know when our root CA will be EV root arranged?
If there is something difficult for you, let us know.
Thank you for your concern.

    
    

    
  
Mr. Kamo,

I have been asked to follow up on this request.

First I need to confirm that this request is to add a new root to Firefox, rather than modify an existing root. The CA hierarchy diagram (https://bugzilla.mozilla.org/attachment.cgi?id=298919) indicates that the EV CA, “Security Communication EV RootCA1” is a newly constructed root that needs to be added to Firefox. There is currently a non-EV CA called “Security Communication RootCA1” in Firefox. However, the EV root is new, and is an addition rather than a modification.  Correct?

Next I would like to follow up on the KPMG evaluation for WebTrust EV compliance (http://people.mozilla.com/~gen/secomtrust/SECOM-WTEV-Report.pdf). The evaluation indicated that there was a need for SECOM to “suitably design controls over the background check process” with respect to employees, agents, or independent contractors engaged in the EV process. Has this been completed? Is there an update to the KPMG evaluation, or another document to state that this has been completed?

Thanks,
Kathleen



    
    

    
  
Kamo-san, to clarify, Kathleen is working for Frank Hecker.

    
    

    
  
I'm assigning this bug to Kathleen Wilson as she gathers any additional information.
Assignee: hecker → kathleen95014
Status: ASSIGNED → NEW

    
  
Status: NEW → ASSIGNED

    
    

    
  
Regardless of releasing Firefox3, the address bar is not changed to green of the websites issued by our EV SSL ceritificates.
According to the previous email from you, it was mentioned that your release updates conducted every 6 to 8 weeks, and you can deal with on these updates.
Is this correct?
Please let us have the most current information.
Thank you for your consideration.


    
    

    
  
(In reply to comment #23)

> needs to be added to Firefox. There is currently a non-EV CA called “Security
> Communication RootCA1” in Firefox. However, the EV root is new, and is an
> addition rather than a modification.  Correct?

Kathleen, I just spoke with Mr. Kamo and he confirmed that this is an addition, not a modification.

> agents, or independent contractors engaged in the EV process. Has this been
> completed? Is there an update to the KPMG evaluation, or another document to
> state that this has been completed?

Kathleen, information about the KPMG evaluation was sent to Frank by Mr. Kamo on Jan. 31.  I'll forward you that email separately as it has the contact information of an individual at KPMG that is not appropriate to share publicly in this bug.
 


    
    

    
  
Kathleen, could you also please provide SecomTrust some guidance on when they might expect to see their EVSSL cert in Firefox 3?  Without any information on how long the process will take or what further steps are required, they are very eager to understand what the schedule is and if there are any further required actions.  Thank you very much.

    
    

    
  
(In reply to comment #27)
> (In reply to comment #23)
> 
> > needs to be added to Firefox. There is currently a non-EV CA called “Security
> > Communication RootCA1” in Firefox. However, the EV root is new, and is an
> > addition rather than a modification.  Correct?
> 
> Kathleen, I just spoke with Mr. Kamo and he confirmed that this is an addition,
> not a modification.

Kathleen, I was mistaken.  Please let me clarify.  

The current "Security Communication RootCA1" is in place today. 

The new root CA is "Security Communication EV RootCA1" and is a new addition, NOT a modification.

Please see the "Updated CA Hierarchy Diagram" attachment as provided by Mr. Kamo for the definitive statement.

https://bugzilla.mozilla.org/attachment.cgi?id=298919



    
    

    
  


  
Attached is the completed information gathering document which contains a summary of all of the information that has been gathered and verified for this request.

    
    

    
  
Assigning this request back to Frank, so he can determine how to move forward. The information-gathering phase of this request is complete, and summarized in the attached document.

The audit issue is that WTEV criteria requires specific background checks of employees, but SECOM cannot do these background checks as per Japanese customs. It appears that SECOM and KPMG have done their best under the circumstances to meet the WTEV requirements and provide full disclosure into the issue.

From the auditor:
--
Regarding background checks, some jurisdictions such as Japan have legal limitations on what checks can be performed.
 
The EV Guidelines contemplate this in section 29(2) where it states that certain checks shall be performed "where allowed by the jurisdiction where the person will be employed."
 
We felt it was important to disclose the checks that were not performed in our report along with an explanation of the circumstances in management's assertion.
--

From SECOM: We believe this [section 29(2) of WTEV Guidelines] is how Microsoft was able to bridge this gap and they made arrangement of EV SSL for SECOM.

Assignee: kathleen95014 → hecker
Status: ASSIGNED → NEW

    
    

    
  
According to https://wiki.mozilla.org/CA:Schedule we are planning to enter this request into the public discussion phase during the week of October 16.

In preparing for the public discussion phase, would you please provide links to your most recent WebTrust CA and WebTrust EV audits, or provide a schedule for when they will be updated? The audits that we have links to are from 2006 and 2007. Here are the links that we currently have:
https://cert.webtrust.org/SealFile?seal=599&file=pdf
http://people.mozilla.com/~gen/secomtrust/SECOM-WTEV-Report.pdf
 
Thanks,
Kathleen

    
    

    
  
Thank you for the information.
We have finished this year’s audit in September.
The consulting firm is now making the report and we believe it will be available by the end of October.

By the way, when and how do we know the EV arrangement has been made?
Could we expect to see the address bar change for green by October 23?

    
    

    
  
The first public discussion phase takes one to two weeks. You will know when this starts, because there will be a posting in this bug.

Sometimes the first public discussion phase raises concerns/issues that have to be resolved and then a second public discussion phase is needed. Once approved, the change can happen as part of a security update. You will see activity posted in this bug when this is happening and when it is completed.

Please post the updated audits (or links to them) here when you have them.

Thanks,
Kathleen

    
    

    
  
The consulting firm is now making the reports, thus they will be updated as soon as ready.
Accroding to your schedule, we very appreciate you are going to start to work for us on October 16.

    
    

    
  
Could you post how the first public discussion phase is going on.
We appreciate if you post in this bug or send me the email.
According to your information, it has already started on October 16.

    
    

    
  
Hisashi, the public discussion has been delayed somewhat and a new schedule will be published. Before your CA will enter the discussion phase a summary will be posted here and you'll know upfront about it and you'll be able to follow the discussion as well. Hope this helps.

    
    

    
  
Thank you for the infomation.
We are disappointed at the dealy of the schedule, however we accept it.
Anyway, please take care of us as soon as possible and we will wait for your update.

    
    

    
  
Could you please let us know the updated schedule of the public discussion for us?

    
    

    
  
Frank, we're running a few weeks late with the public discussion for Secomtrust.  Could you please let Secomtrust know when to expect the public discussion period to begin? Thank you in advance.

    
    

    
  
Regarding the most recent audit reports, because those can only be distributed to the members who have joined CABrowser Form, I sent them to Frank-san and Kathleen-san by email.
Could you please let us know when will the first public discussion phase be started?
We appreciate if you post the current status on bugzilla or send me the email.

    
    

    
  
Regardless of resending the audit report to Kathleen-san, it has not reached to Kathleen-san again.
Please get them from Frank-san or Gen-san.
By the way, when will the public discussion be started?
We eagerly hope the EV treatment of Secom will be finished by the end of this year.

    
    

    
  
Frank, could we provide some information to Kamo-san regarding the schedule: when do you estimate the public discussion period will begin for this request?

    
    

    
  


  
Attached a PDF version of the information gathering document, for the convenience of those not able to read Word files. There are no changes to the text itself.

    
    

    
  
The one-week public discussion period for this request has now started. See the mozilla.dev.tech.crypto newsgroup for more information.

    
    

    
  
Thank you for starting the public discussion.

    
    

    
  
I found the latest WebTrust report for SECOM Trust at

  http://cert.webtrust.org/SealFile?seal=816&file=pdf

I do not yet have a copy of the latest WebTrust EV report.

    
    

    
  
Frank-san, Kathleen-san, I resent the audit reports by email just a few minitus ago.
Regarding the EV audit report, because it is described by the auditor that it can only be distributed to the members of CABF, thus the reports were sent by email.
The reports were already sent by zip files on the email at the end of November, however it seems that you have not received them. This time, I sent them by PDF files on the email.
I hope you can receive them.
Again, thank you for your concern.

    
    

    
  
Hisashi, why can't you publish the EV report? I haven't heard of such a restriction and all CAs had their report published so far.

    
    

    
  
Eddy-san, 
The reason is as follows.
Without revising the IT Committee Report No.2 by Japanese Institute of Certified Public Accountants (JICPA) in order to add the guidance for the WebTrust EV, consulting firm insisted to provide the EV report to the limited members such as CABF.

    
    

    
  
Hisashi-san, thank you for your answers. I think all statements like CP/CPS and audit should be public according to the Mozilla CA Policy.

    
    

    
  
The issue is not merely an arbitrary policy.  The issue is trust.  For a root certificate to be trusted, a KNOWLEDGEABLE user should be able to make the same analyses that have been made by the Mozilla organization.  This requires public disclosure of key documents: CP, CPS, audit report, etc.  

Audit reports are special.  While the CA may have been engaged and paid the auditor, the end users of browsers containing the root certificate are the de facto customers for the audit of the CA.  This is very much equivalent to a financial audit of a publicly-owned corporation, where the corporation engages and pays for the audit but the corporation's vendors and the public investors are the de facto customers for the report.  There is a legal basis for this in the successful lawsuits against audit firms by investors when a corporation's financial data were found to be fraudulent.

    
    

    
  
As Kathleen-san asked for the contact at the consulting firm, the email address of the contact was provided by email to Frank-san, Kathleen-san and Gen-san.
Thank you again for your concern.

    
    

    
  
Thanks to Gen’s efforts, we have received confirmation from PwC Aarata that the two audit documents provided by SECOM are authentic and were created by PwC Aarata. 

Both of these audit documents have the following statement, limiting the distribution:
“This report can only be distributed to the vendors who have joined the CABrowser forum.”

Response from PwC Aarata in regards to this limitation:
“…limitations are applied about WebTrust EV audit report because there are circumstances of Japanese Institute of Certified Public Accountants(JICPA). The circumstances of JICPA is delay of Japanese translation of the WebTrust EV Audit Criteria. To avoid the misunderstanding of the Japanese reader, such a limitation is applied.”

Since the two audit documents cannot be publicly posted, here is a short descritpion of the two documents.

Document #1
Title: Report of Independent Certified Public Accountant
Content: WebTrust for Certification Authorities Criteria for the Security
Communication EV RootCA1 Certification Practice Statement, Security
Communication EV RootCA1 Subordinate CA Certification Policy…
Result: STS management’s assertion … is fairly stated, in all material respects based on the AICPA/CICA WebTrust for Certification Authorities Criteria.
Issues: No issues or concerns noted in the document.

And

Document #2
Title: Independent Auditor’s Report
Content: WebTrust for Certification Authorities - Extended Validation Audit
Criteria for Security Communication EV RootCA1…
Result: STS management’s assertion … is fairly stated, in all material respects, in accordance with the WebTrust for Certification Authorities - Extended Validation Audit Criteria.
Issues: No issues or concerns noted in the document.

    
    

    
  
Thank you Kathleen.  

Could we be informed as to what the next steps would be and or a schedule?  SecomTrust would like to know what to expect so that they can plan ahead.

    
    

    
  
Could we have any information that when our EV update will be?
It is very appreciated if you let us know about it.

    
    

    
  
Frank, SecomTrust is hoping to find out when to expect final approval and what the next steps, and potential schedule will be (i.e. when to expect nightly builds to have the approved cert, when to expect the approved cert in the next minor update, etc.)  Is there any information that can be provided as to schedules here?

    
    

    
  
I think SecomTrust must enter first the public discussion which hasn't happened yet IIRC. This bug will be updated once the discussion starts.

    
    

    
  
So this post by Frank on Dec. 6th was not the start of the public discussion?

http://groups.google.com/group/mozilla.dev.tech.crypto/msg/25a73fdb93e3311e?dmode=source

    
    

    
  
Oh yes, I'm sorry, I completely forgot. I guess it's now up to Frank to come to a decision. Sorry about the mix-up.

    
    

    
  
Thanks for your concern. 
we know things are hectic over there, but we are looking forward to arranging for EV at your next update.
Please let us have your shedule.

    
    

    
  
Frank, is there anything else holding SecomTrust back from approval?  If there is, please let them know as they are eager to have their cert approved and installed as soon as possible.  Thank you.

    
    

    
  
Frank, SecomTrust would like to know what, if anything is required of them at this time.  If nothing, they'd like to know when the cert will be approved and added so they can plan on communicating with their customer base.

Separately, I've been told that Google Chrome now supports SecomTrust's EV cert.

    
    

    
  
According to Frank, he has reviewed the audit reports which isn't public. This might be a problem. 

Also because SecomTrust apparently doesn't use an OCSP responder and isn't required to do so for another year, Firefox has no way to check the certificates status. Firefox might treat such certificates as non-EV or it might result in other complications. This might be another problem.

As such there should be an answer in this respect in order to add the SecomTrust EV root or have them correct whatever needs to be corrected.

    
    

    
  
Gen-san, Eddy-san, thank you for the comment.
According to the previous emails, this matter on OCSP has been resolved.
Because of the long contents of the emails, I will send the infomation on another email after this comment on Bugzilla.

    
    

    
  
The public comment period for this request is now over. 

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

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

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

To summarize, this assessment is for the request to add a new root CA certificate for Security Communication EV RootCA1, and then to enable that root for EV use. There is currently a non-EV CA called Security Communication RootCA1 in NSS, which has issued a cross-signing certificate for Security Communication EV Root CA1.  The plan is to EV-enable only the new EV root, leaving the existing root as is. 

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by SECOM Trust, 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.

There were some concerns expressed in the comment period regarding enabling this root for EV because an OCSP responder is not provided. It has been decided to decouple the issue of approving EV CAs for inclusion and EV enabling (which is a policy issue) with the issue of how those CAs are handled 
for the purposes of the Firefox EV UI. 

Section 6 [Relevancy and Policy]. SECOM Trust appears to provide a service relevant to Mozilla users: It's a commercial CA offering certificates to customers primarily in Japan. It has roots already included in NSS, and this new root is associated with extensions of SECOM Trust’s existing certificate offerings. 

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 Security Communication EV RootCA1 Certification Practice Statement, and the Security Communication EV RootCA1 Subordinate CA Certificate Policy.

https://repository.secomtrust.net/EV-Root1/EVRoot1CPS.pdf
https://repository.secomtrust.net/EV-Root1/EVRoot1CP1.pdf

These documents are provided in Japanese. The necessary sections were translated into English and the translations were verified.

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

* Email: Not applicable. SECOM Trust does not issue certificates for email use through this hierarchy.

* SSL: For EV SSL certificates SECOM Trust validates applicant information in accordance with the EV guidelines. SECOM Trust validates that the applicant controls the domain associated with the certificate by checking the WHOIS database, making phone calls to contact the domain holder, and if applicable a “Domain usage consent form”.

The EV policy OID is 1.2.392.200091.100.721.1.

* Code: Not applicable. SECOM Trust does not issue certificates for code signing use through this hierarchy.

Section 8-10 [Audit]. Section 8-10 [Audit]. SECOM Trust has successfully completed independent audits using the WebTrust for CAs criteria and the WebTrust EV criteria. The audits were done by PricewaterhouseCoopers Aarata. 

SECOM Trust had one caveat on their EV audit, having to do with them not performing certain background checks on staff. This is a side-effect of Japanese laws and regulations, and was determined to not be a substantive problem. 

SECOM Trust’s audit reports for this root are limited in distribution because the auditor included a statement in each report that the report can only be distributed to the vendors who have joined the CABrowser forum. The audit reports were reviewed and verified, and no issues were noted in the reports.

Section 13 [Certificate Hierarchy]. Security Communication EV RootCA1 is being used only for EV SSL certificates. It has a single subordinate CA, SECOM Passport for Web EV CA, (also operated by SECOM Trust), that is the actual issuing CA. The subordinate CA is cross-signed by Security Communication Root CA1 which is already in NSS. 

Other: SECOM Trust issues CRLs on a 24-hour schedule.

Potentially problematic practices: There are no known potentially problematic practices associated with Security Communication EV RootCA1 and its associated CA hierarchy.

Based on this assessment I recommend that Mozilla approve this request to add the Security Communication EV RootCA1 Certificate Authority root certificate to NSS and to enable it in PSM for EV use.

    
    

    
  
To Kathleen: Thank you for your work on this request.

To representatives of SECOM Trust: Thank you for your cooperation and your patience.

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

I have reviewed the summary and recommendation in comment #66, and on behalf of the Mozilla project I approve this request from SECOM Trust to add the Security Communication EV RootCA1 Certificate Authority root certificate to NSS and to enable it in PSM for EV use.

    
    

    
  
Kathleen, I'm re-assigning this bug to you for the final steps. Could you please do the following:

1. File the necessary bugs against NSS and PSM.
2. Mark the PSM bug as dependent on the NSS bug.
3. Mark this bug as dependent on the PSM bug.
4. When those bugs are complete, change the status of this bug to RESOLVED FIXED.

Thanks in advance!
Assignee: hecker → kathleen95014
Status: NEW → ASSIGNED

    
    

    
  
Changed whiteboard to "Approved"
Whiteboard: EV Information confirmed complete → Approved

    
  
Depends on: 477145

    
    

    
  
I have filed bug 477134 against NSS and bug 477145 against PSM for the actual changes.

    
    

    
  
I believe this bug was fixed by the checkin for 
Bug 493709 -  Combined EV enablement 
so I am resolving this bug as fixed.  
Please reopen it if it is not fixed.
I hope Kathleen doesn't mind me resolving these bugs.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED

    
    

    
  

      
      
      
      

        Attached file
          
        2016-Audits-English.pdf (deleted)
        — 
      

    


  
The official audit statements for 2016 are here: https://cert.webtrust.org/SealFile?seal=2105&file=pdf

The attached file "represents a translation, for convenience only, of the original report issued in the Japanese language."

    
  
Product: mozilla.org → NSS
Product: NSS → CA Program

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: