1313982 - Add SECOM root certificates

Status: RESOLVED FIXED

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

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

Comment 28

[Ben Wilson]

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?

Comment 29

[Hisashi Kamo]

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.

• Server certificates
  https://repo1.secomtrust.net/spcpp/pfw/pfwev2ca/
  https://repo1.secomtrust.net/spcpp/pfw/pfwsr3ca/

• SMIME certificates
  We are now planning to update the repository below for the latest version of CP in English on the week of September 14th.
  https://repo1.secomtrust.net/spcpp/pfm20pub/index.html

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 30

[Hisashi 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

Comment 31

[Ben Wilson]

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)

Comment 32

[Hisashi Kamo]

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

Comment 33

[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

Comment 34

[Ben Wilson]

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

Comment 35

[Ben Wilson]

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.

Comment 36

[Hisashi 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

Comment 37

[Ben Wilson]

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

Comment 38

[Ben Wilson]

Greetings SECOM Team.
I have updated the request in the CCADB. There is one section for each of the roots that needs to be reviewed and updated by SECOM. It is the "PKI Hierarchy" section. Could you please review those, provide more details, and let me know whether they are accurate?

Security Communication RootCA3 - https://ccadb.force.com/a00o000000rKIrOAAW
Subordinate CAs under this Root:

• SECOM TimeStamping CA3
• SMBC Certificate Authority CA2 G2 (Sumitomo Mitsui Banking Corporation)
• Subordinate Advanced CA G2 (Technically Constrained)
• Subordinate Advanced CA1 (Expired)

Security Communication ECC RootCA1 - https://ccadb.force.com/a00o000000u8Y9eAAE
Subordinate CAs under this root:

• NII Open Domain CA - G6 (National Institute of Informatics)
• NII Open Domain CA - G7 ECC (National Institute of Informatics)
• Subordinate Advanced ECC CA1 (Expired)
• Subordinate Advanced ECC CA G2 (Technically Constrained)

Please also indicate whether you will have any externally operated CAs under these roots and provide any other relevant information under that section "PKI Hierarchy". Once you have completed this task, I can advance your request to the CP/CPS Review Phase of the Inclusion Process.

Comment 39

[Hisashi Kamo]

Ben-san,

Thank you for your comment.
Please let us answer as follows.

The information is accurate.

The subordinate CA certificates below are already revoked.

Security Communication ECC RootCA1 - https://ccadb.force.com/a00o000000u8Y9eAAE
-NII Open Domain CA - G6 (National Institute of Informatics)

And we do not have externally operated CAs under these roots.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 40

[Ben Wilson]

Just confirming again that in accordance with Comment #11, EV treatment is not requested for these two roots.

Comment 41

[Ben Wilson]

Review of SECOM CP-CPS for Compliance with CABF and Mozilla Requirements
SECOM RootCA CPS, ver. 5.15 (Root CPS); SECOM RootCA Subordinate CA CP, ver. 5.18 (SubCA CP); SECOM Digital Certification Infrastructure CPS, ver. 2.15 (SECOM CPS); SECOM Passport for Web EV CA CP, ver. 2.78 (EV CP); SECOM Passport for Web SR CA CP, ver. 2.97 (OV CP); and Secom Passport for Member 2.0 PUB, ver. 6.00 (SMIME CP).
Based on BR v. 1.8.0 and Mozilla Root Store Policy v. 2.7.1
APPLICABLE REQUIREMENTS and References from RFC 3647, the BRs, the MRSP, CCADB Policy, etc.	DETAILED ROOT PROGRAM REVIEW Reviewer Comments
Preliminary Matters
Preliminary Matters Are the CPs and CPSes structured in accordance with RFC 3647?	Yes
CCADB Policy 5. "CAs must provide English versions of any Certificate Policy, Certification Practice Statement and Audit documents which are not originally in English, with version numbers matching the document they are a translation of. The English version is not required to be authoritative in all cases of dispute, but the CA must attest that the translation is not materially different to the original."	OK
Baseline Requirements for TLS Server Certificates
1 INTRODUCTION
1.1 Overview Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2) “The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and CA/Browser Forum Requirements, those Requirements take precedence.”	Need to fix- Section 1.1 of the OV CP and EV CP state "In the event of a conflict between this CP and the Service Terms or the CPS, the order of precedence in the application thereof shall be the Service Terms, this CP, and the CPS." The CABF requirements need to take precedence.
1.2.1. Revisions Your CP/CPS should have its own table of revisions and there should be a statement somewhere in your CP/CPS that explicitly requires an annual update to your CP/CPS. (MRSP § 3.3.4) (BR § 2.3) “CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.” Also, version history tables provide evidence of compliance and good change management practices.	OK - Each document has a "Version History". Also, section 1.5.3 of the documents says that they "will be reviewed and revised at least annually."
1.2.2. Relevant Dates Note the Compliance date for each item in this table found in the BRs. Those are the dates by which your CP/CPS and practices are expected to be updated to comply with the item. Make sure your CA is in compliance with each of these items. After careful consideration, indicate if your CA is fully compliant with all items in the table, or clearly indicate action that your CA is taking to improve compliance.	OK - SECOM should regularly review the Baseline Requirements to ensure that compliance dates are not missed.
1.3.1 Certification Authorities “CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.” MRSP § 3.3.6	OK - The CCADB provides a method by which the CA can indicate which CP and CPS applies to each root certificate.
1.3.2. Registration Authorities Indicate whether your CA allows for Delegated Third Parties, or not. Indicate which sections of your CP/CPS specify such requirements, and how the CP/CPS meets the BR requirements for RAs (including non-delegation of domain validation to RAs per BR § 1.3.2). (This is also a Mozilla Forbidden Practice.)	Need to fix - The response in the BR Compliance Self-Assessment does not address this issue and I could not locate the place in a CP or CPS where SECOM states that it does assign domain validation to any third party. In fact, section 9.16.2 (Assignment) of the OV and EV CP states, "When assigning the services to a third party, SECOM Trust Systems may assign its responsibilities and other obligations specified in this CP, the Service Terms, and the CPS."
1.4.2 Prohibited Certificate Uses CAs should ensure that the domain name registrant has approved or authorized a certificate request and prohibit the use of certificate to conduct surreptitious interception by third parties (except with the domain registrant's permission).	SECOM could make its policy and practices documentation better by specifying that it does not allow certificate issuance except to the owners of domains that it has verified in accordance with the BRs 3.2.2.4 and/or CP/CPS section 3.2.7.
1.5.2 Contact person In addtion to providing contact information in CP/CPS § 1.5.2, BR § 4.9.3 requires that CP/CPS § 1.5.2 also contain clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.	Need to fix - It is too difficult to locate information in the CPs on how to request revocation. Section 1.5.2 of all CPs and CPSes should explicitly provide clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. Currently, many of them only say, "Inquiries concerning this CP should be directed to: ...."
2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
Annually update CP and/or CPS. (BR § 2)	OK - see above
2.1. Repositories Provide the direct URLs to the CA's repositories	OK
2.2 Publication of information - RFC 3647 The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 with no blank sections. (MRSP § 3.3.5) (BR § 2.2)	OK
2.2 Publication of information - CAA Section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement SHALL state the CA's policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements. It shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue. The CA SHALL log all actions taken, if any, consistent with its processing practice.	Should fix - Section 4.2.4 of the OV CP and EV CP says "The CA shall check the CAA records during the review and authentication of the Certificate Application and the submitted information. The domain name of the CA to be included in the CAA record shall be [secomtrust.net]." This is an inadequate explanation. More detail is needed.
2.2. Publication of information - BR text "The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version." --> Copy the specific text that is used into the explanation in this row. (in English)	Should fix - The OV CP states that the CA conforms to the Baseline Requirements. (Unfortunately it does not say that it will abide by the "latest published version" or "most recent version" , etc.
2.2. Publication of information - test websites "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 that are (i) valid, (ii) revoked, and (iii) expired." --> List the URLs to the three test websites (valid, revoked, expired) for each root certificate under consideration. If you are requesting EV treatment, then the TLS cert for each test website must be EV.	OK - The CCADB provides a mechanism for disclosing the URLs of the three required websites.
2.3. Time or frequency of publication "The CA SHALL ... annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. The CA SHALL indicate conformance with this requirement by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document." Indicate your CA's policies/practices to ensure that the BRs are reviewed regularly, and that the CA's CP/CPS is updated annually.	OK
2.4. Access controls on repositories Acknowledge that all Audit, CP, CPS documents required by Mozilla's CA Certificate Policy and the BRs will continue to be made publicly available.	Need to fix. The CP says that only the "latest version" of the document will be made available in the repository. It does not address the availability of documents for the lifetime of the CA.
3. IDENTIFICATION AND AUTHENTICATION
3.1 Naming Naming must be compliant with X.500, RFC5280 and BRs. The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards. Names for CAs should be meaningful and descriptive. See Generic Names for CAs in Potentially Problematic Practices. Also, CNs and SANs in TLS server certificates cannot contain internal names or reserved IP addresses, see § 7.1.4.2.1 below.	Should reference the Baseline Requirements' naming requirements. Section 3.1.1 says that naming will be consistent with X.500 and that "[Common Name (CN)] shall be the hostname of the web server on which the Certificates issued by the CA will be installed." (Common name can only be one of the verified SANs!) Section 7.1.4 says that the CA conforms to RFC 5280. Documentation should reference that naming will also be in compliance with the Baseline Requirements, too.
3.1 Naming Also, the CA should describe its practices for handling Internationalized Domain Names (IDNs) in its CP/CPS.	SECOM should address this
3.2.2 Authentication of Organization and Domain Identity It is insufficient to just state that WHOIS is checked. See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#WHOIS	See comments about section 3.2.2.4 below
3.2.2.1 Identity If the certificate will contain Subject Identity Information (e.g. OV certificates with name or address of an organization), then indicate how your CP/CPS meets the requirements in this section of the BRs.	OK
3.2.2.2 DBA/Tradename If the certificate will contain a DBA or tradename, then indicate how your CP/CPS meets the requirements in this section of the BRs.	OK - Addressed in section 3.2.2.2
3.2.2.3 Verification of Country If the subject:countryName field will be present in certificates, then indicate how your CP/CPS meets the requirements in this section of the BRs.	OK
3.2.2.4 Validation of Domain Authorization or Control Indicate which of the methods of domain validation your CA uses, and where this is described in your CP/CPS. MRSP § 2.2 states: "The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with." See also MRSP § 3.3.1.	OK - Section 3.2.7 of the EV CP and OV CP discusses Domain Validation. SECOM asserts that domain validation is performed in accordance with BR Sections 3.2.2.4.2, 3.2.2.4.4, 3.2.2.4.7, 3.2.2.4.13, 3.2.2.4.14, 3.2.2.4.15, 3.2.2.4.16, 3.2.2.4.17, 3.2.2.4.18,
3.2.2.4 If the CA will issue .onion certificates, then explain how your CA validates the FQDN in accordance with Appendix B.	.onion not addressed
3.2.2.4 For each FQDN validated, does your CA maintain a record of which of the following domain validation methods was used, including the relevant BR version number?
3.2.2.4.1 Validating the Applicant as a Domain Contact This method SHALL NOT be used.	N/A
3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	OK
3.2.2.4.4 Constructed Email to Domain Contact If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	OK
3.2.2.4.5 Domain Authorization Document This method SHALL NOT be used.	N/A
3.2.2.4.6 Agreed‐Upon Change to Website This method has been replaced with BR § 3.2.2.4.18 and shall not be used.	N/A
3.2.2.4.7 DNS Change If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	OK
3.2.2.4.8 IP Address If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	N/A
3.2.2.4.9 Test Certificate This method SHALL NOT be used.	N/A
3.2.2.4.10. TLS Using a Random Number This method SHALL NOT be used.	N/A
3.2.2.4.11 Any Other Method This method SHALL NOT be used.	N/A
3.2.2.4.12 Validating Applicant as a Domain Contact "This method may only be used if the CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name." If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	N/A
3.2.2.4.13 Email to DNS CAA Contact If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	OK
3.2.2.4.14 Email to DNS TXT Contact If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	OK
3.2.2.4.15 Phone Contact with Domain Contact If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	OK
3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	OK
3.2.2.4.17 Phone Contact with DNS CAA Phone Contact If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	OK
3.2.2.4.18 Agreed-Upon Change to Website v2 If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	OK
3.2.2.4.19 Agreed-Upon Change to Website - ACME If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	N/A
3.2.2.4.20 TLS Using ALPN - If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.	N/A
3.2.2.5 Authentication for an IP Address If your CA allows IP Addresses to be listed in certificates, indicate which methods your CA uses and how your CA meets the requirements in this section of the BRs. MRSP § 2.2.4 requires the CA to "clearly specify the procedure(s) that the CA employs, and each documented procedure must state which subsection of 3.2.2.5 it is complying with." Also, CAs must maintain a record of the IP validation method used for each IP address and the relevant BR version number.	N/A
3.2.2.6 Wildcard Domain Validation If your CA allows certificates with a wildcard character in a CN or subjectAltName of type DNS‐ID, then indicate how your CA meets the requirements in this section of the BRs.	N/A
3.2.2.7 Data Source Accuracy The CA's CP/CPS must explain how the CA determines that a third-party data source is reliable. For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.” (Additional criteria are found in BR § 3.2.2.7) For EV - “A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis.” (EVG § 11.11.5)	Need to Fix - SECOM states that it uses a Reliable Data Source-- "A third party database that is periodically updated and considered a Reliable Data Source", but it does not explain how it selects which sources are reliable. SECOM needs to explain this using applicable criteria in BR section 3.2.2.7.
3.2.2.8 CAs MUST check and process CAA records Indicate how your CA meets the requirements of sections 2.2 and 3.2.2.8 of the BRs. NOTE: BR § 2.2 requires that "Section 4.2. of a CA's Certificate Policy and/or Certification Practice Statement ... state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names [and] ... clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue."	Should add more detail. SECOM should provide more detail on the way it processes CAA records.
3.2.3. Authentication of Individual Identity "The CA SHALL ... inspect the copy [of any personal ID] for any indication of alteration or falsification."	OK - Section 3.2.3 adequately describes verification of individual identity.
3.2.4 Non-verified subscriber information “All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.” (MRSP § 2.2.1)	OK (Section 3.2.4 states "This CA confirms that the department name (Organizational Unit Name) is not misleading from the certificate issuance application documents and CSR information submitted by the Certificate Subscriber."
3.2.5. Validation of Authority "[T]he CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representative’s certificate request."	Good - SubCA CP discusses use of the Reliable Method of Communication to verify authority of Applicant's representative.
3.2.6. Criteria for Interoperation or Certification Disclose all cross-certificates in the CA hierarchies under evaluation. (See e.g. MRSP § 5.3)	OK
3.3.1 Identification and authentication for routine re‑key For data re-use, see subsection 5 of MRSP § 2.1 and BR § 4.2.1.	Should clarify - The policy documents are unclear about data reuse not being allowed after 397 days (domain validation) or 825 days (other information). See BR section 4.2.1.
4. CERTIFICATE LIFE‑CYCLE OPERATIONAL REQUIREMENTS
4.1.1. Who Can Submit a Certificate Application Indicate how your CA identifies suspicious certificate requests.	OK - SECOM checks the site at Council of Anti-Phishing Japan. https://www.antiphishing.jp/
4.1.2. Enrollment Process and Responsibilities The process must require 1. a certificate request, and 2. a Subscriber Agreement.	OK - SECOM states in the BR compliance self-assessment, "In applying for a Certificate, a subscriber or an agent entrusted by the subscriber to perform the application procedure shall agree to the contents of this CP, the Service Terms and the CPS before proceeding with the application and must also guarantee that the information provided in the application is accurate. The method for requesting a Certificate is as follows: Submit the documents required to we in accordance with the "Application Procedure" on the website. CP section 4.1.2 Secom Website - https://www.secomtrust.net/service/pfw/apply/sr/ "
4.2. Certificate application processing As previously stated above, BR § 2.2 says that the CA's CAA records processing must appear somewhere in section 4.2 of the CP/CPS.	SECOM should provide more detail on the way it processes CAA records.
4.2.1. Performing Identification and Authentication Functions (MRSP § 2.1.5) Indicate how your CA identifies high risk certificate requests. Re-use of domain / IP address validation is limited to 398 days and re-use of other validation information is limited to 825 days	Should clarify - The policy documents are unclear about data reuse not being allowed after 397 days (domain validation) or 825 days (other information). See BR section 4.2.1.
4.2.2. Approval or Rejection of Certificate Applications BR § 4.2.2 says, "CAs SHALL NOT issue certificates containing Internal Names." (This prohibition can appear elsewhere in your CP/CPS.)	Should fix - Could be improved to be more explicit that certificates are not issued to internal, non-FQDN domain names. Currently section 7.1.4 of the OV CP and EV CP says, "The CA SHALL NOT include a Domain Name or IP Address in a Subject attribute except as specified in BR Section 3.2.2.4 or BR Section 3.2.2.5."
4.3.1. CA Actions during Certificate Issuance Pre-issuance linting (Recommended Practices) “It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences”	SECOM should explain the pre-issuance linting it performs on server certificates.
4.3.1. CA Actions during Certificate Issuance It is presumed that for each precertificate a corresponding certificate exists. See Required or Recommended Practices. Therefore, CAs must have the means to provide OCSP and revoke the serial number for any precertificate.	Good - Section 4.9.10 of the OV CP and the EV CP states, "The OCSP responder MAY provide definitive responses about "reserved"certificate serial numbers, as if there was a corresponding Certificate that matches the Precertificate [RFC6962]."
4.3.1. CA Actions during Certificate Issuance CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”. (MRSP § 2.1.3)	Should fix - While section 6.5.1 of the CPSes says, "The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance." This is also an obligation applicable to CAs and RAs involved in the issuance of end entity certificates and should also be stated in the OV CP and the EV CP.
4.3.1 CA Actions during Certificate Issuance The backdating of a certificate's notBefore date to avoid a deadline, prohibition, or code-enforced restriction is a Problematic Practice.	Not stated in the SECOM policy documentation. Could be improved.
4.9.1 Circumstances for revocation See Required Practice - CAs must revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.	Good - covered in applicable CPs
4.9.1.1 Reasons for Revoking a Subscriber Certificate Your CA's CP/CPS' reasons and timeframes for revoking an end entity certificate must be consistent with the reasons and timeframes required by this section of the BRs (24-hour revocation for reasons 1 through 5, and 5 days for the second set of reasons 1 through 11).	Good - BR revocation reasons are covered in Sub CA CP, EV CP and OV CP.
4.9.1.2 Reasons for Revoking a Subordinate CA Certificate Your CA's CP/CPS's reasons and timeframes for revoking subordinate CA certificates must be consistent with the reasons and timeframes required by this section of the BRs. (Revocation within 7 days for reasons 1 through 9).	Good - BR revocation reasons are covered in Sub CA CP, EV CP and OV CP.
4.9.2. Who Can Request Revocation In addition to accepting revocation requests from Subscribers, your CA should also accept revocation requests from Relying Parties, Application Software Suppliers, and other third parties who file Certificate Problem Reports. See BR § 4.9.3.	Good - applicable CP documents state, "third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate"
4.9.3. Procedure for Revocation Request The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports. ... The CA SHALL publicly disclose clear instructions through readily accessible online means and in section 1.5.2 of their CPS. (Also see Potentially Problematic Practices re: lack of communication.)	Need to fix - Section 4.9.3 of the SubCA CP states, "The CA SHALL publicly disclose the instructions through a readily accessible online means and the CP "1.5.2 Contact Information". But this is not adequately found in section 1.5.2 of any of the SECOM policy/practices documents.
4.9.5. Time within which CA Must Process the Revocation Request The CA shall investigate and preliminarily respond to the Subscriber and the person filing a Certificate Problem Report within 24 hours. In any case requiring revocation, the timeframe from notice to revocation shall not exceed that stated in BR § 4.9.1.1.	Good - Section 4.9.5 of the relevant CPs states, "The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in this CP, Section 4.9.1.1."
4.9.7. CRL Issuance Frequency Indicate if your CA publishes CRLs. If yes, then please test your CA's CRLs. CRLs must be issued at least every 7 days w/ nextUpdate of not more than 10 days (MRSP § 6)	Good - addressed in section 4.9.7 of the OV CP and the EV CP.
4.9.9. On-line Revocation/Status Checking Availability OCSP responses must be updated at least every 4 days w/ max. expiration of 10 days (MRSP § 6)	Good - addressed in section 4.9.10 of the OV CP and the EV CP.
4.9.10. On-line Revocation Checking Requirements Indicate how your CA meets all of the requirements listed in this section, including support of GET, update frequency (recently updated), and preventing erroneous return of "good" status.	Good - see section 4.9.10 of the relevant CPs
4.9.12 "CA's CP/CPS MUST clearly specify the methods that parties may use to demonstrate private key compromise." (MRSP § 6)	Good - see section 4.9.12 of the relevant CPs
4.9.13 Certificate suspension Suspension must not be supported (for TLS server certificates).	Good
4.10 Certificate status services
4.10.1. Operational Characteristics https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#OCSP	OK
4.10.2. Service Availability CRL and OCSP resources must provide a response time of ten seconds or less under normal operating conditions.	Good - addressed in section 4.10.2 of the relevant CPs
5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS
The Network and Certificate System Security Requirements are incorporated by reference, and the CA SHALL develop, implement, and maintain a comprehensive security program. The security program MUST include an annual Risk Assessment. Based on the Risk Assessment, the CA SHALL develop, implement, and maintain a security plan. (BR § 5)	Good - Section 5 of the relevant CPSes states, "The CA/Browser Forum's "Network and Certificate System Security Requirement" is fully incorporated into this document by reference." They also state, "The CA's security program must include the following annual risk assessments: ...."
5.2.2. Number of Individuals Required per Task CA Private Keys shall be managed only by personnel in trusted roles using, at least, dual control in a physically secured environment	Good - Section 5.2.2. of the CPS states, "Critical operations, such as those related to the CA Private Key, are jointly performed by at least two persons."
5.3.1. Qualifications, Experience, and Clearance Requirements The CA shall verify the identity and trustworthiness of persons involved in certificate management processes.	Good - Adequately addressed in section 5.3.1 of the relevant CPSes
5.3.3. Training Requirements and Procedures The CA must train and keep training records for personnel performing information verification duties.	Good - Adequately addressed in section 5.3.3 of the relevant CPSes
5.3.4. Retraining Frequency and Requirements All persons in trusted roles must maintain the necessary skills.	Good - Adequately addressed in section 5.3.4 of the relevant CPSes
5.3.7. Independent Contractor Controls Third parties performing information verification duties must meet the requirements of BR § 5.3.3.	Good - Adequately addressed in section 5.3.7 of the relevant CPSes
5.4.1. Types of Events Recorded Indicate how your CA meets the requirements of this section.	OK
5.4.3. Retention Period for Audit Logs Certain information has to be maintained for 2 years after certificate expiration/revocation or the occurrence of the security event.	Good - documentation kept for 10 years
5.4.8. Vulnerability Assessments Indicate how your CA meets the requirements of this section.	Good - Adequately addressed in section 5.4.8 of the relevant CPSes
5.5.2. Retention Period for Archive Certain certificate information must be maintained in an archive for 7 years following expiration/revocation.	Good - documentation kept for 10 years
5.7.1. Incident and Compromise Handling Procedures Indicate how your CA meets the requirements of this section, including notifying Mozilla in the event of CA key compromise. MRSP § 7 states, “Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”	Good - Section 5.7.1 of the relevant CPSes states, "The CA SHALL document a business continuity and disaster recovery procedures designed to notify and reasonably protect Application Software Suppliers, Subscribers, and Relying Parties in the event of a disaster, security compromise, or business failure."
6. TECHNICAL SECURITY CONTROLS
6.1.1. Key Pair Generation Indicate how your CA meets the requirements of this section.	Good - Adequately addressed in section 6.1.1 of the relevant CPs and CPSes
6.1.1.3 Subscriber Key Pair Generation - For TLS server certificates, the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA. (MRSP § 5.2)	OK - Section 6.1.1 of the OV CP and the EV CP states, "Subscriber Key Pairs are generated by the Subscriber." (And section 6.1.2 states, "The CA does not deliver Private Keys to Subscribers.")
6.1.2. Private Key Delivery to Subscriber "Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber."	OK - see above
6.1.5. Key Sizes (MRSP § 5.1) For RSA, ensure that the modulus size, when encoded, is at least 2048 bits, and that the modulus size, in bits, is evenly divisible by 8. For ECC, ensure that the key represents a valid point on the NIST P-256 or NIST P-384 curve.	Good - this is stated in section 6.1.5 of the SECOM CPS.
6.1.6. Public Key Parameters Generation and Quality Checking For RSA keys, ensure that public exponent is an odd number equal to 3 or more and in the range between 2^16 + 1 and 2^256 ‐ 1. The modulus should also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. For ECC, use either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine.	Good - this is stated in section 6.1.6 of the SECOM CPS.
6.1.7. Key Usage Purposes Private Keys corresponding to Root Certificates shall only be used for the purposes indicated (and not used to issue end entity certificates). (Mozilla Forbidden Practice)	Good - this is addressed in section 6.1.7 of the Root CPS.
6.2. Private Key Protection and Cryptographic Module Engineering Controls Protections must implemented in a manner that prevents disclosure of the Private Key.	Good - this is addressed in section 6.2 of the relevant CPSes.
6.2.5. Private Key Archival Subordinate CA private keys shall not be archived by third parties.	OK - Section 6.2.5 of the relevant CPs and CPSes states, "The CAs do not archive CA Private Keys."
6.2.6. Private Key Transfer into or from a Cryptographic Module If the Issuing CA generated the Private Key on behalf of the Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Subordinate CA.	OK - Section 6.2.6 of the Root CPS states, "CA Private Keys of the CA are generated inside an HSM and will never be retrieved by other hardware or software." Section 6.2.6 of the SECOM CPS says, "The transfer of Private Keys of the CAs operated on the Digital Certification Infrastructure into and from an HSM is performed in a secure room while encrypted." This explanation of key migration to other HSMs could be clarified by stating the HSM manufacturer's instructions on securely migrating CA keys are followed, that private keys remain encrypted, that they never appear in plaintext outside of the HSM, etc.
6.2.7. Private Key Storage on Cryptographic Module The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140 level 3 or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher).	Good - as stated in section 6.2.1 and other sections in SECOM's CPs and CPSes.
6.5.1. Specific Computer Security Technical Requirements The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance. (MRSP § 2.1) Indicate how your CA meets the requirements of this section.	Should fix - While section 6.5.1 of the CPSes says, "The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance." This is also an obligation applicable to CAs and RAs involved in the issuance of end entity certificates and should also be stated in the OV CP and the EV CP.
6.7 Network Security Controls (MRSP § 2.1.2) CAs must follow industry best practices for securing their networks, for example by conforming to the CA/B Forum's Network and Certificate System Security Requirements. See also https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Network_Security_Controls	Good - Section 5 of the relevant CPSes states, "The CA/Browser Forum's "Network and Certificate System Security Requirement" is fully incorporated into this document by reference."
7. CERTIFICATE, CRL, AND OCSP PROFILES
7.1. Certificate profile CAs SHALL generate non-sequential Certificate serial numbers greater than 0 containing at least 64 bits of output from a CSPRNG. (MRSP § 5.2) Indicate how your CA meets the requirements of this section.	Good - addressed in section 7.1 of the OV CP and the EV CP.
7.1.1. Version Number(s)
7.1.2. Certificate Content and Extensions; Application of RFC 5280
7.1.2.1 Root CA Certificate
7.1.2.1.b Key Usage If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set.	OK
7.1.2.2 Subordinate CA Certificate
7.1.2.2.e Key Usage If the CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set.	OK
7.1.2.2.g Subordinate CA Certificate - Separate, EKU-constrained issuing CAs (MRSP § 5.3) Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU. Also, it is important to distinguish CAs using the appropriate serverAuth or emailProtection EKU. (See Required or Recommended Practices)	Good - Certificate Profile tables in section 7.1 of the SubCA CP flag the importance of not include the wrong EKUs in intermedate CA certificates. E.g. it says, "Be sure to set it after January 1, 2019, but do not set anyExtendedKeyUsage. Do not set id-kp-serverAuth and id-kp-emailProtection at the same time. id-kp-codeSigning is set independently."
7.1.2.3 Subscriber Certificate
7.1.2.3.c OCSP must be provided over http. https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#OCSP	Good - "http" is specified in the certificate profile tables in section 7.1 of the OV CP and the EV CP
7.1.2.3.f For TLS server certificates, either the value id-kp-serverAuth or id-kp-clientAuth or both values MUST be present. id-kp-emailProtection MAY be present. Other values SHOULD NOT be present. The value anyExtendedKeyUsage MUST NOT be present. (MRSP § 5.2)	Good - Only the serverAuth EKU is specified in the certificate profile tables in section 7.1 of the OV CP and the EV CP
7.1.3.2 Signature AlgorithmIdentifier SHA-1 is prohibited (except in a very narrow exception case). (BR § 7.1.3.2.1) (MRSP § 5.1.3) (Also a Mozilla Forbidden Practice)	Should fix - Section 7.1.3 of the Sub CA CP could be ambiguous - it says, "The Algorithm OIDs used in the Services are as follows:. Table 7.1-3-1 Security Communication RootCA1 Algorithm sha1 With RSA Encryption OID 1.2.840.113549.1.1.5" This could mean that the services are using SHA1 for the Security Communication RootCA1.
7.1.4. Name Forms
7.1.4.1 Name Encoding Subject and Issuer Names for all possible certification paths MUST be byte-for-byte identical	Good - this language appears in section 7.1.4 of the relevant CPs
7.1.4.2 Subject Information - Subscriber Certificates CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute except as specified in BR §§ 3.2.2.4 and 3.2.2.5. Subject attributes MUST NOT contain only metadata such as ‘.’, ‘‐’, and ’ ’ (i.e. space) to indicate that it is blank, etc.	Good - this language appears in section 7.1.4 of the relevant CPs
7.1.4.2.1 Subject Alternative Name Extension This extension MUST contain at least one entry. Each entry MUST be either a dNSName (FQDN) or an iPAddress of a server. CAs SHALL NOT issue certificates with a SAN or commonName containing a Reserved IP Address or Internal Name. (Also a Mozilla Forbidden Practice) Entries in the dNSName MUST be in the "preferred name syntax", as specified in RFC 5280, and thus MUST NOT contain underscore characters ("_").	Should fix - Section 7.1 of the EV CP (Table 7.1-1 SECOM Passport for Web EV 2.0 CA Server Certificate Profile) should make it more clear that the CN is a SAN, and that the SAN is an FQDN (and not simply "Server Name" which is ambiguous and could mean an internal server name). This same problem is in the OV CP (Table 7.1-1 SECOM Passport for Web SR 3.0 CA Server Certificate Profile) and should be made more clear.
7.1.4.2.2 Subject Distinguished Name Fields (Common Name) If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 7.1.4.2.1).	Section 7.1 of the EV CP (Table 7.1-1 SECOM Passport for Web EV 2.0 CA Server Certificate Profile) should make it more clear that the CN is a SAN, and that the SAN is an FQDN (and not simply "Server Name" which is ambiguous and could mean an internal server name). This same problem is in the OV CP (Table 7.1-1 SECOM Passport for Web SR 3.0 CA Server Certificate Profile) and should be made more clear.
7.1.4.3 Subject Information - Root Certificates and Subordinate CA Certificates
7.1.5. Name Constraints Indicate your CA's understanding of MRSP § 5.3, and requirement to disclose in the CCADB within 7 days of creation all subordinate CA certificates that are not technically constrained as described in this section of the BRs.	OK
7.1.6. Certificate Policy Object Identifier
7.1.6.1 Reserved Certificate Policy Identifiers
7.1.6.2 Root CA Certificates
7.1.6.3 Subordinate CA Certificates
7.1.6.4 Subscriber Certificates Certificates MUST contain "one or more policy identifier(s) that are specified beneath the CA/Browser Forum’s reserved policy OID arc of {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1)} (2.23.140.1)."	Good - Certificate Profile table in Section 7.1 of OV CP indicates CABF OID of 2.23.140.1.2.2
7.2 and 7.3 - All OCSP responses and CRL entries for Subordinate CA Certificates MUST include a meaningful reason code.	Good - section 7.3 of the OV CP states "Effective 2020-09-30, the CRLReason indicated MUST contain a value permitted for CRLs, as specified in the CP “Section 7.2.2 CRL Entry Extensions”."
7.2.2 CRL and CRL entry extensions The issuer name for the CRL should match the issuer name in the CA certificate byte-for-byte. See Potentially Problematic Practices.	OK - SECOM should note this.
8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS
8.1. Frequency or circumstances of assessment The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration. MRSP sections 3.1.3 and 7.1 require CAs to maintain a Complete Audit History from cradle to grave. For new CA Certificates: The point-in-time readiness assessment SHALL be completed no earlier than twelve months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate. Indicate your CA's understanding of this requirement, and how your CA meets the requirements of this section.	OK - SECOM should note that each CA certificate must be included on a continuous series of audit reports from creation to destruction, i.e. "cradle-to-grave."
Also indicate your understanding and compliance with MRSP § 3.1.3, which says: “Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually from the time of CA key pair generation until the CA public key is no longer trusted by Mozilla's root store. This cradle-to-grave audit requirement applies equally to subordinate CAs as it does to root CAs. Successive period-of-time audits MUST be contiguous (no gaps).	OK - SECOM should note that each CA certificate must be included on a continuous series of audit reports from creation to destruction, i.e. "cradle-to-grave."
8.2. Identity/qualifications of assessor Indicate how your CA meets the requirements of this section. (Mozilla has additional requirements - https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications))	OK - SECOM should note new Mozilla requirements for reporting and checking auditor qualifications
8.4. Topics covered by assessment (Mozilla has slightly different requirements. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#311-audit-criteria))	OK - SECOM should note that Mozilla's audit requirements might differ slightly from those stated by SECOM
8.5 Actions taken as a result of deficiency (Previously undisclosed incidents must be reported in Bugzilla and sufficiently remediated.) https://wiki.mozilla.org/CA/Responding_To_An_Incident	OK - SECOM should note that Mozilla requires that incidents be reported to auditors and to the Mozilla community via Bugzilla
[8.6. Communication of results In addition to BR § 8.6, see also https://www.ccadb.org/policy#51-audit-statement-content "The Audit Report must contain certain information formatted in a certain way, including but not limited to: - name of the company being audited; etc.]"	Good - Section 8.6 of the relevant CPSes contain the appropriate language.
8.7. Self-Audits CAs must perform "self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued."	Good - addressed in section 8.7 of the SECOM CPS.
9. OTHER BUSINESS AND LEGAL MATTERS
9.5 Intellectual Property Rights - E.g. “CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)” (MRSP § 3.3.3)	Should fix - SECOM should acknowledge that publicly disclosed policy/practices documentation is made available to the public with a Creative Commons license Attribution-NoDerivs (CC-BY-ND) 4.0, unless otherwise specified.
9.16.3. Severability In the event of a conflicting law, the CA shall include in Section 9.16.3 of the CA’s CPS a detailed reference to the Law requiring a modification of these Requirements and must immediately notify the CA/Browser Forum.	Should fix - SECOM should address this requirement from section 9.16.3 of the Baseline Requirements.
For CAs seeking enablement of Email Trust bit
The CA's CP/CPS MUST explain how the CA verifies email address control (i.e. using a challenge-response mechanism). (MRSP § 2.2.2 and https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response)	N/A - see next
CA must validate the domain part of all e-mail addresses (MRSP § 2.2.2) - “For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.” (This type of delegation is also a Mozilla Forbidden Practice.)	OK - A process is described in section 3.2.7 of the SMIME CP.
SMIME Reasons for Revocation (MRSP § 6.2) “For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events …” (including "5. the CA receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted").	Wording/Translation could be improved - currently section 4.9.1 of the SMIME CP says, "Use of the domain name or Email address in the certificate gives reasonable evidence that it i s no longer legally permitted;" It might not depend on the "use" of the email address giving reasonable evidence. It might be as simple as "Use of the domain name or Email address in the certificate is no longer legally permitted".

Comment 42

[Hisashi Kamo]

Ben-san,

We appreciate very much for your thorough review.
Please let us apologize for the delay in replying due to the New Year's holidays in Japan.

We start checking the contents Ben-san pointed out.

Let us have some time to give you our update schedule.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 43

[Ben Wilson]

Here are my comments based on a review of the SECOM EV CP (v.3.00) and the EV Guidelines:

Provision from the EV Guidelines	Comments about the SECOM EV CP
EVG 8.4 - the CA shall maintain liability insurance of US$2 million and professional liability insurance of US$5 million.	Must fix Section 9.2.1 of the EV CP should say something similar to: “SECOM Trust Systems maintains adequate insurance or other financial resources for the operation and maintenance of the CA and for meeting the insurance requirements of the EV Guidelines.”
EVG 9.2.1 - the organization name must include the full legal name for the subscribing organization as listed in official records.	Should fix Instead of just saying “Required”, the Subject Organization field in Table 7.1-1 should also say something similar to: “the full legal name for the subscribing organization as listed in official records”.
EVG 9.2.3, 11.2.1 and 11.2.2 – The CA must verify the Applicant’s legal existence and identity directly with the incorporating agency or registration agency and the business category field must contain one of the following: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity"	Good EV CP section 3.2.2.1 says that the CA verifies “whether the certificate subscriber is an organization whose existence and establishment (incorporation) are legally recognized by establishment …, etc.” However, the EV CP does not explain that the business category field must contain one of the allowed values. Also, footnote 2 to Table 7.1-1 indicates that SECOM uses only two values for the business category field –"Private Organization" or "Government Entity".
EVG 9.2.4 - jurisdiction of incorporation/registration fields must not contain information that is not relevant to the level of the incorporating agency or registration agency.	OK It appears from Table 7.1-1 that there is only one value for this jurisdiction of incorporation field – “JP”
EVG 9.2.4, 9.2.5, and 11.1.3 – the CA shall maintain a publicly available list of its verification sources, incorporating agencies, and registration agencies (e.g. QIISes, QGISes, QGTISes). Information about where this information is located must appear in section 3.2 of the CPS.	Must Fix EV CP section 3.2.2 says, “the verification source will be disclosed on the Secom Trust Systems website (https://www.secomtrust.net/ ). This is not specific enough. I could not locate the list of verification sources from that URL, and it wasn’t listed on the repository page either.
EVG 9.2.5 and 11.2.1 - subject registration number: if the jurisdiction of incorporation or registration does not provide a registration number, then the date of incorporation or registration is entered in this field.	Good Footnote 1 to Table 7.1-1 indicates how SECOM populates the subject registration/serial number in certificates.
EVG 9.2.6 - subject physical address of place of business must contain the address of the physical location of the business.	Should fix Unclear what values SECOM uses for “State Or Province” and “Locality” in Table 7.1-1. In both instances it says “Required”, but it should also say something like “Verified Physical Location” so that it is the physical location and not some other address for the organization that has not been verified.
EVG 9.2.7 - the CA shall implement a process that prevents an organizational unit from including a trade name unless the CA has verified that information.	OK EV CP section 3.2.4 states, “The CA confirms that the department name (Organizational Unit Name) is not misleading from the certificate issuance application documents …”
EVG 9.2.8, 9.8.2, and Appendix H – if included in the certificate, the CA shall confirm registration references for legal entities.	N/A It does not appear that SECOM includes registration references in EV certificates.
EVG 9.2.9 - the CA shall not include any subject attributes except as specified in EVG § 9.2.	Must fix In section 7.1 of the EV CP, SECOM must say something similar to “The CA does not include any Subject Distinguished Name attributes except as specified in Section 9.2 of the EV Guidelines.”
EVG 10.1.2 - the roles of certificate requestor, certificate approver, and contract signer are required for the issuance of EV certificates.	Must fix Section 4.1.1 mentions an “Authorized Person” but does not differentiate the three “EV roles” of certificate requestor, certificate approver, and contract signer. These can be the same person, but the roles need to be verified. Also, these roles are noted in comments below related to sections 11.5.1, 11.8.1, 11.9, and 11.12.2 of the EV Guidelines.
EVG 11.2.2(4) - principal individuals must be validated in a face-to-face setting.	N/A
EVG 11.3.1 - assumed names must be verified with an appropriate government agency or a QIIS that has verified the assumed name with the appropriate government agency.	Should fix SECOM should reference Appendix D-1 of the EV Guidelines as an appropriate means for establishing Romanized names, etc., of certificate subscribers.
EVG 11.5.1 - the CA must establish of verified method of communication with the applicant.	Must fix In order to verify information about the Authorized Person, to confirm that SECOM is dealing with the “real” organization and the “real” “authorized person”, a verified method of communication needs to be independently established by reference to an authoritative source. See EVG 11.5.1 for more details
EVG 11.6.1 - the CA must verify that the applicant has the ability to engage in business. The EV issuance process requires that the operational existence be established in one of 4 enumerated ways: “(1) existence for at least three years, ... (2) listed in either a current QIIS or QTIS; (3) Demand Deposit Account ... by receiving authenticated documentation ... directly from a Regulated Financial Institution; or (4) ... a Verified Professional Letter ....”	Must fix The EV CP does not contain an explanation of the “business existence” requirement of EV – i.e. that the EV applicant is engaged in real business or has the ability to engage in real business. EV issuance requires that the organization not just be incorporated or registered with a government entity, but something more is required, as discussed in EVG 11.6.1.
EVG 11.8.1 - the CA must verify the name and title of the contract signer and certificate approver	Must fix Section 4.1.1 of the EV CP does not mention that the CA verifies the name and title of the contract signer and certificate approver
EVG 11.9 - the CA must verify the signature on the subscriber agreement and certificate request	Must fix Section 4.1.1 of the EV CP does not mention that the CA verifies the signature on the subscriber agreement and certificate request
EVG 11.12.2 - the CA must check whether the applicant, contract signer, or certificate approver is on denied persons lists, etc.	Must fix Section 4.1.1 of the EV CP does not mention that the CA checks whether the applicant/organization, contract signer, or certificate approver is on a denied persons list
EVG 11.13, 14.1.3 and 16 - the CA must perform final cross-correlation and other due diligence based on the entire corpus of information and have multi-person, auditable controls to ensure separation of duties with respect to EV certificate issuance	Must fix Section 4.1.1 of the EV CP does not mention that the CA performs final cross-correlation and other due diligence based on the entire corpus of information and implements multi-person, auditable controls to ensure separation of duties with respect to EV certificate issuance.
EVG 12 - root CA private keys must not be used to sign EV certificates.	Must fix Many CAs include a statement in section 6.1.7 of their CP/CPS that mirrors BR section 6.1.7, which says, “Private Keys corresponding to Root Certificates MUST NOT be used to sign Certificates except in the following cases: 1. Self‐signed Certificates to represent the Root CA itself; 2. Certificates for Subordinate CAs and Cross Certificates; 3. Certificates for infrastructure purposes (administrative role certificates, internal CA operational device certificates); and 4. Certificates for OCSP Response verification.”
EVG 14.1.1 - a CA must verify the identity and trustworthiness of anyone involved in EV processes.	OK Sections 5.3.1 and 5.3.2 of the SECOM CPS adequately address this requirement in general.
EVG 14.1.2 – an internal examination of specialists must include the EV certificate validation criteria of the EV guidelines.	OK Section 5.3.3 of the SECOM CPS adequately addresses this requirement in general.
EVG 14.2.1 - the CA shall ensure that third-party personnel satisfy the training and skills requirements of section 14 of the EV guidelines.	OK Section 5.3.7 of the SECOM CPS adequately addresses this requirement in general.

Comment 44

[Hisashi Kamo]

Ben-san,

Thank you very much for your thorough review or our EV CP.
We start checking the contents Ben-san pointed out.

Please let us have some time to update.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 45

[ONO Fumiaki]

Attachment: CP-CPS_Review-20220704-final.xlsx

Comment 46

[ONO Fumiaki]

Attachment: CA Compliance Self Assessment_20220704.xlsx

Comment 47

[Ben Wilson]

This inclusion request has been moved to public discussion with an anticipated closing date of Wed., July 27, 2022.
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/d3LIsEHnJkc/m/RJ223GFbAgAJ

Comment 48

[Ben Wilson]

Today, public discussion closed, and we began a 7-day final call for any objections. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/d3LIsEHnJkc/m/UKu3viPFBwAJ

Comment 49

[Ben Wilson]

The seven-day, last-call period has ended, and I'm recommending that SECOM roots be approved for inclusion as stated herein (websites and email trust bits, no EV).

Comment 50

[Kathleen Wilson]

On behalf of Mozilla I approve this request from SECOM Trust Systems CO., LTD. to include the following root certificates:

** Security Communication RootCA3 (Email, Websites)
** Security Communication ECC RootCA1 (Email, Websites)

I will file the NSS bug for the approved changes.

Comment 51

[Kathleen Wilson]

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