Closed Bug 1096205 Opened 5 years ago Closed 4 years ago

Enable EV for Security Communication RootCA2

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: h-kamo, Assigned: kwilson)

References

Details

(Whiteboard: EV enabled in Firefox 44)

Attachments

(13 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 5.2; rv:29.0) Gecko/20100101 Firefox/29.0
Build ID: 20140506152807




Expected results:

We would like you to make an EV arrangement for our "Security Communication RootCA2" which is already embedded.
https://bugzilla.mozilla.org/show_bug.cgi?id=527419

The most recent WebTrust report is available at the URL below.
https://cert.webtrust.org/SealFile?seal=1717&file=pdf
Assignee: nobody → kwilson
Component: General → CA Certificates
Product: Core → mozilla.org
Summary: "Enable EV for <Security Communication RootCA2>" → Enable EV for Security Communication RootCA2
Version: unspecified → other
I will update this bug when I begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Windows Server 2003 → All
Hardware: x86 → All
The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness, and provide the necessary information in this bug.
Whiteboard: EV - Information incomplete
Kathleen-san,

The document information added is attached.
Please review our answers.

As soon as the URL of our test website and the EV testing result are ready, we will let you know.

Thank you for your consideration.
I am in the process of transitioning the CA Program management into SalesForce. So you will notice a different format for the Updated CA Information document.

Please search the document for "Need Response" and "Need Clarification" to find the parts where information and clarification is still needed.

Please review the full document for accuracy and completeness, and provide the necessary information in this bug.
Comment on attachment 8535156 [details]
Updated CA Information Document

Q
CA's Response to Recommended Practices (IDNs in certificates)

A
Verify the registered hold of the domain or exclusive control of the domain name by using InterNIC and JPRS Whois database. Verify the applicant organization’s existence and identity by Qualified Independent Information Source (QIIS) or Certificate of the seal impression based on Japanese customs and practices.
It is described at the URL below.
https://www.secomtrust.net/service/pfw/apply/ev/1_3.html

If the domain owner is different organization, the applicant organization must provide a domain use permission proof document sealed by the domain own organization.
The document is available at the URL below.
https://www.secomtrust.net/service/pfw/apply/ev/2_2.html


Q
CA's Response to Problematic Practices (delegate validation)

A
We do not delegate to allow for externally-operated subordinate CAs either.


Q  (TA and TSA EE certificates)

A
They mean Time Authority and Timestamp Authority respectively.


Q  (externally-operated subCAs cannot issue EV)

A
We never provide signing for externally-operated subCAs issuing EV certificates.
Regarding EV enablement, browser venders require WebTrust EV audit and without to get authorized, it is no way to issue EV certificates.


Q
Test Website URL (SSL) or Example Cert

A 
https://pfwtest.secomtrust.net/


Q
EV Tested
Need successful output of EV Test: https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

A
We successfully got the test result.
Please take a look at the attached file.


Q
Externally Operated SubCAs

A
The externally-operated subCAs issue SSL certs, not EV certs.


Q
Technical Constraint on 3rd party Issuer

A 
In terms of technical constraints, to provide signing for externally-operated subCAs from our root CA, we check profile for subCA certificates using our profile check sheet.


Q
BR Commitment to Comply

A
The commitment to comply is described at the end of the first clause of section 1.1 in non-EV SSL CP.
https://repo1.secomtrust.net/spcpp/pfw/pfwsr2ca/PfWSR2CA-CP.pdf


Q
SSL Verification Procedures

A
Verify the organization by QIIS or Certificate of the seal impression, and confirm the request of the certificate by making phone call to HRM of the organization.


Q
EV SSL Verification Procedures 

A
Verify the organization by QIIS or Certificate of the seal impression, and confirm the request of the certificate by making phone call to HRM of the organization.


Q
Email Address Verification Procedures

A
Verify the organization by QIIS or Certificate of the seal impression, and subscriber’s email account by making phone call to HRM of the organization.
Possession of private key is confirmed as signing  public key included in CSR by private key.
It is described at section 3 in CP.
https://repo1.secomtrust.net/spcpp/pfw/pfwsr2ca/PfWSR2CA-CP.pdf


Q
Code Signing Subscriber Verification Procedures

A
Verify the organization by QIIS or Certificate of the seal impression, and confirm the request of the certificate by making phone call to HRM of the organization.
Possession of private key is confirmed as signing  public key included in CSR by private key.
It is described at section 3 in CP.
https://repo1.secomtrust.net/spcpp/pfw/pfwsr2ca/PfWSR2CA-CP.pdf


Q
Multi-Factor Authentication

A
We use client certificates and one-time-passwords.
Kathleen-san,

We apologize for late response.
Our response to the CA Information Attachment was provided at comment#9 yesterday.

The successful output of EV Test: https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
is attached now.

Thank you for your consideration.
I'm a bit confused...

(In reply to Hisashi Kamo from comment #9)

> A
> We do not delegate to allow for externally-operated subordinate CAs either.

> A
> We never provide signing for externally-operated subCAs issuing EV
> certificates.
 
> A
> The externally-operated subCAs issue SSL certs, not EV certs.
> 


Please clarify what types of certificates externally operated subordinate CAs are allowed to issue, and how that is controlled.
Please confirm if my understanding is correct: 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.

Are there any externally-operated subCAs chaining up to this root that can issue (non-EV) SSL, email, or code signing certificates?
Kathleen-san,

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.
 => This is correct.

Are there any externally-operated subCAs chaining up to this root that can issue (non-EV) SSL, email, or code signing certificates?
 => Only a few subCAs started issuing non-EV SSL and email certificates.
Kamo-san,

Thank you for your prompt response and clarification.

When a change to an included root is requested we take that opportunity to re-evaluate the CA's policies, CA Hierarchy, and trust bit settings for the root. Therefore, even though your request is only to enable EV treatment, I must still ask about the non-EV SSL, email, and code signing certificates.

In regards to the externally-operated subCAs chaining to this root that can issue non-EV SSL, email, and code-signing certificates, please provide the information listed here:
https://wiki.mozilla.org/CA:SubordinateCA_checklist
and/or 
explain how those subCAs comply with sections 8 through 10 of
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Frequently_Asked_Questions
(In reply to Kathleen Wilson from comment #15)
> In regards to the externally-operated subCAs chaining to this root that can
> issue non-EV SSL, email, and code-signing certificates, please provide the
> information listed here


I have exchanged email with the CA, and my understanding is that there is currently one externally-operated subordinate CA that will be migrated to be internally-operated by SECOM (and thus included in SECOM's policy documentation and audit).
Attached file 1096205-CAInformation.pdf (obsolete) —
Kamo-san, Please confirm (by commenting in this bug) if all of the information in the attached document is correct.
Kathleen-san,

Thank you for the attachment. We confirm the CA information.
Please correct URSs below.
(1)
https://bugzilla.mozilla.org/attachment.cgi?id=8519807
is not the most recent CP.
The most recent CP is available at the URL below.
https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf

(2)
CRL Distribution Point in cert of test website: 
http://testrepository.secomtrust.net/subca6/fullcrl.crl 
is not correct.
The correct one is 
http://repo1.secomtrust.net/spcpp/pfw/pfwev2ca/fullcrl.crl

Thank you for your consideration.
Attachment #8615407 - Attachment is obsolete: true
I will try to start the discussion soon.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

In the meantime, please update this bug with the 2015 audit statements when they are ready.
Whiteboard: EV - Information incomplete → EV - Ready for Public Discussion
Thank you, Kathleen-san,

As soon as the 2015 Webtrust audit is available, I will let you know.
I am now opening the first public discussion period for this request from SECOM to enable EV treatment for the "Security Communication RootCA2" root certificate that is currently included in NSS. 

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called “SECOM Request for EV Treatment”.

Please actively review, respond, and contribute to the discussion.

A representative of SECOM must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: EV - Ready for Public Discussion → EV - In public discussion
Kathleen-san,

Out most recent the WebTrust audit report is posted at the URL below.
https://cert.webtrust.org/ViewSeal?id=1907 

Thank you.
Attached file Secom CP.doc
Attached file Secom CPS.doc
Dear Kathleen-san,

Secom CP and CPS English version are attached.

Thank you.
Attached file Secom CP151027.doc
Dear Kathleen-san,

The updated CP for Ryan-san's comment is attached.
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.
After reviewing the recently attached documents, I have concluded that there is still insufficient information in these documents about which approaches SECOM may take to confirm that the certificate subscriber owns/controls the domain(s) to be included in the certificate, as well as the email address(es) to be included in the certificate. Therefore, I will wait for more complete CP/CPS documentation before recommending approval of this request.

References:
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control
Whiteboard: EV - In public discussion → EV - Post public discussion, need updated CP/CPS
Attached file Secom CP151120.doc
 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.
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.
The public comment period for this request is now over.

This request has been evaluated as per Mozilla’s CA Certificate Inclusion Policy at

https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

Inclusion Policy Section 4 [Technical]. 
I am not aware of instances where SECOM has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Inclusion Policy Section 6 [Relevance and Policy].
SECOM appears to provide a service relevant to Mozilla users. It 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 request is to enable EV-Treatment for Security Communication RootCA2 root certificate that was included via Bugzilla Bug #527419.

Root Certificate Name: Security Communication RootCA2
O From Issuer Field: SECOM Trust Systems CO.,LTD.
Trust Bits already enabled: Code; Email; Websites
EV Policy OID: 1.2.392.200091.100.721.1
Root Certificate Download URL: 	https://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer

Document Repository: https://repository.secomtrust.net/SC-Root2/index.html
CP: https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf
CP (English, updated): https://bugzilla.mozilla.org/attachment.cgi?id=8689921
CPS: https://repository.secomtrust.net/SC-Root/SCRootCPS.pdf
CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=8674035
SubCA CP: https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf

non-EV SSL CP: https://repo1.secomtrust.net/spcpp/pfw/pfwsr2ca/PfWSR2CA-CP.pdf

CRL URL(s):
https://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl
http://repo1.secomtrust.net/spcpp/pfw/pfwev2ca/fullcrl.crl
CRL issuing frequency for subordinate end-entity certificates: 24 hours
From SECOM CA Service Passport for Web SR 2.0 Certificate Policy (PfWSR2CA-CP.pdf), Section4.9.7: CRL is expired regardless of treatment, every 24 hours

OCSP URL: http://ev2.ocsp.secomtrust.net/

Inclusion Policy Section 7 [Validation]. 
SECOM appears to meet the minimum requirements for subscriber verification, as follows.

SSL Verification Procedures: 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.  SECOM’s website describes the process, and SECOM added the following description to the English version of their CP.
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.

Email Verification Procedures: According to translations of SECOM’s mail authentication procedure, the email address to be included in the certificate is verified via an email exchange. Additionally, the domain is verified using Whois gateway. If needed, a phone call is made to the applicant company to verify that the applicant has the authority to request the certificate.

Inclusion Policy Section 18 [Certificate 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.

Externally Operated SubCAs: There is currently one externally-operated subCA, Fuji Xerox (https://bugzilla.mozilla.org/show_bug.cgi?id=1015772). SECOM plans to migrate this subCA to be internally-operated by SECOM and be included in SECOM's policy documentation and audit.
Cross Signing: 	None

Inclusion Policy Sections 11-14 [Audit]. 
Annual audits are performed by PricewaterhouseCoopers Aarata, according to the WebTrust criteria.
Standard Audit: https://cert.webtrust.org/SealFile?seal=1907&file=pdf
BR Audit: https://cert.webtrust.org/SealFile?seal=1907&file=pdf
EV Audit: https://cert.webtrust.org/SealFile?seal=1907&file=pdf

Based on this assessment I intend to approve this request from SECOM to enable EV-Treatment for Security Communication RootCA2 root certificate.

ACTION ITEM (to be done in parallel of EV-enablement)
SECOM: Finish updating the original CP according to the changes that were made to the English version of the CP to address concerns raised in the discussion. Please update this bug when this action item has been completed.
Whiteboard: EV - Post public discussion, need updated CP/CPS → EV - Pending Approval
As per the summary in Comment #31, and on behalf of Mozilla I approve this request from SECOM to enable EV treatment the following root certificate:

** "Security Communication RootCA2" (all three trust bits already enabled), enable EV

I will file the PSM bug for the approved change.
Whiteboard: EV - Pending Approval → EV - Approved - awaiting PSM changes
Depends on: 1230985
I have filed bug #1230985 against PSM for the actual change.

In the meantime...
ACTION ITEM (to be done in parallel of EV-enablement)
SECOM: Finish updating the original CP according to the changes that were made to the English version of the CP to address concerns raised in the discussion. Please update this bug when this action item has been completed.
What action would be taken by Mozilla if the Action Item cited in comment #33 is not completed?
Ideally, the action will be completed before EV treatment is provided. Otherwise, EV treatment may be removed if the CA does not complete the action item.
Dear Kathleen-san,

We finished updating the original CP at the URL below.
(the section 2.2, 3.2.7 and 4.9.9)
https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf

We changed the EV test website as below.
https://ev2v.secomtrust.net/
This is the CA hierarchy for the EV test website.
https://bugzilla.mozilla.org/attachment.cgi?id=8519800

Thank you for your consideration.
(In reply to Hisashi Kamo from comment #36)
> We finished updating the original CP at the URL below.
> (the section 2.2, 3.2.7 and 4.9.9)
> https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf

Confirmed changes via Google Translate. 


> We changed the EV test website as below.
> https://ev2v.secomtrust.net/
> This is the CA hierarchy for the EV test website.
> https://bugzilla.mozilla.org/attachment.cgi?id=8519800

OK
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Whiteboard: EV - Approved - awaiting PSM changes → EV enabled in Firefox 44
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.