1313982 - Add 2 new SECOM root certificates

Status: ASSIGNED

(NSS :: CA Certificate Root Program, task)

Description

[Hisashi Kamo]

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

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

Audit Type (WebTrust, ETSI etc.):
Auditor:
Auditor Website:
Audit Document URL(s):

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

Certificate Name:
Summary Paragraph, including the following:
 - End entity certificate issuance policy
   (i.e. what you plan to do with the root)
 - Number and type of subordinate CAs
 - Diagram and/or description of certificate hierarchy

Certificate download URL (on CA website):
Version:
SHA1 Fingerprint:
Public key length (for RSA, modulus length) in bits:
Valid From (YYYY-MM-DD):
Valid To (YYYY-MM-DD):

CRL HTTP URL:
CRL issuing frequency for subordinate end-entity certificates:
CRL issuing frequency for subordinate CA certificates:
OCSP URL:

Class (domain-validated, identity/organizationally-validated or EV):
Certificate Policy URL:
CPS URL:
Requested Trust Indicators (email and/or SSL and/or code signing):
URL of example website using certificate subordinate to this root
(if applying for SSL):

Comment 1

[Kathleen Wilson]

Kamo-san, will you be using this Bugzilla Bug to request a root inclusion/change request?

Comment 2

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #1)
> Kamo-san, will you be using this Bugzilla Bug to request a root
> inclusion/change request?

I received a reply via email that this bug will be used to request inclusion of two new root certificates.

Comment 3

[Hisashi Kamo]

Dear Kathleen-san,

Let us provide you the information of two new root certificates as below.

#1
CA Details
----------

CA Name: Security Communication RootCA3
Website: https://repository.secomtrust.net/SC-Root3/index.html
One Paragraph Summary of CA, including the following:
 - General nature (e.g., commercial, government, academic/research, nonprofit)
 - Primary geographical area(s) served
Secom Trust Systems is a Japanese commercial CA.

Audit Type (WebTrust, ETSI etc.): WebTrust
Auditor: Pricewaterhouse Coopers Aarata LLC.
Auditor Website: http://www.pwc.com/jp/en/assurance.html
Audit Document URL(s): https://cert.webtrust.org/SealFile?seal=2105&file=pdf

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 RootCA3
Summary Paragraph, including the following:
 - End entity certificate issuance policy
   (i.e. what you plan to do with the root)
As our EE certificates issued using our root certificates, "Security Communication RootCA1" and "Security Communication RootCA2" already embedded in your root certificate program, we conform with the CABF guidelines and settle on the standard fits in Japanese custom and practices.

 - Number and type of subordinate CAs
Intermediate CAs for email,SSL, code signing and timestamping.

 - Diagram and/or description of certificate hierarchy
Not yet decided.

Certificate download URL (on CA website): https://repository.secomtrust.net/SC-Root3/SCRoot3ca.cer
Version: V3
SHA1 Fingerprint: Fingerprint(SHA1) =  C3 03 C8 22 74 92 E5 61 A2 9C 5F 79 91 2B 1E 44 13 91 30 3A
Public key length (for RSA, modulus length) in bits: RSA (4096 Bits)
Valid From (YYYY-MM-DD): 2016/06/16
Valid To (YYYY-MM-DD): 2038/01/18

CRL HTTP URL: https://repository.secomtrust.net/SC-Root3/SCRoot3CRL.crl
CRL issuing frequency for subordinate end-entity certificates: Within seven days
CRL issuing frequency for subordinate CA certificates: Within one year
OCSP URL: http://scrootca3.ocsp.secomtrust.net/

Class (domain-validated, identity/organizationally-validated or EV): OV, 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): email and SSL and code signing
URL of example website using certificate subordinate to this root
(if applying for SSL): Now providing.

-------------------------------

#2
CA Details
----------

CA Name: Security Communication ECC RootCA1 
Website: https://repository.secomtrust.net/SC-ECC-Root1/index.html
One Paragraph Summary of CA, including the following:
 - General nature (e.g., commercial, government, academic/research, nonprofit)
 - Primary geographical area(s) served
Secom Trust Systems is a Japanese commercial CA.

Audit Type (WebTrust, ETSI etc.): WebTrust
Auditor: Pricewaterhouse Coopers Aarata LLC.
Auditor Website: http://www.pwc.com/jp/en/assurance.html
Audit Document URL(s): https://cert.webtrust.org/SealFile?seal=2105&file=pdf

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 ECC RootCA1 
Summary Paragraph, including the following:
 - End entity certificate issuance policy
   (i.e. what you plan to do with the root)
As our EE certificates issued using our root certificates, "Security Communication RootCA1" and "Security Communication RootCA2" already embedded in your root certificate program, we conform with the CABF guidelines and settle on the standard fits in Japanese custom and practices.

 - Number and type of subordinate CAs
Intermediate CAs for email,SSL, code signing and timestamping.

 - Diagram and/or description of certificate hierarchy
Not yet decided.

Certificate download URL (on CA website): https://repository.secomtrust.net/SC-ECC-Root1/SCECCRoot1ca.cer
Version: V3
SHA1 Fingerprint: Fingerprint(SHA1) =  B8 0E 26 A9 BF D2 B2 3B C0 EF 46 C9 BA C7 BB F6 1D 0D 41 41
Public key length (for RSA, modulus length) in bits: ECC (384 Bits)
Valid From (YYYY-MM-DD): 2016/06/16
Valid To (YYYY-MM-DD): 2038/01/18

CRL HTTP URL: https://repository.secomtrust.net/SC-ECC-Root1/SCECCRoot1CRL.crl
CRL issuing frequency for subordinate end-entity certificates: Within seven days
CRL issuing frequency for subordinate CA certificates: Within one year
OCSP URL: http://sceccrootca1.ocsp.secomtrust.net/

Class (domain-validated, identity/organizationally-validated or EV): OV, 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): email and SSL and code signing
URL of example website using certificate subordinate to this root
(if applying for SSL): Now providing.

Comment 4

[Hisashi Kamo]

Attachment: SECOM WebTrust English translation160822.pdf

The English translation version of WebTrust audit report is attached for your reference.

Comment 5

[Kathleen Wilson]

Aaron and Francis, please do the Information Verification for this request.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 6

[Francis Lee [:frlee]]

hi Kamo-san,

could you please provide your CP/CPS in English? i have tried to search on your website, but i couldn't find the English version of your certificate policy.
it will be great that you could provide a direct link to your CP/CPS in English, it will definitely accelerate the certificate verification process.

thank you very much

Comment 7

[Hisashi Kamo]

Hello Francis-san,

Thank you for the comment.
We need to translate them.
So, please let us have sometime to provide them.

Thank you for your consideration.

Comment 8

[Hisashi Kamo]

Hello Francis-san,

Here is our English translated version of CP and CPS.

https://sr4v.secomtrust.net/secom/SecomCP.docx
https://sr4v.secomtrust.net/secom/SecomCPS.docx

Thank you for your consideration.

Comment 9

[Francis Lee [:frlee]]

hi Kamo-san,

i have started your certificate information verification process, but i need your help to make sure that you have acknowledgement our policy and also identify which CP/CPS section describes each of following items:

please read through our wiki link provided below.

Recommended Practices:

1. NEED CA's response to each of the items listed in https://wiki.mozilla.org/CA:Recommended_Practices#CA_Recommended_Practices
1) Publicly Available CP and CPS: (please provide links)
2) CA Hierarchy: (please provide which sections in CP/CPS)
3) Audit Criteria: 
4) Document Handling of IDNs in CP/CPS: 
5) Revocation of Compromised Certificates: 
6) Verifying Domain Name Ownership: 
7) Verifying Email Address Control: 
8) Verifying Identity of Code Signing Certificate Subscriber:  
9) DNS names go in SAN: 
10) Domain owned by a Natural Person: 
11) OCSP: 
12) Network Security Controls:

Problematic Practices:

2. NEED CA's response to each of the items listed in https://wiki.mozilla.org/CA:Problematic_Practices#Potentially_problematic_CA_practices

1) Long-lived DV certificates:
2) Wildcard DV SSL certificates:
3) Email Address Prefixes for DV Certs: 
4) Delegation of Domain / Email validation to third parties: 
5) Issuing end entity certificates directly from roots: 
6) Allowing external entities to operate subordinate CAs: 
7) Distributing generated private keys in PKCS#12 files: 
8) Certificates referencing hostnames or private IP addresses: 
9) Issuing SSL Certificates for Internal Domains: 
10) OCSP Responses signed by a certificate under a different root: 
11) SHA-1 Certificates:
12) Generic names for CAs: 
13) Lack of Communication With End Users: 
14) Backdating the notBefore date:

thank you very much

Comment 10

[Francis Lee [:frlee]]

hi Kamo-san,

as you have requested EV for both root certificates, we need your help to provide following items for verification purpose:

1. NEED: If EV treatment is being requested, then provide successful output from EV Testing as described here https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
please provide your test website for EV test

2. EV audit statement

3. BR audit statement

thank you very much

Comment 11

[Hisashi Kamo]

Hello Francis-san,

We provide answers for Comment 9 as bellow.
We do not request for EV treatment now, thus no answers provided for Comment 10.

Recommended Practices:

1. NEED CA's response to each of the items listed in https://wiki.mozilla.org/CA:Recommended_Practices#CA_Recommended_Practices
1) Publicly Available CP and CPS: (please provide links)
CP 
https://sr4v.secomtrust.net/secom/SecomCP.docx
CPS
https://sr4v.secomtrust.net/secom/SecomCPS.docx

2) CA Hierarchy: (please provide which sections in CP/CPS)
Under the each root CAs, we provide subordinate CAs such as for SSL/TLS servers, email signing/encrypting, and code signing.

3) Audit Criteria: 
WebTrust audit report is available at URL below.
https://cert.webtrust.org/SealFile?seal=2105&file=pdf

4) Document Handling of IDNs in CP/CPS: 
We use Japanese HIRAGANA, KATAKANA, KANZI as well as ASCII alpha numeric characters, which are used very often in Japanese language that our customers use.
We authenticate the identity of domains based on investigations conducted or databases owned by third parties such as WHOIS registry service that SECOM Trust Systems trusts, and other methods determined to be equally trustworthy by the Certification Services Improvement Committee.

5) Revocation of Compromised Certificates: 
We revoke a certificate in the event of any of the following.
The reliability of the certificate may have been lost due to reasons such as the theft, loss, unauthorized disclosure or unauthorized use of the relevant private key.
The relevant private key has been or may be compromised, resulting in loss of confidentiality.

6) Verifying Domain Name Ownership: 
We authenticate the identity of domains based on investigations conducted or databases owned by third parties such as WHOIS registry service that SECOM Trust Systems trusts, and other methods determined to be equally trustworthy by the Certification Services Improvement Committee.

7) Verifying Email Address Control: 
For a certificate to be used for digitally signing and/or encrypting email messages, we take reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate.

8) Verifying Identity of Code Signing Certificate Subscriber: 
We authenticate the identity of organizations based on official documents issued by national and municipal governments, investigations conducted or databases owned by third parties that SECOM Trust Systems trusts, and other methods determined to be equally trustworthy by the Certification Services Improvement Committee.
 
9) DNS names go in SAN: 
We use CN as well as SAN for DNS names.

10) Domain owned by a Natural Person: 
For SSL/TLS server certificates, we will accept subscription application only from organizations and no natural persons.
When subscriber has acknowledgement of Term of Use of domain owned by a natural person, the distinguished name will be for the one of the subscriber organizations, not of a natural person.

11) OCSP: 
We are listening to standard 80 port. 
For OCSP services for end-entity certificates, we all request our subordinate CAs to update OCSP statuses at least every four days, and request OCSP responses from subordinates CAs to have a maximum expiration time of ten days. 

12) Network Security Controls:
A CA system is not connected to other internal or external systems. The repository system is protected from unauthorized access by such means as fire walls and intrusion detection systems.


Problematic Practices:

2. NEED CA's response to each of the items listed in https://wiki.mozilla.org/CA:Problematic_Practices#Potentially_problematic_CA_practices

1) Long-lived DV certificates:
We issue 24months certificates. Upon renewal, each certificates are verify that all of the information that is included in SSL certificates remains current and correct. 

2) Wildcard DV SSL certificates:
Currently, wildcard DV SSL certificates are issued, and we will take consideration to identify to validate the organizaion.

3) Email Address Prefixes for DV Certs: 
Email addresses described acceptable are used for verification.

4) Delegation of Domain / Email validation to third parties: 
No delegation of domain/email validation to third parties. 

5) Issuing end entity certificates directly from roots: 
No issuing end entity certificates directly from roots.

6) Allowing external entities to operate subordinate CAs: 
No external entities to operate subordinate CAs.

7) Distributing generated private keys in PKCS#12 files: 
No Distributing generated private keys in PKCS#12 files.

8) Certificates referencing hostnames or private IP addresses: 
We do not issue certificates referencing hostnames or private IP addresses.

9) Issuing SSL Certificates for Internal Domains: 
We do not issue certificates for internal domains.

10) OCSP Responses signed by a certificate under a different root: 
We do not have the environment such as OCSP Responses signed by a certificate under a different root.

11) SHA-1 Certificates:
We do not issue and do not have SHA-1 certificates.

12) Generic names for CAs: 
No, we incorporate an organizational name Secom (Security Communication) for our names for CAs.

13) Lack of Communication With End Users: 
We operate a 24x7 Helpdesk support center.

14) Backdating the notBefore date:
We do not issue certificates with Backdating the notBefore date.

Thank you for your consideration.

Comment 12

[Aaron Wu]

Attachment: CAInformaion_SECOM_InfoNeeded_20170313.pdf

Comment 13

[Aaron Wu]

Hi Kamo-san,

It is Aaron Wu who will take over the work of information verification on this case.

I've done of 1st round of Information Verification, please see the attachment as Comment#12. We need your more information input which marked as "Need Response from CA".

For Test Website please provide (i) valid, (ii) revoked, (iii) expired.
CA Browser Forum section 2.2: “The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates ..”

Please also clarify the field which marked as"Need Clarification from CA", thanks for your cooperation!

Kind regards,
Aaron

Comment 14

[Hisashi Kamo]

Hi Aaron-san,

Thank you for the comment.

Let us inform you about test web sites.
We are now providing (ii) revoked and (iii) expired test sites for these two root certificates, and these will be ready by next week.
We will let you know when these test web sites and response for comment #12 are ready.

Best regards,
Hisashi Kamo

Comment 15

[Aaron Wu]

Hi Kamo-san,

Noted with thanks.


Kind regards,
Aaron

Comment 16

[Hisashi Kamo]

Hi Aaron-san,

Let us inform you about test web sites.
Now, it is ready for the test web sites for (ii) revoked and (iii) expired test sites for these two root certificates.

・Security Communication RootCA3
(i) valid
https://sr4v.secomtrust.net/
(ii) revoked
https://sr4r.secomtrust.net/
(iii) expired
https://sr4e.secomtrust.net/

・Security Communication ECC RootCA1
(i) valid
https://sr5v.secomtrust.net/
(ii) revoked
https://sr5r.secomtrust.net/
(iii) expired
https://sr5e.secomtrust.net/

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 17

[Aaron Wu]

Attachment: CAInformaion_SECOM_InfoNeeded_20170331.pdf

Comment 18

[Aaron Wu]

Hi Kamo-san,

Noted with thanks, I've verified those test websites and enter into Salesforce. Please see attachment in Comment#17 and we need your more information input and clarify which marked as "Need Response from CA" and "Need Clarification from CA".

Thank you so much!

Kind regards,
Aaron

Comment 19

[Aaron Wu]

Hi Kamo-san,

Please also perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ

Please let me know if you have any question, thank you!


Kind regards,
Aaron

Comment 20

[Hisashi Kamo]

Attachment: Bugzilla8853339_170425.pdf

Aaron-san,

The answers for Bugzilla8853339 are attached.
Thank you for your consideration.

Comment 21

[Aaron Wu]

Hi Kamo-san,

Thank you for information provided as Comment#20, I am verifying and updating into Salesforce now.

In the meanwhile, could you provide BR Self Assessment which i mentioned in Comment#19 above, thank you so much!

Kind regards,
Aaron

Comment 22

[Hisashi Kamo]

Hi Aaron-san,

Thank you for the comment.

we are now taking a look at the BR Self Assessment.
In the second half, there is only a title described. It seems that more description was included... or not...we are not quite sure.
Is the version available now the correct one?

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 23

[Aaron Wu]

Hi Kamo-san,

Please refer to the following wiki which you can find CA/Browser Baseline Requirements and the template of BR Self Assessment.

https://wiki.mozilla.org/CA:Information_checklist#Baseline_Requirements_Self_Assessement

Please let me know if you have any further question, thank you!

Kind regards,
Aaron

Comment 24

[Hisashi Kamo]

Hi Aaron-san,

Thank you for the comment.
This is what we checked and it is cleared now.

Best regards,
Hisashi Kamo

Comment 25

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 26

[Kathleen Wilson]

Attachment: BR-Self-Assessment-Feb1-2018.xlsx

Comment 27

[Kathleen Wilson]

I tried to do the Information Verification for this request, but am going to have to wait until the following is provided. Please update this bug when these documents are available.

1) Updated version of the CP/CPS documents that fully comply with the BRs, including having the BR commitment to comply (see section 2.2 of the BRs)

2) Updated BR Self Assessment based on the new version of the CP/CPS

3) The updated CP/CPS documents translated into English.

Also, please make sure that your next audit statements fully comply with Mozilla's requirements:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#public-audit-information
Including: "3. Distinguished Name and SHA256 fingerprint of each root and intermediate certificate that was in scope"

And make sure that you test...

https://certificate.revocationcheck.com/sr4v.secomtrust.net
https://certificate.revocationcheck.com/sr4v.secomtrust.net
Same errors for both:
- ThisUpdate is more than seven days old, CRLs must be updated and reissued at least every seven days
- ThisUpdate is more than four days old, OCSP information must be updated at least every four days