527419 - Add Secom Trust SHA256 root certificate

Status: RESOLVED FIXED

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

Description

[Hisashi Kamo]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; InfoPath.1)
Build Identifier: 

CA Details
----------

CA Name: Security Communication RootCA2
Website:
One Paragraph Summary of CA, including the following:
  - General nature (e.g., commercial, government, academic/research,
nonprofit): Commercial CA
  - Primary geographical area(s) served: Japan

Audit Type (WebTrust, ETSI etc.): WebTrust Readiness Audit
Auditor: KPMG
Auditor Website: https://cert.webtrust.org/SealFile?seal=975&file=pdf
Audit Document URL(s): The above URL is the reports for our another root certifiactes.
Regarding the "Security Communication RootCA2", it is not publicly accessible
because of the readiness audit.
We will give you the readiness audit report upon your 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 RootCA2
Summary Paragraph, including the following:
  - End entity certificate issuance policy
    (i.e. what you plan to do with the root)
  : https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf

  - Number and type of subordinate CAs: many 
  - Diagram and/or description of certificate hierarchy
  : Root signing from the "Security Communication RootCA2" to subordinate CAs.

Certificate download URL (on CA website)
  : https://repository.secomtrust.net/SC-Root2/index.html
Version: V3
SHA1 Fingerprint: 5F 3B 8C F2 F8 10 B3 7D 78 B4 CE EC 19 19 C3 73 34 B9 C7 74
Public key length (for RSA, modulus length) in bits: RSA2048
Valid From (YYYY-MM-DD): 2009-05-29
Valid To (YYYY-MM-DD): 2029-05-29

CRL HTTP URL: https://repository.secomtrust.net/SC-Root2/index.html
CRL issuing frequency for subordinate end-entity certificates:　1 day
CRL issuing frequency for subordinate CA certificates:　1 year
OCSP URL: None

Class (domain-validated, identity/organizationally-validated or EV): EV
Certificate Policy URL: https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf
CPS URL: https://repository.secomtrust.net/SC-Root/SCRootCPS.pdf
Requested Trust Indicators (email and/or SSL and/or code signing)
  : All is desirable.

URL of example website using certificate subordinate to this root (if applying for SSL)
  : https://fmctest.secomtrust.net/
    https://scrootca2test.secomtrust.net/


Reproducible: Always

Comment 1

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
verified as per
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification

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

Comment 2

[Kathleen Wilson]

Attachment: Editable Version of Info Gathering Doc

Comment 3

[Hisashi Kamo]

Attachment: 527419-InfoGathering Answers Secom reply

Comment 4

[Hisashi Kamo]

Attachment: CA hierarchy diagram

Comment 5

[Hisashi Kamo]

Kathleen-san,
I apologize for long delay response.
I attached the Information Gathering Answers file and the CA hierarchy diagram on this bugzilla.
Regarding our readiness audit report, I will attach on the email I will send you now.

Thank you for your time and consideration.

Comment 6

[Kathleen Wilson]

Thank you for the information.

Please explain the relation between these two documents:
https://repo1.secomtrust.net/spcpp/pfw/pfwsr2ca/PfWSR2CA-CP.pdf
https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf
and the documents linked to from 
https://repository.secomtrust.net/SC-Root2/index.html


Based on the CA Hierarchy Diagram: 
https://bugzilla.mozilla.org/attachment.cgi?id=446676
I see that this root certificate will sign the “Security Communication EV RootCA2” intermediate CA, which will sign the “SECOM Passport for Web EV CA2” intermediate CA, which will sign end-entity EV SSL certificates.
However, my notes indicate that the email and code signing trust bits are also requested to be enabled for this root. Will there be separate intermediate CAs created for signing end-entity Email and Code Signing certificates?


I have reviewed the audit statement that you sent to me via email. I did not notice anything sensitive or unusual about the audit statement.  Is there a reason why the audit statement cannot be attached to this bug report?

Comment 7

[Hisashi Kamo]

Attachment: Relation about the documents

Comment 8

[Hisashi Kamo]

Attachment: Secom readiness audit report

Comment 9

[Hisashi Kamo]

Kathleen-san,

Regarding the documents, please refer to the attached PDF, "Relation about the documents".

Regarding the CA hierarchy diagram, yes, you are right.
The separate intermediate CAs for Email and Code Signing will be created.

It is all right to attached the readiness audit report, so it is now attached.


Thank you for your time and consideration.

Comment 10

[Kathleen Wilson]

Thank you for the clarification.

Would you please change the security settings of the PfWEVCA-CP.pdf document so that copying is allowed?  I need to be able to copy-and-paste sections into a text translator.

In regards to the domain verification procedures, are they documented in the SCRootCP1.pdf or PfWSR2CA-CP.pdf documents?  If yes, please provide page or section numbers where I can find this information.

Please also see:
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership

In regards to the email address verification procedures, are they documented in the SCRootCP1.pdf or PfWSR2CA-CP.pdf documents?  If yes, please provide page or section numbers where I can find this information.

Please also see:
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control

Please also provide the section numbers in the appropriate document(s) that have specific information about code signing certificates.

Comment 11

[Hisashi Kamo]

Kathleen-san,

Thank you for your review.

I am now asking about the security setting for PfWEVCA-CP.

According to the the section 4.1.2 of application procedures on PfWSR2CA-CP, the procedures such as the domain verification is followed with the description on the homepage. 
The information about the domain verifiation is available at the URL below.
http://www.secomtrust.net/service/ninsyo/neforwebsr/3.html

In regards to the email address verifiation and code signing, we follow the internal document as just explained on the "InfoGathering Answers Secom reply".

Comment 12

[Hisashi Kamo]

Attachment: PfWEVCA-CP

Comment 13

[Hisashi Kamo]

Kathleen-san,
Here is the CP for PfWEVCA now attached.

Thank you for your time and concern.

Comment 14

[Kathleen Wilson]

Thank you for providing a copy-and-paste-enabled version of the SECOM Passport for Web EV Certificate Policy. 

Is the EV Policy OID 1.2.392.200091.100.721.1 ?

Please tell me which section numbers I should look at to find the steps that SECOM takes to verify the organization identity and to verify the ownership/control of the domain name to be included in the EV SSL certs.

> According to section 4.1.2 of application procedures on PfWSR2CA-CP, the
> procedures such as the domain verification is followed with the description
> on the homepage. 
> The information about the domain verification is available at the URL below.
> http://www.secomtrust.net/service/ninsyo/neforwebsr/3.html

Maybe the translation isn’t working well, but the information on this web page appears to be actions that the certificate subscriber performs. I need the information about the steps that SECOM takes to verify that the domain name is owned/controlled by the certificate subscriber. We require the CA to perform sufficient checks (such as against 3rd-part databases) to confirm the accuracy of the data provided by the certificate subscriber.

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

> In regards to the email address verifiation and code signing, we follow the
> internal document as just explained on the "InfoGathering Answers Secom
> reply".

We require that the information satisfying section 7 of the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/) must be in a public-facing and audited document, such as a CP or CPS.
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control

Comment 15

[Hisashi Kamo]

Attachment: EV verification document

Comment 16

[Hisashi Kamo]

Kathleen-san,

> Is the EV Policy OID 1.2.392.200091.100.721.1 ?
Yes, it is correct.

> Please tell me which section numbers I should look at to find 
> the steps that SECOM takes to verify the organization 
> identity and to verify the ownership/control of the domain 
> name to be included in the EV SSL certs.

Please take a look at the sections 3.2, 3.3 and 3.4 of PfWEVCA-CP.
For your reference, more detailed information you can find from our EV verification document now attached.
Please understand that the only sections for the verification of the organization and the domain owner are attached.

> > In regards to the email address verification and code signing, we 
> > follow the internal document as just explained on the 
> "InfoGathering Answers Secom reply".
> 
> We require that the information satisfying section 7 of the 
> Mozilla CA Certificate Policy 
> (http://www.mozilla.org/projects/security/certs/policy/)
> must be in a public-facing and audited document, such as a CP or CPS.
> https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Em
> ail_Address_Control

Please take a look at the sections 3.2, 3.3 and 3.4 of CP at the URL below.
https://repo1.secomtrust.net/spcpp/pfm20pub/PfM20PUB-CP.pdf

Comment 17

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Thank you for the information. 

I have attached an updated Information Gathering Document. 

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

Comment 18

[Hisashi Kamo]

Dear Kathleen-san,

I really appreciate very much for your update for the Information Gathering Document.

I reviewed the document and it is all right except the test URL.

The test URL was changed as below.
Test website for
https://fmctest.secomtrust.net/
is no longer existed.

Now, please access to the test URL below.
https://scrootca2test.secomtrust.net

In regards to the items highlighted in yellow,
right now, we cannot tell you when EV audit report will be available, but it is sure that it will not be this year because EV intermediate CA or EV issuing CA has not been constructed yet.

However, this new root CA, "Security Communication RootCA2" will be a trust anchor for EV-SSL service, so please make an arrangement for EV marking.

Thank you again for your time and concern.

Comment 19

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 20

[Kathleen Wilson]

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

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

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

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

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

Comment 21

[David E. Ross]

Regarding comment #18, is it valid to "make an arrangement for EV marking" for a root that has not yet had an EV audit.

Comment 22

[Kathleen Wilson]

In order to consider EV-enablement, there must at least be an EV Readiness Audit, and by the end of this year OCSP will also be required for EV.

When this request approaches the top of the queue for public discussion I will check with the CA to see if all of the requirements for EV-enablement have been completed. If not, then we'll proceed with evaluating the root inclusion request without EV-enablement, and create a separate request for EV-enablement at a later time.

Comment 23

[Hisashi Kamo]

Thank you Kathleen-san.

As we have any progress from now on, we will let you know.

Comment 24

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 25

[Kathleen Wilson]

I am now opening the first public discussion period for this request from SECOM to add the “Security Communication RootCA2” root certificate, and turn on all three trust bits.

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

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

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

The discussion thread is called “SECOM Root Inclusion Request”

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

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

Comment 26

[Kathleen Wilson]

This request has been evaluated as per the Mozilla CA Certificate Policy at

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

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

To summarize, this assessment is for the request from SECOM to add the “Security Communication RootCA2” root certificate, and turn on all three trust bits.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by the SECOM, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy].  SECOM appears to provide a service relevant to Mozilla users: It is a Japanese commercial CA that provides SSL and client certificates for e-Government and participated several projects for financial institutions to ensure the secured on-line transactions. SECOM provides information security services, including authentication and secure data center management services, as well as safety confirmation services, which assist companies in the event of a large-scale disaster.

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 Certificate Policies for the root and each subordinate CA. The documents are in Japanese, and English translations have been provided for some sections.

Root CA Certification Procedures for Operation: 
https://repository.secomtrust.net/SC-Root/SCRootCPS.pdf

Subordinate CA Certificate Policy:
https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf

CA Service Passport for Web SR 2.0 Certificate Policy:
https://repo1.secomtrust.net/spcpp/pfw/pfwsr2ca/PfWSR2CA-CP.pdf

CA Passport for Web EV Certificate Policy:
https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf

EV Verification Document: https://bugzilla.mozilla.org/attachment.cgi?id=451885

CA Passport for Member 20 PUB Certificate Policy:
https://repo1.secomtrust.net/spcpp/pfm20pub/PfM20PUB-CP.pdf

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

* Email: According to translations of SECOM’s mail authentication procedure, the email address to be included in the certificate is verified via an email exchange. Additionally, the domain is verified using Whois gateway, and a phone call is made to the applicant company to verify that the applicant has the authority to request the certificate.

* SSL:  The procedure that SECOM follows to verify the domain owner is the same for EV and non-EV SSL certificates. The only difference is that no lawyer opinion letter is used for Non-EV SSL.  Translations from section 4-2 of SECOM’s Verification Document describe the process by which Whois is used to verify that the domain owner is the same as the certificate subscriber company name.

* Code: SECOM has 2 procedures that are used to verify the organization and authority of SSL and code signing certificate applicants. The first procedure applies when the organization is registered in the QIIS, so SECOM can query the QIIS regarding the organization's existence, and get a phone number that they use to contact the organization to confirm the applicant’s authority to request the certificate. QIIS is provided by Tokyo Shoko Research (TSR), a member of the D&B Worldwide Network. http://www.tsr-net.co.jp/english/
The second procedure applies when the organization is not registered in the QIIS. In this case SECOM verifies the "Certificate of seal impression" on a document that is only issued to a representative of the organization by Japan’s Legal Affairs Bureaus of Ministry of Justice. SECOM’s representative studies the “Certificate of seal impression” to make sure it is authentic, and then uses the phone number from that document to call the organization, and ask the switchboard for transfer to the applicant’s representative to confirm the applicant’s authority to request the certificate.

* EV Policy OID: Not requesting EV treatment at this time.

Section 15 [Certificate Hierarchy]. 
* This is the SHA256 version of the “Security Communication RootCA1” (SHA1) root certificate that is currently in NSS. It will have separate intermediate CAs for signing certificates for SSL, EV SSL, email, and code signing.

* CRL: https://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl
** From PfWSR2CA-CP.pdf Section4.9.7: CRL is expired regardless of treatment, every 24 hours

* OCSP: Not yet provided in this new hierarchy

Section 8-10 [Audit]. Audits are performed annually by PricewaterhouseCoopers Aarata according to the WebTrust CA criteria, and are posted on the webtrust.org website, https://cert.webtrust.org/ViewSeal?id=1087. The 2011 audit is currently in progress.

Based on this assessment I intend to approve this request from SECOM to add the “Security Communication RootCA2” root certificate, and turn on all three trust bits.

Comment 27

[Kathleen Wilson]

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

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

As per the summary in Comment #26, and on behalf of Mozilla I approve this request from SECOM to include the following root certificate in Mozilla:

* Security Communication RootCA2 (websites, email, code signing)

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

Comment 28

[Kathleen Wilson]

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

Comment 29

[Kathleen Wilson]

"Security Communication RootCA2" is a "Builtin Object Token" in FF 11.