636557 - Add Visa Information Delivery Root CA certificate

Status: RESOLVED WONTFIX

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

Description

[Kim Wagner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13
Build Identifier: 

General information about the VISA InfoDelivery Root CA

1. Name:
Visa Information Delivery Root CA
2. Website URL:
	http://www.visa.com
3. Organizational type:
	The CA is operated by a private corporation (Visa Inc.)
4. Primary market / customer base:
	Which types of customers does the CA serve:
The inclusion of these certificate authorities will enable Mozilla’s consumers to authenticate to Visa products and services.  
	Are there particular vertical market segments in which it operates:
		Financial services
	Does it focus its activities on a particular country or other geographical region:
		No, the CA is global.
5. Impact to Mozilla users:
	Describe the types of Mozilla users who are likely to encounter your root certificate as relying parties while web browsing (HTTPS servers doing SSL), sending/receiving email to their own MTA (SMTPS, IMAPS servers doing SSL), sending/receiving S/MIME email (S/MIME email certs), etc.:
		Any Visa issuing bank using any of Visa's secured web based services. CA Contact Information:
	
Visa Inc.
P.O. Box 8999
San Francisco, CA 94128-8999	Michael Stefanich
[e-mail]
[phone]	Richard Burgos
[e-mail]
[phone]

Technical information about the Visa InfoDelivery Root CA certificate

1.	Certificate Name:
Visa Information Delivery Root CA
2.	Certificate Issuer Field
CN = Visa Information Delivery Root CA
OU = Visa International Service Association
O = VISA
C = US
3.	Certificate Summary

Certificates used by this CA will be used to support payment and information delivery applications (business to business payments, business to consumer payments, non-payment applications) as well as some Visa internal applications.  All of these applications are tied to Visa products, services or platforms that are governed by Visa's global operating regulations that bind all of the parties to specified terms, conditions, responsibilities, recourse, etc.  Given our large international participation base -- 21,000+ banks, billions of customers, millions of acceptors and our global nature -- warrants the use of the Root CA infrastructure that is owned and managed by Visa.  

The Visa Information Delivery Root CA which provides Certificate Signing, Off-line CRL Signing, CRL Signing (06) has several subordinate online CAs that issue end entity certificates (SSL client, SSL server, digital signature, VPN/IP Sec, SSL Server & Client).

The Visa Information Delivery Root was created in 2005 and has passed WebTrust Audits conducted by KPMG from 2005 through 2010.  The WebTrust report is not publicly accessible but can be provided upon request.  Visa’s Certificate Policy is publicly accessible from http://www.visa.com/pki. The Visa Certification Practice Statement is not publicly accessible but can be provided if required.

4.	Root Certificate URL
o	http://enroll.visaca.com 

5.	SHA1 fingerprint
5a 4d 0e 8b 5f dc fd f6 4e 72 99 a3 6c 06 0d b2 22 ca 78 e4
6.	Valid from (YYYY-MM-DD)
Monday, June 27, 2005 17:42:42 GMT
7.	Valid to (YYYY-MM-DD)
Sunday, June 29, 2025 17:42:42 GMT
8.	Certificate Version (should be 3)
V3
9.	Certificate Signature Algorithm
sha1RSA
10.	Signing key parameters
2048 bits
11.	Test website URL -- if you are requesting to enable the Websites (SSL/TLS) trust bit
	http://enroll.visaca.com 

12.	Example certificates
o	If this root does not issue certificates for SSL, then provide example certificate(s) issued within the hierarchy rooted at this root, including the full certificate chain(s).
Visa will provide end-entity certificates from our issuing Certificate Authorities for the chain validation testing requirement by a separate e-mail.  
13.	Certificate Revocation Lists (CRLs)
o	URL(s) at which the CRL(s) may be obtained -- for end-entity certs and for intermediate CAs.
http://enroll.visaca.com/ , and
http://crl.inov.visa.net/ , as well as
ldap://enroll.visaca.com/ , and
ldap://crl.inov.visa.net/
o	The value that nextUpdate is set to in the CRLs for end-entity certificates.
For end-entity certificates under the issuing sub CA, VI CA1, nextUpdate is 5 days.  For end-entity certificates under the issuing sub CA, VI CA2, nextUpdate is 2 days.
o	The sections of your CP/CPS documentation that state the requirements about frequency of updating CRL.
Certification Practice Statement, Chapter 4, Certificate Revocation List (CRL) Issuance Frequency.
o	Note the CA/Browser Forum's EV guidelines: CRLs MUST be updated and reissued at least every seven days, and the nextUpdate field value SHALL NOT be more ten days
o	You must test your CRLs by importing them into the Firefox browser.
	Error Codes:
	ffffe095, is equivalent to -8043, SEC_ERROR_CRL_UNKNOWN_CRITICAL_EXTENSION Resolution: See Potentially Problematic Practice CRL with Critical CIDP Extension
	ffffe009 is equivalent to -8183, “Security library: improperly formatted DER-encoded message.” It means that the reply contained anything other than a valid DER-encoded CRL. Typical Resolution: Change encoding from PEM to DER.
14.	OCSP (OCSP is required for EV enablement)
Not applicable.  Visa is currently not planning to issue EV certificates from the Visa InfoDelivery Root CA.

15.	Requested Trust Bits
o	State which of the three trust bits you are requesting to be enabled for this root. One or more of:
	Websites (SSL/TLS)
	Email (S/MIME)
	Code Signing

The Visa Information Delivery Root CA which provides Certificate Signing, Off-line CRL Signing, CRL Signing (06) has several subordinate online CAs that issue end entity certificates (SSL client, SSL server, digital signature, VPN/IP Sec, SSL Server & Client).

o	Mozilla’s standpoint is that we should operate the root program in terms of minimizing risk. One way that we can minimize risk is by not enabling more trust bits than CAs absolutely require.

16.	SSL Validation Type
o	Indicate the levels of SSL validation that are used for certificates within this root's hierarchy. One or more of:
	OV -- In addition to verifying the domain ownership, you also validate the organization to be listed in the O field - making sure public record and government resources can verify the address, existence, and good legal standing of the organization itself. Verifying that the whois listed address matches the verified address, and any other additional checks that a given CA lists in its CPS.
 
17.	If EV certificates are issued within the hierarchy rooted at this root, the EV policy OID(s) associated with those EV certificates.
N/A.

CA hierarchy information for the Visa InfoDelivery Root CA certificate

1.	CA Hierarchy
o	A description of the PKI hierarchy rooted at or otherwise associated with this root CA certificate.
	List and/or describe all of the subordinate CAs that are signed by this root.
	Identify which of the subordinate CAs are internally-operated; e.g. list the subordinate CAs that operated by the CA organization associated with the root CA. For example, this might include subordinate CAs created to issue different classes or types of end entity certificates to the general public: Class 1 vs. class 2 certificates, qualified vs. non-qualified certificates, EV certificates vs. non-EV certificates, SSL certificates vs. email certificates, and so on.
It might also include subordinate CAs operated for the benefit of specific third parties. In this case note that we do not require that the CA submit a complete customer list; rather we are interested in the general type and nature of the third-party arrangements. 

The Visa Information Delivery Root CA has two subordinate Issuing CAs:

	(1) VICA1 – Visa Inc. Certificate Authority for Internet use – VI CA1 
	(2) VICA2 – Visa Inc. Certificate Authority for Intranet use – VI CA2

These two CA’s are internally operated Issuing CAs and issue only end-entity certificates.

2.	Sub CAs Operated by 3rd Parties
o	If this root has any subordinate CAs that are operated by external third parties, then provide the information listed in the Subordinate CA Checklist
o	If the CA functions as a super CA such their CA policies and auditing don't apply to the subordinate CAs, then those CAs must apply for inclusion themselves as separate trust anchors.

N/A.  Visa does not permit sub CAs operated by 3rd parties.

3.	Cross-Signing
o	List all other roots for which this root CA has issued cross-signing certificates.
o	List all other root CAs that have issued cross-signing certificates for this root CA.
o	If any such roots exist, it is important to note whether the roots in question are already included in the Mozilla root store or not.

N/A.  Visa does not permit cross signing Certificate Authorities.


Reproducible: Always

Comment 1

[Kim Wagner]

Attachment: Filled out questionnaire

Comment 2

[Kathleen Wilson]

Starting the information verification phase for this request, as per
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 3

[Kathleen Wilson]

I was not able to find the URL to download this certificate. The url that was provided above did not have the cert in it. e.g. Where are your customers downloading the root from?


I have reviewed the Visa PKI CP, and I have determined that the document does not provide sufficient information to determine if Visa's operations in regards to the Visa Information Delivery Root CA meet the requirements of sections 6, 7, and 8 of the Mozilla CA Certificate Policy.
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

Please refer to section 14 of the policy: "We rely on publicly disclosed documentation (e.g., in a Certificate Policy and Certification Practice Statement) and publicly disclosed audit statements to ascertain that the above requirements are met. Therefore, inclusion requests will only be considered if the following are true:
- the publicly disclosed documentation provides sufficient information for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate signing requests;
- the documentation is available from the CA's official website;"


Does the CPS contain more information about the steps that the CA or RA must take to verify the information that is provided by the certificate subscriber? Is the CPS confidential?  If not, is there a reason why it cannot be posted on the Visa website?

Comment 4

[Christopher L. Grassi]

Hi Kathleen,

My name is Chris Grassi and I am taking over for Kim Wagner regarding the request that is stipulated within *Bug 636557 - Add Visa Information Delivery Root CA certificate*.

Would it be possible for us to speak by telephone regarding the particulars of your concerns as outlined in the following feedback you had provided?:

*The Visa PKI CP does not provide sufficient information to determine if Visa's operations in regards to the Visa Information Delivery Root CA meet the requirements of sections 6, 7, and 8 of the Mozilla CA Certificate Policy*

I shall send an e-mail to you as well. If you would like to contact me, my e-mail address is *[e-mail]*.  We can exchange telephone numbers if that is amenable.

Thanks
And
Cheers

C.L. Grassi

Comment 5

[Kathleen Wilson]

Hi Chris,

Please see the following wiki pages regarding the information that needs to be in a publicly-available version of the CP or CPS.

If you are requesting that the websites (SSL/TLS) trust bit be enabled for this root, then see
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership


If you are requesting that the email (S/MIME) trust bit be enabled for this root, then see
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control


If you are requesting that the code signing trust bit be enabled for this root, then see
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Identity_of_Code_Signing_Certificate_Subscriber

Cheers,
Kathleen

Comment 6

[Kathleen Wilson]

Attachment: Audit Statement 2010

Comment 7

[Christopher L. Grassi]

Hi Kathleen, below is a resubmission of the *General information about the VISA InfoDelivery Root CA* with some minor additions and revisions.  

General information about the VISA InfoDelivery Root CA

1. Name:
Visa Information Delivery Root CA
2. Website URL:
	http://www.visa.com
3. Organizational type:
	The CA is operated by a private corporation (Visa Inc.)
4. Primary market / customer base:
	Which types of customers does the CA serve:
The inclusion of these certificate authorities will enable Mozilla’s consumers to authenticate to Visa products and services.  
	Are there particular vertical market segments in which it operates:
		Financial services
	Does it focus its activities on a particular country or other geographical region:
		No, the CA is global.
5. Impact to Mozilla users:
	Describe the types of Mozilla users who are likely to encounter your root certificate as relying parties while web browsing (HTTPS servers doing SSL), sending/receiving email to their own MTA (SMTPS, IMAPS servers doing SSL), sending/receiving S/MIME email (S/MIME email certs), etc.:
		Any Visa issuing bank using any of Visa's secured web based services. CA Contact Information:
	
Visa Inc.
P.O. Box 8999
San Francisco, CA 94128-8999	Michael Stefanich
[e-mail]
[phone]	Richard Burgos
[e-mail]
[phone]

Technical information about the Visa InfoDelivery Root CA certificate

1.	Certificate Name:
Visa Information Delivery Root CA
2.	Certificate Issuer Field
CN = Visa Information Delivery Root CA
OU = Visa International Service Association
O = VISA
C = US
3.	Certificate Summary

Certificates used by this CA will be used to support payment and information delivery applications (business to business payments, business to consumer payments, non-payment applications) as well as some Visa internal applications.  All of these applications are tied to Visa products, services or platforms that are governed by Visa's global operating regulations that bind all of the parties to specified terms, conditions, responsibilities, recourse, etc.  Given our large international participation base -- 21,000+ banks, billions of customers, millions of acceptors and our global nature -- warrants the use of the Root CA infrastructure that is owned and managed by Visa.  

The Visa Information Delivery Root CA which provides Certificate Signing, Off-line CRL Signing, CRL Signing (06) has several subordinate online CAs that issue end entity certificates (SSL client, SSL server, digital signature, VPN/IP Sec, SSL Server & Client).

The Visa Information Delivery Root was created in 2005 and has passed WebTrust Audits conducted by KPMG from 2005 through 2011.  The WebTrust report is not publicly accessible but can be provided upon request.  Visa’s Certificate Policy is publicly accessible from http://www.visa.com/pki. The Visa Certification Practice Statement is not publicly accessible but can be provided if required.

4.	Root Certificate URL
o	http://enroll.visaca.com 

5.	SHA1 fingerprint
5a 4d 0e 8b 5f dc fd f6 4e 72 99 a3 6c 06 0d b2 22 ca 78 e4
6.	Valid from (YYYY-MM-DD)
Monday, June 27, 2005 17:42:42 GMT
7.	Valid to (YYYY-MM-DD)
Sunday, June 29, 2025 17:42:42 GMT
8.	Certificate Version (should be 3)
V3
9.	Certificate Signature Algorithm
sha1RSA
10.	Signing key parameters
2048 bits
11.	Test website URL -- if you are requesting to enable the Websites (SSL/TLS) trust bit
	http://enroll.visaca.com 

12.	Example certificates
o	If this root does not issue certificates for SSL, then provide example certificate(s) issued within the hierarchy rooted at this root, including the full certificate chain(s).
Visa will provide end-entity certificates from our issuing Certificate Authorities for the chain validation testing requirement by a separate e-mail.  
13.	Certificate Revocation Lists (CRLs)
o	URL(s) at which the CRL(s) may be obtained -- for end-entity certs and for intermediate CAs.
http://enroll.visaca.com/ , and
http://crl.inov.visa.net/ , as well as
ldap://enroll.visaca.com/ , and
ldap://crl.inov.visa.net/
o	The value that nextUpdate is set to in the CRLs for end-entity certificates.
For end-entity certificates under the issuing sub CA, VI CA1, nextUpdate is 5 days.  For end-entity certificates under the issuing sub CA, VI CA2, nextUpdate is 2 days. For end-entity certificates under the issuing sub CA, VI CA3, nextUpdate is 7 days. For end-entity certificates under the issuing sub CA, VI CA4, nextUpdate is 3 days.

o	The sections of your CP/CPS documentation that state the requirements about frequency of updating CRL.

Certification Practice Statement, Chapter 4, Certificate Revocation List (CRL) Issuance Frequency. Please see page no. 37 of section 4.8 of the VISA CP.

o	Note the CA/Browser Forum's EV guidelines: CRLs MUST be updated and reissued at least every seven days, and the nextUpdate field value SHALL NOT be more ten days
o	You must test your CRLs by importing them into the Firefox browser.
	Error Codes:
	ffffe095, is equivalent to -8043, SEC_ERROR_CRL_UNKNOWN_CRITICAL_EXTENSION Resolution: See Potentially Problematic Practice CRL with Critical CIDP Extension
	ffffe009 is equivalent to -8183, “Security library: improperly formatted DER-encoded message.” It means that the reply contained anything other than a valid DER-encoded CRL. Typical Resolution: Change encoding from PEM to DER.
14.	OCSP (OCSP is required for EV enablement)
Not applicable.  Visa is currently not planning to issue EV certificates from the Visa InfoDelivery Root CA.

15.	Requested Trust Bits
o	State which of the three trust bits you are requesting to be enabled for this root. One or more of:
	Websites (SSL/TLS)
	Email (S/MIME)
	Code Signing

The Visa Information Delivery Root CA which provides Certificate Signing, Off-line CRL Signing, CRL Signing (06) has several subordinate online CAs that issue end entity certificates (SSL client, SSL server, digital signature, VPN/IP Sec, SSL Server & Client). Email (S/MIME) and Code Signing Certificates ARE NOT issued from the Visa Information Delivery subordinate online CAs.

o	Mozilla’s standpoint is that we should operate the root program in terms of minimizing risk. One way that we can minimize risk is by not enabling more trust bits than CAs absolutely require.

16.	SSL Validation Type
o	Indicate the levels of SSL validation that are used for certificates within this root's hierarchy. One or more of:
	OV -- In addition to verifying the domain ownership, you also validate the organization to be listed in the O field - making sure public record and government resources can verify the address, existence, and good legal standing of the organization itself. Verifying that the whois listed address matches the verified address, and any other additional checks that a given CA lists in its CPS.
 
17.	If EV certificates are issued within the hierarchy rooted at this root, the EV policy OID(s) associated with those EV certificates.

E/V Certificates ARE NOT currently issued from the Visa Information Delivery subordinate online CAs.

CA hierarchy information for the Visa InfoDelivery Root CA certificate

1.	CA Hierarchy
o	A description of the PKI hierarchy rooted at or otherwise associated with this root CA certificate.
	List and/or describe all of the subordinate CAs that are signed by this root.
	Identify which of the subordinate CAs are internally-operated; e.g. list the subordinate CAs that operated by the CA organization associated with the root CA. For example, this might include subordinate CAs created to issue different classes or types of end entity certificates to the general public: Class 1 vs. class 2 certificates, qualified vs. non-qualified certificates, EV certificates vs. non-EV certificates, SSL certificates vs. email certificates, and so on.
It might also include subordinate CAs operated for the benefit of specific third parties. In this case note that we do not require that the CA submit a complete customer list; rather we are interested in the general type and nature of the third-party arrangements. 

The Visa Information Delivery Root CA has four subordinate Issuing CAs:

	(1) VICA1 – Visa Inc. Certificate Authority for Internet use 
	(2) VICA2 – Visa Inc. Certificate Authority for Intranet use 
        (3) Visa Inc. External Issuing Certificate Authority for Internet use – VI CA3
        (4) Visa Inc. Internal Issuing Certificate Authority for Intranet use – VI CA4
         

These four CA’s are internally operated Issuing CAs and issue only end-entity certificates.

2.	Sub CAs Operated by 3rd Parties
o	If this root has any subordinate CAs that are operated by external third parties, then provide the information listed in the Subordinate CA Checklist
o	If the CA functions as a super CA such their CA policies and auditing don't apply to the subordinate CAs, then those CAs must apply for inclusion themselves as separate trust anchors.

N/A.  VISA DOES NOT permit sub CAs operated by 3rd parties.

3.	Cross-Signing
o	List all other roots for which this root CA has issued cross-signing certificates.
o	List all other root CAs that have issued cross-signing certificates for this root CA.
o	If any such roots exist, it is important to note whether the roots in question are already included in the Mozilla root store or not.

N/A.  VISA DOES NOT permit cross signing Certificate Authorities.

Comment 8

[Christopher L. Grassi]

Hi Kathleen,  below is VISA's review and response to the Mozilla Recommended CA Practices:

1. Publicly Available CP and CPS –
•	The CP/CPS should be publicly available from the CA's official web site. 
•	The format of the CP/CPS document should be PDF or another suitable format for reading documents. CAs should not use Microsoft Word or other formats intended primarily for editable documents. 
•	The CP/CPS should be available in an English version. 
•	The CA should provide references to the CP/CPS sections (e.g., by section number and/or page number) that address the requirements of the Mozilla policy. 

[ VISA Response ]  VISA CP Version 1.2 is currently available at URL -- *www.visa.com/pki*.

2. CA Hierarchy -  A hierarchical structure of a single root with intermediate certs (subroots) is preferred. The single top-level root's public certificate is supplied for Mozilla's root list; the subroots are not.

[ VISA Response ] InfoDelivery Root signs : 

(1) VICA1 – Visa Inc. Certificate Authority for Internet use 
(2) VICA2 – Visa Inc. Certificate Authority for Intranet use 
(3) Visa Inc. External Issuing Certificate Authority for Internet use – VI CA3
(4) Visa Inc. Internal Issuing Certificate Authority for Intranet use – VI CA4

Please see Figure 1-2 entitled *VISA PKI Hierarchies* on page no. 20 of the VISA CP version 1.2.  The VISA InfoDelivery Root CA and the VICA1, VICA2, ,Visa Inc. External Issuing Certificate Authority, and Visa Inc. Internal Issuing Certificate Authority hierarchical relationship is clearly illustrated.

3. Audit Criteria –
CAs should supply evidence of their being evaluated according to one or more of the criteria accepted as suitable per the Mozilla policy. 
•	The CA should indicate exactly which criteria they are being evaluated against (i.e., which of the criteria listed in the Mozilla policy). 
•	All documents supplied as evidence should be publicly available. 
•	Documents purporting to be from the CA's auditor (or other evaluator) should be available directly from the auditor (e.g., as documents downloadable from the auditor's web site). 

[ VISA Response ] Supplied Webtrust audit report summaries for 2010. Plan to supply Webtrust audit reports for 2011 when they become available.


4. Document Handling of IDNs in CP/CPS: If a CA allows the use of internationalized domain names (IDNs) in certificates (e.g., as issued for SSL/TLS-enabled servers), the CA should address the issue of homographic spoofing of IDNs in their CP/CPS, even if primary responsibility for dealing with this issue falls on domain registries. (This doesn't mean that the CAs must prevent such spoofing. It merely means that a CA should describe how it handles the issue of spoofing when authenticating the owner of a domain.)

[ VISA Response ] Please see page no. 30 section 3.2 of version 1.2 of the VISA CP entitled *Distinguished Names (DNs) Restrictions* specifically the section that states the following: “Certificates that contain a domain name not owned by Visa (“foreign entity certificates”),for example, server_name.BankX.com., may be signed and requires signed written permission by an officer (Vice President level or above) on company letterhead from thecompany that owns the domain name authorizing the signing of the certificate.”

 
5. Revocation of Compromised Certificates -
CAs should revoke certificates with private keys that are known to be compromised, or for which verification of subscriber information is known to be invalid.

[ VISA Response ] Please see page no. 36 section 4.8 of version 1.2 of the VISA CP entitled *Certificate Revocation and Suspension*. Please see section 7.2 entitled *Certificate Revocation List (CRL) Profile* on page no. 55 versdion 1.2 of the VISA CP.

VISA Currently publishes CRLs via HTTP and LDAP.  URLS:

http://enroll.visaca.com/ , and
http://crl.inov.visa.net/ , as well as
ldap://enroll.visaca.com/ , and
ldap://crl.inov.visa.net/


6. Verifying Domain Name Ownership We rely on public documentation and audits of those documented processes to ascertain that the requirements of section 7 of the Mozilla CA Certificate Policy are met. Section 7 of the Mozilla CA Certificate Inclusion Policy states: “for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf" 

[ VISA Response ] Please see page no. 30 section 3.2 of Version 1.2 of the VISA CP entitled *Distinguished Names (DNs) Restrictions*   We stated in an e-mail message to Mozilla on *08/31/2011*: 1. *Verifying Domain Name Ownership* -- Please see page no. 30 of section 3.2 entitled *Distinguished Names (DNs) Restrictions* of version 1.2 of the VISA Certificate Policy document.   There is a section that states the following:
“Certificates that contain a domain name not owned by Visa (“foreign entity certificates”),for example, server_name.BankX.com., may be signed and requires signed writtenpermission by an officer (Vice President level or above) on company letterhead from the company that owns the domain name authorizing the signing of the certificate.”


7. Verifying Email Address Control -- We rely on public documentation and audits of those documented processes to ascertain that the requirements of section 7 of the Mozilla CA Certificate Policy are met. Section 7 of the Mozilla CA Certificate Inclusion Policy states: “for a certificate to be used for digitally signing and/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” 

[ VISA Response ] We stated in an e-mail message to Mozilla on *08/31/2011*:

 *Verifying Email Address Control* -- According to the VISA version 1.2 Certificate Policy, this DOES NOT apply to the *VISA Info Delivery Root CA*, it  is the only VISA CA that we are currently submitting for inclusion to the *Mozilla CA Certificate Inclusion Program*. VISA e-mail signing and encryption certificates are only issued by the VISA 3rd Party Root CA for VISA internal use only. – Please see *Figure 1-2* entitled *VISA PKI Hierarchies* on page no. 20 of version 1.2 of the VISA Certificate Policy document.  As an additional aside, section 6.2 entitled *Private Key Protection and Cryptographic Module Engineering Controls* on page no. 48 of the VISA version 1.2 Certificate Policy states the following:
  
“If key recovery is implemented, data encryption private keys (used for email encryption)must be stored in a password protected media or in the end-user's smart card, or whenstored by the Certificate Authority (CA) protected by cryptographic hardware.”

Note:  The box above this section states this applies only to the *VISA Corporate Root CA’s* and DOES NOT apply to the *VISA Info Delivery Root CA*.

8. Verifying Identity of Code --Signing Certificate Subscriber 
We rely on public documentation and audits of those documented processes to ascertain that the requirements of section 7 of the Mozilla CA Certificate Policy are met. Section 7 of the Mozilla CA Certificate Inclusion Policy states: “for certificates to be used for digitally signing code objects, the CA takes reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf; ” 

[ VISA Response ] We stated in an e-mail message to Mozilla on *08/31/2011*:
*Verifying Identity of Code Signing Certificate Subscriber* -- Once again according to the VISA version 1.2 Certificate Policy, this DOES NOT at all apply to the *VISA Info Delivery* Root Certificate Authority, it is the only VISA CA that we are currently submitting for inclusion to the *Mozilla CA Certificate Inclusion Program*.  VISA code signing certificates are only issued by the VISA Corporate Root CA (Internal) Issuing Certificate Authority (VCIICA) – Please see *Figure 1-2* entitled *VISA PKI Hierarchies* on page no. 20 of version 1.2 of the VISA Certificate Policy document. As an additional aside, section 4.4 entitled 
*Key Pair and Certificate Usage* under the sub-section entitled *Publisher Certificate and Usage* on page 35 of version 1.2 of the VISA Certificate Policy document states the following:
“A publisher certificate is a certificate with code or document signing extensions. Only theVisa Corporate Internal Issuing Certificate Authority (VCIICA) shall sign publishercertificates and only for Visa Internal use. Publisher certificates private keys must be stored with a tamper resistant security module, for example, smart card.”


9. DNS names go in SAN -- 
Some CAs mistakenly believe that one primary DNS name should go into the Subject Common Name and all the others into the SAN. That's wrong. ALL should go into the SAN. 

[ VISA Response ] We normally place primary DNS names within the SAN (Subject Alternate Name) extension of X.509v3 certificates and in some instances use the SCN (Subject Common Name) for the primary DNS name (This is dependent on the subject application's architectural requirements).


10. Domain owned by a Natural Person -- 

[ VISA Response ] Domain names owned by individuals are NOT permitted by VISA. Please see page no. 30 section 3.2 entitled *Distinguished Names (DNs) Restrictions* of version 1.2 of the VISA CP.

11. OCSP -- Mozilla strongly recommends that OCSP be provided for certificates chaining to CAs that are included in NSS. OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443. 

[ VISA Response ] VISA does not currently have an OCSP capability in place. VISA is currently looking at the high-level business and engineering requirements for implementing OCSP and is in the process building an overall go-forward strategy.

Please see section 7.3 entitled *Online Certificate Status Protocol (OCSP)* on page no. 55 of version 1.2 of the VISA CP.

Comment 9

[Kathleen Wilson]

(In reply to Christopher L. Grassi from comment #8)
> [ VISA Response ]  VISA CP Version 1.2 is currently available at URL --
> *www.visa.com/pki*.


Unfortunately, I am only able to find version 1.1 of the CP.

Comment 10

[Kathleen Wilson]

Two more things...

Please provide an https url to a website whose SSL certificate chains up to this root cert.

When I try to import the CRL 
http://enroll.visaca.com/VisaInfoDeliveryRootCA.crl
into my Firefox browser, I get the following error:
Error Importing CRL to local Database. Error Code:ffffe009
-- ffffe009 is equivalent to -8183, “Security library: improperly formatted DER-encoded message.” It means that the reply contained anything other than a valid DER-encoded CRL. 
Typical Resolution: Change encoding from PEM to DER.
Please correct and test with Firefox.

Comment 11

[Christopher L. Grassi]

Hi Kathleen,

Thank You for pointing this out.  I humbly apologize and will get this fixed ASAP. :-)

Cheers
C.L. Grassi

Comment 12

[Christopher L. Grassi]

"RE: Two more things...

Please provide an https url to a website whose SSL certificate chains up to this root cert.

When I try to import the CRL 
http://enroll.visaca.com/VisaInfoDeliveryRootCA.crl
into my Firefox browser, I get the following error:
Error Importing CRL to local Database. Error Code:ffffe009"

Thanks Kathleen, I will get on this right away. :-)

Cheers
C.L. Grassi

Comment 13

[Christopher L. Grassi]

Hi Kathleen,

RE: "In reply to Christopher L. Grassi from comment #8)
> [ VISA Response ]  VISA CP Version 1.2 is currently available at URL --
> *www.visa.com/pki*.
Unfortunately, I am only able to find version 1.1 of the CP."

We fixed that problem, you should now be able to access Version 1.2 of the VISA CP using URL: *www.visa.com/pki*.

Comment 14

[Christopher L. Grassi]

Hi Kathleen,

We have published the following CDP with the InfoDelivery CRLs bundled up and encoded in the DER-Binary format:

http://enroll.visaca.com/VisaInfoDeliveryRootCA.der.crl

In response to your comment:

"When I try to import the CRL
http://enroll.visaca.com/VisaInfoDeliveryRootCA.crl
into my Firefox browser, I get the following error:
Error Importing CRL to local Database. Error Code:ffffe009
-- ffffe009 is equivalent to -8183, “Security library: improperly formatted DER-encoded message.” It means that the reply contained anything other than a valid DER-encoded CRL. 
Typical Resolution: Change encoding from PEM to DER.
Please correct and test with Firefox."

Comment 15

[Christopher L. Grassi]

Hi Kathleen,

We will get a relevant https url to you shortly .

This is in regards to:

"--- Comment #10 from Kathleen Wilson <[e-mail]> 2011-11-17 16:03:20 PST ---
Two more things...

Please provide an https url to a website whose SSL certificate chains up to
this root cert."

Comment 16

[Christopher L. Grassi]

Hi Kathleen,

In response to your request shown below:

--- Comment #10 from Kathleen Wilson <[e-mail]> 2011-11-17 16:03:20 PST ---
Two more things...

*Please provide an https url to a website whose SSL certificate chains up to
this root cert.*

[VISA] – We plan on putting into place a public facing *HTTPS URL* that will provide a concrete example of how a VISA InfoDelivery end-entity SSL certificate chains up to the root certificate. This won’t be available until after Jan 16, 2012 because we are currently in a change freeze until after the new year.

Please let us know if you have any further questions.

Cheers
C.L. Grassi

Comment 17

[Kathleen Wilson]

Attachment: Initial CA Information Document

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.

Comment 18

[Kathleen Wilson]

There are two remaining items:

1) test website (as per Comment #16)

2) CRL must import without error into Firefox browser

Once the CRL is fixed, I can add this request to the queue for public discussion.

Comment 19

[Brandon Beam]

Greeting Kathleen,
I'm resuming this thread in place of Chris.  By next week, I expect you'll be able to test the website as requested in Item 1 above.

As for Item 2, is there someone I can work with at Mozilla to import the CRL?  As you may recall, we use .pem format.  However, the LDAP link in our CRL is in .der format.

Let me know. 

Thanks,
Brandon

Comment 20

[Kathleen Wilson]

(In reply to Brandon Beam from comment #19)
> Greeting Kathleen,
> I'm resuming this thread in place of Chris.  By next week, I expect you'll
> be able to test the website as requested in Item 1 above.

Please provide the URL to the test website when it is ready.

> 
> As for Item 2, is there someone I can work with at Mozilla to import the
> CRL?  As you may recall, we use .pem format.  However, the LDAP link in our
> CRL is in .der format.
>

You can test importing the CRL into Firefox as follows:
Firefox -> Preferences -> Advanced -> Encryption -> Revocation Lists
Import... http://enroll.visaca.com/VisaInfoDeliveryRootCA.crl

When I do this I get the error ffffe009, which is equivalent to -8183, “Security library: improperly formatted DER-encoded message.” It means that the reply contained anything other than a valid DER-encoded CRL.

Comment 21

[Jeff Emerson]

Please use the url https://enroll.visaca.com to observe a certificate that chains up to the Visa InfoDelivery Root CA certificate

We only publish der crl's using the ldap format.  Please use ldap://Enroll.visaca.com:389/cn=Visa Information Delivery Root CA,c=US,ou=Visa International Service Association,o=VISA?certificateRevocationList
to test crl importing into Firefox.

Comment 22

[Kathleen Wilson]

Please attach a recent audit statement to this bug, or provide a url to the most recent audit statement. 

(In reply to Jeff Emerson from comment #21)
> Please use the url https://enroll.visaca.com to observe a certificate that
> chains up to the Visa InfoDelivery Root CA certificate

I get the sec_error_unknown_issuer when I try to browse to this site, even though I have imported the "Visa Information Delivery Root CA" cert into my browser.

SSL servers are expected to send out the intermediate CA certificates together with their own certificates whenever they are asked to send out their certificates. 

> 
> We only publish der crl's using the ldap format.  Please use
> ldap://Enroll.visaca.com:389/cn=Visa Information Delivery Root
> CA,c=US,ou=Visa International Service
> Association,o=VISA?certificateRevocationList
> to test crl importing into Firefox.

I still get the ffffe009 when I try to import
http://enroll.visaca.com/VisaInfoDeliveryRootCA.crl

Comment 23

[Brandon Beam]

Attachment: 2011 e-Commerce WebTrust Report

The 2011 e-Commerce WebTrust Report is attached.

Comment 24

[Brandon Beam]

Attachment: 2011 InfoDelivery WebTrust Report

The 2011 InfoDelivery WebTrust Report is attached.

Comment 25

[Kathleen Wilson]

Attachment: 2012 e-Commerce WebTrust Report

Comment 26

[Kathleen Wilson]

Attachment: 2012 InfoDelievery WebTrust Report

Comment 27

[Kathleen Wilson]

The test website, https://enroll.visaca.com/, works now.

CRLs:
http://Enroll.visaca.com/VisaInfoDeliveryRootCA.crl
http://Enroll.visaca.com/VICA3.crl

When I try to import these CRLs into my Firefox browser, I get Error Code:ffffe009
which is equivalent to -8183, “Security library: improperly formatted DER-encoded message.” It means that the reply contained anything other than a valid DER-encoded CRL. 
Typical Resolution: Change encoding from PEM to DER.
Please correct and test with Firefox.


OCSP not provided -- Required now as per the CA/Browser Forum's baseline Requirements.


Please update this root hierarchy to be in compliance with the CA/Browser Forum's Baseline Requirements, and then update this bug.

Comment 28

[Nicholas Piasecki]

It appears that Visa has steamrollered ahead with this on properties that it owns:

https://support.authorize.net/

https://support.cybersource.com/

and they advise that users of these popular gateways that they can no longer use Firefox, so it is something that will start to effect real users. These sites can be used as two "real-world" example sites for testing should Mozilla decide to allow the CA.

Comment 29

[David E. Ross]

See bug #1034834, which reports that Visa recently issued 1024 bit certificates and thus potentially creating security vulnerabilities for end-users.  To counter Visa's assertion that users should not use Firefox (or other Mozilla-based browsers), Visa's violation of BR requirements should be widely publicized (e.g., at Slashdot, press release to various TV network news organizations).

Comment 30

[David E. Ross]

Expanding upon my comment #29, further action on any Visa request for certificate roots should be held until bug #1034834 is satisfactorily addressed.

Comment 31

[Brandon Beam]

Attachment: 2013 e-Commerce WebTrust Report.pdf

2013 e-Commerce WebTrust Report

Comment 32

[Brandon Beam]

Attachment: 2013 InfoDelievery WebTrust Report.pdf

2013 InfoDelievery WebTrust Report

Comment 33

[Marcelo B. Silva]

The OCSP Service alerady was implemeted as required by the CA/Browser Forum's Baseline Requirements:

http://ocsp.visa.com/ocsp

Comment 34

[Marcelo B. Silva]

The OCSP Service alerady was implemeted.

Comment 35

[Kathleen Wilson]

Attachment: 636557-CAInformation.pdf

I have entered the information for this request into SalesForce, so am attaching the updated CA Information document.

Please review the full document for accuracy, and search for "need" to find where further information is still needed.

Comment 36

[Kathleen Wilson]

Attachment: Visa-eCommerce-2015-WTCA-Report.pdf

2015 e-Commerce WebTrust Report

Comment 37

[Kathleen Wilson]

Attachment: Visa-InfoDelivery-2015-WTCA-Report.pdf

Comment 38

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #35)
> Created attachment 8552631 [details]
> 636557-CAInformation.pdf
> 
> I have entered the information for this request into SalesForce, so am
> attaching the updated CA Information document.
> 
> Please review the full document for accuracy, and search for "need" to find
> where further information is still needed.

As per the attachment 636557 [details]-CAInformation.pdf, the status of this request is that I am waiting for Visa to provide the following.

1)  BR audit statement for this root and hierarchy (and for the e-Commerce root and hierarchy)
Please see: https://wiki.mozilla.org/CA:BaselineRequirements

2) Commitment to comply with the BRs 
https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs
The CA's CP or CPS documents must include a commitment to comply with the BRs, as described in BR section 8.3.

3) Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance. See #6 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

4) Confirm that you have performed the actions listed in #7 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

Comment 39

[Kathleen Wilson]

And 5) Please also respond to:
https://wiki.mozilla.org/CA:Problematic_Practices#SHA-1_Certificates

Comment 40

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #36)
> Created attachment 8639559 [details]
> Visa-eCommerce-2015-WTCA-Report.pdf

(In reply to Kathleen Wilson from comment #37)
> Created attachment 8640125 [details]
> Visa-InfoDelivery-2015-WTCA-Report.pdf


A representative of KPGM has confirmed the authenticity of these audit statements.

Comment 41

[David E. Ross]

Has Visa's issuance of 1024 bit certificates been resolved?  If not, I request that there be no further action on this request.  See my comment #29 and comment #30.

Comment 42

[Kathleen Wilson]

(In reply to David E. Ross from comment #41)
> Has Visa's issuance of 1024 bit certificates been resolved?  If not, I
> request that there be no further action on this request.  See my comment #29
> and comment #30.

Agreed. And we are also still waiting for Visa to provide the information requested in Comment #38 and Comment #39.

Comment 43

[PKI Policy]

(In reply to Kathleen Wilson from comment #38)
> (In reply to Kathleen Wilson from comment #35)
> > Created attachment 8552631 [details]
> > 636557-CAInformation.pdf
> > 
> > I have entered the information for this request into SalesForce, so am
> > attaching the updated CA Information document.
> > 
> > Please review the full document for accuracy, and search for "need" to find
> > where further information is still needed.
> 
> As per the attachment 636557 [details]-CAInformation.pdf, the status of this
> request is that I am waiting for Visa to provide the following.
> 
> 1)  BR audit statement for this root and hierarchy (and for the e-Commerce
> root and hierarchy)
> Please see: https://wiki.mozilla.org/CA:BaselineRequirements
> 
> 2) Commitment to comply with the BRs 
> https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs
> The CA's CP or CPS documents must include a commitment to comply with the
> BRs, as described in BR section 8.3.
> 
> 3) Confirm that multi-factor authentication is required for all accounts
> capable of directly causing certificate issuance. See #6 of
> https://wiki.mozilla.org/CA:
> Information_checklist#Verification_Policies_and_Practices
> 
> 4) Confirm that you have performed the actions listed in #7 of
> https://wiki.mozilla.org/CA:
> Information_checklist#Verification_Policies_and_Practices

Responses in line:

1)BR audit statement for this root and hierarchy (and for the e-Commerce root and hierarchy) Please see: https://wiki.mozilla.org/CA:BaselineRequirements 
Response:-
Based on the global impact of implementing some of the prescriptive requirements of Criteria for Certification Authorities - SSL Baseline with Network Security - Version 2 standard, Visa has scheduled to begin participating in Criteria for Certification Authorities - SSL Baseline with Network Security - Version 2 standard requirements in with our 2015 annual audit to be conducted in 2016.  The prescriptive requirements outlined require an Organizational changes that require us to align properly prior to the participating in the new audit requirement

2) Commitment to comply with the BRs https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs The CA's CP or CPS documents must include a commitment to comply with the BRs, as described in BR section 8.3. 
Response:-
As part of our Baseline readiness we have updated our CP and CPS to be published that will be aligned with Baseline requirements.

3)Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance. See #6 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices 
Response:-
Yes we have multi-factor authentication is required for all accounts capable of directly causing certificate issuance

4) Confirm that you have performed the actions listed in #7 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices
Response:-
Confirm that you have done the following, and will do the following on a regular basis: 
Maintain network security controls that at minimum meet the Network and Certificate System Security Requirements. 
•Check for mis-issuance of certificates, especially for high-profile domains.  
==> Yes we do check for any certificate request for any “high-profile” domains and deny such requests. Visa only issues certificates to VISA owned domains or to VISA Clients for their domains.
•Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness. 
==> Yes Visa has very mature and stringent security programs that monitor, scan, review and alert on any network, systems or application intrusions and weakness. VISA Technical Security Requirements (TSR’s) program is implement across all VISA assets to ensure a very high level of security and compliance.
•Ensure Intrusion Detection System and other monitoring software is up-to-date. 
==> Yes VISA’s IDS and monitoring systems are kept up to date
•Confirm that you will be able to shut down certificate issuance quickly if you are alerted of intrusion
==> Yes, we do have the ability to shut down immediately.

Comment 44

[PKI Policy]

(In reply to Kathleen Wilson from comment #39)
> And 5) Please also respond to:
> https://wiki.mozilla.org/CA:Problematic_Practices#SHA-1_Certificates

Response:
Yes. We have started replacing all SHA-1 certificates and all of them will be either expired before 2017 or revoked

Comment 45

[David E. Ross]

(In reply to PKI Policy from comment #44)
> (In reply to Kathleen Wilson from comment #39)
> > And 5) Please also respond to:
> > https://wiki.mozilla.org/CA:Problematic_Practices#SHA-1_Certificates
> 
> Response:
> Yes. We have started replacing all SHA-1 certificates and all of them will
> be either expired before 2017 or revoked

SHA-1 certificates were signed by Visa in 2014.  Allowing any of them to persist through the end of 2016 means their lifespan will exceed two years.  Is this acceptable?

Comment 46

[Kathleen Wilson]

(In reply to David E. Ross from comment #45)
> (In reply to PKI Policy from comment #44)
> > (In reply to Kathleen Wilson from comment #39)
> > > And 5) Please also respond to:
> > > https://wiki.mozilla.org/CA:Problematic_Practices#SHA-1_Certificates
> > 
> > Response:
> > Yes. We have started replacing all SHA-1 certificates and all of them will
> > be either expired before 2017 or revoked
> 
> SHA-1 certificates were signed by Visa in 2014.  Allowing any of them to
> persist through the end of 2016 means their lifespan will exceed two years. 
> Is this acceptable?

Well, according to the BRs, SSL certs can have validity up to 39 months.
So, this seems acceptable to me. Am I missing something?

Comment 47

[Kathleen Wilson]

Here's what is needed before this request can move to the public discussion phase:

1) Resolution to https://bugzilla.mozilla.org/show_bug.cgi?id=1034834

2) Published CP/CPS with BR Commitment to Comply as per https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs

3) BR audit statement as per https://wiki.mozilla.org/CA:BaselineRequirements

Please update this bug when these 3 items are complete.

Comment 48

[Marcelo B. Silva]

Hi Kathleen, following below the answers:

1) Resolution to https://bugzilla.mozilla.org/show_bug.cgi?id=1034834
We no longer issue any SHA-1 certificate. And this bug is related to the Visa eCommerce Root CA and not to the Visa Information Delivery Root CA.
So it should not impact the current process for this CA.

2) Published CP/CPS with BR Commitment to Comply as per https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs
Both CP and CPS are published at http://www.visa.com/pki
Please see the "Documents" section of the webpage.
And we have included in these new versions the commitment to comply with the BR.

3) BR audit statement as per https://wiki.mozilla.org/CA:BaselineRequirements
Both Visa CAs (Visa Ecommerce Root CA and Visa Information Delivery Root CA) are in compliance with the latest BR.
Please see our Certificate Policy document, as it's indicated in multiple sections.

Comment 49

[Kathleen Wilson]

(In reply to Marcelo B Silva from comment #48)
> Hi Kathleen, following below the answers:
> 
> 1) Resolution to https://bugzilla.mozilla.org/show_bug.cgi?id=1034834
> We no longer issue any SHA-1 certificate. And this bug is related to the
> Visa eCommerce Root CA and not to the Visa Information Delivery Root CA.
> So it should not impact the current process for this CA.

Bug #1034834 is about Visa issuing 1024 bit certificates.
Please update that bug to indicate if/when Visa stopped issuing 1024 bit SSL certificates.

> 
> 2) Published CP/CPS with BR Commitment to Comply as per
> https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs
> Both CP and CPS are published at http://www.visa.com/pki
> Please see the "Documents" section of the webpage.
> And we have included in these new versions the commitment to comply with the
> BR.

Thanks. I will review the updated documentation.

> 
> 3) BR audit statement as per https://wiki.mozilla.org/CA:BaselineRequirements
> Both Visa CAs (Visa Ecommerce Root CA and Visa Information Delivery Root CA)
> are in compliance with the latest BR.
> Please see our Certificate Policy document, as it's indicated in multiple
> sections.


It is not sufficient just to document your compliance with the BRs in your CP/CPS, you must also have a corresponding annual audit to attest to said compliance.

Please either send me a link to your current WebTrust BR Audit Statement, or attach it to this bug.
See: http://www.webtrust.org/homepage-documents/item79806.pdf

Additionally, I have never received a WebTrust BR Audit Statement for the "Visa eCommerce Root" root. This is in direct violation of Mozilla CA Certificate Policy, and needs to be resolved soon, or I will have to remove that root certificate from NSS.

Comment 50

[Francis Lee [:frlee]]

Attachment: R00000066 ~ Salesforce - Enterprise Edition.pdf

Comment 51

[Francis Lee [:frlee]]

hi Marcelo,

i have updated comment49 item 1 and 2 in salesforce, please refer to the attachment.
by the ways, we have found a test error in Website lint test as below:

Error
Unallowed key usage for RSA public key

please fix this error along with providing WebTrust BR audit statement mentioned in the comment49 item 3.

thank you very much

Francis & Aaron

Comment 52

[Marcelo B. Silva]

Thank you Francis.

Do you have any additional detail on this error? 

"Unallowed key usage for RSA public key".

Thank you.
Marcelo.

Comment 53

[PKI Policy]

(In reply to Kathleen Wilson from comment #49)
> (In reply to Marcelo B Silva from comment #48)
> > Hi Kathleen, following below the answers:
> > 
> > 1) Resolution to https://bugzilla.mozilla.org/show_bug.cgi?id=1034834
> > We no longer issue any SHA-1 certificate. And this bug is related to the
> > Visa eCommerce Root CA and not to the Visa Information Delivery Root CA.
> > So it should not impact the current process for this CA.
> 
> Bug #1034834 is about Visa issuing 1024 bit certificates.
> Please update that bug to indicate if/when Visa stopped issuing 1024 bit SSL
> certificates.
> 
> > 
> > 2) Published CP/CPS with BR Commitment to Comply as per
> > https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs
> > Both CP and CPS are published at http://www.visa.com/pki
> > Please see the "Documents" section of the webpage.
> > And we have included in these new versions the commitment to comply with the
> > BR.
> 
> Thanks. I will review the updated documentation.
> 
> > 
> > 3) BR audit statement as per https://wiki.mozilla.org/CA:BaselineRequirements
> > Both Visa CAs (Visa Ecommerce Root CA and Visa Information Delivery Root CA)
> > are in compliance with the latest BR.
> > Please see our Certificate Policy document, as it's indicated in multiple
> > sections.
> 
> 
> It is not sufficient just to document your compliance with the BRs in your
> CP/CPS, you must also have a corresponding annual audit to attest to said
> compliance.
> 
> Please either send me a link to your current WebTrust BR Audit Statement, or
> attach it to this bug.
> See: http://www.webtrust.org/homepage-documents/item79806.pdf
> 
> Additionally, I have never received a WebTrust BR Audit Statement for the
> "Visa eCommerce Root" root. This is in direct violation of Mozilla CA
> Certificate Policy, and needs to be resolved soon, or I will have to remove
> that root certificate from NSS.

We have just finished out WebTrust (BR + Network Security) audit for this year 2016 (Visa eCommerce Root and Visa Information Delivery Root Certificate Authority (CA))  are expecting out auditors KPMG to send us  the report early next week (week of 8th August).

We will provide them to you as soon as we receive them.

Thank You 
Anup Chauhan

Comment 54

[Francis Lee [:frlee]]

hi Marcelo,

information added below, hope that helps you to resolve "Unallowed key usage for RSA public key". error.

An RSA key can't be used to perform key agreement directly. It can be used
to exchange a key by encrypting it (so the keyEncipherment usage makes
sense) and it can sign the data used in a DH key agreement (so the
digitalSignature usage makes sense), but there isn't a key agreement
algorithm that just uses RSA in the same way that DH does.

so, i think you may need to make sure certificates with RSA
keys don't have the keyAgreement usage asserted.

thank you very much

Comment 55

[Marcelo B. Silva]

Hi Francis, thanks for explaining about the error indicated in your report.
Actually it's not an issue, as per the RFC5280 Section 4.2.1.3 (link provided below), and we should be good to proceed with the final publishing of our Root CA certificate.

https://tools.ietf.org/html/rfc5280#section-4.2.1.3


The Key Usage extension is described in section 4.2.1.3 of X.509, with the following possible flags:
digitalSignature (0)
nonRepudiation (1)
keyEncipherment (2)
dataEncipherment (3)
keyAgreement (4)
keyCertSign (5)
cRLSign (6)
encipherOnly (7)
decipherOnly (8) 

In SSL/TLS, when the server certificate contains a RSA key, then:
• either a DHE or ECDHE cipher suite is used, in which case the RSA key is used for a signature (see section 7.4.3 of RFC 5246: the "Server Key Exchange" message); this exercises the digitalSignature key usage;
• or "plain RSA" is used, with a random value (the 48-byte pre-master secret) being encrypted by the client with the server's public key (see section 7.4.7.1 of RFC 5246); this is right in the definition of the keyEncipherment key usage flag.
dataEncipherment does not apply, because what is encrypted is not directly meaningful data, but a value which is mostly generated randomly and used to derive symmetric keys. keyAgreement does not apply either, because that one is for key agreement algorithms which are not a case of asymmetric encryption (e.g. Diffie-Hellman). The keyAgreement usage flag would appear in a certificate which contains a DH key, not a RSA key. nonRepudiation is not used, because whatever is signed as part of a SSL/TLS key exchange cannot be used as proof for a third party (there is nothing in a SSL/TLS tunnel that the client could record and then use to convince a judge when tring to sue the server itself; the data which is exchanged within the tunnel is not signed by the server).

Summary
digitalSignature for (EC)DHE cipher suites, keyEncipherment for plain RSA cipher suites. However, some implementations will also accept keyAgreement in lieu of keyEncipherment, or nonRepudiationeven if digitalSignature is not set; and some will just totally ignore the Key Usage extension (even if marked critical).

Comment 56

[Francis Lee [:frlee]]

hi Marcelo,

thank you for your reply.

The analysis you provided looks correct to me (long story short, a certificate with an RSA key should not assert keyAgreement).
If we're still talking about the same test site ( https://enroll.visaca.com ), as far as I can tell the certificate in use there has an RSA key and does assert the keyAgreement usage (see https://crt.sh/?id=10442658&opt=cablint ), so that's technically a non-conforming certificate. Per consulting with Mozilla's technical member, we are not aware of any implementation that would actually have a problem verifying that certificate. 

So, we still think that Visa shouldn't be issuing certificates with this issue.

it may be worthy to double check and see if its possible to fix it.

thank you very much

Francis & Aaron

Comment 57

[Kathleen Wilson]

Note that updated WebTrust CA audits have been provided as attachments to Bug #1301210.
Still need updated WebTrust BR audit.

Comment 58

[Marcelo B. Silva]

Attachment: Visa_enroll.visaca.com_cert_Info.png

Error message based on the old certificate, issued on 10/30/2015.

Comment 59

[Marcelo B. Silva]

Attachment: Visa_enroll.visaca.com_cert_Info_2.png

New certificate issued with updated Key Usage.

Comment 60

[Marcelo B. Silva]

Hi Francis, we have updated the Key Usage and the error reported (ERROR: Unallowed key usage for RSA public key)was resolved. The information available @ https://crt.sh/?id=10442658&opt=cablint is based on the old certificate from 2015. Please see these attachments:
- https://bug636557.bmoattachments.org/attachment.cgi?id=8789596
- https://bugzilla.mozilla.org/attachment.cgi?id=8789597
Thanks,
Marcelo.

Comment 61

[Francis Lee [:frlee]]

hi Marcelo,

thank you for your confirmation for the key usage error.
now, once Webtrust BR audit is updated (as mentioned in comment 57), the information verification phase will be completed.

thank you very much

Comment 62

[Kathleen Wilson]

BR Audit has been provided: https://bug1301210.bmoattachments.org/attachment.cgi?id=8795503

Comment 63

[Francis Lee [:frlee]]

hi Marcelo,

please refer to your BR audit statement https://bug1301210.bmoattachments.org/attachment.cgi?id=8795503 page 7-10, it contains 7 exceptions. May we understand what's the action you are taking? and do you have a schedule to fix them?

thank you very much

Comment 64

[Marcelo B. Silva]

(In reply to Francis Lee [:frlee] from comment #63)
> hi Marcelo,
> 
> please refer to your BR audit statement
> https://bug1301210.bmoattachments.org/attachment.cgi?id=8795503 page 7-10,
> it contains 7 exceptions. May we understand what's the action you are
> taking? and do you have a schedule to fix them?
> 
> thank you very much

Hi Francis,
The Visa responses are included in the second part of each "Matters Noted" column.
Please see the first one starting with "In July 2014, Visa established a worldwide PKI roadmap to end enterprise-wide SHA-1 trust in 1/1/2017... Management notes that the issue has been remediated".
Thanks,
Marcelo.

Comment 65

[Francis Lee [:frlee]]

hi Marcelo,

please confirm that Visa will be able to resolve all exceptions in the next BR audit statement. it is not sufficient to provide comments in 'matters noted' column. 
Moz will proceed to the next step only if Visa can confirm all exceptions will be resolved in the next BR audit.


thank you very much

Comment 66

[Marcelo B. Silva]

(In reply to Francis Lee [:frlee] from comment #65)
> hi Marcelo,
> 
> please confirm that Visa will be able to resolve all exceptions in the next
> BR audit statement. it is not sufficient to provide comments in 'matters
> noted' column. 
> Moz will proceed to the next step only if Visa can confirm all exceptions
> will be resolved in the next BR audit.
> 
> 
> thank you very much

Hi Francis, we confirm that the Visa already has remediated all exceptions and they will not be listed in the next BR audit report.

Thanks,
Marcelo.

Comment 67

[Francis Lee [:frlee]]

hi Marcelo,

thank you for your confirmation.
i have put Visa case in the queue for public discussion.

thank you very much

Comment 68

[Kathleen Wilson]

Bug #1315016 -- SHA-1 issuance by Visa. Even though it's the other root, I think it is still relevant for this CA's request to include another root.

Comment 69

[Marcelo B. Silva]

Hi Francis, do we have any update on the Public Discussion so we can have our process moved to the next step? Thank you.
Marcelo.

Comment 70

[Marcelo B. Silva]

Hi Francis/Kathleen, any update on this? Thank you. Marcelo.

Comment 71

[Kathleen Wilson]

(In reply to Marcelo B. Silva from comment #70)
> Hi Francis/Kathleen, any update on this? Thank you. Marcelo.

This request is still in the queue for discussion (https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion). I will update this bug when I start the discussion.

The discussions are taking even longer than usual, because there are currently no resources to do the detailed review of the CP/CPS/audit statements that Ryan and Andrew were previously doing as part of the public discussion
https://wiki.mozilla.org/CA:Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21
We are trying to figure out how to get the discussion process moving forward again, and apologize for the delay.

Kathleen

Comment 72

[Kathleen Wilson]

Visa, Please 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
In particular, note:
+ For the CAs currently in the queue for discussion, I would ask them to perform this BR Self Assessment before I would start their discussion.

Comment 73

[Marcelo B. Silva]

Attachment: Visa - CA's BR Self Assessment - 07.07.17.xlsx

Comment 74

[Marcelo B. Silva]

(In reply to Kathleen Wilson from comment #72)
> Visa, Please 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
> In particular, note:
> + For the CAs currently in the queue for discussion, I would ask them to
> perform this BR Self Assessment before I would start their discussion.

Hi Kathleen, we just attached the Visa - CA's BR Self Assessment.
Thank you,
Marcelo

Comment 75

[Aaron Wu]

Hi Marcelo,

I'm verifying the BR Self Assessment you provided, there are two things still need your input/update

1. Since your root requests Website trust bit, please provide the 3 URLs to the test websites as described in Section 2.2 of the BRs: "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

2. I found the effective date of your audit statement date is in 2015, could you please kindly update your audit statement accordingly?


Thanks,
Aaron

Comment 76

[Daniel C]

When considering this request, I think it would be prudent to review previous statements and bugs, including bug 1034834, bug 1315016, bug 1391087 and bug 1398261 in order to decide whether systemic issues have been resolved and that the responsibilities of being in a browser root store are fully understood. (Some of these bugs are still open).

In particular, bug 1391087 comment 15 states:

"Certificates that are issued by Visa public CA’s are issued only to our clients for interconnectivity purposes"

Bug 1391087 comment 20 states:

"We adopted the Baseline Requirements in late 2016" (admitting that the BRs were not adopted until over 4 years after they were first introduced).

Bug 1315016 comment 3 states:

"we had developed an internal exception process" (choosing to opt themselves out of the SHA-1 requirements).

And bug 1315016 comment 10 states:

"we are not a commercial CA, and that we provide certificates only for our clients and partners that leverage Visa products".

Gerv also points out a misleading answer to a CCADB request in bug 1315016 comment 4.

I wouldn't say that these necessarily preclude inclusion of this new root, but that the bar is raised for being convinced of trustworthiness.

(Note that this comment is based my personal thoughts and opinions only).

Comment 77

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 78

[Wayne Thayer]

(In reply to Aaron Wu from comment #75)

> 2. I found the effective date of your audit statement date is in 2015, could
> you please kindly update your audit statement accordingly?
> 
Marcelo: will you please provide the 2016 audit statement that Aaron requested for this root?

Also, please provide historic WebTrust for CAs audit statements for this root back to at least 2011-03-08 when this subordinate was issued: https://crt.sh/?id=1855984 If possible, please provide audit statements back to 2005-06-07 when this root was issued.

Comment 79

[Kathleen Wilson]

Attachment: WTCA InfoDel 2017.pdf

Comment 80

[Kathleen Wilson]

Attachment: WTBR InfoDel 2017.pdf

The 2017 audit statements for this root are available here:
https://enroll.visaca.com/WTCA%20InfoDel.pdf
https://enroll.visaca.com/WTBR%20InfoDel.pdf 

Attaching to this bug for reference as well.

Comment 81

[Kathleen Wilson]

Moving this bug back to the Information Verification phase, step 2 of
https://wiki.mozilla.org/CA/Application_Process

Comment 82

[Kathleen Wilson]

Attachment: 636557-CA-Information-May-2018.pdf

The attached document shows the information that has been verified. 

Search for "need" to find the additional information or clarification that the CA needs to provide in this bug.

In particular:

1) https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CAA_Domains_listed_in_CP.2FCPS

2) https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Domain_Name_Ownership

3) Testing problems need to be resolved: revocation testing, lint testing.


Also, the following may be a show-stopper for this inclusion request:

As far as I can tell from this bug and my records, the first BR audit statement that I have seen for this Information Delivery Root was only recently provided per Comment #80.
** The BR audit statement lists many significant problems.
** It is concerning that this is the first BR audit statement for this root cert. See Comment #38 and https://wiki.mozilla.org/CA/Communications#May_2014_Responses

Comment 83

[Kathleen Wilson]

I received email from Visa saying that they would like to withdraw their request to include this SHA1 root.

Visa may create a new root inclusion request for their new SHA2 Root and ECC Root CA.

https://wiki.mozilla.org/CA/Application_Process#Process_Overview