Re: Symantec Update on SubCA Proposal

2017-08-12 Thread 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 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 

Re: Final Decision by Google on Symantec

2017-07-28 Thread wizard--- via dev-security-policy
With respect to the date of distrust of symantec certificates issues before 
June 1, 2016, I believe Mozilla has a third option:

Remove indicators of trust (green lock, etc.) on December 1, 2017 for Symantec 
certificates issued prior to June 1, 2016 (but do not produce interstitials and 
do not actively distrust until April 17th 2018).

Yes, this is somewhat more engineering work for Mozilla, but it strikes the 
right balance between usability and safety.

Why? The underlying security rationale for an earlier distrust of certificates 
issued prior to June 1, 2016 is that there is no CT disclosure requirement for 
DV/OV. The lack of transparency afforded to issuances prior to June 1, 2016, 
inherently makes them "riskier" to end users given Symantec's demonstrated 
prior practices.

The above strategy properly incorporates that additional risk in the trust 
decision, while not introducing the much larger potential compatibility issues 
of full distrust of old certificates on the same day that the managed CA 
becomes fully operational.

Mozilla could even consider waiving the above if Symantec were to log *all* 
(including expired and revoked) certificates from prior to June 1, 2016 [with 
the enforcement being: if anyone in the world provides Mozilla with a copy of 
even a single certificate that is not in CT after Symantec says that they are, 
then the above, or something more stringent, immediately goes into effect]. 
Symantec has even provided a fairly accurate count of how many non-expired, 
non-revoked certificates prior to June 1, 2016 should be present as an initial 
sanity check.

Note this strategy may also help eliminate compatibility problems April 17th 
2018, since there will have been a large period of time where indicators of 
trust were removed (but otherwise remaining functional).

On Friday, July 28, 2017 at 2:15:43 AM UTC-4, Gervase Markham wrote:
> Google have made a final decision on the various dates they plan to
> implement as part of the consensus plan in the Symantec matter. The
> message from blink-dev is included below.
> 
> Most of the dates have consensus - the dates for Symantec to implement
> the Managed CA infrastructure are agreed by all, and the date for final
> distrust of the old Symantec PKI is agreed by Google and Mozilla (to
> within a week, at any rate). I proposed November 1st 2018. Google has
> gone for October 23rd 2018; in practical terms, we would implement that
> using Firefox 63 (October 16th) or 64 (November 27th).
> 
> However, there is some difference in the proposals for the date on which
> browsers should dis-trust Symantec certificates issued before June 1st,
> 2016. This date is significant because after that, Symantec have been
> required to log all their certs to CT and so there is much better
> transparency of issuance practice. I proposed December 1st 2017. Google
> strongly considered late January, but have finally chosen April 17th 2018.
> 
> We now have two choices. We can accept the Google date for ourselves, or
> we can decide to implement something earlier. Implementing something
> earlier would involve us leading on compatibility risk, and so would
> need to get wider sign-off from within Mozilla, but nevertheless I would
> like to get the opinions of the m.d.s.p community.
> 
> I would like to make a decision on this matter on or before July 31st,
> as Symantec have asked for dates to be nailed down by then in order for
> them to be on track with their Managed CA implementation timetable. If
> no alternative decision is taken and communicated here and to Symantec,
> the default will be that we will accept Google's final proposal as a
> consensus date.
> 
> Gerv
> 
>  Forwarded Message 
> Subject:  Re: [blink-dev] Intent to Deprecate and Remove: Trust in
> existing Symantec-issued Certificates
> Date: Thu, 27 Jul 2017 17:16:06 -0700
> From: Darin Fisher 
> To:   Darin Fisher 
> CC:   blink-dev 
> 
> 
> 
> Representing Google Chrome and the Chromium open source project, what
> follows is our final proposal on this matter.
> 
> 
> We’d like to first thank the blink-dev community for your input on this
> discussion. After taking this input into consideration along with the
> latest responses from Symantec and Mozilla, we have produced the
> following proposal that is intended to be our final plan of action on
> this matter.
> 
> 
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016:
> 
> Chrome 66 will distrust Symantec-issued TLS certificates issued before
> June 1, 2016, which is tentatively scheduled to hit Canary on January
> 19, 2018; Beta on March 15, 2018; and Stable (the vast majority of
> Chrome users) on April 17, 2018. Affected site operators are strongly
> encouraged to replace their TLS certificates before March 15, 2018 to
> prevent breakage. Although this is significantly later than our initial
> 

Re: Symantec response to Google proposal

2017-06-08 Thread wizard--- via dev-security-policy
On Tuesday, June 6, 2017 at 10:03:29 AM UTC-4, Gervase Markham wrote:
> On 02/06/17 15:53, Gervase Markham wrote:
> > https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
> 
> I'm slightly surprised to see no engagement here. 

I think many of us are worn out with the poor responses from Symantec, who seem 
to treat this as a matter easily resolved with negotiation rather than actually 
addressing the underlying technical and procedural concerns. 

Symantec's slow responsiveness, attempt to limit community input by hosting 
responses outside the natural conversation threads (PDFs, blog posts that don't 
load on locked down browsers, etc), and apparent attempts to shield was should 
be a transparent process under the guise of "commercial secrets" would be cause 
for full loss of trust by any other CA. They have now had multiple chances to 
respond in an appropriate fashion and have failed to do so, so I don't see why 
the response here should be any different. Thus, at this point, if I were 
mozilla and Google, I would:

1) set a sunset date of 06/01/2018 for the ban to take effect. 
2) immediately (next firefox/chrome release) add a small banner message (or 
similar) any time a Symantec certificate is found stating "Symantec 
certificates will soon be distrusted; if you are the site owner,  to 
read more" Where go here goes to this and the intent thread @ Google. Site 
owners will get the message -- either directly by their own browsing, or from 
their customers. Note that this direct-to-user messages, while should be used 
sparingly, is the ~only mechanism available to browsers to make sure 
appropriate eyeballs see that a certificate change is needed by the site owner. 
I suspect it would greatly have helped with the Wosign distrust, for example.

Of course the above does not preclude Symantec from getting a separate/new 
managed PKI (from another CA) to be able to replace certificates for customers 
immediately, nor does it preclude the possibility of this new PKI transitioning 
back to symantec control once they demonstrate they have resolved the 
underlying issues. 

But what the above does do is shift the risks from the relying parties (who are 
the ones with almost all the risk as symantec drags their feet), to Symantec 
(they either get their act together or exit the CA business).

So I, for one, have no particular interest in continuing to engage in a 
discussion with an uncooperative party. The time for softball has ended.


> Perhaps it would be
> help to break it down. Symantec's specific requests for modification are
> as follows (my interpretation):
> 
> 1) Scope of Distrust
> 
> Google proposal: existing CT-logged certificates issued after 1st June
> 2016 would continue to be trusted until expiry.
> Symantec proposal: all CT-logged certificates should continue to be
> trusted until expiry.
> Rationale for change: if transparency is enough to engender trust, that
> principle should be applied consistently. This also significantly
> reduces the revalidation burden.
> 
> 2) Timeline
> 
> Google proposal: a set of dates by which certain milestones must be
> achieved.
> Symantec proposal: no specific alternative dates (more info by the end
> of June), but the Google dates are too aggressive.
> Rationale: need to establish business relationships; capacity issues at
> Managed CAs; international requirements further complicate things; the
> revalidation burden is very large; writing solid code takes time.
> 
> 3) SubCA Audit Type
> 
> Google proposal: SubCAs are audited with the standard audits.
> Symantec proposal: treat SubCAs as Delegated Third Parties and so give
> them BR section 8 audits (an audit by the CA not an auditor; 3% sampling).
> Rationale: none given.
> 
> 4) Validation Task Ownership
> 
> Google proposal: Symantec and its affiliates must not participate in any
> of the information verification roles permitted under the Baseline
> Requirements. They may, however, collect and aggregate information.
> Symantec proposal: Symantec currently uses a 2-step process - validation
> and review. Symantec should be allowed to do the first, with the SubCA
> doing the second (with 100% review, not samplingh).
> Rationale: reducing the burden on the SubCA, reducing the time for them
> to ramp up, and (presumably) to allow the Symantec personnel to continue
> to have jobs.
> 
> 5) Use of DTPs by SubCA
> 
> Google proposal: SubCAs may not use Delegated Third Parties in the
> validation process for domain names or IP addresses.
> Symantec proposal: SubCAs should be allowed to continue to use them in
> situations where they already do.
> Rationale: SubCAs should not be required to rejig their processes to
> work with Symantec.
> 
> 6) SubCA Audit Timing
> 
> Google proposal: SubCAs are audited at 3 month intervals in the 1st
> year, 6 months intervals in the 2nd year, and then yearly.
> Symantec proposal: after the initial audit, only yearly audits should be
> required.
> 

Re: New undisclosed intermediates

2017-06-08 Thread wizard--- via dev-security-policy
But Censys lists it as a trusted intermediate chaining to a root ( 
ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa ) in NSS: 

https://censys.io/certificates/b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca/validation

With respect to Gerv's question: given the ample time to disclose 
intermediates, and given all CAs in the program indicated that they had, seems 
reasonable to immediately add undisclosed ones that are discovered to OneCRL. 
Other than some breakage, as already noted, main downside would seem to be 
potentially large growth in OneCRL.

On Thursday, June 8, 2017 at 7:58:51 AM UTC-4, Kurt Roeckx wrote:
> On 2017-06-08 13:31, richmoor...@gmail.com wrote:
> > This one is interesting since the domain name of the CRL resolves to an RFC 
> > 1918 IP address. Surely that is a violation of the baseline requirements.
> > 
> > https://crt.sh/?sha256=b82210cde9ddea0e14be29af647e4b32f96ed2a9ef1aa5baa9cc64b38b6c01ca
> 
> That seems to be a root CA. It does not mention any CRL. I don't expect 
> a root CA to have a CRL. I'm not sure from where crt.sh is getting the 
> CRL URL.
> 
> 
> Kurt

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


Re: Symantec: Update

2017-05-11 Thread 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: Draft further questions for Symantec

2017-05-08 Thread wizard--- via dev-security-policy
In addition to requesting disclosure of intermediates that have been (even if 
not currently are) able to issue server certs, and the catchall, both of which 
seem excellent, I encourage Mozilla to consider asking these questions as part 
of an implemented remedy plan.

That is, put in motion Mozilla's plan of action given all the information 
available today, but note that certain modifications are possible should 
Symantec provide in responses to these queries additional information Mozilla 
considers useful and actionable.

For example, consider executing the planned phase out of all existing symantec 
certs by early next year, with distrust of all existing roots at that time, and 
a limit on new cert lifetimes of 13 months.  But should symantec become a 
leader in reducing cert lifetimes with the stand up of a clean PKI (cf. Eric 
Mill's proposal), then Mozilla would strive to (a) include the new roots by 
next year, and (b) accept certs with lifetime of 27 months. Or, should symantec 
be able to verifiably demonstrate other things (e.g. a complete map of their 
PKI inter-relations, and all parts that are non-BR compliant and thus should be 
distrusted), then the old ones might not be removed.

Yes, this is harder on the coders (I sympthasize), but how much longer can the 
current situation (and the risks it does pose *today*) go on?

On Monday, May 8, 2017 at 1:08:27 PM UTC-4, richm...@gmail.com wrote:
> On Monday, May 8, 2017 at 1:24:28 PM UTC+1, Gervase Markham wrote:
> > I think it might be appropriate to have a further round of questions to
> > Symantec from Mozilla, to try and get some clarity on some outstanding
> > and concerning issues. Here are some _proposed_ questions; feel free to
> > suggest modifications or other questions, and I will decide what to send
> > officially to Symantec in a few days. Please focus on formulating
> > questions which would have an effect on Mozilla's view of Symantec or
> > our response to the recent issues.
> 
> How about adding a catch all:
> 
> Are you aware of any information that might have an effect on Mozilla's view 
> of Symantec, our response to the recent issues or any of any further issues 
> that have not been disclosed to us so far?
> 
> Cheers
> 
> Rich.

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


Re: Symantec: Draft Proposal

2017-05-08 Thread wizard--- via dev-security-policy
It makes perfect sense if the game plan is to force continued delays of 
decisions on the part of root programs! Which appears to be exactly what is 
happening. After all, wait long enough, and it can be claimed that all possibly 
bad things would be expired, so don't distrust us, m'ok.

I think the idea of giving Symantec a path to keep 27 month certificates, e.g. 
Coupled to the standup of a new PKI, makes a lot of sense, since going to a new 
PKI would help get rid of the risks associated with the present PKI, and make a 
big player a leader in making shorter lifetimes a reality (In the absence of a 
new PKI it would seem 9 mo or 13 mo validity is needed to reduce ecosystem 
risk).

On Sunday, May 7, 2017 at 6:56:56 PM UTC-4, Eric Mill wrote:
> On Sun, May 7, 2017 at 6:09 PM, Rick Andrews via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > I'm posting this on behalf of Symantec:
> >
> > We would like to update the community about our ongoing dialogue with
> > Google.
> >
> > Following our May 4th post, senior executives at Google and Symantec
> > established a new dialogue with the intention to arrive at a new proposal
> > for the community that addresses the substantial customer impact that would
> > result from prior proposals. We urge Symantec customers and the browser
> > community to pause on decisions related to this matter until final
> > proposals are posted and accepted.
> 
> 
> This call for the browser community to not make any decisions until Google
> and Symantec finalize and accept a proposal completely marginalizes and
> ignores both Mozilla and the broader web community.
> 
> The "new dialogue" part also comes across as having gone over Ryan's head.
> This is unfortunately consistent with Symantec's latest blog post, which
> unprofessionally referred to proposals by "Mr. Sleevi" and "Mr. Markham".
> These statements personalize the issue and marginalize the proposals by
> casting them as individual opinions and not the views of their
> organization. They also reinforce the perception that Symantec sees their
> situation as the product of an unreasonable person or two and not the
> result of their own errors.
> 
> This list just spent the last two weeks focused on a large host of issues,
> curated by Mozilla on their wiki and discussed by the broader community
> here. So far, all Symantec has done to publicly respond to those is to send
> a single email per-issue, and then not otherwise participate in the
> discussion beyond blog posts.
> 
> Posting a call to Mozilla's community list asking for Mozilla and its
> community to pause while Symantec gets on the phone with senior Google
> executives to work it all out is a baffling tactic. I hope Mozilla
> continues to assert its stake in this process.
> 
> -- Eric
> 
> The intent of both Google and Symantec is to arrive at a proposal that
> > improves security while minimizing business disruption across the community.
> >
> > We want to reassure the community that we are taking these matters and the
> > impact on the community very seriously.
> > ___
> > 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: [EXT] Re: Symantec: Draft Proposal

2017-05-05 Thread wizard--- via dev-security-policy
Steve,

Thank you for the prompt response, and I am glad this certificate was in fact 
validated internally by Symantec.

On Tuesday, May 2, 2017 at 6:55:13 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
> > wizard--- via dev-security-policy
> > Sent: Tuesday, May 02, 2017 7:10 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: [EXT] Re: Symantec: Draft Proposal
> >
> >
> > Also, in the responses, Symantec claims that MSC Trustgate is no longer an
> > RA (but could be a reseller). I did a quick search on crt.sh for recent
> > certificates that have supplied by MSC Trustgate:
> >
> > [link]
> >
> > Going back to April 2013, this is the *only* "supplied by MSC trustgate"
> > certificate in crt.sh that chains off a Symantec root; all others are 
> > Globalsign.
> > Can Symantec confirm that they vetted this (OV) certificate in-house? While 
> > I
> > suppose MSC could supply certs from multiple CAs, I find it odd that
> > everything in the logs since April 2013 is Globalsign except this one 
> > outlier --
> > and am concerned it means there was some mechanism for MSC to issue /
> > have issued a cert off a Symantec chain -- and this concerns me given the
> > higher nominal level of validation.
> 
> MSC Trustgate is an approved reseller of Symantec certificates. They are no 
> longer operating as an SSL/TLS RA. This certificate was authenticated and 
> issued by Symantec after having been properly submitted to us by MSC 
> Trustgate.

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


Re: Symantec: Draft Proposal

2017-05-02 Thread wizard--- via dev-security-policy
This seems like a very reasonable stance for Mozilla to take: strongly 
encourage a new Symantec PKI so they start with a clean slate, otherwise staged 
distrust of all existing certificates with the requirement that Symantec 
produce a full document/diagram of how the components of their PKI are 
connected so that the non-BR-compliant bits can be "chopped off" from trust via 
OneCRL.

Given Symantec's propensity for responding right at deadlines, might I suggest 
that, should Symantec not choose to stand up a new PKI, that you set a 
reasonable deadline for the production of the document described above? Perhaps 
May 12th?

Also, in the responses, Symantec claims that MSC Trustgate is no longer an RA 
(but could be a reseller). I did a quick search on crt.sh for recent 
certificates that have supplied by MSC Trustgate:

https://crt.sh/?Identity=%25MSC+Trustgate.com+Sdn+Bhd

It looks to me like MSC is now a globalsign reseller (sure, why not). But one 
certificate stood out:

https://crt.sh/?id=68658151

Going back to April 2013, this is the *only* "supplied by MSC trustgate" 
certificate in crt.sh that chains off a Symantec root; all others are 
Globalsign. Can Symantec confirm that they vetted this (OV) certificate 
in-house? While I suppose MSC could supply certs from multiple CAs, I find it 
odd that everything in the logs since April 2013 is Globalsign except this one 
outlier -- and am concerned it means there was some mechanism for MSC to issue 
/ have issued a cert off a Symantec chain -- and this concerns me given the 
higher nominal level of validation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Symantec Conclusions and Next Steps

2017-04-27 Thread wizard--- via dev-security-policy
I don't know about others, but I am quite disappointed by Symantec's proposed 
remediation plan. Intentional or not, these response seems to indicate they 
don't really understand the potential consequences of many of their past 
actions.  Essentially, they promise to:

1) Have a third party audit all of their EV certs
2) Have a third party audit all of their partner certs
3) Have quarterly audits
4) Will offer certs with 3 month validity periods
5) Engage better with CAB and browser programs to help the ecosystem

These steps, while no doubt appealing to Symantec and its customers, do not 
address the significant relying party risks introduced by their past actions, 
including allowing various third parties carte blanche to issue certs chaining 
to publicly trusted roots without meaningful oversight (issues L, W, and Y). 
This is compounded by apparent institutional difficulties with properly 
identifying the scope of problems and resolving them (e.g. why did SHA-1 Issue 
H not lead to procedures so Issue J didn't happen; on Issue D, why did the 
first set of test cert mis-issues not catch the March 2016 ones?). Further 
doubts as to the trustworthiness of Symantec's PKI comes from the significant 
lack of oversight (intentional or not) even in cases where they *knew* there 
were problems (e.g. Issues P,Q,T,V). 

In light of this history (as well as related history for other CAs discussed on 
this forum in the past), on what basis are relying parties supposed to conclude 
that "more audits" and a "promise to do better" is a sufficient response?

It seems to me the existing Symantec PKI is a mess and any steps short of 
complete distrust of all existing roots leaves relying parties exposed to 
significant risk.

No-one (apparently not even Symantec given demonstrated past inability to 
identify similar issues within their PKI) has a full view of all the past 
actions (e.g. cross-signs, creation of unconstrained CAs, etc.) under their 
existing roots; and the scope of issues here are more serious than other cases 
that have led to full dis-trust under Mozilla's program. 

The problem of course is compatibility (Symantec's own plan essentially says 
"yes, many bad architectural decisions were made by us and our (mostly large 
enterprise) clients, so we are too big to fail and you can't do drastic 
things").

But this does not absolve Symantec's existing PKI of their 6+ year history of 
poor decisions and management.

So what about the following: plan a scheduled phasing out of trust in existing 
Symantec certificates (timeline from Google's proposal seems reasonable), but 
with all certificates chaining to existing roots, and the old roots themselves, 
distrusted in the final milestone. 

This may seem more extreme, but with one addition there are some attractive 
features that actually reduce compatibility risks (especially to non-browser 
facing systems), allows symantec to rearchitect their public PKI to follow 
practices that should help avoid complete distrusts in the future, and gives 
stronger assurances to relying parties:

To deal with the compatibility consequences, during this timeframe, permit 
Symantec to generate and begin using new root CAs. These roots could/should be 
unidirectionally cross-signed by one or more of their existing (but to be 
removed) roots, so that they can begin issuing replacement certificates 
~immediately for their customers from sub CAs under the new roots. The plan 
would then be to strive to have these new roots incorporated in the trust store 
by the time of the final milestone above (and given Symantec's public 
statements to support their customers, they would actually do this).

>From the perspective of the public web PKI, this "cleans the slate", and 
>allows the various root programs to clearly articulate requirements under 
>which these new roots operate (eg mandatory disclosure and auditing of all 
>subCAs and cross-signed roots (and their subCAs) *technically capable* (even 
>if administratively constrained or constrained by technical means not 
>recognized by public web PKI browsers) of issuing browser trusted 
>certificates, CT logging, validation methods, certificate validity limits, 
>etc). Since these new roots don't have legacy baggage, any violations of root 
>program policy thus become clear cut, simplifying monitoring.

If done right, this approach might even help *reduce* compatibility issues. 
Each server using existing Symantec certificates falls into one of three 
categories:
1) services solely non-browser clients (eg fixed firmware devices, apps,...)
2) services solely browser clients
3) services both 1&2

#1 should be completely unaffected by the above plan (continue to use 
Symantec's old PKI which is now essentially a large private PKI).

#2 has three sub-categories:
2a: solely browsers managed by enterprise policy: these can be made immune to 
the above (and continue to use Symantec's old PKI) if the to be publicly 
distrusted roots can be