RE: Symantec Update on SubCA Proposal

[Jeremy Rowley via dev-security-policy]

Hi Jakob, 

Your below description raises two questions of general interest (though not of 
interest to the Mozilla root program):

1. Will DigiCert establish cross-signatures from the old/historic
   Symantec roots to continuing DigiCert roots and subCAs?

[JR]  We won’t be cross-signing from DigiCert to Symantec.  For cross-signs the 
other way, we plan on supporting the community’s needs and would love to hear 
more online and offline about what cross-signs to DigiCert are needed for 
compatibility and interoperability. Mozilla proposed distrusting Symantec’s 
roots in 2018 so we’ll work towards that goal. Once it’s removed, the one-way 
trust from Symantec to DigiCert will fall out of scope.  Prior to that, the 
cross-sign will be operated per the BRs and subject to the Google and Mozilla 
proposals.

2. Will DigiCert continue those Symantec services that were not trusted
   by Mozilla/Google and which have no functional alternative elsewhere.

This includes a number of situations where Microsoft and other
   companies are enforcing that things are signed exclusively by specific
   Symantec issuance systems.  Known examples include: The original SHA-1
   time stamping service for code signing (needed for compatibility with
   older Windows and Internet Explorer versions).  The special signing
   portal for Windows Mobile (the original product line, not the new
   renamed Windows 10 Phone product line).  The "hosted" signing service
   for Android Apps.  Possibly any remnants of the Geotrust-based
   services for the old Nokia platforms (Symbian S60 etc.). Etc.

[JR] As you mentioned, none of these are trusted by Mozilla or Google so that 
discussion is better held elsewhere.  However, I can say that we plan to 
support Symantec communities to the extent possible.  The only planned 
deprecation is the Symantec publicly-trusted Web PKI.  

Jeremy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Update on SubCA Proposal

[Jakob Bohm via dev-security-policy]

Your below description raises two questions of general interest (though
not of interest to the Mozilla root program):

1. Will DigiCert establish cross-signatures from the old/historic
  Symantec roots to continuing DigiCert roots and subCAs?

2. Will DigiCert continue those Symantec services that were not trusted
  by Mozilla/Google and which have no functional alternative elsewhere.

   This includes a number of situations where Microsoft and other
  companies are enforcing that things are signed exclusively by specific
  Symantec issuance systems.  Known examples include: The original SHA-1
  time stamping service for code signing (needed for compatibility with
  older Windows and Internet Explorer versions).  The special signing
  portal for Windows Mobile (the original product line, not the new
  renamed Windows 10 Phone product line).  The "hosted" signing service
  for Android Apps.  Possibly any remnants of the Geotrust-based
  services for the old Nokia platforms (Symbian S60 etc.). Etc.


NOTICE TO SOME READERS: Please read the first paragraph of this mail!

On 14/08/2017 06:03, Jeremy Rowley wrote:

Hi wizard,

Although DigiCert will acquire the assets related to Symantec’s CA business, 
DigiCert is not required to use those assets in its business operations.  We 
are organizing the operations of DigiCert to meet the requirements established 
in the Managed CA proposal. This includes having all validation and issuance 
performed through DigiCert’s existing PKI and using DigiCert processes 
accompanied by DigiCert leadership.

Our interpretation of the Google and Mozilla requirements is similar to yours – 
that the goal is to migrate from Symantec’s existing PKI to a third party while 
implementing systematic and operational controls over the issuing and 
validation processes.  Post close, we plan to continue towards these objectives 
using the path adopted by the browsers in the Managed CA process. This path 
includes regular audits during the transition, a migration away from Symantec’s 
issuing and validation systems, and implementation of operational controls to 
prevent mis-issuance.  Our plan is to transition completely away from the 
Symantec issuance platform and validation processes by December 1 and work 
towards the distrust dates set by Mozilla for the end of 2018.

The Managed CA requirements seemed designed to (1) give Symantec time to 
reengineer processes and systems and (2) work towards rebuilding trust in the 
Symantec’s operations.  The acquisition eliminates the need to reengineer the 
process and makes the question of restoring trust moot.  With only DigiCert 
performing the validation and operating the CA, the risks identified to be 
fixed by the Managed CA proposal are remediated as of closing.

Of course, we’re always open to feedback and additional ideas on how to build 
community trust.  Feel free to message us or submit follow-up questions and 
ideas about how we can answer the community’s concerns.


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of wizard--- via dev-security-policy
Sent: Friday, August 11, 2017 9:12 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec Update on SubCA Proposal

Steve,

Thank you for responding relatively promptly (at least as compared to previous 
Symantec responses) to Devon's questions.

However, these responses seem to imply that a side effect of the sale *is* to 
skirt the remediation requirements imposed by Google and Mozilla.

In particular, the agreed upon plan requires issuance (and information 
verification) by a managed SubCA that does *not* involve Symantec processes, 
equipment, personnel, etc., until trust in those equipment, people, and 
processes is established.

if Digicert were *not* acquiring any of the equipment/personnel/processes from 
Symantec, only the customers, this would seem to meet the spirit and letter of 
the Symantec remediation plan.

However, the publicly announced details of the acquisition [Devon ref. 2] 
explicitly state that equipment and personnel will be transferred from Symantec 
to Digicert. Combined with the answers below, this means that as soon as the 
deal closes and this transfer occurs, there is no barrier to the 
formerly-Symantec-but-now-Digicert equipment and personnel from immediately 
assisting in the issuance of new certificates (presumably under the Digicert 
roots). This seems to go against the spirit (and possibly letter) of the 
remediation plan, which was designed to prevent the bad practices within the 
existing Symantec CA organization from being involved in further issuances 
until a level of trust could be demonstrated.

Perhaps you or Digicert could clarify why you believe the above to not be the 
case.

Thank you.

On Friday, August 11, 2017 at 8:32:33 PM UTC-4, Steve Medin wrote:

-Original Message-
From: dev-security-policy [

RE: Symantec Update on SubCA Proposal

[Jeremy Rowley via dev-security-policy]

Hi wizard,

Although DigiCert will acquire the assets related to Symantec’s CA business, 
DigiCert is not required to use those assets in its business operations.  We 
are organizing the operations of DigiCert to meet the requirements established 
in the Managed CA proposal. This includes having all validation and issuance 
performed through DigiCert’s existing PKI and using DigiCert processes 
accompanied by DigiCert leadership.  

Our interpretation of the Google and Mozilla requirements is similar to yours – 
that the goal is to migrate from Symantec’s existing PKI to a third party while 
implementing systematic and operational controls over the issuing and 
validation processes.  Post close, we plan to continue towards these objectives 
using the path adopted by the browsers in the Managed CA process. This path 
includes regular audits during the transition, a migration away from Symantec’s 
issuing and validation systems, and implementation of operational controls to 
prevent mis-issuance.  Our plan is to transition completely away from the 
Symantec issuance platform and validation processes by December 1 and work 
towards the distrust dates set by Mozilla for the end of 2018.  

The Managed CA requirements seemed designed to (1) give Symantec time to 
reengineer processes and systems and (2) work towards rebuilding trust in the 
Symantec’s operations.  The acquisition eliminates the need to reengineer the 
process and makes the question of restoring trust moot.  With only DigiCert 
performing the validation and operating the CA, the risks identified to be 
fixed by the Managed CA proposal are remediated as of closing.

Of course, we’re always open to feedback and additional ideas on how to build 
community trust.  Feel free to message us or submit follow-up questions and 
ideas about how we can answer the community’s concerns. 

Thanks!

Jeremy



-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of wizard--- via dev-security-policy
Sent: Friday, August 11, 2017 9:12 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Symantec Update on SubCA Proposal

Steve,

Thank you for responding relatively promptly (at least as compared to previous 
Symantec responses) to Devon's questions.

However, these responses seem to imply that a side effect of the sale *is* to 
skirt the remediation requirements imposed by Google and Mozilla. 

In particular, the agreed upon plan requires issuance (and information 
verification) by a managed SubCA that does *not* involve Symantec processes, 
equipment, personnel, etc., until trust in those equipment, people, and 
processes is established.

if Digicert were *not* acquiring any of the equipment/personnel/processes from 
Symantec, only the customers, this would seem to meet the spirit and letter of 
the Symantec remediation plan. 

However, the publicly announced details of the acquisition [Devon ref. 2] 
explicitly state that equipment and personnel will be transferred from Symantec 
to Digicert. Combined with the answers below, this means that as soon as the 
deal closes and this transfer occurs, there is no barrier to the 
formerly-Symantec-but-now-Digicert equipment and personnel from immediately 
assisting in the issuance of new certificates (presumably under the Digicert 
roots). This seems to go against the spirit (and possibly letter) of the 
remediation plan, which was designed to prevent the bad practices within the 
existing Symantec CA organization from being involved in further issuances 
until a level of trust could be demonstrated. 

Perhaps you or Digicert could clarify why you believe the above to not be the 
case.

Thank you.

On Friday, August 11, 2017 at 8:32:33 PM UTC-4, Steve Medin wrote:
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Devon O'Brien via dev-security-policy
> > Sent: Wednesday, August 09, 2017 12:24 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Re: Symantec Update on SubCA Proposal
> >
> > Hello m.d.s.p.,
> >
> > I'd just like to give the community a heads up that Chrome’s plan 
> > remains to put up a blog post echoing our recent announcement on 
> > blink-dev [1], but in the meantime, we are reviewing the facts 
> > related to Symantec’s sale of their PKI business to DigiCert [2].
> >
> > Recently, it has come to our attention that Symantec may have 
> > selected DigiCert from the RFP process to become a Managed CA 
> > Partner. As defined in Google’s first Managed CA proposal [3], then 
> > supported by Symantec’s commitment to “[cover] all aspects of the 
> > SubCA proposal” [4], and finally reiterated in Google’s final 
> > proposal [1], the requireme

Re: Symantec Update on SubCA Proposal

[Nick Lamb via dev-security-policy]

One good thing we should be able to hope for from a change in ownership even if 
the personnel and equipment are the same or a great deal in common: improved 
management oversight. In my view the most worrying underlying problem at 
Symantec was the inadequate oversight. Senior management at the corporation 
just can't have been giving this the attention it needs. The sale takes them 
out of the picture. That's not a great story for Symantec's shareholders, who 
might reasonably assume that similarly inadequate oversight will continue for 
the other activities of the business - but it's good news for the Relying 
Parties.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Update on SubCA Proposal

[wizard--- via dev-security-policy]

Steve,

Thank you for responding relatively promptly (at least as compared to previous 
Symantec responses) to Devon's questions.

However, these responses seem to imply that a side effect of the sale *is* to 
skirt the remediation requirements imposed by Google and Mozilla. 

In particular, the agreed upon plan requires issuance (and information 
verification) by a managed SubCA that does *not* involve Symantec processes, 
equipment, personnel, etc., until trust in those equipment, people, and 
processes is established.

if Digicert were *not* acquiring any of the equipment/personnel/processes from 
Symantec, only the customers, this would seem to meet the spirit and letter of 
the Symantec remediation plan. 

However, the publicly announced details of the acquisition [Devon ref. 2] 
explicitly state that equipment and personnel will be transferred from Symantec 
to Digicert. Combined with the answers below, this means that as soon as the 
deal closes and this transfer occurs, there is no barrier to the 
formerly-Symantec-but-now-Digicert equipment and personnel from immediately 
assisting in the issuance of new certificates (presumably under the Digicert 
roots). This seems to go against the spirit (and possibly letter) of the 
remediation plan, which was designed to prevent the bad practices within the 
existing Symantec CA organization from being involved in further issuances 
until a level of trust could be demonstrated. 

Perhaps you or Digicert could clarify why you believe the above to not be the 
case.

Thank you.

On Friday, August 11, 2017 at 8:32:33 PM UTC-4, Steve Medin wrote:
> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Devon O'Brien via dev-security-policy
> > Sent: Wednesday, August 09, 2017 12:24 PM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Re: Symantec Update on SubCA Proposal
> >
> > Hello m.d.s.p.,
> >
> > I'd just like to give the community a heads up that Chrome’s plan remains to
> > put up a blog post echoing our recent announcement on blink-dev [1], but
> > in the meantime, we are reviewing the facts related to Symantec’s sale of
> > their PKI business to DigiCert [2].
> >
> > Recently, it has come to our attention that Symantec may have selected
> > DigiCert from the RFP process to become a Managed CA Partner. As defined
> > in Google’s first Managed CA proposal [3], then supported by Symantec’s
> > commitment to “[cover] all aspects of the SubCA proposal” [4], and finally
> > reiterated in Google’s final proposal [1], the requirement has always been
> > that the Managed Partner Infrastructure be operated by an independent
> > and non-affiliated CA while Symantec worked to rebuild the web
> > community's confidence.
> >
> > Based on this information, we have a series of questions that we’d like
> > Symantec to address for public discussion:
> >
> > 1. Just to confirm, Did Symantec select DigiCert to be Managed CA Partner
> > under the RFP process? If so, in light of DigiCert’s acquisition of 
> > Symantec’s
> > PKI business and Symantec’s substantial equity investment in DigiCert, can
> > you explain how you believe selecting DigiCert as the Managed CA Partner
> > meets the stated requirement of being an independent and non-affiliated
> > organization?
> >
> 
> Before we initiated our SubCA RFP process in May, Google provided Symantec 
> with a list of Certificate Authorities, including DigiCert, which met the 
> eligibility requirements of a Managed CA under the SubCA proposal.   Symantec 
> conducted a thorough SubCA RFP process and believes DigiCert can credibly 
> meet browser requirements and timelines.
> 
> Symantec decided it was in the best interests of all of its stakeholders to 
> sell its Website Security and related PKI solutions to DigiCert. To ensure 
> business continuity for customers, Symantec entered into a SubCA arrangement 
> with DigiCert simultaneous with entry into the definitive acquisition 
> agreement to account for the possibility that the acquisition may not close 
> by December 1, 2017.
> 
> Regardless of whether the acquisition closes before December 1, 2017 or not, 
> there is never a circumstance under which DigiCert will be an 'affiliate' of 
> Symantec with respect to acting as Symantec's Managed CA under the SubCA 
> proposal.  Symantec currently has no ownership interest in or ability 
> (contractual or otherwise) to control the operations of DigiCert, nor does 
> either party otherwise constitute an 'affiliate' of the other, as such term 
> is defined in the CA-Browser Forum Baseline Requirements (v 1.4.9).
> 
> At the clos

Re: Symantec Update on SubCA Proposal

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Devon O'Brien via dev-security-policy
> Sent: Wednesday, August 09, 2017 12:24 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Re: Symantec Update on SubCA Proposal
>
> Hello m.d.s.p.,
>
> I'd just like to give the community a heads up that Chrome’s plan remains to
> put up a blog post echoing our recent announcement on blink-dev [1], but
> in the meantime, we are reviewing the facts related to Symantec’s sale of
> their PKI business to DigiCert [2].
>
> Recently, it has come to our attention that Symantec may have selected
> DigiCert from the RFP process to become a Managed CA Partner. As defined
> in Google’s first Managed CA proposal [3], then supported by Symantec’s
> commitment to “[cover] all aspects of the SubCA proposal” [4], and finally
> reiterated in Google’s final proposal [1], the requirement has always been
> that the Managed Partner Infrastructure be operated by an independent
> and non-affiliated CA while Symantec worked to rebuild the web
> community's confidence.
>
> Based on this information, we have a series of questions that we’d like
> Symantec to address for public discussion:
>
> 1. Just to confirm, Did Symantec select DigiCert to be Managed CA Partner
> under the RFP process? If so, in light of DigiCert’s acquisition of Symantec’s
> PKI business and Symantec’s substantial equity investment in DigiCert, can
> you explain how you believe selecting DigiCert as the Managed CA Partner
> meets the stated requirement of being an independent and non-affiliated
> organization?
>

Before we initiated our SubCA RFP process in May, Google provided Symantec with 
a list of Certificate Authorities, including DigiCert, which met the 
eligibility requirements of a Managed CA under the SubCA proposal.   Symantec 
conducted a thorough SubCA RFP process and believes DigiCert can credibly meet 
browser requirements and timelines.

Symantec decided it was in the best interests of all of its stakeholders to 
sell its Website Security and related PKI solutions to DigiCert. To ensure 
business continuity for customers, Symantec entered into a SubCA arrangement 
with DigiCert simultaneous with entry into the definitive acquisition agreement 
to account for the possibility that the acquisition may not close by December 
1, 2017.

Regardless of whether the acquisition closes before December 1, 2017 or not, 
there is never a circumstance under which DigiCert will be an 'affiliate' of 
Symantec with respect to acting as Symantec's Managed CA under the SubCA 
proposal.  Symantec currently has no ownership interest in or ability 
(contractual or otherwise) to control the operations of DigiCert, nor does 
either party otherwise constitute an 'affiliate' of the other, as such term is 
defined in the CA-Browser Forum Baseline Requirements (v 1.4.9).

At the closing of the acquisition, Symantec is being paid in both cash and 
stock, with the latter comprising a 30% ownership interest in the common equity 
of DigiCert, which allows for Symantec stockholders to benefit from the 
potential value created by the DigiCert business after the closing. This 
minority ownership position, which shall not be received by Symantec until the 
closing of the acquisition, represents a financial investment in DigiCert.  
This financial investment does not give Symantec control over DigiCert's CA 
technology, operations or business, and therefore we believe that it satisfies 
the spirit of the non-affiliate status that the browser community was seeking 
to achieve through the SubCA proposal.

It is Symantec's understanding that all certificates issued by DigiCert on or 
after December 1, 2017 and the closing of the acquisition will chain to 
DigiCert's existing public roots. If the acquisition closes before December 1, 
2017, then no certificates will ever be issued by DigiCert as a Managed CA of 
Symantec because DigiCert will not be issuing certificates under a new ICA that 
chains to a new Symantec PKI.  Rather, in this instance, certificates will 
either (i) be issued off of Symantec’s existing PKI, which is permitted under 
the SubCA proposal until November 30, 2017, or (ii) be issued off of DigiCert’s 
existing PKI.  The actual timing of the acquisition closing relative to the 
parties’ operational integration planning schedule will determine whether 
certificates are issued under both scenarios or just the latter.

If the acquisition does not close before December 1, 2017, then DigiCert has 
agreed to serve as Symantec's Managed CA partner as of December 1, 2017, but 
will not be an 'affiliate' during this pre-closing period for the reasons 
explained above.

> 2. Were any additional CAs selected to be a Managed CA Partner from the
> list of 

Re: Symantec Update on SubCA Proposal

[Devon O'Brien via dev-security-policy]

Hello m.d.s.p.,

I'd just like to give the community a heads up that Chrome’s plan remains to 
put up a blog post echoing our recent announcement on blink-dev [1], but in the 
meantime, we are reviewing the facts related to Symantec’s sale of their PKI 
business to DigiCert [2].

Recently, it has come to our attention that Symantec may have selected DigiCert 
from the RFP process to become a Managed CA Partner. As defined in Google’s 
first Managed CA proposal [3], then supported by Symantec’s commitment to 
“[cover] all aspects of the SubCA proposal” [4], and finally reiterated in 
Google’s final proposal [1], the requirement has always been that the Managed 
Partner Infrastructure be operated by an independent and non-affiliated CA 
while Symantec worked to rebuild the web community's confidence. 

Based on this information, we have a series of questions that we’d like 
Symantec to address for public discussion:

1. Just to confirm, Did Symantec select DigiCert to be Managed CA Partner under 
the RFP process? If so, in light of DigiCert’s acquisition of Symantec’s PKI 
business and Symantec’s substantial equity investment in DigiCert, can you 
explain how you believe selecting DigiCert as the Managed CA Partner meets the 
stated requirement of being an independent and non-affiliated organization? 

2. Were any additional CAs selected to be a Managed CA Partner from the list of 
trusted CAs that Symantec “felt best met the browser requirements”?

[1]https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/El1mH8S6AwAJ
[2]http://investor.symantec.com/About/Investors/press-releases/press-release-details/2017/DigiCert-to-Acquire-Symantecs-Website-Security-and-Related-PKI-Solutions/default.aspx
[3]https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/ovLalSBRBQAJ
[4]https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/6iZUc7kOCAAJ
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Update on SubCA Proposal

[Alex Gaynor via dev-security-policy]

Just to be explicit: your count includes certificates which, with high
probability have already been replaced, because it does not subtract names
for which new certificates have been issued?

I realize it may seem like I'm putting a lot of emphasis on this one
number, but given that it's the basis for your assertion about the relative
difficulty for different distrust dates, I think it's quite significant.
Given that your methodology appears to over-count (to the advantage of
laxer distrust policies!), and cannot be independently verified, it really
boils down to "trust us to do right by the security of the WebPKI". Not to
put too fine a point on it, but we're in this situation because of
Symantec's history of _not_ acting in the interests of the security of the
WebPKI. It seems to me you could improve the transparency of this process
by logging all DV certs from this time frame to CT.

Alex

On Thu, Jul 27, 2017 at 11:53 AM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, July 26, 2017 at 10:20:08 AM UTC-7, Alex Gaynor wrote:
> > On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy
> > wrote:
> >
> > > Symantec has proposed timing changes that are consistent with the
> scope of
> > > distrust of the original SubCA proposal as proposed by Google and
> endorsed
> > > by Mozilla, which requires premature replacement of over 234,000
> > > certificates based on our proposed May 1, 2018 distrust date for
> > > certificates issued before June 1, 2016, and optimizes for replacement
> > > certificates to be issued off the new Managed CA(s) infrastructure
> > > (avoiding the requirement for double early replacement for the same
> > > original validity period). We believe our proposal minimizes
> disruption to
> > > websites and web end-users while meeting the spirit of Google’s and
> > > Mozilla’s prior commentary on their intent regarding the SubCA
> proposal,
> > > which is to limit the issuance of Symantec certificates under
> Symantec’s
> > > existing infrastructure and governance.
> > >
> >
> > Hi Rick,
> >
> > Given the importance of this 234,000 number, I was curious to explore.
> > Using the list of certificates Peter Bowen previously put together (
> > https://groups.google.com/a/chromium.org/d/msg/blink-dev/
> eUAKwjihhBs/aQqYZX6oBgAJ),
> > I ran a small script to filter out ones that expire before May 2018, or
> > were issued after June 2016. Using this methodlogy, I got a count of
> 166k,
> > a deviation of ~70k from your number. My 166k includes any certificates
> > that have been replaced since Peter put together the list in April, so in
> > that sense it likely reflects an over estimate of the number of certs
> > needing to be replaced.
> >
> > Can you say a little more on how you came to this number?
> >
> > Cheers,
> > Alex
>
> Our reference to over 234,000 certificates is based on our internal
> records of all active, unrevoked certificates that we issued prior to June
> 1, 2016 that expire after May 1, 2018. The dataset you reference relies on
> CT logs, which includes all active EV certificates Symantec has issued
> before June 1, 2016, but does not include all active, unrevoked OV and DV
> certificates Symantec has issued before June 1, 2016.
> ___
> 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: Symantec Update on SubCA Proposal

[Jakob Bohm via dev-security-policy]

On 25/07/2017 22:28, Rick Andrews wrote:

...

You are correct in that most customers are indeed not prepared to 
deal with potential crises in the SSL system. We have all witnessed 
this first hand with Heartbleed, the replacement of SHA1

certificates, etc. A four month replacement window for a forced
replacement of this magnitude is unprecedented and we know that
things will break. In the recent CA survey, most major CAs reported
that replacing certificates annually is something that many
organizations are not prepared for – a conclusion that is reinforced
by the recent CA/Browser Forum vote rejecting ballot 185, which
proposed to limit the maximum validity of SSL/TLS certificates
issued by all CAs to 13 months. Do you have data leading you to
believe that this replacement can be executed with limited Internet
ecosystem disruption, particularly amongst the largest enterprises
globally whose certificates would be impacted? If so, we would welcome
seeing that data/rationale. The issues that we have all witnessed
with other forced replacement events on much longer timelines indicate 
that the community is not yet at a place of automation to deal with 
such a transition, especially in a short timeframe. In this case, 
forcing a distrust date of December 1, 2017 (vs. our May 1, 2018 
distrust date recommendation) for certificates issued prior to 
June 1, 2016 increases the total number of premature replacement

certificates that would be need to be issued by approximately 50%
and gives website operators substantially less time (4 months vs.
9 months) in which to plan and execute such a replacement. A 
December 1, 2017 distrust date for certificates issued prior to

June 1, 2016 would introduce a known, actual, material risk to the
Internet ecosystem given the industry’s prior experience with forced
mass replacement episodes. We do not think the perceived benefit of
accelerating distrust for Symantec certificates issued before
June 1, 2016 from May 1, 2018 to December 1, 2017 (5 months of
validity) can possibly justify the significant ecosystem disruption 
that is likely to result from not accepting our proposed May 1, 2018

distrust date for certificates issued before June 1, 2016. We agree
with your public comments on June 19, 2017 that it is not
constructive to get into a date-based "negotiation" over the SubCA
proposal. We have worked backwards from our best estimate for how
long it would take us and our Managed CA partner(s) to implement the
SubCA proposal in a manner that allows for an orderly transition of
Symantec’s existing PKI infrastructure for SSL/TLS certificates to
a Managed CA(s) while minimizing disruption to websites and web
end-users, and have proposed aggressive, yet achievable deadlines
accordingly. As such, while we are willing to go down the SubCA path
overall, we strongly believe that this must be done in a way that
aims to minimize website disruption.



Where exactly was it suggested to distrust certificates issued before
Jun 1, 2016 on December 1, 2017?

So far most of the discussion seems to have been about distrusting
Symantec certs issued after December 1, 2017, at least as I read it.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



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

Re: Symantec Update on SubCA Proposal

[Alex Gaynor via dev-security-policy]

On Tue, Jul 25, 2017 at 4:28 PM, Rick Andrews via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Symantec has proposed timing changes that are consistent with the scope of
> distrust of the original SubCA proposal as proposed by Google and endorsed
> by Mozilla, which requires premature replacement of over 234,000
> certificates based on our proposed May 1, 2018 distrust date for
> certificates issued before June 1, 2016, and optimizes for replacement
> certificates to be issued off the new Managed CA(s) infrastructure
> (avoiding the requirement for double early replacement for the same
> original validity period). We believe our proposal minimizes disruption to
> websites and web end-users while meeting the spirit of Google’s and
> Mozilla’s prior commentary on their intent regarding the SubCA proposal,
> which is to limit the issuance of Symantec certificates under Symantec’s
> existing infrastructure and governance.
>

Hi Rick,

Given the importance of this 234,000 number, I was curious to explore.
Using the list of certificates Peter Bowen previously put together (
https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/aQqYZX6oBgAJ),
I ran a small script to filter out ones that expire before May 2018, or
were issued after June 2016. Using this methodlogy, I got a count of 166k,
a deviation of ~70k from your number. My 166k includes any certificates
that have been replaced since Peter put together the list in April, so in
that sense it likely reflects an over estimate of the number of certs
needing to be replaced.

Can you say a little more on how you came to this number?

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

Re: Symantec Update on SubCA Proposal

[Nick Lamb via dev-security-policy]

On Tuesday, 25 July 2017 21:29:06 UTC+1, Rick Andrews  wrote:
> The details of this process would probably be best served in a separate 
> thread. Essentially, such a process would involve a quick assessment by the 
> community on the context and merits of the request by the customer

You want us to do Symantec's job, for which Symantec will get paid, in order to 
preserve Symantec's ongoing revenue stream despite Symantec screwing up badly 
to get themselves into this mess ?

Counter proposal: When a customer runs into such a remarkable "exception", 
Symantec pays them $5000 or fully refunds their last year of Symantec services, 
whichever is more, and encourages them to go use the money to choose a 
different CA where they might not need "exceptions" all the time. Maybe you can 
get Symantec's lawyers to make acceptance of the $5000 conditional on agreeing 
not to sue once they understand how much trouble Symantec's incompetence has 
caused for them.

> We may be more aligned on this point than your response suggests. We are in 
> agreement with you that we will cease issuing certificates under the existing 
> infrastructure and governance on December 1, 2017. At that point you could 
> stop accepting the issuance of new certificates off the existing 
> infrastructure and PKI. (See our last reply to this thread where we confirmed 
> this point, but asked for an exception process.) Our point here is that if 
> you also make December 1, 2017 the "distrust date" for all certificates 
> issued off of Symantec’s current PKI before June 1, 2016 then, in effect, you 
> will be forcing all customers to "double down" on the existing Symantec PKI

No there is no need to "double down". Your customers can and should switch to a 
CA which doesn't have a long history of "problems" due to inadequate oversight. 
Trying to retain your customer base is a commercial problem for Symantec, not a 
Web PKI trust problem. This is not "Keep Symantec being like, totally stoked 
about, like, the general vibe and stuff".

> We look forward to the broader community weighing in on this. We urge the 
> community to validate our points, especially the website operators that are 
> being forced to execute this plan. The implementation of a forced plan that 
> introduces material risks on an unrealistic timeline is inappropriate and 
> dangerous.

The underlying cause here is Symantec. This isn't a systemic problem, it's a 
Symantec problem, the only "website operators" affected are those who foolishly 
trusted Symantec to run a CA properly. A reasonable question for such website 
operators to ask would be: Where's the press release listing all the board 
members and other core leadership who were terminated as a result of their 
failure to execute their only task, providing oversight for the business so 
that it doesn't blunder into such problems ? Where's the communication from 
Symantec warning me that their failings may cause my business massive 
inconvenience and I should begin planning now to move to a different CA to 
avoid that ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Update on SubCA Proposal

[Gervase Markham via dev-security-policy]

Hi Rick,

Some more thoughts on your post. I continue to invite community
commentary on the issues we are discussing.

On 21/07/17 07:00, Rick Andrews wrote:
> In our June 1 post, we stated that we would update the community after the 
> end of the month. 

Indeed. I was more referring to the suggestions made in the meeting with
Mozilla about when the public statement would be forthcoming. But no matter.

> Correct. However, as we indicated in our update, with a change of
> this magnitude we believe that there will likely be material
> compatibility and interoperability issues that will only come to
> light once server operators begin the transition to the Managed CA
> issued certificates. Recognizing this, we recommend that we establish
> a clear process to evaluate exception requests that includes
> consultations with the browsers to handle such corner cases.
Operators who have initial difficulty with the transition can, of
course, stay on their certificates issued from the old infrastructure.
(It's worth noting that if all of those customers had recently renewed
their certificates, as my proposal suggests, then there would not be a
problem with their existing-infra certs expiring while they were
attempting to make the transition.)

How would you see such an exception process working, and how would it be
implemented technically?

> While this is true under the terms of the SubCA proposal, we do not
> believe this is consistent with the spirit of Google’s and Mozilla’s
> prior commentary on their intent regarding the SubCA proposal, which
> is to limit the issuance of Symantec certificates under Symantec’s
> existing infrastructure and governance.
I'm not sure how you reach that conclusion. We want to end new issuance
in December, you want it to continue until next May. How are our dates
more inconsistent than yours with a desire to limit the issuance of
Symantec certificates under the existing infrastructure and governance?
We want to limit it earlier.

> dates.  Accordingly, our intention and expectation is that the
> majority of certificates issued before June 1, 2016 that will need to
> be replaced before their expiration under the current SubCA proposal
> will occur after the Managed CA is implemented. This will ensure
> there are no limitations on the replacement certificates that are
> issued to affected customers, which limits the substantial risks of
> implementation problems if our customers are not given the
> appropriate time to plan and execute their certificate replacements.
It may be appropriate for the limitations on current-infra issuance
lifetime in the plan to be adjusted by a few months such that a
certificate issued now can continue to work until the full distrust date
of November 1st, 2018. This would effectively mean that there are no
(additional) limitations on the replacement certificates.

> In our post we explained our rationale of why this period needs to be
> a minimum of 9 months. It is important for the community to note the
> significant operational burden and compatibility / interoperability
> risks that our customers will face if they have to replace their
> certificates once, let alone twice.
Why do you see a compatibility and interoperability risk in the process
of replacing a certificate with an identical certificate except that is
a) definitely logged to CT, and b) has a later expiry date?

You may argue that it's a customer operational burden but again, if
customers have difficulty replacing their SSL certs in a 4-month
timeframe, then they are not well positioned to deal with a number of
potential crises in the SSL system, such as compromise (and distrust) of
an intermediate, or compromise of their webservers.

> Our recommendation for replacing certificates issued before June 1,
> 2016 by May 1, 2018 (and preferably by February 1, 2019) enables a
> single shift to our new PKI for SSL/TLS certificates and eliminates
> any necessity for organizations to replace their certificates
> multiple times.
As noted above, I am not particularly impressed by arguments that
"replacing our certificates twice in 2-3 years is too hard".

It's also worth noting that in the timeline you propose, organizations
would have only 5 months (Dec 1 2017 - May 1 2018), including the
holiday period, to test and deploy the actual certificates they would be
using from the Managed CAs - those which do carry compatibility risk.
And it's only 3 months if they want to replace with fully-validated
non-DV certificates. My plan allows 9 uninterrupted months for that,
which gives significantly more scope to deal with unexpected
compatibility problems caused by new algorithms, new chains, etc. etc.
If customers are asking for time to manage a transition to a new
hierarchy, and that is your key concern, the plan I am proposing gives
them significantly more of it than yours does.

> The practical effect of this suggestion is to require up to two early
> replacements for affected customers of certificates 

Re: Symantec Update on SubCA Proposal

[Gervase Markham via dev-security-policy]

On 21/07/17 07:00, Rick Andrews wrote:
> In light of all of these implications, we respectfully request that Mozilla, 
> Google and the community consider the dates Symantec has proposed, which are 
> the results of our earnest and extensive efforts to implement the spirit of 
> the SubCA proposal. 

Thank you for the timeliness and completeness of your response. I am
travelling today, but will try and consider it over the weekend.

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

Re: Symantec Update on SubCA Proposal

[Rick Andrews via dev-security-policy]

On Thursday, July 20, 2017 at 12:31:56 PM UTC-7, Gervase Markham wrote:
> Hi Steve,
> 
> Thanks for posting this. I appreciate the level of detail provided,
> which is useful in giving us a basis for discussion. It's a little
> regrettable, though, that it was published a couple of weeks after we
> were led to expect it...

In our June 1 post, we stated that we would update the community after the end 
of the month. Considering the community’s request for detail in our response, 
we wanted our update to reflect our latest discussions with RFP respondents, 
which took place during the first two weeks of July.  These discussions have 
directly informed our proposed dates as described in our post.  We also felt it 
was important to collect feedback from both Google and Mozilla (which we have 
done) on our draft timing proposal before submitting it to the community for 
consideration given that Google and Mozilla authored / endorsed the SubCA 
proposal.

> One note before we start: Symantec's business dealings regarding its CA
> business are not of concern to Mozilla other than relating to the
> "change of ownership or control" provisions in Mozilla policy (policy
> 2.5 section 8). However, if dates are proposed or agreed for
> implementation of the consensus plan, we would not expect those dates to
> be renegotiated because of a change of ownership or control.
> 
> Am I right in saying that, in order to hit these dates you are
> proposing, you would strongly desire to get consensus on them by August 1st?

Symantec would like to reach consensus on the totality of the SubCA proposal, 
including final dates, as soon as possible.  This is in the best interest of 
all.  Our proposed dates assume we are able to finalize negotiation of 
contracts with the selected Managed CA partner(s), which incorporate final 
agreed-upon dates by the community, by no later than July 31, 2017.

> On 18/07/17 19:22, Steve Medin wrote:
> > New Certificate Issuance: We believe the dates for transition of validation 
> > and issuance to the Managed CA that are both aggressive and achievable are 
> > as follows:
> > 
> > - Implement the Managed CA by December 1, 2017 (changed from August 8, 
> > 2017);
> > 
> > - Managed CA performs domain validation for all new certificates by 
> > December 1, 2017 (changed from November 1, 2017); and
> > 
> > - Managed CA performs full validation for all certificates by February 1, 
> > 2018. Prior to this date, reuse of Symantec authenticated organization 
> > information would be allowable for certificates of <13 months in validity.
> 
> To summarise for those reading along: this represents a change of a
> little less than 4 months for the first date, 1 month for the second
> date, and the third date is as originally proposed.

This is correct. We have worked with our RFP respondents to put together an 
aggressive but achievable plan that delivers on the spirit of the original 
proposal.

> Steve: to be clear, this means that browsers could implement a block on
> certificates from Symantec's existing PKI as follows: after December
> 1st, 2017, they could dis-trust all certificates with a notBefore
> greater than December 1st 2017?

Correct. However, as we indicated in our update, with a change of this 
magnitude we believe that there will likely be material compatibility and 
interoperability issues that will only come to light once server operators 
begin the transition to the Managed CA issued certificates. Recognizing this, 
we recommend that we establish a clear process to evaluate exception requests 
that includes consultations with the browsers to handle such corner cases.

> Given the explanations Symantec has given as to why these dates are
> reasonable, and the effort required to stand up the new PKI, I am minded
> to accept them, particularly as they have managed to hit the third
> originally-proposed date on the nose. However, I am still open to
> community input.
> 
> > Replacement of Unexpired Certificates Issued Before June 1, 2016: There are 
> > two major milestones that must be achieved after implementation of the 
> > Managed CA in order to replace unexpired certificates issued before June 1, 
> > 2016 that do not naturally expire before the distrust date(s) in the SubCA 
> > proposal. Those include the full revalidation of certificate information 
> > and then the customer replacement of those certificates. 
> 
> That is not necessarily so. The customers could replace their
> certificates using new, CT-logged certificates from Symantec's old
> infrastructure. This doesn't require any revalidation or any change in
> the certificate chain, so should have excellent compatibility
> properties, and it's something that could begin today.

While this is true under the terms of the SubCA proposal, we do not believe 
this is consistent with the spirit of Google’s and Mozilla’s prior commentary 
on their intent regarding the SubCA proposal, which is to limit the issuance of 
Symantec 

Re: Symantec Update on SubCA Proposal

[Gervase Markham via dev-security-policy]

Hi Steve,

Thanks for posting this. I appreciate the level of detail provided,
which is useful in giving us a basis for discussion. It's a little
regrettable, though, that it was published a couple of weeks after we
were led to expect it...

One note before we start: Symantec's business dealings regarding its CA
business are not of concern to Mozilla other than relating to the
"change of ownership or control" provisions in Mozilla policy (policy
2.5 section 8). However, if dates are proposed or agreed for
implementation of the consensus plan, we would not expect those dates to
be renegotiated because of a change of ownership or control.

Am I right in saying that, in order to hit these dates you are
proposing, you would strongly desire to get consensus on them by August 1st?

On 18/07/17 19:22, Steve Medin wrote:
> New Certificate Issuance: We believe the dates for transition of validation 
> and issuance to the Managed CA that are both aggressive and achievable are as 
> follows:
> 
> - Implement the Managed CA by December 1, 2017 (changed from August 8, 2017);
> 
> - Managed CA performs domain validation for all new certificates by December 
> 1, 2017 (changed from November 1, 2017); and
> 
> - Managed CA performs full validation for all certificates by February 1, 
> 2018. Prior to this date, reuse of Symantec authenticated organization 
> information would be allowable for certificates of <13 months in validity.

To summarise for those reading along: this represents a change of a
little less than 4 months for the first date, 1 month for the second
date, and the third date is as originally proposed.

Steve: to be clear, this means that browsers could implement a block on
certificates from Symantec's existing PKI as follows: after December
1st, 2017, they could dis-trust all certificates with a notBefore
greater than December 1st 2017?

Given the explanations Symantec has given as to why these dates are
reasonable, and the effort required to stand up the new PKI, I am minded
to accept them, particularly as they have managed to hit the third
originally-proposed date on the nose. However, I am still open to
community input.

> Replacement of Unexpired Certificates Issued Before June 1, 2016: There are 
> two major milestones that must be achieved after implementation of the 
> Managed CA in order to replace unexpired certificates issued before June 1, 
> 2016 that do not naturally expire before the distrust date(s) in the SubCA 
> proposal. Those include the full revalidation of certificate information and 
> then the customer replacement of those certificates. 

That is not necessarily so. The customers could replace their
certificates using new, CT-logged certificates from Symantec's old
infrastructure. This doesn't require any revalidation or any change in
the certificate chain, so should have excellent compatibility
properties, and it's something that could begin today. In fact, as I
understand it, Symantec has already been encouraging their customers to
do exactly this.

This would, of course, mean, that those certificates would need
replacing again at some point before the final total dis-trust of the
current Symantec PKI.

This activity would need to start during the December holiday season
when many organizations impose infrastructure blackout periods.  As
such, we believe that the only achievable timing for this transition is
after the holiday season. We understand that browsers may want to
technically enforce this transition and that multiple milestones may be
undesirable from a coding perspective. In order to accommodate a
simplified and cost efficient transition schedule (especially for
organizations that currently have certificates with notBefore dates of
both June 1, 2015 and June 1, 2016) and to allow impacted organizations
the time, as they will likely need to replace, test and operationalize
these replacement certificates in their infrastructure, we recommend
consolidating Chrome's distrust dates to a single date of May 1, 2018.
This would mean that Chrome's distrust of Symantec certificates issued
before June 1, 2015 would change from August 31, 2017 to May 1, 2018,
and that Chrome's distrust of Symantec certificates issued before June
1, 2016 would change from January 18, 2018 to May 1, 2018.

A key date for Mozilla is when we can tell our software to dis-trust any
certificate issued by the Symantec current PKI which was issued before
June 1st 2016, because certificates issued after that are guaranteed
(pretty much) to be in CT, and therefore are a bounded and known set.
Therefore pushing that date out to May 1st 2018 seems like a negative
from our perspective.

A two-stage strategy such as the one outlined above seems to us to be
worth investigating, as it would allow us to give Symantec more time to
transition its customers from the current to the new PKI (something
which might come with compatibility risk, as you have correctly noted)
without having to bear the risk of continuing to 

Re: Symantec: Update

[Gervase Markham via dev-security-policy]

On 20/05/17 15:26, Michael Casadevall wrote:
> However, for Mozilla's purposes, is there a case where having a SCT in
> certificate would either break something, or otherwise be undesirable?

I believe we turned the checking on and discovered performance issues,
so we turned it off. I'm not sure if those have since been solved. JC?

> Well, at least with the current state of webpki, mandating an embedded
> SCT is probably not practical for everyone. I actually forgot about the
> OCSP stapling mechanism for SCTs, though my concern here is not everyone
> turns on OCSP stapling. Since both OCSP CT stapling and embedded SCTs
> require that the cert be submitting to a log at issuance, 

That's not so. OCSP CT stapling doesn't require the cert be submitted to
 a log at issuance. You only need to do it at some point before you
start using it. The same is true of the SSL handshake method.

>  - By default, Symantec shall issue certificates with embedded SCTs
> (soft-fail for failure to validate SCT information)

Given that Chrome is requiring CT for all Symantec certificates, one
could argue there's minimal value in Mozilla coming up with its own
CT-related requirements, particularly as Mozilla has not (yet?) deployed
SCT checking in Firefox.

Gerv


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

Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

On 05/19/2017 10:25 AM, Gervase Markham wrote:
> Embedding SCTs is not the only way SCTs can be delivered - they can come
> in the SSL handshake or via OCSP. Requiring them to be embedded does
> have the advantage that certificates now carry an unforgeable timestamp,
> and it was something I proposed in a version of Mozilla's now-dormant CT
> policy. But for various reasons, it's not necessarily practical to
> require it in all circumstances (which is why the CT RFC defines
> multiple mechanisms).
> 
> Firefox does have some support for checking SCT presence and validity,
> but it's not turned on.
> 

My concern here is right now, we're trying to rebuild trust for
Symantec. We're very much in a "trust but verify" sorta thing, and I
don't think it's an unjustified requirement to do so. I think CT is
about the only thing that has allowed us to reasonably consider keeping
Symantec in the root store at all.

However, for Mozilla's purposes, is there a case where having a SCT in
certificate would either break something, or otherwise be undesirable?

Well, at least with the current state of webpki, mandating an embedded
SCT is probably not practical for everyone. I actually forgot about the
OCSP stapling mechanism for SCTs, though my concern here is not everyone
turns on OCSP stapling. Since both OCSP CT stapling and embedded SCTs
require that the cert be submitting to a log at issuance, part of me
wonders if the right middle ground is this:

As far as I know, I think Microsoft's IIS is the only major web server
that turns OCSP stapling on out of the box.

 - By default, Symantec shall issue certificates with embedded SCTs
(soft-fail for failure to validate SCT information)

 - If, due to customer demand, a certificate with an embedded SCT can
not be used, said certificate must get the SCT information by a stapled
OCSP response or via TLS extension to be trusted by Mozilla. (hard-fail)

This should cover the general case fairly well, and for the edge cases,
well either its for a special class of device that we don't care about,
or the customer has to do some work to get things working in Mozilla.

Or in other words, if there's a case where an embedded SCT can't fly
here, then we mandate that one of the other two validation options must
be present for things to fly. That being said, for my personal
knowledge, I'd love to know more on the real world practicalities of
embedding SCTs.

Thanks for your feedback.

>>> Are there any RA's left for Symantec?

Following up to this, the question that I should have asked is who can
technically do an issuance of certificates based on Symantec's roots.
SSP customers are a recent discovery. I wonder if there's anything else.
Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Update

[Gervase Markham via dev-security-policy]

On 19/05/17 15:28, Peter Bowen wrote:
> This is not accurate.  They have indicated that the SSP customers have
> some level of issuance capability.

Oops. Well, they said that a while back, but yes indeed, since then we
have discovered the above fact.

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

Re: Symantec: Update

[Peter Bowen via dev-security-policy]

On Fri, May 19, 2017 at 7:25 AM, Gervase Markham via
dev-security-policy  wrote:
> On 15/05/17 21:06, Michael Casadevall wrote:
>
>>> Are there any RA's left for Symantec?
>>
>> TBH, I'm not sure. I think Gervase asked for clarification on this
>> point, but its hard to keep track of who could issue as an RA. I know
>> quite a few got killed, but I'm not sure if there are any other subCAs
>> based off re-reading posts in this thread.
>
> Symantec say they have closed their RA program, only Apple and Google
> are left in their GeoRoot program, and they have no other programs which
> allow third parties to have issuance capability.

This is not accurate.  They have indicated that the SSP customers have
some level of issuance capability.

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

Re: Symantec: Update

[Gervase Markham via dev-security-policy]

On 15/05/17 21:06, Michael Casadevall wrote:
> Sorry, I could have been more clear here. What I'm proposing is that
> after a specific TBD NotBefore date, we require SCTs to be in place on
> the certificate to be trusted. Certificates from before that date
> would remain trusted as-is (pending any reduction of expiration time).
> 
> I don't know if NSS has support for checking of SCTs (I can't pull the
> source at the moment to check), but it should fail if the SCT is
> missing, and otherwise behave like OCSP validation.

Embedding SCTs is not the only way SCTs can be delivered - they can come
in the SSL handshake or via OCSP. Requiring them to be embedded does
have the advantage that certificates now carry an unforgeable timestamp,
and it was something I proposed in a version of Mozilla's now-dormant CT
policy. But for various reasons, it's not necessarily practical to
require it in all circumstances (which is why the CT RFC defines
multiple mechanisms).

Firefox does have some support for checking SCT presence and validity,
but it's not turned on.

>> Are there any RA's left for Symantec?
> 
> TBH, I'm not sure. I think Gervase asked for clarification on this
> point, but its hard to keep track of who could issue as an RA. I know
> quite a few got killed, but I'm not sure if there are any other subCAs
> based off re-reading posts in this thread.

Symantec say they have closed their RA program, only Apple and Google
are left in their GeoRoot program, and they have no other programs which
allow third parties to have issuance capability.

>> I believe the only reasonable interpretation of the "new root"
>> plan would be based on cross signing for trust by old Mozilla
>> browsers and other root programs.
> 
> Won't the cross signature though have to be embedded in Firefox, or
> included in a server's SSL bundle for it to actually work?

The latter, yes. This is not difficult nor that unusual.

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

Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

On 05/16/2017 03:50 AM, Michael Casadevall wrote:
> On 05/15/2017 06:05 PM, Jakob Bohm wrote:
>>
> 
>  - A three-day grace period shall be in place from the issuance date of
> a certificate to when it must be in the CT logs for validation reasons
> (this is in line with other proposals here).
> 
>  - All server authentication certificates shall be submitted to at least
> two public CT logs.
> 

Just realized I had a brainfart when writing this. Don't believe I can
supersede on this list to fix it so sorry for the chatter.

This should say that certificates must be issued with an embedded SCT
which Symantec can get from their own log, and then upload the
certificate to other logs as part of the issuance.

As part of the CT validation, there would be a three day grace period
from the issuance date, to when the certificate can start failing due to
CT failure which should leave a nice bit of padding for the maximum
merge delay on the current public logs.
Michael
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

On 05/15/2017 06:05 PM, Jakob Bohm wrote:
>
> Ok, that's much better.
> 

Yay for reasonable courses of action. We'll see if it goes into the next
proposal.

>> I can see the point here, but I'm not sure I agree. Every time we keep
>> digging, we keep finding more and more problems with these roots.
>> WebPKI depends on all certificates in the root store being
>> trustworthy, and Symantec as a whole has not exactly shown themselves
>> to be responsive or willing to communicate publicly on the various
>> issues brought up on the list.
>>
> 
> Yes, that seems to be the trend.  But it has nothing to do with if the
> "9 month" rule or some other measures are the best remedy.
> 

There might be a reasonable compromise here, see below.

> RAs (external companies that can decide if Symantec itself should issue
> a cert) are completely different from external SubCAs (external
> companies that have their own CA and a certificate chain back to a
> Symantec root), which are different from internal SubCAs (CA
> certificates for Symantec controlled keys, such as the SubCA that
> signed normal OV certificates issued in January 2017).
> 
> External and Internal SubCAs can be blocked by simple technical means
> via TrustDB and OneCRL manipulations.  RAs are indistinguishable from
> Symantec itself when checking certificates, because the certificates
> were in fact signed by Symantec itself.
> 

I thought the RAs were being issued off their own intermediate branches
and not off Symantec ones. Rechecking crt.sh "C=KR, O=CrossCert,
OU=AccreditedCA, CN=CrossCert Class 1 Server CA" is a separate
intermediate chaining to KISA so I done goofed here. Oops.

Re-reading the issues, I think I got crossed between subCAs missing
audits, and RA issuance.

> The standard way this is done is that the old roots (which are trusted
> by old browsers) cross-sign the new roots or the subCAs of the new
> roots.  People buying new certs get (as always) a new cert chain for
> their new cert, which contains enough data to pass in browsers that
> trust new root, trust the old root, or trust both roots.
> 
> Servers with old certs still return the old certificate chain that
> leads to the old roots.
> 
> Other measures (such as browser embedded SubCA/cross certs) can be used
> to reduce how much of the old CA tree Firefox/Thunderbird trust during
> the transition.
> 

Thanks for clearing this up.

> I think we will need to look separately at two very different issues:
> 
> 1. Symantec's PKI and the location of the EV trust bit unfortunately
>   allows non-EV SubCAs to issue EV certs that Firefox marks as green.
>This same issue applies to most Mozilla trusted roots, because
>   Mozilla implemented the EV trust at the root CA level rather than at
>   a SubCA level.
> 
>This can be fixed technically by restricting the EV trust to the
>   SubCAs that are supposed to issue EV certs, rather than to whatever
>   general WebPKI root cert resides above it (in order for legitimate EV
>   certs to be trusted as normal certs by old browsers).
> 

This is a start.

We'd need confirmation from Symantec which subCAs are supposed to be
able to sign EV as I don't believe we have a complete list. That's also
assuming that things are that nice and organized (which is far from a
given). If we can successfully cut a good chunk of the crud away, it
would at least help in mind keeping EV being a reasonable option.

> 2. If there were any significant failures in the validation of EV
>   certs signed directly by the dedicated EV SubCAs at Symantec (other
>   than the one test cert that got some Symantec people fired some time
>   ago).
> 

Can we reasonably determine we're good here beyond a reasonable doubt?

The current responses to the last question found new parts of the fPKI
that are chaining via the Issue Y intermediates that appear that they
would be trusted by Mozilla. We also have confirmation that some of the
RAs could issue EVs and could validate certificates.

Symantec said that they independently checked the non-expired EV
certificates, but I think I have (IMHO) justified concerns there might
be additional ones here we don't know about.

Given the number of unknown knows with the EV situation right now, I
think I'm going to wait for more information before pushing any one
specific option, but at a minimium, we need to cut down the parts of the
tree that can sign for EV.

There's also a third issue is "what is the correct response to the
severity of Symantec's trust issues". We're fairly close to CNNIC
territory here, since we've got multiple intermediates that chain to the
Mozilla roots and can issue certificates which are either not BR
compliant, or out of scope of an audit.

In an attempt to try and get this thread to a point where the powers
that be might choose to include it in their proposal, let's try the
following in the addition to what is under PKI concerns in the gdoc:

---
 - For any Symantec-owned root certificate in the Mozilla trust 

Re: Symantec: Update

[Jakob Bohm via dev-security-policy]

On 15/05/2017 22:06, Michael Casadevall wrote:

On 05/15/2017 09:32 AM, Jakob Bohm wrote:

This won't work for the *millions* of legitimate, not-misissued,
end certificates that were issued before Symantec began SCT
embedding (hopefully in the past) and haven't expired before such
an early deadline.



Sorry, I could have been more clear here. What I'm proposing is that
after a specific TBD NotBefore date, we require SCTs to be in place on
the certificate to be trusted. Certificates from before that date
would remain trusted as-is (pending any reduction of expiration time).



Ok, that's much better.


I don't know if NSS has support for checking of SCTs (I can't pull the
source at the moment to check), but it should fail if the SCT is
missing, and otherwise behave like OCSP validation.


Also, since both Mozilla and Debian-derived systems such as Ubuntu
use the the Mozilla store as the basis for S/MIME checking, it is
worth noting that CT-logging of S/MIME end certs under the current
Google- dominated specifications is a guaranteed spam disaster, as
it would publish all the embedded e-mail addresses for easy
harvesting.



I didn't consider the S/MIME use case here. A brief look at the root
store I'd be fine with the SCT restriction only applying when looking
at CKA_TRUST_SERVER_AUTH, and not in other cases. Looking at certdata,
it looks like at least some of the current Verisign/Symantec roots
have both the S/MIME and server auth bits enabled.

While I feel CT would be a nice thing for S/MIME, unfortunately, I
have to agree with this point that we don't need to make spammers
lives easier. That being said, part of me wonders if there would be
other undisclosed intermediates if one could easily evaluate S/MIME
issuances ...


Mandating the X509v3 extension for TLS certificates means that
downstream servers don't have to be updated for CT awareness, and
we should never be in a case where a Mozilla product is accepting
a certificate that we can't independent review at a further point
via the CT logs. It should also prevent an undisclosed
intermediately from being undetected (as we've seen with Issue
Y).



However it would mandate that they be updated with new
certificates instead.  A lot easier, but still a mountain not
easily moved.


See above on NotBefore.




I'd also like to add the following to the transition plans: -
Limit certificate expiration to nine months from the existing
roots for new certificates.


I strongly believe the "9 month" rule mysteriously proposed but
never explained by Google was designed specifically to make buying
certs from Symantec all but worthless, chasing away all their
customers.  People *paying* for certificates generally don't want
to buy from anyone selling in increments of less than 1 year,
preferably 2 or 3.  "9 months" is an especially bad duration, as it
means the renewal dates and number of renewals per fiscal year will
fluctuate wildly from an accounting perspective.



I can see the point here, but I'm not sure I agree. Every time we keep
digging, we keep finding more and more problems with these roots.
WebPKI depends on all certificates in the root store being
trustworthy, and Symantec as a whole has not exactly shown themselves
to be responsive or willing to communicate publicly on the various
issues brought up on the list.



Yes, that seems to be the trend.  But it has nothing to do with if the
"9 month" rule or some other measures are the best remedy.


There's a decent argument to be had to simply disallow new issuance
from the existing roots and allow the current certificates to age out
(in which case imposing SCT embedded as I propose is simple), but I'm
not sure we've gotten a complete picture of how far this rabbit hole goe
s.



That wouldn't work, see below.


There's been a continual pattern of "this is everything", and then we
find another bunch of misissued certificates/undisclosed subCAs/etc.
Can we honestly say that we're comfortable with allowing these roots
to still be active at all?


- The above SCT requirement shall come into affect for the old
roots no less that three months from the date the proposal is
ratified. - Create a whitelist of intermediate certificates from
the root that can continue issuing certificates, but cutting off
RAs after an initial six month time period


Are there any RA's left for Symantec?



TBH, I'm not sure. I think Gervase asked for clarification on this
point, but its hard to keep track of who could issue as an RA. I know
quite a few got killed, but I'm not sure if there are any other subCAs
based off re-reading posts in this thread.



RAs (external companies that can decide if Symantec itself should issue
a cert) are completely different from external SubCAs (external
companies that have their own CA and a certificate chain back to a
Symantec root), which are different from internal SubCAs (CA
certificates for Symantec controlled keys, such as the SubCA that
signed normal OV certificates issued in January 

Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

On 05/15/2017 09:32 AM, Jakob Bohm wrote:
> This won't work for the *millions* of legitimate, not-misissued,
> end certificates that were issued before Symantec began SCT
> embedding (hopefully in the past) and haven't expired before such
> an early deadline.
> 

Sorry, I could have been more clear here. What I'm proposing is that
after a specific TBD NotBefore date, we require SCTs to be in place on
the certificate to be trusted. Certificates from before that date
would remain trusted as-is (pending any reduction of expiration time).

I don't know if NSS has support for checking of SCTs (I can't pull the
source at the moment to check), but it should fail if the SCT is
missing, and otherwise behave like OCSP validation.

> Also, since both Mozilla and Debian-derived systems such as Ubuntu
> use the the Mozilla store as the basis for S/MIME checking, it is
> worth noting that CT-logging of S/MIME end certs under the current
> Google- dominated specifications is a guaranteed spam disaster, as
> it would publish all the embedded e-mail addresses for easy
> harvesting.
> 

I didn't consider the S/MIME use case here. A brief look at the root
store I'd be fine with the SCT restriction only applying when looking
at CKA_TRUST_SERVER_AUTH, and not in other cases. Looking at certdata,
it looks like at least some of the current Verisign/Symantec roots
have both the S/MIME and server auth bits enabled.

While I feel CT would be a nice thing for S/MIME, unfortunately, I
have to agree with this point that we don't need to make spammers
lives easier. That being said, part of me wonders if there would be
other undisclosed intermediates if one could easily evaluate S/MIME
issuances ...

>> Mandating the X509v3 extension for TLS certificates means that 
>> downstream servers don't have to be updated for CT awareness, and
>> we should never be in a case where a Mozilla product is accepting
>> a certificate that we can't independent review at a further point
>> via the CT logs. It should also prevent an undisclosed
>> intermediately from being undetected (as we've seen with Issue
>> Y).
>> 
> 
> However it would mandate that they be updated with new
> certificates instead.  A lot easier, but still a mountain not
> easily moved.

See above on NotBefore.


>> 
>> I'd also like to add the following to the transition plans: -
>> Limit certificate expiration to nine months from the existing
>> roots for new certificates.
> 
> I strongly believe the "9 month" rule mysteriously proposed but
> never explained by Google was designed specifically to make buying
> certs from Symantec all but worthless, chasing away all their
> customers.  People *paying* for certificates generally don't want
> to buy from anyone selling in increments of less than 1 year,
> preferably 2 or 3.  "9 months" is an especially bad duration, as it
> means the renewal dates and number of renewals per fiscal year will
> fluctuate wildly from an accounting perspective.
> 

I can see the point here, but I'm not sure I agree. Every time we keep
digging, we keep finding more and more problems with these roots.
WebPKI depends on all certificates in the root store being
trustworthy, and Symantec as a whole has not exactly shown themselves
to be responsive or willing to communicate publicly on the various
issues brought up on the list.

There's a decent argument to be had to simply disallow new issuance
from the existing roots and allow the current certificates to age out
(in which case imposing SCT embedded as I propose is simple), but I'm
not sure we've gotten a complete picture of how far this rabbit hole goe
s.

There's been a continual pattern of "this is everything", and then we
find another bunch of misissued certificates/undisclosed subCAs/etc.
Can we honestly say that we're comfortable with allowing these roots
to still be active at all?

>> - The above SCT requirement shall come into affect for the old
>> roots no less that three months from the date the proposal is
>> ratified. - Create a whitelist of intermediate certificates from
>> the root that can continue issuing certificates, but cutting off
>> RAs after an initial six month time period
> 
> Are there any RA's left for Symantec?
> 

TBH, I'm not sure. I think Gervase asked for clarification on this
point, but its hard to keep track of who could issue as an RA. I know
quite a few got killed, but I'm not sure if there are any other subCAs
based off re-reading posts in this thread.

>> - Require that Symantec reapply to the root program for a new DV
>> and EV root certificates, and begin the migration here. Once the
>> new roots are approved, then they can cross-sign from the old
>> roots to the new ones.
>> 
>> My thought process here is to try and keep impact on WebPKI a
>> minimum, while making sure that we can externally audit how
>> Symantec is using their root store for certificates that will be
>> trusted by Mozilla.
>> 
>> I'm concerned that spinning up new roots and having them be in
>> the most 

Re: Symantec: Update

[Jakob Bohm via dev-security-policy]

On 13/05/2017 12:27, Michael Casadevall wrote:

On 05/11/2017 09:53 AM, Jonathan Rudenberg via dev-security-policy wrote:



On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy 
 wrote:

I would appreciate people's comments on the details of the current draft.


I don’t think that this proposal goes far enough.


First post on the list but long time lurker, but I feel the need to
weigh in here that I think Jonathah's proposal is much closer to what
has to happen.



I suspect you may be believing too much of what Google says, see
specific problems below.


Reading through Gervase's document, I'd like to add the following to
this in addition to the existing notes in PKI operations:

 - EV certificate roots loose their trust bits effective immediately
   (I don't think this can be done via OneCRL so it would be via the
next release)
 - Any root stores (new or old) operated by Symantec shall require all
certificates to be posted to a CT log.
 - Within three months, require all certificates issued from Symantec to
have SCT embedded in the end point certificate, and mandate this from
the beginning for any root certificates.
   - NSS shall only accept certificates with the embedded SCT record in
the certificate.


This won't work for the *millions* of legitimate, not-misissued, end
certificates that were issued before Symantec began SCT embedding
(hopefully in the past) and haven't expired before such an early
deadline.

Also, since both Mozilla and Debian-derived systems such as Ubuntu use
the the Mozilla store as the basis for S/MIME checking, it is worth
noting that CT-logging of S/MIME end certs under the current Google-
dominated specifications is a guaranteed spam disaster, as it would
publish all the embedded e-mail addresses for easy harvesting.



Certificate transparency was the only way we began to get a real look at
how bad some of these issues are, and I feel that if we're going to
actually continue with Symatec as a CA, then we're going to make
absolutely sure we know how certificates are being utilized.



That is unfortunately true.


Mandating the X509v3 extension for TLS certificates means that
downstream servers don't have to be updated for CT awareness, and we
should never be in a case where a Mozilla product is accepting a
certificate that we can't independent review at a further point via the
CT logs. It should also prevent an undisclosed intermediately from being
undetected (as we've seen with Issue Y).



However it would mandate that they be updated with new certificates
instead.  A lot easier, but still a mountain not easily moved.



I'd also like to add the following to the transition plans:
 - Limit certificate expiration to nine months from the existing roots
for new certificates.


I strongly believe the "9 month" rule mysteriously proposed but never
explained by Google was designed specifically to make buying certs from
Symantec all but worthless, chasing away all their customers.  People
*paying* for certificates generally don't want to buy from anyone
selling in increments of less than 1 year, preferably 2 or 3.  "9
months" is an especially bad duration, as it means the renewal dates
and number of renewals per fiscal year will fluctuate wildly from an
accounting perspective.


 - The above SCT requirement shall come into affect for the old roots no
less that three months from the date the proposal is ratified.
 - Create a whitelist of intermediate certificates from the root that
can continue issuing certificates, but cutting off RAs after an initial
six month time period


Are there any RA's left for Symantec?


 - Require that Symantec reapply to the root program for a new DV and EV
root certificates, and begin the migration here. Once the new roots are
approved, then they can cross-sign from the old roots to the new ones.

My thought process here is to try and keep impact on WebPKI a minimum,
while making sure that we can externally audit how Symantec is using
their root store for certificates that will be trusted by Mozilla.

I'm concerned that spinning up new roots and having them be in the most
common root stores is going to take a significant period of time and
during that window we're still stuck with the old roots being in
operation. By limiting the branches of the old roots, it should limit
our risk while the new roots come into existence and begin to spread
through the ecosystem.


I believe the only reasonable interpretation of the "new root" plan
would be based on cross signing for trust by old Mozilla browsers and
other root programs.



Winding down the old roots (phase four as described in the proposal) is
going to be a long and slow process so I want to make sure we're making
sure that while we're in the transition period that we've got an
extremely clear picture on what's going on on both sets of roots.

My problem with the Google "sliding scale" is that's its damn hard to
understand when exactly a 

Re: Symantec: Update

[Michael Casadevall via dev-security-policy]

On 05/11/2017 09:53 AM, Jonathan Rudenberg via dev-security-policy wrote:
> 
>> On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy 
>>  wrote:
>>
>> I would appreciate people's comments on the details of the current draft.
> 
> I don’t think that this proposal goes far enough.

First post on the list but long time lurker, but I feel the need to
weigh in here that I think Jonathah's proposal is much closer to what
has to happen.

Reading through Gervase's document, I'd like to add the following to
this in addition to the existing notes in PKI operations:

 - EV certificate roots loose their trust bits effective immediately
   (I don't think this can be done via OneCRL so it would be via the
next release)
 - Any root stores (new or old) operated by Symantec shall require all
certificates to be posted to a CT log.
 - Within three months, require all certificates issued from Symantec to
have SCT embedded in the end point certificate, and mandate this from
the beginning for any root certificates.
   - NSS shall only accept certificates with the embedded SCT record in
the certificate.

Certificate transparency was the only way we began to get a real look at
how bad some of these issues are, and I feel that if we're going to
actually continue with Symatec as a CA, then we're going to make
absolutely sure we know how certificates are being utilized.

Mandating the X509v3 extension for TLS certificates means that
downstream servers don't have to be updated for CT awareness, and we
should never be in a case where a Mozilla product is accepting a
certificate that we can't independent review at a further point via the
CT logs. It should also prevent an undisclosed intermediately from being
undetected (as we've seen with Issue Y).


I'd also like to add the following to the transition plans:
 - Limit certificate expiration to nine months from the existing roots
for new certificates.
 - The above SCT requirement shall come into affect for the old roots no
less that three months from the date the proposal is ratified.
 - Create a whitelist of intermediate certificates from the root that
can continue issuing certificates, but cutting off RAs after an initial
six month time period
 - Require that Symantec reapply to the root program for a new DV and EV
root certificates, and begin the migration here. Once the new roots are
approved, then they can cross-sign from the old roots to the new ones.

My thought process here is to try and keep impact on WebPKI a minimum,
while making sure that we can externally audit how Symantec is using
their root store for certificates that will be trusted by Mozilla.

I'm concerned that spinning up new roots and having them be in the most
common root stores is going to take a significant period of time and
during that window we're still stuck with the old roots being in
operation. By limiting the branches of the old roots, it should limit
our risk while the new roots come into existence and begin to spread
through the ecosystem.

Winding down the old roots (phase four as described in the proposal) is
going to be a long and slow process so I want to make sure we're making
sure that while we're in the transition period that we've got an
extremely clear picture on what's going on on both sets of roots.

My problem with the Google "sliding scale" is that's its damn hard to
understand when exactly a certificate is good or when it expires since
the dates in the X509 certificate don't necessarily correspond with
reality. By simply capping Symantec certificates to nine months, it puts
us in a position that moving to a new DV/EV root would be required for
them to remain competitive while not drastically affecting the ecosystem
as a whole.

Maybe I'm off-kilter here, but I think this proposal would help keep
impact on WebPKI to a minimum but light a fairly serious fire to get
users moved to the new root stores ASAP. Please let me know if I am
seriously off base with my understanding of the situation or the
technologies involved; WebPKI is a complicated thing to understand :)
Michael





signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Update

[okaphone.elektronika--- via dev-security-policy]

On Thursday, 11 May 2017 19:08:06 UTC+2, Gervase Markham  wrote:
> On 11/05/17 13:02, wiz...@ida.net wrote:
> > That said, it is fair point that the plan should spell out what happens if 
> > symantec does not cooperate. 
> 
> I think we should cross that bridge when we come to it, which I hope we
> won't. Not that I'm not prepared to cross it, but there's no point
> devising plans and writing text in advance for a situation which can be
> dealt with when and if it occurs.
> 
> Gerv

Better keep your deadlines short then. They seem to be the only times Symantec 
actually responds to anything asked/said here. :-(

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

Re: Symantec: Update

[Gervase Markham via dev-security-policy]

On 11/05/17 13:02, wiz...@ida.net wrote:
> That said, it is fair point that the plan should spell out what happens if 
> symantec does not cooperate. 

I think we should cross that bridge when we come to it, which I hope we
won't. Not that I'm not prepared to cross it, but there's no point
devising plans and writing text in advance for a situation which can be
dealt with when and if it occurs.

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

Re: Symantec: Update

[Jonathan Rudenberg via dev-security-policy]

> On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy 
>  wrote:
> 
> I would appreciate people's comments on the details of the current draft.

I don’t think that this proposal goes far enough.

Symantec has demonstrated that they have no interested in engaging with the 
Mozilla community about these issues. Over the past months, dozens of relevant 
and important questions have been asked of Symantec by community members, and 
most of them remain unanswered to this day. In most cases, when questions were 
answered, it was only after setting a deadline, at the last possible moment of 
that deadline, and in a format that made it very hard to track responses and 
ask follow-up questions.

Given this lack of constructive engagement, the recent request that we “pause” 
making any decisions, and the breathtaking severity of the issues discovered, I 
believe that the only objective should be to minimize risk to users of the 
Mozilla root store by removing the Symantec roots as quickly as possible. 
Trusted roots are a privilege and a responsibility, not a right, and Symantec 
has demonstrated that they are not capable of fulfilling that responsibility at 
this time.

With that in mind and taking into account the responses to previous incidents, 
I believe the following actions should be taken as part of the proposed ‘new 
PKI’ plan:

1) Immediate removal of EV treatment from all certificates issued by existing 
Symantec roots.

2) The establishment of a cutoff date a few months from now after which new 
certificates issued from existing Symantec roots will no longer be trusted 
based on notBefore. A variant of this is already in the proposal, but the 
timeline is unclear.

3) Complete removal of existing Symantec roots from the trust store as quickly 
as possible while limiting user impact, using the Chrome accelerated expiry 
proposal as a starting point.

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

Re: Symantec: Update

[urijah--- via dev-security-policy]

Possibly this is irrelevant, but I have some concerns on how Symantec, it seems 
to me, is willfully mischaracterizing their certificate compliance issues in 
their prepared remarks to their investors yesterday.[1]

It makes it sound as if there are some generic certificate industry changes 
that are coming that might affect them. They do not seem willing to accept 
public responsibility for their actions and compliance failures.

"As you may be aware, in late March, Google put forth a proposal that, if 
implemented, would introduce major changes to the processes and operations that 
are standard across our industry, including our Certificate Authority business. 
Since that time, we've been engaged in conversations with Google, Mozilla, and 
other members of the CA community to seek input on our counter proposal that we 
believe minimizes business disruption for our customers and improves trust in 
Symantec's CA business. We believe we will find a mutually agreeable path 
forward that is in the best interest of our customers, and we expect 
discussions around our proposal to continue and have factored our current 
expectations around this headwind into our financial outlook."

[1] 
http://s1.q4cdn.com/585930769/files/doc_financials/2017/Q4/Symantec-4Q17-Prepared-Remarks.pdf


On Tuesday, May 9, 2017 at 11:51:33 AM UTC-4, Gervase Markham wrote:
> Hi everyone,
> 
> Yesterday was May 8th, which was the day I had said we would stop
> discussing my proposal of what to do about Symantec and hand it over to
> Kathleen for a decision. This didn't happen for two reasons: I had some
> personal things to deal with, and also I think the proposal needs some
> modification.
> 
> Mozilla runs an open and transparent root program, and listens to the
> voice of its community. And over the past few days it's been clear that
> our community is not impressed with Symantec's engagement, or lack
> thereof, with this process. I personally am also not impressed with the
> way that getting information from Symantec feels like pulling teeth;
> questions are answered at the last possible minute, and despite there
> being major outstanding problems with compliance to Mozilla's root
> program requirements (issue Y), no effort is made from their side to
> proactively engage and start to resolve these issues. It is clear from
> the issues list that there are a number of serious concerns, and these
> are not being engaged with. Despite the fact that there appear to be
> numerous under-audited and unaudited publicly-trusted sub-CAs out there,
> and this fact has been known for weeks now, Symantec has not said
> anything about the situation to Mozilla, either publicly or privately.
> Would we find this acceptable in any other CA?
> 
> I am also not happy with simply waiting for the outcome of private
> discussions between Google and Symantec in which Mozilla's interests are
> not adequately represented. I am keen to move forward, to demonstrate
> that delay is not rewarded, and (despite the fact that our process can
> be slow) to make sure that timely action is taken based on the results
> of our investigations. This is only fair, given that this is what we
> have attempted to do for other CAs which we have investigated. We should
> treat everyone the same, as far as we can.
> 
> I am therefore proposing the following:
> 
> * Editing the proposal to withdraw the "alternative" option, leaving
> only the "new PKI" option. I no longer have confidence that the
> alternative option represents an appropriate response. As some have
> pointed out, the "documentation" requirement is actually something
> Symantec should have done years ago as part of our intermediate
> disclosure process, and which other CAs have made great efforts to
> comply with already. The "new PKI" option represents the best way to
> reduce the risk from Symantec's under-managed and sprawling existing PKI.
> 
> * Engagement here in m.d.s.p. with the community to refine and flesh out
> the "new PKI" proposal, based on the Google outline but examining it and
> enhancing it to make sure it is practical, both from an implementation
> perspective and to reduce disruption to sites as far as possible.
> 
> * Discussions within Mozilla as necessary to make sure the appropriate
> parts of the organization are briefed on this process.
> 
> * Submission of the proposal document to Kathleen at the earliest
> possible moment to propose that we have that plan approved as our
> requirements of Symantec. (The timeline here is dependent on other
> moving parts, but as noted above, delay is to be avoided.)
> 
> We may in parallel ask further questions of Symantec, and expect timely
> answers (as this is a baseline requirement for participation in our root
> program), but this process will not wait around for those answers.
> 
> I will begin work on these tasks tomorrow.
> 
> Gerv

___
dev-security-policy mailing list

Re: Symantec: Update

[wizard--- via dev-security-policy]

Symantec, in previous blog posts on their site, has indicated that they will 
support their customers [1].

That said, it is fair point that the plan should spell out what happens if 
symantec does not cooperate. It seems appropriate to have the plan do what it 
says -- scheduled phase out of the old roots -- with the same timescale. If 
symantec does not step up to fill their customer needs, I am sure one or more 
of their competitors will [and remember all this only applies to symantec 
customers who need publicly trusted certs... one big appeal of the proposal is 
that non-public uses can remain unaffected]. 

As the recent Wosign/Startcom experiences teaches, though, if the CA is not 
cooperative, it is very important for the browsers to step in with messaging. 
Not sure what form this would take, since most developers I know do not use 
beta/nightly versions of browsers, so it would need to be something in actual 
releases. Perhaps a single line with orange background just below URL box that 
says "in one month, this site will cease to be trusted by major browsers [click 
here for why]", or somesuch. With the link being very clear: it is the owner of 
the website that needs to update their certificate. 

Just a thought.

1. https://www.symantec.com/connect/blogs/message-our-ca-customers "In the 
event Google implements its proposal, Symantec will ensure your websites, 
webservers or web applications continue to work across browsers."

On Wednesday, May 10, 2017 at 4:11:59 PM UTC-4, okaphone.e...@gmail.com wrote:
> On Wednesday, 10 May 2017 17:52:40 UTC+2, Gervase Markham  wrote:
> > On 09/05/17 16:51, Gervase Markham wrote:
> > > * Editing the proposal to withdraw the "alternative" option, leaving
> > > only the "new PKI" option. 
> > 
> > This has now been done:
> > 
> > https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#
> > 
> > > * Engagement here in m.d.s.p. with the community to refine and flesh out
> > > the "new PKI" proposal, based on the Google outline but examining it and
> > > enhancing it to make sure it is practical, both from an implementation
> > > perspective and to reduce disruption to sites as far as possible.
> > 
> > I would appreciate people's comments on the details of the current draft.
> 
> Makes sense to me.
> 
> But it does seem to assume that Symantec will cooperate with this. What 
> happens if they decide not to is less clear. Perhaps it would be a good idea 
> to indicate which steps will be taken in any case?

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

Re: Symantec: Update

[Andrew R. Whalley via dev-security-policy]

On Wed, May 10, 2017 at 2:06 PM, mono.riot--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, May 10, 2017 at 7:59:37 PM UTC+2, Itzhak Daniel wrote:
> > The next step, if Symantec wish to continue to use their current PKI in
> the future, should be logging (ASAP) *all* of the certificates they issued
> to a CT log, then we'll know how deep is the rabbit hole.
>
> already the case since '15
>
> https://security.googleblog.com/2015/10/sustaining-
> digital-certificate-security.html


The blog post is dated October 15, but the requirement* only came into
effect June 1st, 2016


> although I'm not certain if this applied only to certs issued under the
> Symantec brand.


Any certs issued by any Symantec CA, regardless of brand, unless the CA is
operated by a 3rd party under its own, separate, audit.

Andrew

*required for the cert to be trusted in Chrome.  They are still free to
issue certs that don't comply with the Chrome CT Policy, but those will
cause an interstitial warning in Chrome.

___
> 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: Symantec: Update

[Kurt Roeckx via dev-security-policy]

On Tue, May 09, 2017 at 07:03:16PM +0200, Kurt Roeckx via dev-security-policy 
wrote:
> 
> Instead of the removal of the roots, I suggest we either ask them
> to revoke all the intermediate CAs that do not have the required
> audits or that Mozilla adds them to OneCRL.

Just to clarify, I believe that under 4.9.1.2 of the BRs, either
point 5, 8 or 9, Symantec is required to revoke those certificates
within 7 days. There is no indication that they follow the BR
requirements, the audit report even says that Symantec does not
control them, just monitor them. They are a clear danger.


Kurt

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

Re: Symantec: Update

[mono.riot--- via dev-security-policy]

On Wednesday, May 10, 2017 at 7:59:37 PM UTC+2, Itzhak Daniel wrote:
> The next step, if Symantec wish to continue to use their current PKI in the 
> future, should be logging (ASAP) *all* of the certificates they issued to a 
> CT log, then we'll know how deep is the rabbit hole.

already the case since '15

https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html

although I'm not certain if this applied only to certs issued under the 
Symantec brand. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Update

[okaphone.elektronika--- via dev-security-policy]

On Wednesday, 10 May 2017 17:52:40 UTC+2, Gervase Markham  wrote:
> On 09/05/17 16:51, Gervase Markham wrote:
> > * Editing the proposal to withdraw the "alternative" option, leaving
> > only the "new PKI" option. 
> 
> This has now been done:
> 
> https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#
> 
> > * Engagement here in m.d.s.p. with the community to refine and flesh out
> > the "new PKI" proposal, based on the Google outline but examining it and
> > enhancing it to make sure it is practical, both from an implementation
> > perspective and to reduce disruption to sites as far as possible.
> 
> I would appreciate people's comments on the details of the current draft.

Makes sense to me.

But it does seem to assume that Symantec will cooperate with this. What happens 
if they decide not to is less clear. Perhaps it would be a good idea to 
indicate which steps will be taken in any case?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Update

[Kathleen Wilson via dev-security-policy]

On Tuesday, May 9, 2017 at 10:03:53 AM UTC-7, Kurt Roeckx wrote:
> 
> Do we somewhere have the official templates being used to send
> reminders of the audit requirements? 

Unofficial templates: 
https://wiki.mozilla.org/CA:Email_templates

The official templates are in Salesforce, but currently match the wiki page.


> Kathleen posts a summary of
> the email that got send, but I'm not sure if they contain more
> text or if the text changes as the period gets longer.

For directly included certs, the email changes as the period gets longer.

So far we only have one email template for intermediate certs:
https://wiki.mozilla.org/CA:Email_templates#Disclosure_Incomplete_Email_Template

I have not yet created automation around notifying CAs of overdue audit 
statements for intermediate certs.

Kathleen


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

Re: Symantec: Update

[Kurt Roeckx via dev-security-policy]

On Tue, May 09, 2017 at 04:51:12PM +0100, Gervase Markham via 
dev-security-policy wrote:
> Despite the fact that there appear to be
> numerous under-audited and unaudited publicly-trusted sub-CAs out there,
> and this fact has been known for weeks now, Symantec has not said
> anything about the situation to Mozilla, either publicly or privately.
> Would we find this acceptable in any other CA?

Do we somewhere have the official templates being used to send
reminders of the audit requirements? Kathleen posts a summary of
the email that got send, but I'm not sure if they contain more
text or if the text changes as the period gets longer.

>From the draft templates I could find, I suggest we skip the 
first one because it's about being late and there are no audit
reports here. The second template would file a removal bug and start
discussing it here.

Instead of the removal of the roots, I suggest we either ask them
to revoke all the intermediate CAs that do not have the required
audits or that Mozilla adds them to OneCRL.

Did someone try to make a list of all CA certificates that don't
have all the required audit requirements marked in the common CA
database, including other CAs? We really should do this for all
such cases.


Kurt

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

Re: Symantec: Update

[Vincent Lynch via dev-security-policy]

Hi Gervase,

Thank you for the update on Mozilla's process.

I have one question regarding your wording. You write"I am therefore *proposing
*the following," and then you list your changes.

Does this mean that the "alternative" option is officially, 100%, off the
table? Or is this still an option Kathleen is considering?

-Vincent

On Tue, May 9, 2017 at 11:51 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi everyone,
>
> Yesterday was May 8th, which was the day I had said we would stop
> discussing my proposal of what to do about Symantec and hand it over to
> Kathleen for a decision. This didn't happen for two reasons: I had some
> personal things to deal with, and also I think the proposal needs some
> modification.
>
> Mozilla runs an open and transparent root program, and listens to the
> voice of its community. And over the past few days it's been clear that
> our community is not impressed with Symantec's engagement, or lack
> thereof, with this process. I personally am also not impressed with the
> way that getting information from Symantec feels like pulling teeth;
> questions are answered at the last possible minute, and despite there
> being major outstanding problems with compliance to Mozilla's root
> program requirements (issue Y), no effort is made from their side to
> proactively engage and start to resolve these issues. It is clear from
> the issues list that there are a number of serious concerns, and these
> are not being engaged with. Despite the fact that there appear to be
> numerous under-audited and unaudited publicly-trusted sub-CAs out there,
> and this fact has been known for weeks now, Symantec has not said
> anything about the situation to Mozilla, either publicly or privately.
> Would we find this acceptable in any other CA?
>
> I am also not happy with simply waiting for the outcome of private
> discussions between Google and Symantec in which Mozilla's interests are
> not adequately represented. I am keen to move forward, to demonstrate
> that delay is not rewarded, and (despite the fact that our process can
> be slow) to make sure that timely action is taken based on the results
> of our investigations. This is only fair, given that this is what we
> have attempted to do for other CAs which we have investigated. We should
> treat everyone the same, as far as we can.
>
> I am therefore proposing the following:
>
> * Editing the proposal to withdraw the "alternative" option, leaving
> only the "new PKI" option. I no longer have confidence that the
> alternative option represents an appropriate response. As some have
> pointed out, the "documentation" requirement is actually something
> Symantec should have done years ago as part of our intermediate
> disclosure process, and which other CAs have made great efforts to
> comply with already. The "new PKI" option represents the best way to
> reduce the risk from Symantec's under-managed and sprawling existing PKI.
>
> * Engagement here in m.d.s.p. with the community to refine and flesh out
> the "new PKI" proposal, based on the Google outline but examining it and
> enhancing it to make sure it is practical, both from an implementation
> perspective and to reduce disruption to sites as far as possible.
>
> * Discussions within Mozilla as necessary to make sure the appropriate
> parts of the organization are briefed on this process.
>
> * Submission of the proposal document to Kathleen at the earliest
> possible moment to propose that we have that plan approved as our
> requirements of Symantec. (The timeline here is dependent on other
> moving parts, but as noted above, delay is to be avoided.)
>
> We may in parallel ask further questions of Symantec, and expect timely
> answers (as this is a baseline requirement for participation in our root
> program), but this process will not wait around for those answers.
>
> I will begin work on these tasks tomorrow.
>
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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