Add 2 new SECOM root certificates
Categories
(NSS :: CA Certificate Root Program, task)
Tracking
(Not tracked)
People
(Reporter: h-kamo, Assigned: bwilson)
Details
(Whiteboard: [ca-verifying] - BW Comment #31 2020-09-28)
Attachments
(5 files)
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•4 years ago
|
||
Kamo-san, will you be using this Bugzilla Bug to request a root inclusion/change request?
Comment 2•4 years ago
|
||
(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.
Reporter | ||
Comment 3•4 years ago
|
||
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.
Reporter | ||
Comment 4•4 years ago
|
||
The English translation version of WebTrust audit report is attached for your reference.
Comment 5•4 years ago
|
||
Aaron and Francis, please do the Information Verification for this request. https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
Updated•4 years ago
|
Updated•4 years ago
|
Comment 6•4 years ago
|
||
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
Reporter | ||
Comment 7•4 years ago
|
||
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.
Reporter | ||
Comment 8•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
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
Reporter | ||
Comment 11•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 12•4 years ago
|
||
Comment 13•4 years ago
|
||
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
Reporter | ||
Comment 14•4 years ago
|
||
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•4 years ago
|
||
Hi Kamo-san, Noted with thanks. Kind regards, Aaron
Reporter | ||
Comment 16•4 years ago
|
||
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•4 years ago
|
||
Comment 18•4 years ago
|
||
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•4 years ago
|
||
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
Reporter | ||
Comment 20•4 years ago
|
||
Aaron-san, The answers for Bugzilla8853339 are attached. Thank you for your consideration.
Updated•4 years ago
|
Comment 21•4 years ago
|
||
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
Reporter | ||
Comment 22•4 years ago
|
||
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•4 years ago
|
||
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
Reporter | ||
Comment 24•4 years ago
|
||
Hi Aaron-san, Thank you for the comment. This is what we checked and it is cleared now. Best regards, Hisashi Kamo
Comment 25•3 years ago
|
||
Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324
Comment 26•3 years ago
|
||
Updated•3 years ago
|
Comment 27•3 years ago
|
||
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
Assignee | ||
Comment 28•6 months ago
|
||
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?
Reporter | ||
Comment 29•6 months ago
|
||
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
Reporter | ||
Comment 30•6 months ago
|
||
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
Assignee | ||
Comment 31•5 months ago
|
||
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)
Assignee | ||
Updated•5 months ago
|
Assignee | ||
Updated•5 months ago
|
Reporter | ||
Comment 32•5 months ago
|
||
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
Reporter | ||
Comment 33•4 months ago
|
||
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
Assignee | ||
Comment 34•4 months ago
|
||
Yes. Now I can proceed with additional review of your application.
Assignee | ||
Comment 35•11 days ago
|
||
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.
Reporter | ||
Comment 36•11 days ago
|
||
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
Assignee | ||
Comment 37•11 days ago
|
||
It looks like they are working. Thanks. I'll continue processing your inclusion case.
Description
•