Request to enable EV for VeriSign Class 3 G4 ECC root

[Kathleen Wilson]

Request to enable EV for VeriSign Class 3 G4 ECC root

This request by Symantec is to enable EV treatment for the "VeriSign Class 3 Public Primary Certification Authority - G4" root certificate that was included via bug #409235, and has all three trust bits enabled.

Symantec is a major commercial CA with worldwide operations and customer base.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=833974

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=8734043

Noteworthy points:

* The primary documents are the CP and CPS, which are provided in English.

Document Repository:
https://www.symantec.com/about/profile/policies/repository.jsp
CP: https://www.symantec.com/content/en/us/about/media/repository/stn-cp.pdf
CPS: https://www.symantec.com/content/en/us/about/media/repository/stn-cps.pdf

* CA Hierarchy: This root signs internally-operated SubCAs which issue OV and EV SSL certificates, as well as Code Signing certificates. S/MIME certs may also be issued in this CA hierarchy.

* This request is to enable EV treatment. All three trust bits are already enabled for this root ceritificate.

* CPS sections 3.1.1.1, 3.2.2.1, 4.1.2.2, 4.3.3, 4.9.1.1, 4.9.3.2: EV SSL Certificates, EV Code Signing, and domain-validated and organization-validated SSL Certificates conform to the CA / Browser Forum requirements as set forth in the STN Supplemental Procedures, Appendix B1, Appendix C and Appendix D, respectively.

* Appendix B1 and Appendix D just say: The current version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates can be accessed at https://cabforum.org/baseline-requirements-documents/

* CPS section 3.2.2: At a minimum Symantec shall:
- Determine that the organization exists by using at least one third party identity proofing service or database, or alternatively, organizational documentation issued by or filed with the applicable government agency or competent authority that confirms the existence of the organization,
- Confirm by telephone, confirmatory postal mail, or comparable procedure to the Certificate Applicant certain information about the organization, that the organization has authorized the Certificate Application, and that the person submitting the Certificate Application on behalf of the Certificate Applicant is authorized to do so. When a certificate includes the name of an individual as an authorized representative of the Organization, the employment of that individual and his/her authority to act on behalf of the Organization shall also be confirmed.
Where a domain name or e-mail address is included in the certificate Symantec authenticates the Organization's right to use that domain name either as a fully qualified Domain name or an e-mail domain. For Organization Validated (OV) and Extended Validation (EV) Certificates domain validation is completed in all cases along with Organizational validation.
...
Extended Validation (EV) Certificates: Symantec's procedures for issuing EV SSL Certificates are described in Appendix B1 to this CPS.

* CPS section 3.2.2.3: Symantec uses the following methods of vetting a domain name, with option 1 being the primary method:
1. Confirm the Applicant as the Domain Name Registrant directly with the Domain Name Registrar by performing a whois look up.
2. Communicate directly with the Domain Name Registrant using an address, email, or telephone number provided by the Domain Name Registrar;
3. Rely upon a Domain Authorization Document;
4. Communicate directly with the Domain Name Registrant using the contact information listed in the WHOIS record's "registrant", "technical", or "administrative" field;
5. Communicate with the Domain's administrator using an email address created by pre-pending 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster' in the local part, followed by the at-sign ("@"), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;
6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN.

* Email certs can be issued for Class 1, 2, and 3 verification levels, for both individuals and organizations.
The absolute minimum verification is for Class 1 individual.
STN-CPS section 3.2.3
Class 1: No identity authentication. Email address validation - Limited confirmation that the certificate subscriber has access to the email address.
Symantec performs a challenge-response type of procedure in which Symantec sends email to the email address to be included in the certificate, containing unpredictable information such as a randomly generated PIN/Password unique to the owner of the email address. The owner of the email address (the subscriber of the certificate) demonstrates control over the email address by using the information within the email, to then proceed with accessing a portal with the unique information sent in the email, to download and install the certificate.
Class 2: Authenticate identity by:
- Manual check performed by the enterprise administrator customer for each subscriber requesting a certificate, "in which the subscriber receives the certificate via an email sent to the address provided during enrollment" or
- Passcode-based authentication where a randomly-generated passcode is delivered out-of-band by the enterprise administrator customer to the subscriber entitled to enroll for the certificate, and the subscriber provides this passcode at enrollment time or
- Comparing information provided by the subscriber to information contained in business records or databases (customer directories such as Active Directory or LDAP.
Class 3: For Class 3 Organizational Email certificates, Symantec verifies that the subscriber owns the base domain using methods 1 or 3 from Section 3.2.2.4, and allows the subscriber to put in the certificate any email address from that verified domain.

EV Policy OIDs: (2 requested)
2.16.840.1.113733.1.7.23.6
2.23.140.1.1

* Test Website: https://ssltest35.ssl.symclab.com/

* CRL URLs:
http://crl.ws.symantec.com/pca3-g4.crl
http://EV256SecureECC-crl.ws.symantec.com/EV256SecureECC.crl

* OCSP URL(s)
http://ocsp.ws.symantec.com
http://EV256SecureECC-ocsp.ws.symantec.com

* Audit: Annual audits are performed by KPMG, according to the WebTrust criteria.
Standard Audit: https://cert.webtrust.org/SealFile?seal=1565&file=pdf
BR Audit: https://cert.webtrust.org/SealFile?seal=1565&file=pdf
EV Audit: https://cert.webtrust.org/SealFile?seal=1565&file=pdf

*Potentially Problematic Practices:
(http://wiki.mozilla.org/CA:Problematic_Practices)
** Delegation of Domain / Email validation to third parties - CPS section 1.3.2: Third parties, who enter into a contractual relationship with Symantec, may operate their own RA and authorize the issuance of certificates by a STN CA. Third party RAs must abide by all the requirements of the STN CP, the STN CPS and the terms of their enterprise services agreement with Symantec. RAs may, however implement more restrictive practices based on their internal requirements.
RAs who perform domain validation functions are covered as part of Symantec's WebTrust audits.
** Allowing external entities to operate subordinate CAs -- CPS section 1.3.1: Symantec enterprise customers may operate their own CAs as subordinate CAs to a public STN PCA. Such a customer enters into a contractual relationship with Symantec to abide by all the requirements of the STN CP and the STN CPS. These subordinate CAs may, however implement a more restrictive practices based on their internal requirements.

This begins the discussion of this request from Symantec is to enable EV treatment for the "VeriSign Class 3 Public Primary Certification Authority - G4" root certificate. 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.

Kathleen

[Nick Lamb]

Some more thoughts (my previous substantive comments are awaiting moderation because I foolishly sent them before subscribing)

1. Historically other CAs in this family have issued certificates which abuse wildcards, like this:

https://crt.sh/?id=16640133&opt=cablint

Over the several years this request has been floating, no-one from Symantec / Verisign mentioned these violations. Can we expect the same from the root which is to be granted EV in this request? Or has Symantec since put in place an effective control against this sort of wildcard abuse? If so, when?

Presumably it is only a coincidence that KPMG are both Symantec's auditors and that they receive such non-conformant wildcard certificates only from Symantec even though they deal with several other CAs?

2. After changes negotiated in the Bugzilla ticket, the CA Hierarchy information currently reads: "S/MIME certs may also be issued in this CA hierarchy."

Compared to the situation for SSL and Code Signing where internally operated SubCAs are specified, this is very vague. Why? What technical controls are in place to ensure that systems which issue S/MIME certs "in this CA hierarchy" are not capable of issuing an SSL server certificate ?

[tiala...@gmail.com]

On Thursday, 14 April 2016 00:12:49 UTC+1, Kathleen Wilson wrote:
> Request to enable EV for VeriSign Class 3 G4 ECC root

> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8734043

Topic as I understand it is enabling EV treatment for https://crt.sh/?caid=1386 - anyone please step in if I have not correctly diagnosed the topic.

Kathleen's summary links https://bugzilla.mozilla.org/show_bug.cgi?id=1019864 as the list of publicly disclosed and audited SubCAs for this CA.

The last change to that ticket is almost two years ago, Kathleen is this an oversight and actually Symantec are continuing to disclose SubCAs to Mozilla via another route? If so please link that information instead of/ as well as the 2014 Bugzilla ticket.

I also can't see any information here about revoked SubCAs for this CA. Again it's possible either that this is an oversight or that there simply haven't been any revocations under this root (or that any revocations took place before Mozilla's policy changed a few years back to require they be explicitly disclosed rather than quietly added to a CRL) but this should be explicit.

[Ryan Sleevi]

On Tuesday, April 19, 2016 at 10:15:16 AM UTC-7, Nick Lamb wrote:
> Some more thoughts (my previous substantive comments are awaiting moderation because I foolishly sent them before subscribing)
>
> 1. Historically other CAs in this family have issued certificates which abuse wildcards, like this:
>
> https://crt.sh/?id=16640133&opt=cablint
>
> Over the several years this request has been floating, no-one from Symantec / Verisign mentioned these violations. Can we expect the same from the root which is to be granted EV in this request? Or has Symantec since put in place an effective control against this sort of wildcard abuse? If so, when?

[Not a Symantec representative, just a party who has argued such certificates violate the BRs]

Symantec has, based on discussions in the CA/B Forum, argued that this restriction is ambiguous, and thus chosen to interpret the Baseline Requirements in the most permissive fashion possible, despite many other CAs reading it and taking the strict approach, which is also consistent with the material advice of RFC 6125, and of the practical implementation of Chrome and Firefox (which explicitly prohibit such certificates)

You can see discussion in the thread starting https://cabforum.org/pipermail/public/2016-March/006933.html , including the response from Symantec at https://cabforum.org/pipermail/public/2016-March/006940.html

You can see that Peter Bowen, of Amazon, attempted to clarify the BRs to match what browsers expect, in https://cabforum.org/pipermail/public/2016-March/007051.html . However, this proposed clarification was removed in https://cabforum.org/pipermail/public/2016-April/007170.html (the actual ballot). As Peter noted, this was due to objections on the call - objections raised by Rick Andrews of Symantec. These objections and the discussion were noted in https://cabforum.org/pipermail/public/2016-April/007322.html

The contention here drives from the two mentions of wildcards within the BRs, and Symantec's explanation that they view it as ambiguous.

>From the Definitions (Section 1.6.1 of BRs v1.3.4): "A Certificate containing an asterisk (*) in the left‐most position of any of the Subject Fully‐Qualified Domain Names contained in the Certificate."

Section 3.2.2.6 documents a procedure for what to do if a wildcard appears "in the first label immediately to the left of a registry-controlled or public suffix"

The interpretation Symantec has argued is that the definition of wildcard certificates is "A certificate with a wildcard in the first label" (e.g. permitting this), while the definition that some (but not all) browsers have taken is that a wildcard certificate is in "the left-most position", where position means character.

Further, the Section 7.1.4.2.1 of the BRs uses the term "Wildcard FQDNs", a term not defined in the BRs, and arguably at odds, since an FQDN cannot contain a wildcard (since an FQDN is a valid hostname, and * is not a valid host name). As such, it would seem that Symantec is arguing that "foo-*.whatever.example.com" is definitionly not a wildcard certificate (according to the browsers definition) but is a wildcard FQDN, and such are permitted.

In either event, the only objection to clarifying this ambiguity in the Forum was raised by Symantec, and as such, a ballot to correct this confusion has remained stalled.

[Kurt Roeckx]

On 2016-04-20 15:48, Ryan Sleevi wrote:
> On Tuesday, April 19, 2016 at 10:15:16 AM UTC-7, Nick Lamb wrote:
>> Some more thoughts (my previous substantive comments are awaiting moderation because I foolishly sent them before subscribing)
>>
>> 1. Historically other CAs in this family have issued certificates which abuse wildcards, like this:
>>
>> https://crt.sh/?id=16640133&opt=cablint
>>
>> Over the several years this request has been floating, no-one from Symantec / Verisign mentioned these violations. Can we expect the same from the root which is to be granted EV in this request? Or has Symantec since put in place an effective control against this sort of wildcard abuse? If so, when?
>
> [Not a Symantec representative, just a party who has argued such certificates violate the BRs]
>
> Symantec has, based on discussions in the CA/B Forum, argued that this restriction is ambiguous, and thus chosen to interpret the Baseline Requirements in the most permissive fashion possible, despite many other CAs reading it and taking the strict approach, which is also consistent with the material advice of RFC 6125, and of the practical implementation of Chrome and Firefox (which explicitly prohibit such certificates)

RFC 6125 has:
6.4.3. Checking of Wildcard Certificates
[...]

3. The client MAY match a presented identifier in which the wildcard
character is not the only character of the label (e.g.,
baz*.example.net and *baz.example.net and b*z.example.net would
be taken to match baz1.example.net and foobaz.example.net and
buzz.example.net, respectively). However, the client SHOULD NOT
attempt to match a presented identifier where the wildcard
character is embedded within an A-label or U-label [IDNA-DEFS] of
an internationalized domain name [IDNA-PROTO].


So the RFC seems to allow it to me, but a client can obviously decide
not to do it.


Kurt

[Ryan Sleevi]

On Wednesday, April 20, 2016 at 7:16:12 AM UTC-7, Kurt Roeckx wrote:
> So the RFC seems to allow it to me, but a client can obviously decide
> not to do it.

I didn't say it wasn't allowed, merely that it was against the material advice of RFC 6125

https://tools.ietf.org/html/rfc6125#section-7.2

[Charles Reiss]

"Symantec AATL ECC Intermediate CA" is an unconstrained subCA
(https://crt.sh/?caid=13519) of this
root, albeit one with a certificate policy OID that should prohibit it
from receiving EV treatment:
- Why was this subCA not included in the disclosure attached to
https://bugzilla.mozilla.org/show_bug.cgi?id=1019864 ?
- Where and since when was this subCA disclosed in compliance with
Mozilla's policies?
- What CP/CPSes apply to this subCA?
- Presumably this subCA is not meant to be used for TLS server
certificates, so why is it not technically constrained from doing so?

[Matt Palmer]

On Wed, Apr 20, 2016 at 06:48:14AM -0700, Ryan Sleevi wrote:
> In either event, the only objection to clarifying this ambiguity in the
> Forum was raised by Symantec, and as such, a ballot to correct this
> confusion has remained stalled.

It seems fairly dysfunctional if a single member of the CA/B Forum can
prevent a ballot from going ahead.

- Matt

[Ryan Sleevi]

On Wednesday, April 20, 2016 at 5:53:28 PM UTC-7, Matt Palmer wrote:
> It seems fairly dysfunctional if a single member of the CA/B Forum can
> prevent a ballot from going ahead.

To be clear: That is not the same as what I said. No single member can prevent a ballot going forward - but it can be enough to discourage someone from proposing/progressing on a ballot due to not feeling strongly enough.

You can see an original proposal raised on https://cabforum.org/pipermail/public/2016-March/006933.html (which I referred to earlier). There was interested in proposing a ballot, but that interest waned with Symantec's objections.

A clean-up ballot was attempted by Peter Bowen; his goal was to only include non-controversial aspects, so that it would clean up significant portions of ambiguous text. When Symantec raised concerns (thereby making it "controversial"), Peter withdrew that text from his ballot, rather than seeing it go to the full Forum.

So someone can still propose a ballot to address this, and Symantec cannot prevent this (as you suggest); merely, no one has done so, in light of the objections - thus, the discussion has stalled (what I said).

[Rick Andrews]

On Thursday, April 21, 2016 at 3:35:55 AM UTC-7, Ryan Sleevi wrote:
> On Wednesday, April 20, 2016 at 5:53:28 PM UTC-7, Matt Palmer wrote:
> > It seems fairly dysfunctional if a single member of the CA/B Forum can
> > prevent a ballot from going ahead.
>
> To be clear: That is not the same as what I said. No single member can prevent a ballot going forward - but it can be enough to discourage someone from proposing/progressing on a ballot due to not feeling strongly enough.
>
> You can see an original proposal raised on https://cabforum.org/pipermail/public/2016-March/006933.html (which I referred to earlier). There was interested in proposing a ballot, but that interest waned with Symantec's objections.

I wouldn't say I had objections; I merely pointed out that the BRs, as written, prohibit a type of wildcard that Microsoft officially allows in TLS certificates (https://support.microsoft.com/en-us/kb/258858), specifically, w*.example.com and ww*.example.com Ideally, CAs and/or Microsoft would have noticed that long ago and brought it up to be resolved before it was encoded in the BRs. So I admit that we were negligent in not raising the issue sooner, but I won't take full blame for it, because other CAs also issued such certificates and Microsoft could have disclosed the conflict. Microsoft has now expressed their opinion that they need to allow them (https://cabforum.org/pipermail/public/2016-April/007335.html).

[Peter Bowen]

On Thu, Apr 21, 2016 at 9:15 AM, Rick Andrews <rick_a...@symantec.com> wrote:
> On Thursday, April 21, 2016 at 3:35:55 AM UTC-7, Ryan Sleevi wrote:

>> On Wednesday, April 20, 2016 at 5:53:28 PM UTC-7, Matt Palmer wrote:
>> > It seems fairly dysfunctional if a single member of the CA/B Forum can
>> > prevent a ballot from going ahead.
>>
>> To be clear: That is not the same as what I said. No single member can prevent a ballot going forward - but it can be enough to discourage someone from proposing/progressing on a ballot due to not feeling strongly enough.
>>
>> You can see an original proposal raised on https://cabforum.org/pipermail/public/2016-March/006933.html (which I referred to earlier). There was interested in proposing a ballot, but that interest waned with Symantec's objections.
>

> I wouldn't say I had objections; I merely pointed out that the BRs, as written, prohibit a type of wildcard that Microsoft officially allows in TLS certificates (https://support.microsoft.com/en-us/kb/258858), specifically, w*.example.com and ww*.example.com Ideally, CAs and/or Microsoft would have noticed that long ago and brought it up to be resolved before it was encoded in the BRs. So I admit that we were negligent in not raising the issue sooner, but I won't take full blame for it, because other CAs also issued such certificates and Microsoft could have disclosed the conflict. Microsoft has now expressed their opinion that they need to allow them (https://cabforum.org/pipermail/public/2016-April/007335.html).

In the context of Mozilla, I don't think there is anything more
specific than the BRs on wildcards. Given that it is clear that the
current text can be interpreted in multiple ways, don't think that the
cited certificate(s) should be at issue for enabling EV for this CA.

Thanks,
Peter

[Rick Andrews]

Apologies; I mixed up two discussions. Microsoft hasn't yet expressed their opinion in favor of this. Please ignore that last link.

[Nick Lamb]

On Thursday, 21 April 2016 17:15:43 UTC+1, Rick Andrews wrote:
Microsoft has now expressed their opinion that they need to allow them (https://cabforum.org/pipermail/public/2016-April/007335.html).

Did you mean to put another link there? That link is Jody writing about the hack of shoving IP addresses into DNS SANs because older Windows versions didn't grok IP address SANs. If Jody has written proclaiming that Microsoft (or its customers) "need" for everybody to allow these wildcards then I haven't seen it, and would appreciate a link.

"Other CAs also issued such certificates" is a bit vague. Other CAs also issued certificates for "webmail" and "10.0.0.1" but they stopped, because the BRs prohibit those abuses. Or if you've got evidence that they haven't stopped I'm sure m.d.s.policy is a good place to mention that in a new thread.

When _did_ another CA last issue one of these KB 258858 style wildcard certificates? A bit of ferreting around finds me a StartCom certificate from 2014, and a GoDaddy cert from 2009. These are ancient history in SSL terms.

I did stumble onto horrors like https://crt.sh/?id=8066242 and https://crt.sh/?id=11547944 but mostly my searching for such shenanigans found me hilarious malware certs with CN=*.* reminding us why nobody legitimate would ever want to issue such things. Very thin gruel when it comes to current, unexpired, unrevoked certificates except for several issued to KPMG (Symantec's auditors) by Symantec.

[Rick Andrews]

Symantec AATL ECC Intermediate CA was never intended for issuing SSL/TLS certificates. It has never been used and will not be used in the future for SSL/TLS. As such, it hasn't been disclosed to date. We are planning to revoke the Symantec AATL ECC Intermediate CA and provide it along with the "Revoked" list of ICAs to Mozilla in the coming month.

[Nick Lamb]

On Friday, 22 April 2016 01:00:42 UTC+1, Rick Andrews wrote:
> Symantec AATL ECC Intermediate CA was never intended for issuing SSL/TLS certificates. It has never been used and will not be used in the future for SSL/TLS. As such, it hasn't been disclosed to date. We are planning to revoke the Symantec AATL ECC Intermediate CA and provide it along with the "Revoked" list of ICAs to Mozilla in the coming month.

Mozilla's policy doesn't ask you to decide what you "intend" to use an intermediate for, it tells you to make a very simple binary decision, either the intermediate must be technically constrained according to Mozilla's rules or it must be publicly disclosed AND included in your audits. So far as I can see you chose "Neither" which is non-compliant.

In 2014 Mozilla's periodic communication to CAs included an entire section asking CAs to confirm that they had read and obeyed these rules about SubCAs from its policy. Symantec picked option A, confirming that they had read and obeyed all the rules. Did you write that answer? Why?

[Richard Barnes]

On Thu, Apr 21, 2016 at 8:00 PM, Rick Andrews <rick_a...@symantec.com>
wrote:

> On Wednesday, April 20, 2016 at 12:47:58 PM UTC-7, Charles Reiss wrote:

> Symantec AATL ECC Intermediate CA was never intended for issuing SSL/TLS
> certificates. It has never been used and will not be used in the future for
> SSL/TLS. As such, it hasn't been disclosed to date.

That is not the criterion, Rick. The criterion is "capable of being used
to issue new certificates":

"""
All certificates that are capable of being used to issue new certificates,
and which directly or transitively chain to a certificate included in
Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s
CA Certificate Policy
<https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/>
and MUST either be *technically constrained* or be *publicly disclosed and
audited.*
"""

So until that CA is constrained, disclosed+audited, or revoked, the G4 root
is out of compliance with Mozilla's policy. If you have any more of these
around, please make sure include them in your upcoming disclosures.

--Richard

> We are planning to revoke the Symantec AATL ECC Intermediate CA and
> provide it along with the "Revoked" list of ICAs to Mozilla in the coming
> month.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Rick Andrews]

On Friday, April 22, 2016 at 6:41:46 AM UTC-7, Richard Barnes wrote:
> That is not the criterion, Rick. The criterion is "capable of being used
> to issue new certificates":
>
> """
> All certificates that are capable of being used to issue new certificates,
> and which directly or transitively chain to a certificate included in
> Mozilla's CA Certificate Program, MUST be operated in accordance with Mozilla's
> CA Certificate Policy
> <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/>
> and MUST either be *technically constrained* or be *publicly disclosed and
> audited.*
> """
>
> So until that CA is constrained, disclosed+audited, or revoked, the G4 root
> is out of compliance with Mozilla's policy. If you have any more of these
> around, please make sure include them in your upcoming disclosures.
>
> --Richard
>
>
>
> > We are planning to revoke the Symantec AATL ECC Intermediate CA and
> > provide it along with the "Revoked" list of ICAs to Mozilla in the coming
> > month.
> > _______________________________________________
> > dev-security-policy mailing list
> >

It was an oversight. We'll disclose it in SalesForce today.

[sanja...@symantec.com]

We will provide an update on the technical control question you have.

[sanja...@symantec.com]

We have a technical control in place for systems that issue S/MIME certs in this CA hierarchy. Our systems use static cert templates from which end-entity certs are issued. Those templates include an EKU value, but do not use the serverAuth or anyExtendedKeyUsage values.

[Andrew Ayer]

What hash algorithm is used to sign these end-entity certificates? As
I've explained before, a chosen-prefix attack can be used to turn any
bit of signed data (such as an S/MIME certificate, or even an OCSP
response) into a certificate with a serverAuth EKU value.

This is why the EKU needs to be in the CA certificate and not just the
end-entity cert, and why it's essential that sub-CAs like this one be
disclosed. Mozilla policy does not and should not provide an exception
for sub-CAs that are capable of certifying serverAuth certificates but
promise not to.

Regards,
Andrew

[Kathleen Wilson]

Here is a summary of this discussion so far about Symantec's request to enable EV treatment for the "VeriSign Class 3 Public Primary Certification Authority - G4" root certificate that was included via bug #409235, and has all three trust bits enabled.

1) The "Symantec AATL ECC Intermediate CA" needs to be revoked and added to OneCRL. The intermediate cert has been added to Salesforce.
I'm assuming we may proceed with this request, as long as the cert is added to OneCRL before EV treatment is actually enabled in a Firefox release.

2) Questions were raised about wildcard certs in regards to the BRs. But it sounds like for now Symantec's use of wildcard certs is not breaking any BRs.
Question for Symantec: Are any of the issued wildcard certs EV?

3) Question raised: What technical controls are in place to ensure that systems which issue S/MIME certs "in this CA hierarchy" are not capable of issuing an SSL server certificate?
Answer from Symantec: We have a technical control in place for systems that issue S/MIME certs in this CA hierarchy. Our systems use static cert templates from which end-entity certs are issued. Those templates include an EKU value, but do not use the serverAuth or anyExtendedKeyUsage values.

4) Intermediate certificates for this root have been loaded into Salesforce, and are available at the following links:
https://wiki.mozilla.org/CA:SubordinateCAcerts
https://mozillacaprogram.secure.force.com/CA/PublicIntermediateCerts?CAOwnerName=Symantec%20/%20VeriSign
Symantec’s revoked intermediate certs have not yet been loaded into Salesforce.
As per https://wiki.mozilla.org/CA:Communications#March_2016_Responses Symantec plans to enter this data by June 30, 2016.

This request is still under discussion, so please continue to provide your input.

Thanks,
Kathleen

[Nick Lamb]

On Wednesday, 18 May 2016 22:58:54 UTC+1, Kathleen Wilson wrote:
> This request is still under discussion, so please continue to provide your input.

Andrew's question remains unanswered as far as I can see. When Symantec's "technical controls" allow issuance of S/MIME certs "in this CA hierarchy", are they SHA-1 signed ?

[Peter Kurrasch]

Hi Kathleen, 

My recommendation is for Mozilla to reject this request from Symantec on the grounds that it is unnecessary. As others have pointed out recently, the chief function of a CA is to certify identity. That certification should be ably met with the regular cert issuance procedures rendering the EV procedures superfluous. That, or perhaps the CA knows of certain weaknesses in the regular identification process that have been remedied for the EV process? Perhaps EV is a way of saying, "No, seriously you guys, this time we really, really identified the cert applicant."

Whatever the case may be, I don't see how turning on EV ‎benefits Mozilla users. If basic identity is sufficiently established for regular certs, and that being the chief function of CA's, what improvement will EV enablement possibly produce?

Thanks.

  Original Message  
From: Kathleen Wilson
Sent: Wednesday, May 18, 2016 4:58 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Request to enable EV for VeriSign Class 3 G4 ECC root

This request is still under discussion, so please continue to provide your input.

Thanks,
Kathleen

[Matt Palmer]

On Thu, May 19, 2016 at 02:26:15PM -0500, Peter Kurrasch wrote:
> My recommendation is for Mozilla to reject this request from Symantec on
> the grounds that it is unnecessary. As others have pointed out recently,
> the chief function of a CA is to certify identity. That certification
> should be ably met with the regular cert issuance procedures rendering the
> EV procedures superfluous. That, or perhaps the CA knows of certain
> weaknesses in the regular identification process that have been remedied
> for the EV process? Perhaps EV is a way of saying, "No, seriously you
> guys, this time we really, really identified the cert applicant."

Huh? There are different degrees of identity verification that can be
undertaken (identity of the server, identity of the applicant), and those
are valid and useful distinctions.

- Matt

[Gervase Markham]

On 19/05/16 20:26, Peter Kurrasch wrote:
> My recommendation is for Mozilla to reject this request from Symantec
> on the grounds that it is unnecessary. As others have pointed out
> recently, the chief function of a CA is to certify identity. That
> certification should be ably met with the regular cert issuance
> procedures rendering the EV procedures superfluous.

You have this the wrong way around. Mozilla's position (de facto, I
guess) is that anything short of EV is not sufficient validation of
identity. Which is why we don't present it in the UI. So yes, an
important function of a CA is to certify identity, and that's precisely
why we have EV.

> That, or perhaps
> the CA knows of certain weaknesses in the regular identification
> process that have been remedied for the EV process? Perhaps EV is a
> way of saying, "No, seriously you guys, this time we really, really
> identified the cert applicant."

You would need to ask individual CAs about the way that they market and
validate their non-EV certificates which purport to contain identity
information. (They usually call this "OV".)

Gerv

[sanja...@symantec.com]

We used SHA1 and SHA2 in signing algorithm to sign end-entity SMIME certificates. SHA2 is the current practice for new end-entity SMIME certificates. We will be stopping SHA1 ICA usage by the end of 2016 for SMIME. We plan to use a new ICA that has a compliant EKU to issue SMIME certificates by the end of 2016.

Thanks,
- Sanjay

[Nick Lamb]

On Tuesday, 24 May 2016 04:29:10 UTC+1, sanja...@symantec.com wrote:
> We used SHA1 and SHA2 in signing algorithm to sign end-entity SMIME certificates. SHA2 is the current practice for new end-entity SMIME certificates. We will be stopping SHA1 ICA usage by the end of 2016 for SMIME. We plan to use a new ICA that has a compliant EKU to issue SMIME certificates by the end of 2016.

Thanks Sanjay. This timetable is relatively good news, I hope you will keep Mozilla informed if it slips. Where Symantec do issue SHA-1 signed S/MIME today, are there measures in place to ensure chosen prefix attacks are harder through some contents of the certificate being unpredictable to the subscriber, particularly random bits in the serial number field?

[sanja...@symantec.com]

Nick,
For SHA-1 signed S/MIME certificates, the serial number is a 128-bit random number, which makes the certificate contents unpredictable.

- Sanjay

[sanja...@symantec.com]

On Wednesday, May 18, 2016 at 2:58:54 PM UTC-7, Kathleen Wilson wrote:
> Here is a summary of this discussion so far about Symantec's request to enable EV treatment for the "VeriSign Class 3 Public Primary Certification Authority - G4" root certificate that was included via bug #409235, and has all three trust bits enabled.
>
> 1) The "Symantec AATL ECC Intermediate CA" needs to be revoked and added to OneCRL. The intermediate cert has been added to Salesforce.
> I'm assuming we may proceed with this request, as long as the cert is added to OneCRL before EV treatment is actually enabled in a Firefox release.

It’s been revoked.

>
> 2) Questions were raised about wildcard certs in regards to the BRs. But it sounds like for now Symantec's use of wildcard certs is not breaking any BRs.
> Question for Symantec: Are any of the issued wildcard certs EV?

No, we’ve have not issued an EV wildcard certificate.

>
> 3) Question raised: What technical controls are in place to ensure that systems which issue S/MIME certs "in this CA hierarchy" are not capable of issuing an SSL server certificate?
> Answer from Symantec: We have a technical control in place for systems that issue S/MIME certs in this CA hierarchy. Our systems use static cert templates from which end-entity certs are issued. Those templates include an EKU value, but do not use the serverAuth or anyExtendedKeyUsage values.
>
> 4) Intermediate certificates for this root have been loaded into Salesforce, and are available at the following links:
> https://wiki.mozilla.org/CA:SubordinateCAcerts
> https://mozillacaprogram.secure.force.com/CA/PublicIntermediateCerts?CAOwnerName=Symantec%20/%20VeriSign
> Symantec’s revoked intermediate certs have not yet been loaded into Salesforce.
> As per https://wiki.mozilla.org/CA:Communications#March_2016_Responses Symantec plans to enter this data by June 30, 2016.

Yes, the revoked intermediates have been added to Salesforce.

[Andrew Ayer]

On Wed, 29 Jun 2016 11:46:14 -0700 (PDT)
sanja...@symantec.com wrote:

> On Wednesday, May 18, 2016 at 2:58:54 PM UTC-7, Kathleen Wilson wrote:

> > Here is a summary of this discussion so far about Symantec's
> > request to enable EV treatment for the "VeriSign Class 3 Public
> > Primary Certification Authority - G4" root certificate that was
> > included via bug #409235, and has all three trust bits enabled.
> >
> > 1) The "Symantec AATL ECC Intermediate CA" needs to be revoked and
> > added to OneCRL. The intermediate cert has been added to
> > Salesforce. I'm assuming we may proceed with this request, as long
> > as the cert is added to OneCRL before EV treatment is actually
> > enabled in a Firefox release.
>

> It’s been revoked.

Hi Kathleen,

Could this cert be added to OneCRL? Here is its crt.sh entry:
https://crt.sh/?id=12722025

Thanks,
Andrew

P.S. Cheers to Rob Stradling for integrating OneCRL with crt.sh!

[Kathleen Wilson]

Bugzilla Bug filed to add this cert to OneCRL:
https://bugzilla.mozilla.org/show_bug.cgi?id=1287592

Thanks,
Kathleen

[Kathleen Wilson]

On 5/18/16 2:51 PM, Kathleen Wilson wrote:
> Here is a summary of this discussion so far about Symantec's request to enable EV treatment for the "VeriSign Class 3 Public Primary Certification Authority - G4" root certificate that was included via bug #409235, and has all three trust bits enabled.
>
> 1) The "Symantec AATL ECC Intermediate CA" needs to be revoked and added to OneCRL. The intermediate cert has been added to Salesforce.
> I'm assuming we may proceed with this request, as long as the cert is added to OneCRL before EV treatment is actually enabled in a Firefox release.

It’s been revoked.
https://bugzilla.mozilla.org/show_bug.cgi?id=1287592

> 2) Questions were raised about wildcard certs in regards to the BRs. But it sounds like for now Symantec's use of wildcard certs is not breaking any BRs.
> Question for Symantec: Are any of the issued wildcard certs EV?

Symantec responded to say that they have not issued EV wildcard certs.'

> 3) Question raised: What technical controls are in place to ensure that systems which issue S/MIME certs "in this CA hierarchy" are not capable of issuing an SSL server certificate?
> Answer from Symantec: We have a technical control in place for systems that issue S/MIME certs in this CA hierarchy. Our systems use static cert templates from which end-entity certs are issued. Those templates include an EKU value, but do not use the serverAuth or anyExtendedKeyUsage values.

Symantec's further responses: We will be stopping SHA1 ICA usage by the

end of 2016 for SMIME. We plan to use a new ICA that has a compliant EKU
to issue SMIME certificates by the end of 2016.

For SHA-1 signed S/MIME certificates, the serial number is a 128-bit
random number, which makes the certificate contents unpredictable.

> 4) Intermediate certificates for this root have been loaded into Salesforce, and are available at the following links:
> https://wiki.mozilla.org/CA:SubordinateCAcerts

and
https://wiki.mozilla.org/CA:RevokedSubCAcerts

I believe that all of the questions/concerns raised during this
discussion have been resolved. So I am about ready to wrap up this
discussion and recommend approval of this request.

However, I am not finding the current WTBR audit statement for this root
certificate. I am finding the other Symantec audit statements in the
"Roots & Audit Reports" tab of
https://www.symantec.com/about/legal/repository.jsp
And I have exchanged email with the auditor to confirm the authenticity
of the audit statements.

Sanjay, Please let me know which of the audit statements on the website
contain the WTBR audit statement covering this root certificate.

Thanks,
Kathleen

[Kathleen Wilson]

On 7/20/16 9:17 AM, Steve Medin wrote:
>
> The WT/BR audit covering this root is at
>https://www.symantec.com/content/en/us/about/media/repository/Symantec-Thawte-WTBR-2015.pdf.


Thanks Steve. I see it now.


All,

Thanks again to all of you who participated in this discussion about

Symantec's request to enable EV treatment for the "VeriSign Class 3

Public Primary Certification Authority - G4" root certificate.

I am not aware of any issues that would prevent us from moving forward
with this request. Therefore, I will recommend approval in the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=833974

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen