Re: SECOM Request for EV Treatment
I don't so much have a problem with the change but I would like to know if this is fairly common across other cert issuers? Personally I'm of the opinion that email is inherently insecure which makes it a bad mechanism to use in the course of trying to establish trust. However, my concern at the moment is the use of privacy services to obscure the actual owner/registrar of the domain. I see no reason to believe such services are any more trustworthy than the email channel. In fact it seems to me that those services are the weakest link in the chain. The implication is that only method 1, below, should be employed. However, if everyone else is also employing method 2 I don't want to single out SECOM unfairly. Original Message From: Kathleen Wilson Sent: Tuesday, December 1, 2015 11:34 AM > Here is the text that was added to the CP: > ~~ > The authentication method is as follows: > 1. Using the WHOIS registry service, SECOM Trust System verifies that > the relevant subscriber owns the domain to which the Certificate pertains. > 2. Should the owner of the domain be different from the subscriber, > SECOM Trust Systems authenticates the domain by having the domain owner > submit to SECOM Trust Systems a document granting subscriber the > permission to use the domain or by sending a verification e-mail to the > e-mail address of the domain owner registered in the WHOIS registry > service. > ~~ > > If everyone is OK with this, then I will proceed with recommending > approval of this request to enable EV treatment for the "Security > Communication RootCA2" root certificate. > > I will also track an action item to ensure that SECOM adds the updates > in the translated version of their CP back to the original CP. > > Kathleen > Thanks again to everyone who reviewed and commented on this request from SECOM to enable EV treatment for the "Security Communication RootCA2" root certificate. I am now re-closing this discussion and will recommend approval in the bug. In parallel, I will also track the action item for SECOM to update their original CP according to the changes they drafted in the English version. https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 Any further follow-up on this request should be added directly to the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECOM Request for EV Treatment
On 11/24/15 4:24 PM, Kathleen Wilson wrote: On 11/19/15 11:00 PM, h-k...@secom.co.jp wrote: Dear Kathleen-san, The updated CP for detailed descrition(the certificate subscriber owns/controls) about domain verification for the section 3.2.7 is attached on bugzilla. https://bugzilla.mozilla.org/attachment.cgi?id=8689921 Email address verification does not apply to this EV SSL CP/CPS. The corresponding section were made comprehensible by blue characters. Thank you for your consideration. Thank you, Kamo-san. All, As requested, the CP has been updated to reflect what SECOM does in regards to domain name validation. Note that this information was already available on the SECOM website, but we asked that it also be added to their CP. Here is the text that was added to the CP: ~~ The authentication method is as follows: 1. Using the WHOIS registry service, SECOM Trust System verifies that the relevant subscriber owns the domain to which the Certificate pertains. 2. Should the owner of the domain be different from the subscriber, SECOM Trust Systems authenticates the domain by having the domain owner submit to SECOM Trust Systems a document granting subscriber the permission to use the domain or by sending a verification e-mail to the e-mail address of the domain owner registered in the WHOIS registry service. ~~ If everyone is OK with this, then I will proceed with recommending approval of this request to enable EV treatment for the "Security Communication RootCA2" root certificate. I will also track an action item to ensure that SECOM adds the updates in the translated version of their CP back to the original CP. Kathleen Thanks again to everyone who reviewed and commented on this request from SECOM to enable EV treatment for the "Security Communication RootCA2" root certificate. I am now re-closing this discussion and will recommend approval in the bug. In parallel, I will also track the action item for SECOM to update their original CP according to the changes they drafted in the English version. https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 Any further follow-up on this request should be added directly to the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECOM Request for EV Treatment
On 11/19/15 11:00 PM, h-k...@secom.co.jp wrote: Dear Kathleen-san, The updated CP for detailed descrition(the certificate subscriber owns/controls) about domain verification for the section 3.2.7 is attached on bugzilla. https://bugzilla.mozilla.org/attachment.cgi?id=8689921 Email address verification does not apply to this EV SSL CP/CPS. The corresponding section were made comprehensible by blue characters. Thank you for your consideration. Thank you, Kamo-san. All, As requested, the CP has been updated to reflect what SECOM does in regards to domain name validation. Note that this information was already available on the SECOM website, but we asked that it also be added to their CP. Here is the text that was added to the CP: ~~ The authentication method is as follows: 1. Using the WHOIS registry service, SECOM Trust System verifies that the relevant subscriber owns the domain to which the Certificate pertains. 2. Should the owner of the domain be different from the subscriber, SECOM Trust Systems authenticates the domain by having the domain owner submit to SECOM Trust Systems a document granting subscriber the permission to use the domain or by sending a verification e-mail to the e-mail address of the domain owner registered in the WHOIS registry service. ~~ If everyone is OK with this, then I will proceed with recommending approval of this request to enable EV treatment for the "Security Communication RootCA2" root certificate. I will also track an action item to ensure that SECOM adds the updates in the translated version of their CP back to the original CP. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECOM Request for EV Treatment
2015年11月13日金曜日 23時27分46秒 UTC+9 Kathleen Wilson: > On 11/13/15 5:43 AM, Peter Kurrasch wrote: > > Kathleen, is SECOM getting special treatment? I was wondering if there was > > some reason to move forward before a CA has everything in order? Will we be > > seeing more of this going forward? > > > > I thought everything was in order, except perhaps there might be a few > more suggestions to updating their CPS that could be tracked in parallel > (i.e. not show stoppers). We have done that in the past, and Ryan had > sent me email saying that he might not be able to participate in the > inclusion review discussions for a while, so to go forward without him. > > But as you can see in the bug I realized that was not quite the case > when I went to write the summary to recommend approval. So, in the bug I > clarified that SECOM needs to make further updates to their CP/CPS > before we can move forward. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1096205#c28 > > So, it was not intentional. > > However, I would like to get the root inclusion/update discussions > moving forward again -- those discussions have stalled out. > > Kathleen Dear Kathleen-san, The updated CP for detailed descrition(the certificate subscriber owns/controls) about domain verification for the section 3.2.7 is attached on bugzilla. https://bugzilla.mozilla.org/attachment.cgi?id=8689921 Email address verification does not apply to this EV SSL CP/CPS. The corresponding section were made comprehensible by blue characters. Thank you for your consideration. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECOM Request for EV Treatment
On 11/13/15 5:43 AM, Peter Kurrasch wrote: Kathleen, is SECOM getting special treatment? I was wondering if there was some reason to move forward before a CA has everything in order? Will we be seeing more of this going forward? I thought everything was in order, except perhaps there might be a few more suggestions to updating their CPS that could be tracked in parallel (i.e. not show stoppers). We have done that in the past, and Ryan had sent me email saying that he might not be able to participate in the inclusion review discussions for a while, so to go forward without him. But as you can see in the bug I realized that was not quite the case when I went to write the summary to recommend approval. So, in the bug I clarified that SECOM needs to make further updates to their CP/CPS before we can move forward. https://bugzilla.mozilla.org/show_bug.cgi?id=1096205#c28 So, it was not intentional. However, I would like to get the root inclusion/update discussions moving forward again -- those discussions have stalled out. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECOM Request for EV Treatment
On 11/9/15 3:54 PM, Kathleen Wilson wrote: SECOM has applied to enable EV treatment for the "Security Communication RootCA2" root certificate that was included in NSS via Bugzilla Bug #527419. SECOM is a Japanese commercial CA that provides SSL and client certificates for e-Government and participates in several projects for financial institutions to ensure the secured on-line transactions. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 And in the pending certificates list: https://wiki.mozilla.org/CA:PendingCAs Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8641274 Noteworthy points: * Documents are in Japanese. Translations of some sections are attached to the bug. Document Repository: https://repository.secomtrust.net/SC-Root2/index.html CP: https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf CPS: https://repository.secomtrust.net/SC-Root/SCRootCPS.pdf SubCA CP: https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf non-EV SSL CP: https://repo1.secomtrust.net/spcpp/pfw/pfwsr2ca/PfWSR2CA-CP.pdf SSL Verification Procedures: https://www.secomtrust.net/service/pfw/apply/ev/1_3.html English Translations: https://bug1096205.bugzilla.mozilla.org/attachment.cgi?id=8573613 * CA Hierarchy This root certificate has subordinate CAs which sign end-entity certificates for SSL, EV SSL, email (S/MIME), and code signing. Intermediate CAs are available here: https://www.secomtrust.net/service/pfw/apply/sr/3_2.html https://www.secomtrust.net/service/pfw/apply/ev/3_2.html There is only one (internally-operated) subordinate CA that can issue EV certs, namely "SECOM Passport for Web EV 2.0 CA". Externally-operated subCAs are not allowed to issue EV certs. There is currently one externally-operated subCA, Fuji Xerox. SECOM is migrating this subCA to be internally-operated by SECOM and be included in SECOM's policy documentation and audit. * All three trust bits are already enabled for this root certificate. The request is to enable EV treatment. most recent the WebTrust audit report is posted at the URL below. https://cert.webtrust.org/ViewSeal?id=1907 The updated SECOM CP for Ryan-san's comment is attached to https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8679302 The addition for the section 2.2, 3.2.7 and 4.9.9 addressed with proposed update to the English version of CP. The corresponding section were made comprehensible by red characters. I propose that we move forward with approving and implementing SECOM's request to enable EV treatment for the the "Security Communication RootCA2" root certificate that was included in NSS via Bugzilla Bug #527419. In parallel, I plan to continue to track the action item for SECOM to update their CP/CPS documentation to address the concerns that have been raised. I believe that Ryan Sleevi is also planning to review the full translated CP, but I am confident that SECOM will be prompt to address any further concerns that are raised. I plan to track SECOM's status on updating their CP in the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 Does anyone have objections or concerns about this? Thanks, Kathleen Thanks again to everyone who reviewed and commented on this request from SECOM to enable EV treatment for the "Security Communication RootCA2" root certificate. I am now closing this discussion and will recommend approval in the bug. In parallel, I will also track the action item to finish the review of SECOM's translated CP/CPS and for SECOM to finish updating their CP/CPS (based on that review). https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 Any further follow-up on this request should be added directly to the bug. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECOM Request for EV Treatment
SECOM has applied to enable EV treatment for the "Security Communication RootCA2" root certificate that was included in NSS via Bugzilla Bug #527419. SECOM is a Japanese commercial CA that provides SSL and client certificates for e-Government and participates in several projects for financial institutions to ensure the secured on-line transactions. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 And in the pending certificates list: https://wiki.mozilla.org/CA:PendingCAs Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8641274 Noteworthy points: * Documents are in Japanese. Translations of some sections are attached to the bug. Document Repository: https://repository.secomtrust.net/SC-Root2/index.html CP: https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf CPS: https://repository.secomtrust.net/SC-Root/SCRootCPS.pdf SubCA CP: https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf non-EV SSL CP: https://repo1.secomtrust.net/spcpp/pfw/pfwsr2ca/PfWSR2CA-CP.pdf SSL Verification Procedures: https://www.secomtrust.net/service/pfw/apply/ev/1_3.html English Translations: https://bug1096205.bugzilla.mozilla.org/attachment.cgi?id=8573613 * CA Hierarchy This root certificate has subordinate CAs which sign end-entity certificates for SSL, EV SSL, email (S/MIME), and code signing. Intermediate CAs are available here: https://www.secomtrust.net/service/pfw/apply/sr/3_2.html https://www.secomtrust.net/service/pfw/apply/ev/3_2.html There is only one (internally-operated) subordinate CA that can issue EV certs, namely "SECOM Passport for Web EV 2.0 CA". Externally-operated subCAs are not allowed to issue EV certs. There is currently one externally-operated subCA, Fuji Xerox. SECOM is migrating this subCA to be internally-operated by SECOM and be included in SECOM's policy documentation and audit. * All three trust bits are already enabled for this root certificate. The request is to enable EV treatment. most recent the WebTrust audit report is posted at the URL below. https://cert.webtrust.org/ViewSeal?id=1907 The updated SECOM CP for Ryan-san's comment is attached to https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8679302 The addition for the section 2.2, 3.2.7 and 4.9.9 addressed with proposed update to the English version of CP. The corresponding section were made comprehensible by red characters. I propose that we move forward with approving and implementing SECOM's request to enable EV treatment for the the "Security Communication RootCA2" root certificate that was included in NSS via Bugzilla Bug #527419. In parallel, I plan to continue to track the action item for SECOM to update their CP/CPS documentation to address the concerns that have been raised. I believe that Ryan Sleevi is also planning to review the full translated CP, but I am confident that SECOM will be prompt to address any further concerns that are raised. I plan to track SECOM's status on updating their CP in the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 Does anyone have objections or concerns about this? Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECOM Request for EV Treatment
Dear Ryan-san and public discussion members, The updated SECOM CP for Ryan-san's comment is attached to https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8679302 The addition for the section 2.2, 3.2.7 and 4.9.9 addressed with proposed update to the English version of CP. The corresponding section were made comprehensible by red characters. Thank you for your consideration. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECOM Request for EV Treatment
Dear Ryan-san and public discussion members, The updated SECOM CP for Ryan-san's comment is attached to https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8679302 The addition for the section 2.2, 3.2.7 and 4.9.9 addressed with proposed update to the English version of CP. The corresponding section were made comprehensible by red characters. Thank you for your consideration. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECOM Request for EV Treatment
2015年8月26日水曜日 4時29分37秒 UTC+9 Ryan Sleevi: > On Wed, August 5, 2015 2:51 pm, Kathleen Wilson wrote: > > SECOM has applied to enable EV treatment for the "Security Communication > > RootCA2" root certificate that was included in NSS via Bugzilla Bug > > #527419. > > > > SECOM is a Japanese commercial CA that provides SSL and client > > certificates for e-Government and participates in several projects for > > financial institutions to ensure the secured on-line transactions. > > This begins the discussion of the request from SECOM to enable EV > > treatment for the "Security Communication RootCA2" root certificate that > > is currently included in NSS. > > > > At the conclusion of this discussion I will provide a summary of issues > > noted and action items. If there are outstanding issues, then an > > additional discussion may be needed as follow-up. If there are no > > outstanding issues, then I will recommend approval of this request in > > the bug. > > Hi Kathleen, > > I've attempted to separately review this inclusion request and examine the > CP and CPS. > > Overall, this was the most difficult review, given the lack of > availability of the policy documentation in English. While I attempted to > use Google Translate for most of it, I think it may be noteworthy to > consider requiring CAs to provide translated versions of their documents > in a future update of the Mozilla inclusion policy. > > The most recent audit information for SECOM that I can find is not the > 1717 seal you indicated, but Seal #1907, > https://cert.webtrust.org/SealFile?seal=1907=pdf > > In examining that seal, we see that there are a variety of CP/CPSes > provided as part of in scope for the audit. Relevant to this discussion, > it appears, is the "Security Communications Root CA2 Certification > Practice Statement" [1], the "Security Communications Root CA2 CA > Certificate Policy" [2], and the "SECOM Passport for Web EV 2.0 CA" CP [3] > and [4]. > > Given that the SECOM Root CA2 is already included in Mozilla's Root > Program, I attempted to focus my efforts on reviewing documents [3] and > [4], as they were deemed most relevant for EV enablement. > > While there are a several positive things noted within the CP/CPS, > overall, I'm concerned about the lack of information provided that makes > it difficult to impossible for the community to reliably inspect SECOM's > conformance to the relative policies, and leaves ambiguity with respect to > Mozilla's own ability to ensure that SECOM is operating in the public > interest. > > Given that [3] largely defers to [4] for most sections, I will focus my > primary comments on [4], and then circle back. > > https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf > > Good things: > - Section 1.5.2 provides contact information for the public in the event > of the need to revoke a certificate immediately. This is quite useful for > relying parties and members of the public to raise concern, and many CAs > make this difficult to find. > - Section 7.1 provides an exhaustive list of the certificate profile, > fields, and values. This sort of documentation is what ideally all members > of the Mozilla Root Store would provide, and provides ways for the public > to detect non-conformance to the profile specified. > > Mixed things: > - While Section 4.1 indicates that SECOM will examine CAA records, as > required by version 1.2.0 of the Baseline Requirements (as adopted by > Ballot 125), SECOM does not list which CAA records it will process or what > it would do if they mismatch. This may be seen as an incomplete adherence > to the Baseline Requirements, but I would rather see it as a reasonable > confusion related to expectations. An ideal resolution for this would be > for SECOM to indicate what CAA records it will expect to find (if CAA is > present) in order to issue, and what SECOM's process and procedures will > be for CAA records that fail to meet that (e.g. to deny the request, to > treat it as a High-Value request, to require some form of extended > validation, to allow a notarized letter on company letterhead to override, > etc) > > Bad things: > - Section 2.2 of the CP fails to provide information in the repository for > testing certificates issued by these roots. While SECOM's audit was > conducted against the WebTrust SSL BRs 1.1 (themselves based on the CA/B > Forum's SSL BRs 1.1), this was required in Appendix C (normatively) of the > BRs, and has been incorporated in Section 2.2 of the BRs 1.3.0 (providing > a model policy for CAs to adopt). I consider this a major issue of > non-conformance, although it may be remediated relatively easily. > - Section 3.2.2 fails to comprehensively explain how domain name > validation works. This is unquestionably the most important part of a CAs > operation, and I had difficulty finding any such information provided in > any of the attested-to documents by the auditors. While Auditors are, > unfortunately, not
Re: SECOM Request for EV Treatment
2015年8月26日水曜日 4時29分37秒 UTC+9 Ryan Sleevi: > On Wed, August 5, 2015 2:51 pm, Kathleen Wilson wrote: > > SECOM has applied to enable EV treatment for the "Security Communication > > RootCA2" root certificate that was included in NSS via Bugzilla Bug > > #527419. > > > > SECOM is a Japanese commercial CA that provides SSL and client > > certificates for e-Government and participates in several projects for > > financial institutions to ensure the secured on-line transactions. > > This begins the discussion of the request from SECOM to enable EV > > treatment for the "Security Communication RootCA2" root certificate that > > is currently included in NSS. > > > > At the conclusion of this discussion I will provide a summary of issues > > noted and action items. If there are outstanding issues, then an > > additional discussion may be needed as follow-up. If there are no > > outstanding issues, then I will recommend approval of this request in > > the bug. > > Hi Kathleen, > > I've attempted to separately review this inclusion request and examine the > CP and CPS. > > Overall, this was the most difficult review, given the lack of > availability of the policy documentation in English. While I attempted to > use Google Translate for most of it, I think it may be noteworthy to > consider requiring CAs to provide translated versions of their documents > in a future update of the Mozilla inclusion policy. > > The most recent audit information for SECOM that I can find is not the > 1717 seal you indicated, but Seal #1907, > https://cert.webtrust.org/SealFile?seal=1907=pdf > > In examining that seal, we see that there are a variety of CP/CPSes > provided as part of in scope for the audit. Relevant to this discussion, > it appears, is the "Security Communications Root CA2 Certification > Practice Statement" [1], the "Security Communications Root CA2 CA > Certificate Policy" [2], and the "SECOM Passport for Web EV 2.0 CA" CP [3] > and [4]. > > Given that the SECOM Root CA2 is already included in Mozilla's Root > Program, I attempted to focus my efforts on reviewing documents [3] and > [4], as they were deemed most relevant for EV enablement. > > While there are a several positive things noted within the CP/CPS, > overall, I'm concerned about the lack of information provided that makes > it difficult to impossible for the community to reliably inspect SECOM's > conformance to the relative policies, and leaves ambiguity with respect to > Mozilla's own ability to ensure that SECOM is operating in the public > interest. > > Given that [3] largely defers to [4] for most sections, I will focus my > primary comments on [4], and then circle back. > > https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf > > Good things: > - Section 1.5.2 provides contact information for the public in the event > of the need to revoke a certificate immediately. This is quite useful for > relying parties and members of the public to raise concern, and many CAs > make this difficult to find. > - Section 7.1 provides an exhaustive list of the certificate profile, > fields, and values. This sort of documentation is what ideally all members > of the Mozilla Root Store would provide, and provides ways for the public > to detect non-conformance to the profile specified. > > Mixed things: > - While Section 4.1 indicates that SECOM will examine CAA records, as > required by version 1.2.0 of the Baseline Requirements (as adopted by > Ballot 125), SECOM does not list which CAA records it will process or what > it would do if they mismatch. This may be seen as an incomplete adherence > to the Baseline Requirements, but I would rather see it as a reasonable > confusion related to expectations. An ideal resolution for this would be > for SECOM to indicate what CAA records it will expect to find (if CAA is > present) in order to issue, and what SECOM's process and procedures will > be for CAA records that fail to meet that (e.g. to deny the request, to > treat it as a High-Value request, to require some form of extended > validation, to allow a notarized letter on company letterhead to override, > etc) > > Bad things: > - Section 2.2 of the CP fails to provide information in the repository for > testing certificates issued by these roots. While SECOM's audit was > conducted against the WebTrust SSL BRs 1.1 (themselves based on the CA/B > Forum's SSL BRs 1.1), this was required in Appendix C (normatively) of the > BRs, and has been incorporated in Section 2.2 of the BRs 1.3.0 (providing > a model policy for CAs to adopt). I consider this a major issue of > non-conformance, although it may be remediated relatively easily. > - Section 3.2.2 fails to comprehensively explain how domain name > validation works. This is unquestionably the most important part of a CAs > operation, and I had difficulty finding any such information provided in > any of the attested-to documents by the auditors. While Auditors are, > unfortunately, not
SECOM Request for EV Treatment
SECOM has applied to enable EV treatment for the Security Communication RootCA2 root certificate that was included in NSS via Bugzilla Bug #527419. SECOM is a Japanese commercial CA that provides SSL and client certificates for e-Government and participates in several projects for financial institutions to ensure the secured on-line transactions. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 And in the pending certificates list: https://wiki.mozilla.org/CA:PendingCAs Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8641274 Noteworthy points: * Documents are in Japanese. Translations of some sections are attached to the bug. Document Repository: https://repository.secomtrust.net/SC-Root2/index.html CP: https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf CPS: https://repository.secomtrust.net/SC-Root/SCRootCPS.pdf SubCA CP: https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf non-EV SSL CP: https://repo1.secomtrust.net/spcpp/pfw/pfwsr2ca/PfWSR2CA-CP.pdf SSL Verification Procedures: https://www.secomtrust.net/service/pfw/apply/ev/1_3.html English Translations: https://bug1096205.bugzilla.mozilla.org/attachment.cgi?id=8573613 * CA Hierarchy This root certificate has subordinate CAs which sign end-entity certificates for SSL, EV SSL, email (S/MIME), and code signing. Intermediate CAs are available here: https://www.secomtrust.net/service/pfw/apply/sr/3_2.html https://www.secomtrust.net/service/pfw/apply/ev/3_2.html There is only one (internally-operated) subordinate CA that can issue EV certs, namely SECOM Passport for Web EV 2.0 CA. Externally-operated subCAs are not allowed to issue EV certs. There is currently one externally-operated subCA, Fuji Xerox. SECOM is migrating this subCA to be internally-operated by SECOM and be included in SECOM's policy documentation and audit. * All three trust bits are already enabled for this root certificate. The request is to enable EV treatment. ** The procedure that SECOM follows to verify the domain owner is the same for EV and non-EV SSL certificates. The only difference is that no lawyer opinion letter is used for Non-EV SSL. Translations from section 4-2 of SECOM’s Verification Document describe the process by which Whois is used to verify that the domain owner is the same as the certificate subscriber company name. ** Translations from Security Communication RootCA Subordinate CA Certificate Policy (SCRootCP1) and PfWEVCA‐CP 3.2 Initial identification and authentication 3.2.1 Method to prove possession of private key It is proved that the applicant has the private key as follows. Certificate Signing Request, CSR submitted by the applicant and verify that the corresponding public key contained in it is signed with private key. In addition, check the fingerprint of the CSR to identify the owner of the public key. 3.2.2 Authentication of company Secom authorize the authentication of the applicant company as follows. By using the official documents from central or local government, database provided by QIIS or QGIS, and another ways that the equal level of authorization possible. 3.2.3 Authentication of individual Secom authorize the authentication of the applicant individual as follows. By using the official documents from central or local government, database provided by QIIS or QGIS, and another ways that the equal level of authorization possible. 3.2.4 Information of non verified certificate user Not described. 3.2.5 Confirmation of the authority to apply Secom confirm that the applicant has proper right to apply the certificate by the section 3.2 or 3.3 on this CP. In the case if the application is made by third party, we request to give us the letter of attorney. * The third party application means that other than the company using the host name described on common name of the certificate that is described on the section 3.1.1. 4.3.1 Procedures to issue certificate by CA Secom issues the certificate and prepares the certificate download site only available for the applicant. The applicant uses a client certificate or one time password along with access key to reach the download site. ** Notes from the discussion of the inclusion request *** There are 2 types of organizations. One is the organization registered in the QIIS, Tokyo Shoko Research. The applicant information is obtained from the reliable independent source. This is much like an organizational credit reporting agency. Tokyo Shoko Research (TSR) is a member of the DB Worldwide Network since 2005. http://www.tsr-net.co.jp/en/outline.html *** Another type is the organization not registered in the QIIS, Tokyo Shoko Rearch. This time, Secom require the organization to submit Certificate of seal impression. Certificate of seal impression is the official document issued by the local government and only available for the
