Open Bug 1313982 Opened 4 years ago Updated 11 days ago

Add 2 new SECOM root certificates

Categories

(NSS :: CA Certificate Root Program, task)

Product:
NSS
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: h-kamo, Assigned: bwilson)

Details

(Whiteboard: [ca-verifying] - BW Comment #31 2020-09-28)

Attachments

(5 files)

SECOM WebTrust English translation160822.pdf
227.68 KB, application/pdf
Details
CAInformaion_SECOM_InfoNeeded_20170313.pdf
213.32 KB, application/pdf
Details
CAInformaion_SECOM_InfoNeeded_20170331.pdf
209.94 KB, application/pdf
Details
Bugzilla8853339_170425.pdf
22.14 KB, application/pdf
Details
BR-Self-Assessment-Feb1-2018.xlsx
32.03 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details 
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):
Kamo-san, will you be using this Bugzilla Bug to request a root inclusion/change request?
(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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: Add [your CA's name] root certificate(s) → Add 2 new SECOM root certificates
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.
The English translation version of WebTrust audit report is attached for your reference.
Aaron and Francis, please do the Information Verification for this request.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
Whiteboard: Information incomplete - Begin Information Verification
Assignee: kwilson → 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
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.
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.
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
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
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.
Assignee: frlee → awu
Whiteboard: Information incomplete - Begin Information Verification → [ca-verification]
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
Whiteboard: [ca-verification] → [ca-verifying]
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
Hi Kamo-san,

Noted with thanks.


Kind regards,
Aaron
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
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
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
Whiteboard: [ca-verifying] → [ca-verifying] - Need BR Self Assessment
Aaron-san,

The answers for Bugzilla8853339 are attached.
Thank you for your consideration.
Product: mozilla.org → NSS
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
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
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
Hi Aaron-san,

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

Best regards,
Hisashi Kamo
Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324
Assignee: awu → kwilson
Whiteboard: [ca-verifying] - Need BR Self Assessment → [ca-verifying] - BR Self Assessment provided 2018-02-01
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
Whiteboard: [ca-verifying] - BR Self Assessment provided 2018-02-01 → [ca-verifying] - KW Comment #27 2018-04-11

I reviewed the SECOM repository - https://repository.secomtrust.net/

I note that there is a CP (v.5.15) and a CPS (v.5.13) for the Root CAs, but that these do not detail the issuance practices for server certificates or SMIME certificates. Where is the CPS that documents compliance with the CA/Browser Forum's Baseline Requirements and Mozilla's Root Store Policy?

Flags: needinfo?(h-kamo)
QA Contact: kwilson

Dear Ben-san,

Thank you for your comment.

The CP (v.5.15) and the CPS (v.5.13) you commented are the policy and statement for signing from Root CAs to intermediate CAs.
The detail of issuance practices for server certificates or SMIME certificates are described on CPs for the relevant intermediate CAs.

Specifically, these are the CPs posted in the repository below.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Flags: needinfo?(h-kamo)

Dear Ben-san,

Please let us tell you that the repository of SMIME certificates is updated.
https://repo1.secomtrust.net/spcpp/pfm20pub/index.html

Thank you for your consideration.

Best regards,
Hisashi Kamo

In testing you test web sites, I receive the following errors, which need to be corrected:

https://sr4v.secomtrust.net/ AND https://sr4r.secomtrust.net/ - Intermediate and Leaf certificates are expired
https://sr5v.secomtrust.net/ AND https://sr5r.secomtrust.net/ - Intermediate and Leaf certificates are expired

Lint Test - https://sr5v.secomtrust.net/ - Unallowed key usage for EC public key (Key Encipherment)

Whiteboard: [ca-verifying] - KW Comment #27 2018-04-11 → [ca-verifying] - BW Comment #31 2020-09-28
Assignee: kwilson → bwilson

Dear Ben-san,

Thank you for the comment.
We are aware of it and now schduling as target of Mid-October for correction of the test web sites.

Best regards,
Hisashi Kamo

Dear Ben-san,

Please let us tell you that the test websites including OCSP setup have been finished.
Thank you for your consideration.

Best regards,
Hisashi Kamo

Yes. Now I can proceed with additional review of your application.

The test website https://sr5v.secomtrust.net/ passed testing, but the following websites still show errors:

https://sr5r.secomtrust.net/
https://sr5e.secomtrust.net/
https://sr4v.secomtrust.net/
https://sr4r.secomtrust.net/
https://sr4e.secomtrust.net/

For example, when I try to test "https://sr4v.secomtrust.net" the SAN in the certificate says "testrepository.secomtrust.net". The browser error reads, "The requested URL was not found on this server." I also read an error from the test results that says, "bad chain at intermediate". I think there must also be other errors with the certificate chain, too.

Flags: needinfo?(h-kamo)

Dear Ben-san,

Thank you for your notice.

As described at CCADB, the correct URLs of the test websites are as below.
(Already changed, not today)

・Security Communication RootCA3
(i) valid
https://sr4v.secom-cert.jp/
(ii) revoked
https://sr4r.secom-cert.jp/
(iii) expired
https://sr4e.secom-cert.jp/

・Security Communication ECC RootCA1
(i) valid
https://sr5v.secom-cert.jp/
(ii) revoked
https://sr5r.secom-cert.jp/
(iii) expired
https://sr5e.secom-cert.jp/

In regards to the Root CAs information on "Root Case00000084", we changed the test website URLs on "R00000125" and "R00000126" as above.
However, we got some message for "Test Websites" and "Test Results (When EKU has id-kp-serverAuth)" even though CRLs and OCSP are working all right.
Would you please check them?

https://ccadb.force.com/s/root-case/a00o000000rKIrOAAW/r00000125
https://ccadb.force.com/s/root-case/a00o000000u8Y9eAAE/r00000126

Thank you for your consideration.

Best regards,
Hisashi Kamo

Flags: needinfo?(h-kamo)

It looks like they are working. Thanks. I'll continue processing your inclusion case.

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