Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[Kathleen Wilson]

On 7/17/16 7:16 PM, Andrew Ayer wrote:

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


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

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!




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

Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[sanjay_modi]

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. 

> 
> This request is still under discussion, so please continue to provide your 
> input.
> 
> Thanks,
> Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[sanjay_modi]

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

- Sanjay
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[sanjay_modi]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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-security-pol...@lists.mozilla.org
Subject: Re: Request to enable EV for VeriSign Class 3 G4 ECC root

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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[Andrew Ayer]

On Wed, 27 Apr 2016 23:46:25 -0700 (PDT)
sanjay_m...@symantec.com wrote:

> 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.

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[sanjay_modi]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[sanjay_modi]

We will provide an update on the technical control question you have.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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
> 
> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[Richard Barnes]

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

> On Wednesday, April 20, 2016 at 12:47:58 PM UTC-7, Charles Reiss wrote:
> > On 04/13/16 23:12, Kathleen Wilson wrote:
> > > 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.
> >
> > "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?
>
> 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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[Rick Andrews]

On Wednesday, April 20, 2016 at 12:47:58 PM UTC-7, Charles Reiss wrote:
> On 04/13/16 23:12, Kathleen Wilson wrote:
> > 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.
> 
> "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?

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[Rick Andrews]

On Thursday, April 21, 2016 at 9:15:43 AM UTC-7, Rick Andrews 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).

Apologies; I mixed up two discussions. Microsoft hasn't yet expressed their 
opinion in favor of this. Please ignore that last link.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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).

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[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=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 ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[tialaramex]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy