Symantec: Draft Proposal

[Gervase Markham]

Here is my analysis and proposal for what actions the Mozilla CA
Certificates module owner should take in respect of Symantec.

https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#

Please discuss the document here in mozilla.dev.security.policy. A good
timeframe for discussion would be one week; we would aim to finalise the
plan and pass it to the module owner for a decision next Monday, 8th
May. Note that Kathleen is not around until Wednesday, and may choose to
read rather than comment here. It is not a given that she will agree
with me, or the final form of the proposal :-)

Gerv

[Alex Gaynor]

Hi Gerv,

One idea that occurred to me (maybe novel, though I doubt it), is requiring
mandatory _timely_ CT submission for intermediates/cross signatures. That
is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be
less than some period, perhaps 3 days. This would ensure rapid visibility
into important changes to the WebPKI.

Alex

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

[Rob Stradling]

On 01/05/17 18:33, Alex Gaynor via dev-security-policy wrote:
> Hi Gerv,
>
> One idea that occurred to me (maybe novel, though I doubt it), is requiring
> mandatory _timely_ CT submission for intermediates/cross signatures. That
> is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be
> less than some period, perhaps 3 days. This would ensure rapid visibility
> into important changes to the WebPKI.

Hi Alex. Mandatory timely CCADB submission is already planned (for the
next version of the Mozilla Root Store Policy, I presume):

https://github.com/mozilla/pkipolicy/commit/b7d1b6c04458114fbe73fa3f146ad401235c2a1b

I keep an eye on https://crt.sh/mozilla-disclosures#unknown (which shows
intermediates known to CCADB but not yet known to CT/crt.sh). When an
intermediate appears in that list, I'll grab the PEM data from CCADB,
paste it onto https://crt.sh/gen-add-chain, and then submit it to some
CT logs. However, it would be great if the CAs would do this
themselves. :-)

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Gervase Markham]

On 01/05/17 18:33, Alex Gaynor wrote:
> One idea that occurred to me (maybe novel, though I doubt it), is requiring
> mandatory _timely_ CT submission for intermediates/cross signatures. That
> is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be
> less than some period, perhaps 3 days. This would ensure rapid visibility
> into important changes to the WebPKI.

Interesting idea. Thanks for suggesting it :-) So something like:

Any certificate issued in Symantec's publicly-trusted hierarchies with
the cA boolean set to TRUE in basicConstraints must be submitted to two
public CT logs within 3 days of issuance.

Gerv

[tmcque...@gmail.com]

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.

[Kurt Roeckx]

I assume that would include all there certificates including those not
chaining to one in the Mozilla root store because they are for instance
only used for code signing? I guess we don't care about those that only
chain to a root that has been removed?


Kurt

[Steve Medin]

Gerv- Thank you for the thoughtful analysis. We are reviewing and intend to respond to your latest proposal shortly.

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Monday, May 01, 2017 10:16 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: [EXT] Symantec: Draft Proposal
>
> Here is my analysis and proposal for what actions the Mozilla CA Certificates
> module owner should take in respect of Symantec.
>

> https://clicktime.symantec.com/a/1/embmpyHl0xYIotG8R33Pcl_WmrsRKtG6
> UZVWv_jadWg=?d=977fUDFLd45Mc01kdDpFIhp6BGh6E7vHhynhAdgYKc7LS5
> -IW4PMfwwNk44IWsf3kg5SL1bzVN-
> 8qX842oWjKLUf2m0Opcf9ODVHP1yk400fxZY5ty4Y7BHrKRTStgnQaIyPPxl9e3l
> AN-
> M5fnM7v_3sviEmWrjTcLDXrkH6P3_FhoZEWwOu7_SX_QsCYpqcwNH3EeXWn
> 8BVLk1qqeWV5Bif1bTaL7Tt5x_6O96V7wmSpo0fuZsKDynd5LRJ5avq6ktSx2zc6
> BxeiHPXpDkIDzTHojYMzatcb0laJUTi5E44JYuI814oUpBm5xZoXoYGsUEwyOjur
> brIcHHkAb_putgEp4COnDlh3Hs74FPlR6WYnSOOiCdCydUdXVYLK3_OMlBomq
> iTSb6W4q8rG_2GPMwHZCk0nBrDFZ0Ncr6WDZU%3D&u=https%3A%2F%2Fd
> ocs.google.com%2Fdocument%2Fd%2F1RhDcwbMeqgE2Cb5e6xaPq-
> lUPmatQZwx3Sn2NPz9jF8%2Fedit%23

[Gervase Markham]

Hi Steve,

On 02/05/17 18:39, Steve Medin wrote:
> Gerv- Thank you for the thoughtful analysis. We are reviewing and intend to respond to your latest proposal shortly.

Please understand that this is not (yet) Mozilla's response to Symantec.
If we were a closed root program, this would be an internal discussion
draft. As we do everything in the open you get to read it now, but it
may change before we make a formal decision on our position. You are
welcome to participate in the discussion, but it is probably too early
for a formal response to the document as a whole.

If there are errors of fact in it, I would particularly appreciate
correction.

Gerv

[Steve Medin]

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of
> wizard--- via dev-security-policy
> Sent: Tuesday, May 02, 2017 7:10 AM
> To: mozilla-dev-s...@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.

[Han Yuwei]

So Mozilla think Symantec's issues are on t serious enough to lose trust entirely?

[Jakob Bohm]

Some notes on the text now in the document:

1. Issue D actually seems to conflate three *completely different*
issues:

D1) MisIssuance of actual test certificates for real world domains
that had not approved that issuance. I think this was mostly the
old issue involving a very small number of improper in-house test
certs by Symantec.

D2) Dubious / non-permitted substitution of the word "test" for the
organization name in otherwise fully validated OV certificates as
a service to legitimate domain holders wanting to test Symantec
certificates before paying for final issuance of certs with their
actual name. This was much less harmful, but was done in large
numbers by the CrossCert RA.

D3) Dubious and actual misussance of certificates for some domains
containing "test" as a substring under the direction of the
CrossCert RA. These vary in seriousness but I think their total
number is much smaller than those in category D2.

Splitting these three kinds of "test" certificates will properly give
a much clearer issue of what was going on and how serious it was.

2. If the remaining unconstrained SubCAs are operated by Symantec and
subject to (retroactive if necessary) compliance audits showing that
they don't issue certs that could not (under the BR and Mozilla
policies) be issued from a public Symantec CA by an "Enterprise RA"
(as defined in the BRs), could those SubCAs not simply be
reclassified as "public SubCAs" for Mozilla/BR policy purposes while
remaining further usage limited by actual Symantec practices and
contractual arrangements beyond the BR/Mozilla policies?

3. The plan involving a new hierarchy outsourced to a Symantec
competitor leaves some big questions when seen from outside the
Google perspective:

- Is it really necessary to outsource this to bring the Symantec PKI
under control? Or was this simply copy/pasted from the
WoSign/StartCom situation?

- If this is outsourced as suggested, how can/should Symantec
continue to serve customers wanting certificates that chain to
older CA certs in the old hierarchy. For example some brands of
Smartphones require that all apps installed are signed by specific
old Symantec hierarchies via exclusivity deals that were in place
when those Smartphones were manufactured, and no changes to that
requirement are feasible at this point for the already sold phones.
Similar issues may exist in the WebPKI for jobs such as providing
HTTPS downloads of Firefox to machines whose existing browser is
outdated and contains an outdated root store.

- Should Symantec be allowed to cross-sign SubCAs of the new roots
directly from the old roots, thus keeping the chain length to the
old roots short?

- Could some of the good SubCAs under the "Universal" and "Georoot"
program be salvaged by signing them from new roots and adding the
cross certs to default Mozilla and Chrome installations (so servers
don't need to install them)? For example, if the legit EV SubCAs
under "Universal" are cross-signed by a (new) "EV-only" root, could
Mozilla move the EV trust to that new root, thus removing the
risk of EV-trusting any other "Universal" subCAs.


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

[Alex Gaynor]

Hi all,

This morning Symantec disclosed ~20 new intermediate certs. I went through
these and identified 7 of them which are a) not revoked, b) not expired, c)
lack a BR audit:

https://crt.sh/?q=54EFD2977D89EDE24DDC3797CEB5A80668B3905788B58FB1AC6893EF4B78A24A
https://crt.sh/?q=D7D90D0FCFB5CDEC5754D663EEB3915D53703E1A29FAEEB398DCE0E22B5D4F9A
https://crt.sh/?q=58FED89E47BC48DDC659419BB64BD0862A448FCB25842F8A3FA3671FF6468F42
https://crt.sh/?q=9127783BF5190D85BC5248364145AA683EC49CD63F344721B3914E2CAF61D7A0
https://crt.sh/?q=CC6D4E8FD20599A8CC23E739774EAFB70D03B24A824C0E05D94666F5E29FC5CA
https://crt.sh/?q=DEEE5527B753A18D02BA2DAD6DFFB674CED0AF657BC0F430D4B32D97580F4D0E
https://crt.sh/?q=BC983BE6435622EF64C8EFD23084D6F8E5DCFBE9D7BCFCE6A5E51C75A29D549A

I believe this further underscores finding Y, and others related to lack of
visibility into and BR-compliance of Symantec's intermediates.

The fact that we can still be finding new intermediates leaves me to wonder
if this is really the last of them, or there are still more. Personally, I
think this highlights the value of my earlier proposal, and I think it's
worth considering if, before any long term remediation strategies are
considered, such a rule requiring full disclosure and CT submission of all
Symantec CA certificates be implemented.

Cheers,
Alex

On Thu, May 4, 2017 at 2:30 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 01/05/2017 16:16, Gervase Markham wrote:
>

[Ryan Sleevi]

Gerv,



Regarding your understanding of the “First Chrome Proposal”, which seems to
have influenced your “Alternative” suggestions, some quick clarifications:



(Wearing a Chrome/Google hat here)



The first Chrome proposal was operating on the concern that a complete and
total removal of trust in Symantec might be necessary, similar to the ones
practiced for other CAs that have issued or permitted unconstrained
intermediates. While CNNIC saw a full removal of trust relatively quickly,
and for which Mozilla produced a rather long analysis of the issues
<https://blog.mozilla.org/security/files/2015/04/CNNIC-MCS.pdf>, the
concern was that Symantec’s scale and scope prevented the immediate ability
to treat them the same, without significantly disrupting users and site
operators, and thus aimed to move the ecosystem forward on security and to
shake out the issues and impact of a full distrust.



However, recognizing the practical limitations - that a whitelist (as used
for CNNIC) would be too large, and that a notBefore block (as used with
WoSign/StartCom) would not only be inadequate for the issues (since an
intermediate can bypass those), but also be particularly disruptive (for
things such as pinning or which rely on the ubiquity of roots) - the first
proposal sought to accomplish that by gradually reducing the validity
period - first to nine months, certainly, while allowing a continued
investigation into further issues that might signal the need for total
distrust while balancing users’ needs and security. It was not an
assumption that the issues had been resolved, or that new certificates
would be fine - rather, it was based on the evidence that there were issues
and patterns that were unresolved, and thus sought to minimize the impact
of an eventual total distrust in a gradual way.



(Personally speaking from here on, and the opinions here do not necessarily
reflect that of my employer/Google)



Regarding EV certificates, your analysis of EV certificates appears to have
failed to include Issue D. In particular, in the iterations of the Final
Reports, Symantec acknowledged that their authentication team was not
properly reviewing the work of validation. That is, EV certificates are
required to have a separation of duties to ensure multi-party control
(Section 14.1.3), while Symantec’s incident report notes that:

“When testing features involving Organization or Extended Validation
certificates, our authentication team has a specific review and approval
process designed for issuance of internal-only Symantec test certificates.
The existing policy was explicit that this process should only be used for
Symantec-owned domains. That process was not followed in the issuance of
these test certificates that included non-Symantec domains. We have updated
the test certificate approval process tools and team training to ensure
that this process is only applied to the issuance of test certificates for
Symantec-owned domains“



This is also captured in “Issue 3” on https://www.symantec.com/page.
jsp?id=test-certs-update#



I’m also having trouble finding assertions or guarantees from Symantec that
at no point has any RA been involved in the issuance of EV certificates. If
Symantec is unwilling or unable to provide that assurance, or if it later
emerges that evidence of such issuance is found, does Mozilla have any
thoughts on how best to address it? More specifically - would that be a
removal of EV or a removal of trust, should such evidence emerge?



Regarding your analysis of the other incidents for precedent, you drew a
bright line around intentional deception in the case of WoSign and
StartCom, which seems a little heavy-handed. Were you thinking about their
response to the disclosure of StartCom’s sale, or to the backdated
issuance? Does Mozilla have a process for determining what is deceptive
and/or intentional? During those past discussions, there was concern that
perhaps the answers were just based on a misunderstanding of the request,
and not intentional deception. Richard Wang certainly argued this
perspective, in part, in his Incident Report regarding Issue R
<https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf>.
Wouldn’t it be better to not speculate intent - and instead examine the
result and whether the expectations placed on CAs were clear and
unambiguous. In the case of WoSign, Mozilla’s policy on SHA-1 issuance was
clear, and, judging by other CAs actions, so was the policy on
acquisitions. It was also clear when Mozilla asked WoSign regarding the
acquisition what was expected.



I’m curious how you view the answers for Q9. In particular, in light of the
subsequent information disclosing that third-party RAs are involved in the
issuance of domain controller certificates, for which the publicly
available evidence suggests are indistinguishable from SSL/TLS
certificates, thus in scope of the Mozilla Certificate Policy, what was the
reasonable or common understanding of CAs on what was being asked, and was
it upheld? Further, given the the lack of complete disclosure of some
subordinates, or the exclusion of other subordinates from the scope of the
audits that they’re claimed to participate in, at what point does the
result become unreasonable?



I ask this, in part, because your alternative proposal to moving to new,
independently operated infrastructure to take some form of immediate action
to clean up and document the extent of the publicly-trusted PKI. Given the
statements Symantec made to Mozilla - in May 13, 2014
<https://wiki.mozilla.org/CA:Communications#May_13.2C_2014> and in May 2015
<https://wiki.mozilla.org/CA:Communications#May_2015> - asserting to
Mozilla that they had fully disclosed their subordinate certificates, and
that those capable of issuance were in compliance with Mozilla’s policies,
how does this alternative proposal require anything new or different of
Symantec? Mozilla has already required of all CAs what you propose as a
viable alternative, and seemingly all CAs, excluding Symantec, have already
been in compliance with that requirement. In light of the statements made
in the CNNIC analysis, do you believe that granting an extension for
disclosure is consistent with the standards and expectations
<https://blog.mozilla.org/security/files/2015/04/CNNIC-MCS.pdf> that
Mozilla outlined, and with Section 7.3 of Mozilla’s policy?

On Mon, May 1, 2017 at 10:16 AM, Gervase Markham via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> Here is my analysis and proposal for what actions the Mozilla CA
> Certificates module owner should take in respect of Symantec.
>
> https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-
> lUPmatQZwx3Sn2NPz9jF8/edit#
>
> Please discuss the document here in mozilla.dev.security.policy. A good
> timeframe for discussion would be one week; we would aim to finalise the
> plan and pass it to the module owner for a decision next Monday, 8th
> May. Note that Kathleen is not around until Wednesday, and may choose to
> read rather than comment here. It is not a given that she will agree
> with me, or the final form of the proposal :-)
>

> Gerv

[Steve Medin]

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symant...@lists.mozilla.org] On Behalf Of

> Gervase Markham via dev-security-policy
> Sent: Monday, May 01, 2017 10:16 AM
> To: mozilla-dev-s...@lists.mozilla.org

> Subject: [EXT] Symantec: Draft Proposal
>
> Here is my analysis and proposal for what actions the Mozilla CA
Certificates
> module owner should take in respect of Symantec.
>

[snip]

> Please discuss the document here in mozilla.dev.security.policy. A good
> timeframe for discussion would be one week; we would aim to finalise the
> plan and pass it to the module owner for a decision next Monday, 8th May.
> Note that Kathleen is not around until Wednesday, and may choose to read
> rather than comment here. It is not a given that she will agree with me,
or
> the final form of the proposal :-)
>
> Gerv

Gerv, thank you for your draft proposal under consideration. We have posted
our comments and detailed information at:
https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue
.

[tmcque...@gmail.com]

Steve,

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

[tmcque...@gmail.com]

Steve,

I am glad to see that Symantec is willing to continue public discussion on possible paths forward. But these responses still seem to continue to focus on the RA issue, and do not respond to or address all of the other serious issues identified here. For example, issue Y (Q9) -- un- or under- audited sub-CAs technically capable (even if administratively constrained) of issuing SSL/TLS certificates trusted by Mozilla (and others). Especially given that there are clearly still undislosed sub-CAs that Symantec is only now revealing (despite claims in 2014/2015 that all had been), at least one with a non-zero pathlen constraint (e.g. https://crt.sh/?sha256=68a9878d55ad42107cfeb758e34873686969b0a47c7468fb189991acb62da798 ) and thus capable not only of issuing end-entity certs, but of having undisclosed sub-subCAs.

For reasons such as this, I am highly skeptical that Symantec [intentionally or not] appreciates the gravity of the issues raised here; had Symantec's current proposal been the response to the test certificate problems from a couple of years ago, I would have considered it an appropriate response. Now I view it as an untenable position that can be succinctly described as: too little, too late, to restore confidence in Symantec management and issuance practices.

The argument against the new public PKI (making the existing symantec PKI a large private PKI) also seems quite weak, essentially boiling down to: Symantec thinks it is not a proportional response to the issues identified, implicitly acknowledging that it may mitigate many of the compatibility concerns of your customers as long as the new roots or subCAs are signed by the old roots as needed.

I'd also be very curious to know the answer to Ryan's question about EV certificates and RAs (both now and in the past), as the answer to that seems germane to Mozilla's decision making process.

Also, your reporting of the responses of your enterprise customers seems a bit incongruous: in the earlier response, you claimed many large enterprises would require months or years to plan a change of certificates -- but then claim here that should Symantec be restricted to 13 months, these customers will move to other CAs who can issue longer certs. But given the direction of travel in cert lifetimes (where 2 yr+renewal time begins in 2018 and it is plausible a 13 month lifetime may be required in 2-3 years), I don't understand how moving would be substantially advantageous to these customers (esp. since any of the proposals here would involve less compatability risks since chaining to the old symantec roots would be maintained).

[Kurt Roeckx]

On 2017-05-04 22:55, Alex Gaynor wrote:
> I believe this further underscores finding Y, and others related to lack of
> visibility into and BR-compliance of Symantec's intermediates.
>
> The fact that we can still be finding new intermediates leaves me to wonder
> if this is really the last of them, or there are still more. Personally, I
> think this highlights the value of my earlier proposal, and I think it's
> worth considering if, before any long term remediation strategies are
> considered, such a rule requiring full disclosure and CT submission of all
> Symantec CA certificates be implemented.

They were already required to disclose them, so I think just requiring
them to submit them to CT it not going to change much. You would also
need to enforce that all CA certificates have been submitted to CT when
validating anything that that traces back to one of their CAs. Note that
the subscriber certificate doesn't need to be submitted for that,
just all the CA certificates.

If we were to require submission to CT, we should probably also require
that it's been submitted to CT some time before, so that we can do such
checks as seeing they actually have the proper audit.

That leave what we should do with such certificates if they don't have
the needed audits. And I think Mozilla already has a policy for that,
which we should probably follow.


Kurt

[Alex Gaynor]

It is clear to me from reading this that there is a significant gap between
Symantec's perspective on the severity of the issues discussed and the
perspective of many m.d.s.p. participants. Hopefully this email will serve
to highlight some specific areas that contribute to this gap, and which
leads many of us to find Symantec's proposal insufficient.

Quoting:
> Moreover, the additional transparency we are already providing by logging
all certificates issued to Certificate Transparency logs – including DV and
OV – is a practice that the rest of the industry has yet to adopt.

Given that Symantec's CT logging was imposed as a requirement for continued
trust in Chrome, it is misleading to state that this reflects an effort by
Symantec to go above and beyond (particularly given that some other CAs
_voluntarily_ log all certs to CT).

That is, however, a question of style. To ask a substantive question, you
have asserted that all certificates issued have been logged to CT; this
Symantec CA currently has no publicly logged issued certificates:
https://crt.sh/?sha256=68a9878d55ad42107cfeb758e34873686969b0a47c7468fb189991acb62da798&opt=mozilladisclosure.
Can you confirm that this CA has _never_ been used to issue a certificate?
(There are several other similar Symantec intermediates for which there are
no publicly logged certs about which I have the same question).

Some of Symantec's assertions (particularly those about re-auditing issued
certificates) seem to largely revolve around distinguishing the level to
which their practices resulted in mis-issuance and the level of risk they
represented for relying parties. To use an analogy, if I have a publicly
trusted CA certificate and private key on a USB stick in my apartment, this
represents a _massive_ risk for relying parties everywhere, even I never
issue a single certificate from it. I would expect the WebPKI community to
treat this with the utmost severity, even if I never (mis-)issued a single
a certificate!

Finally, Symantec states "we have put forward a proposal [1] that provides
the highest level of transparency and reassurance of trust in active
SSL/TLS certificates available in the industry" and "we believe our
proposal provides the most open and transparent posture of any CA in the
industry and reassures trust in active Symantec certificates and our
current issuance practice". To help bridge the gap between Symantec and
many other participants understanding, if Symantec were to propose an _even
more_ aggressive remediation plan, aiming to achieve even higher levels of
reassurance, what is the next additional change you would propose?

Alex

[Gervase Markham]

On 04/05/17 19:30, Jakob Bohm wrote:
> 1. Issue D actually seems to conflate three *completely different*
> issues:

Are you sure you are not referring to the Issues List document here
rather than the proposal?

> 2. If the remaining unconstrained SubCAs are operated by Symantec and
> subject to (retroactive if necessary) compliance audits showing that
> they don't issue certs that could not (under the BR and Mozilla
> policies) be issued from a public Symantec CA by an "Enterprise RA"
> (as defined in the BRs), could those SubCAs not simply be
> reclassified as "public SubCAs" for Mozilla/BR policy purposes while
> remaining further usage limited by actual Symantec practices and
> contractual arrangements beyond the BR/Mozilla policies?

I'm afraid I just don't understand this.

> - Is it really necessary to outsource this to bring the Symantec PKI
> under control? Or was this simply copy/pasted from the
> WoSign/StartCom situation?

Nothing like this was proposed for WoSign/StartCom.

> - If this is outsourced as suggested, how can/should Symantec
> continue to serve customers wanting certificates that chain to
> older CA certs in the old hierarchy.

The old cross-signs the new.

> - Could some of the good SubCAs under the "Universal" and "Georoot"
> program be salvaged by signing them from new roots and adding the
> cross certs to default Mozilla and Chrome installations (so servers
> don't need to install them)? For example, if the legit EV SubCAs
> under "Universal" are cross-signed by a (new) "EV-only" root, could
> Mozilla move the EV trust to that new root, thus removing the
> risk of EV-trusting any other "Universal" subCAs.

I'm sure we'd be open to discussing implementation details like that.

Gerv

[Gervase Markham]

On 04/05/17 21:58, Ryan Sleevi wrote:> rather, it was based on the

evidence that there were issues
> and patterns that were unresolved, and thus sought to minimize the impact
> of an eventual total distrust in a gradual way.

So the first Chrome proposal had the explicit target of an eventual
total distrust? Or was it possible that, upon good behaviour from
Symantec, the extent of that proposal would remain the status quo on an
ongoing basis?

> Regarding EV certificates, your analysis of EV certificates appears to have
> failed to include Issue D.

Hmm, you are correct. At least one EV cert, for www.google.com, was
mis-issued in issue D; it ended up in CT logs. Noted.

> In particular, in the iterations of the Final
> Reports, Symantec acknowledged that their authentication team was not
> properly reviewing the work of validation. That is, EV certificates are
> required to have a separation of duties to ensure multi-party control
> (Section 14.1.3),

That section says: "The CA MUST enforce rigorous control procedures for
the separation of validation duties to ensure that no one person can
single-handedly validate and authorize the issuance of an EV Certificate."

While the Symantec report does not provide explicit evidence that this
part of the EV Guidelines was violated by their test certificate
issuance, you are right that it's likely it was.

> This is also captured in “Issue 3” on https://www.symantec.com/page.
> jsp?id=test-certs-update#

I don't see numbered issues, or an "Issue #3", at that URL?

> I’m also having trouble finding assertions or guarantees from Symantec that
> at no point has any RA been involved in the issuance of EV certificates.

I asked Symantec what fields CrossCert had control over. Their answer is
here on page 3:
https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825
It says CrossCert (and so, presumably, the other RAs in the program) had
no control over the CP field, which is (AIUI) the one they'd need to
change in order to add an EV OID. If I've got this wrong, please tell me
ASAP.

> If
> Symantec is unwilling or unable to provide that assurance, or if it later
> emerges that evidence of such issuance is found, does Mozilla have any
> thoughts on how best to address it? More specifically - would that be a
> removal of EV or a removal of trust, should such evidence emerge?

If these RAs had EV issuance capability, given the lack of oversight of
them and their lack of EV audits, I would consider that to be more than
sufficient grounds for removing the EV indicator from Symantec. As for a
removal of trust, I withhold judgement.

> Regarding your analysis of the other incidents for precedent, you drew a
> bright line around intentional deception in the case of WoSign and
> StartCom, which seems a little heavy-handed. Were you thinking about their
> response to the disclosure of StartCom’s sale, or to the backdated
> issuance?

Both. (Some of the relevant interactions regarding the sale were by
private email.)

> Does Mozilla have a process for determining what is deceptive
> and/or intentional? During those past discussions, there was concern that
> perhaps the answers were just based on a misunderstanding of the request,
> and not intentional deception. Richard Wang certainly argued this
> perspective, in part, in his Incident Report regarding Issue R
> <https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf>.

I am basing my assessment not only on the published documentation from
WoSign, but also the conversations we had at our face-to-face meeting,
where deception was plainly admitted.

> I’m curious how you view the answers for Q9.

Presumably you mean the answer in
https://bug1334377.bmoattachments.org/attachment.cgi?id=8860216
?

> In particular, in light of the
> subsequent information disclosing that third-party RAs are involved in the
> issuance of domain controller certificates, for which the publicly
> available evidence suggests are indistinguishable from SSL/TLS
> certificates, thus in scope of the Mozilla Certificate Policy, what was the
> reasonable or common understanding of CAs on what was being asked, and was
> it upheld? Further, given the the lack of complete disclosure of some
> subordinates, or the exclusion of other subordinates from the scope of the
> audits that they’re claimed to participate in, at what point does the
> result become unreasonable?

I guess I have a high standard for calling someone a liar.

> I ask this, in part, because your alternative proposal to moving to new,
> independently operated infrastructure to take some form of immediate action
> to clean up and document the extent of the publicly-trusted PKI. Given the
> statements Symantec made to Mozilla - in May 13, 2014
> <https://wiki.mozilla.org/CA:Communications#May_13.2C_2014> and in May 2015
> <https://wiki.mozilla.org/CA:Communications#May_2015> - asserting to
> Mozilla that they had fully disclosed their subordinate certificates, and
> that those capable of issuance were in compliance with Mozilla’s policies,
> how does this alternative proposal require anything new or different of
> Symantec?

That is a fair point. The continued discovery of new parts of Symantec's
PKI which have the ability to issue publicly trusted certificates (and
the lack of response from Symantec to the issue in general and these
additional revelations) makes me less inclined to support this solution.

Gerv

[Gervase Markham]

On 05/05/17 04:30, Steve Medin wrote:
> Gerv, thank you for your draft proposal under consideration. We have posted
> our comments and detailed information at:
> https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue

It feels somewhat strange to have this disjointed blog-vs.forum
conversation... Here are my initial reactions on reading it.

It seems to me that Symantec's new statement says very little which has
not been said before, and that Symantec continues to underestimate the
perceived severity of the issues.

An argument that "we have revalidated all of these certificates and we
haven't found very many with problems" seems basically like "OK, we
weren't paying attention to what was going on over there, but as far as
we can tell now, turns out it was nothing bad, so that's all OK then,
isn't it?" Well, no.

Symantec makes much of their upcoming super-strict audit regime, but
does not seem to address the concerns raised in my proposal about the
limitations of audit as a mechanism for ensuring appropriate conduct.

They also seem to have ceased engaging with the issues list entirely,
despite the fact that issue Y, a very serious issue, seems to be
developing new facets and ramifications daily.

> This transparency effort included explicitly providing to Google for
> whitelisting the certificates that were issued by Symantec prior to us
> fully deploying CT support.

I notice Chrome does not contain such a whitelist. Ryan: are you able to
comment on this?

> If this action is taken exclusively against Symantec, it will create
> significant disruption for hundreds of thousands of customers / users
> and will harm our CA business.

Mozilla does not take the possible business harm to CAs into
consideration - in either direction - when considering our appropriate
response to a CA incident. It is unreasonable of Symantec to argue that
Mozilla should only take actions which result in no harm to Symantec's
business, just as it would be unreasonable for a community member to
argue that Mozilla should take additional actions "because the harm
isn't great enough yet to teach them a lesson" or somesuch.

Gerv

[Peter Bowen]

On Fri, May 5, 2017 at 9:02 AM, Gervase Markham via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> On 04/05/17 21:58, Ryan Sleevi wrote:
>
> I asked Symantec what fields CrossCert had control over. Their answer is
> here on page 3:
> https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825
> It says CrossCert (and so, presumably, the other RAs in the program) had
> no control over the CP field, which is (AIUI) the one they'd need to
> change in order to add an EV OID. If I've got this wrong, please tell me
> ASAP.

Note footnote (1): "These attributes and extensions are static values
configured in the certificate profile"

We know that the RAs could use different certificate profiles, as
certificates they approved had varying issuers, and "Issuer DN" has
the same "No(1)" that CP has in the table in the doc you linked. I
don't see any indication of what profiles each RA was allowed to use.
It could be that Symantec provided one or more profiles to the RA that
contained EV OIDs.

Thanks,
Peter

[Gervase Markham]

On 05/05/17 17:09, Peter Bowen wrote:
> We know that the RAs could use different certificate profiles, as
> certificates they approved had varying issuers, and "Issuer DN" has
> the same "No(1)" that CP has in the table in the doc you linked. I
> don't see any indication of what profiles each RA was allowed to use.
> It could be that Symantec provided one or more profiles to the RA that
> contained EV OIDs.

So the question to Symantec is: "did any of the RAs in your program have
EV issuance capability? If not, given that they had issuance capability
from intermediates which chained up to EV-enabled roots, what technical
controls prevented them from having this capability?" Is that right?

Gerv

[Peter Bowen]

On Fri, May 5, 2017 at 9:18 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 05/05/17 17:09, Peter Bowen wrote:

>> We know that the RAs could use different certificate profiles, as
>> certificates they approved had varying issuers, and "Issuer DN" has
>> the same "No(1)" that CP has in the table in the doc you linked. I
>> don't see any indication of what profiles each RA was allowed to use.
>> It could be that Symantec provided one or more profiles to the RA that
>> contained EV OIDs.
>

> So the question to Symantec is: "did any of the RAs in your program have
> EV issuance capability? If not, given that they had issuance capability
> from intermediates which chained up to EV-enabled roots, what technical
> controls prevented them from having this capability?" Is that right?

I do not see answers to those questions in any of the documents
Symantec has attached to the bug.

Thanks,
Peter

[Andrew Ayer]

On Fri, 5 May 2017 17:18:38 +0100

Gervase Markham via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> On 05/05/17 17:09, Peter Bowen wrote:

> > We know that the RAs could use different certificate profiles, as
> > certificates they approved had varying issuers, and "Issuer DN" has
> > the same "No(1)" that CP has in the table in the doc you linked. I
> > don't see any indication of what profiles each RA was allowed to
> > use. It could be that Symantec provided one or more profiles to the
> > RA that contained EV OIDs.
>

> So the question to Symantec is: "did any of the RAs in your program
> have EV issuance capability? If not, given that they had issuance
> capability from intermediates which chained up to EV-enabled roots,
> what technical controls prevented them from having this capability?"
> Is that right?

It may be useful to note that Certsuperior, Certisur, Certisign, and
Crosscert were all advertising EV certificates on their websites at
some point in 2016:

http://web.archive.org/web/20160428051833/https://www.certsuperior.com/SecureSiteProEV.aspx

http://web.archive.org/web/20161114232112/https://www.certisur.com/soluciones/sitios-seguros

http://web.archive.org/web/20161101111634/https://www.certisign.com.br/certificado-servidor/ssl-validacao-avancada

http://web.archive.org/web/20161223000146/http://www.crosscert.com/

Regards,
Andrew

[Jakob Bohm]

On 05/05/2017 17:37, Gervase Markham wrote:
> On 04/05/17 19:30, Jakob Bohm wrote:
>> 1. Issue D actually seems to conflate three *completely different*
>> issues:
>
> Are you sure you are not referring to the Issues List document here
> rather than the proposal?
>

I am referring to the "summary" of D in the proposal, which talks about
"Test Certificate Misissuance - issuance of several thousand test
certs...", the descriptions I have found in the newsgroup talk about the
separate situations I call D1, D2 and D3, each of which was different in
their degree of misissuance and in their quantity.

I think summarizing it as misissuance times several thousands leads to
an exaggeration, and a suggestion that problems in one part occurred
also in another part.

From my understanding of past discussions:

D1 had actual misissuance, violation of procedures and apparently no
separation of duties. But it was a small number of certs, the private
keys never left Symantec, the certs were quickly revoked, it was years
ago and other concrete measures were taken.

D2 only violated a form requirement (that an actual company name should
be in the O field), but it was a deliberate violation of procedure, a
lack of RA oversight, collusion between separated duties at the RA and
a large number of certificates. And it was relatively recent.

D3 had actual misissuance (where CrossCert didn't control the test
domains) a deliberate violation of procedure, a lack of RA oversight,
collusion between separated duties at the RA and it was relatively
recent. But it was apparently a smallish number of certificates (I
don't think there was an actual counting of how many certs were
actually in category D3 versus false positives from issue D2
and valid uses of the word test).

Please correct me if I missed some other test certificate misissuance
incidents.

>> 2. If the remaining unconstrained SubCAs are operated by Symantec and
>> subject to (retroactive if necessary) compliance audits showing that
>> they don't issue certs that could not (under the BR and Mozilla
>> policies) be issued from a public Symantec CA by an "Enterprise RA"
>> (as defined in the BRs), could those SubCAs not simply be
>> reclassified as "public SubCAs" for Mozilla/BR policy purposes while
>> remaining further usage limited by actual Symantec practices and
>> contractual arrangements beyond the BR/Mozilla policies?
>
> I'm afraid I just don't understand this.
>

Symantec has claimed that some of the remaining unconstrained SubCA's
identified before my post (they had not yet commented on the most
recent batch found) are hosted within Symantec's infrastructure, which
means that Symantec probably has some direct control over issuance
limitations, as well as complete logs of all issued certs. This could
mean that reinterpreting their status as "public SubCAs subject to
Symantec policies and audits" rather than "flawed TCSCs lacking proper
'technical' constraints" could make them compliant.

Since such a formal/legal reinterpretation of the ground facts would be
retroactive going back from some time in May 2017 to when each SubCA
was issued, the related rephrased policy documents and additional BR
etc. audits would have to be similarly retroactive.

The goal of such a paperwork exercise would be to avoid revocation and
replacement of the EE certs issued from the SubCAs thus rescued.

>> - Is it really necessary to outsource this to bring the Symantec PKI
>> under control? Or was this simply copy/pasted from the
>> WoSign/StartCom situation?
>
> Nothing like this was proposed for WoSign/StartCom.

I seem to recall that making WoSign/StartCom a (possibly disguised)
reseller of certs from another CA was a suggestion made as to what
WoSign/StartCom could do to keep their customer relationships during
their minimum 1 year of complete distrust.

>
>> - If this is outsourced as suggested, how can/should Symantec
>> continue to serve customers wanting certificates that chain to
>> older CA certs in the old hierarchy.
>
> The old cross-signs the new.

Some of the examples I mention seem to have tree height or other
technical limitations baring this. Which means that to serve those
segments, Symantec would need to operate the core of their CA
infrastructure while not having the large volume of WebPKI and S/MIME
certificates to fund basic operations.

Also some of these operate in peculiar (CP specified) modes that
most/all other CAs don't have ready systems to handle. One variant
involve submitting the item to be signed to Symantec for (automated
and/or manual) inspection of the item, issuance of a one-off
certificate for signing that item followed by the immediate destruction
of the private key (this allows individual signatures to be revoked by
revoking the associated one-off cert).

>
>> - Could some of the good SubCAs under the "Universal" and "Georoot"
>> program be salvaged by signing them from new roots and adding the
>> cross certs to default Mozilla and Chrome installations (so servers
>> don't need to install them)? For example, if the legit EV SubCAs
>> under "Universal" are cross-signed by a (new) "EV-only" root, could
>> Mozilla move the EV trust to that new root, thus removing the
>> risk of EV-trusting any other "Universal" subCAs.
>
> I'm sure we'd be open to discussing implementation details like that.
>

[Eric Mill]

On Thu, May 4, 2017 at 11:30 PM, Steve Medin via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> Gerv, thank you for your draft proposal under consideration. We have posted
> our comments and detailed information at:
> https://www.symantec.com/connect/blogs/symantec-ca-
> continues-public-dialogue

(Posting in my personal capacity.)

Symantec says that Google's and Mozilla's proposals to impose a shorter
certificate lifetime will harm their CA business and cause customers to
move to other CAs.

The last time that Symantec was targeted for selective technical
enforcement was when Google imposed a CT requirement on Symantec-issued
certificates. Symantec had already set up a CT log and advocated for an
ecosystem-wide CT requirement before then, and responded to Google's
requirement by continuing this advocacy.

But in this case, Symantec is rejecting the premise and stating that to
impose a 13-month limit industry-wide would require automation and not be
feasible for enterprises, and lead to increased operating costs:

We also do not believe that a 13-month validity limit should be imposed on
the CA industry *at this time* – 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. As we have stated in our public response, many enterprises are not
at the level of automation maturity necessary to practically and
cost-effectively adopt shorter validity certificates. For these
organizations, standardizing on shorter validity certificates would present
substantial increases in their operating costs.


I believe that Symantec's assessment of this issue, expressed in this post
and in their public voting statement on Ballot 185 [1], is seriously
mistaken.

While it's certainly true that enterprises would experience some pain and
cost, Symantec states that 13-month certificates would either require
automation to use, or would create such a workload increase that IT shops
would have to hire staff. This is unpersuasive, as Mozilla and Google and
others (myself included) have tried to communicate throughout the various
discussions on this issue since January.

Everyone has recognized that a decrease to 90-day certificates would likely
create such a situation. However, as someone who has worked in very large
enterprises myself, I do not believe that moving to an annual renewal
schedule is infeasible for the enterprise community to handle.

Yes, it will cost them something, but the organizations that feel the pain
most acutely will logically be the largest ones -- and the largest
enterprises will also have the resources to respond appropriately.

As importantly, Symantec should be embracing changes that move enterprise
customers along the path towards automation. My experience is that the lack
of progress on automation is one of the most toxic and self-destructive
features of the enterprise IT sector. At scale, a reliance on error-prone
and unscalable human processes for basic infrastructure maintenance is a
massive contributor to defense being so much more expensive than offense
today.

Symantec's current proposal and blog post indicate that they are working to
create automation-friendly options for customers, but that's not nearly
sufficient to motivate the industry to change their behavior.

I believe that if Symantec changes their attitude and puts their full
weight behind shorter-lived certificates, it would indicate:

* A recognition that technical controls are superior to policy controls,
especially when a CA is of such a significant size that reliable policy
control enforcement becomes expensive.
* An understanding that Symantec's enterprise customers will always push
back on changes that create more work for them, but that Symantec's goal of
being an industry leader requires Symantec to lead their customers rather
than to follow their instructions.
* A belief that automation by default, on the part of both CAs and their
customers, is a collective action problem that is worth challenging the
industry to solve.

Those are the kinds of indicators that Mozilla and Google tend to weight
favorably in assessing the likelihood of future risk to users from a CA's
practices. So, I suggest that Mozilla and Google consider offering to drop
the portions of their proposals that limit Symantec's certificate lifetime,
if Symantec commits to supporting an industry-wide reduction in certificate
lifetimes to 13 months.

A commitment like this could take several forms, but to me it might look
like:

* Symantec publicly and privately asking the browser programs to impose an
industry-wide reduction by a reasonable date, whether or not a majority of
browsers support it, and whether or not 2/3 of CAs support it.
* Symantec proposing a ballot to impose this through the CA/Browser Forum's
Baseline requirements.
* Symantec immediately beginning to communicate to their customers the
positive security benefits of moving to 13-month-or-less certificates, and
Symantec's clear expectation (and support for) this to happen industry-wide
in the near future.

This would remove the aspect of the proposal most likely to create
competitive impacts to Symantec's business, and significantly easing the
path towards reducing certificate lifetimes.

Even though Symantec isn't handling this crisis of confidence well, I
believe the intent of Symantec's employees is good -- that they are there
to do more than just make money, and want to make the world a more stable
and secure place. However, the identified issues and Symantec's responses
suggest that their business incentives are not well-aligned with this goal.

Given Symantec's resources and reputation, I believe Symantec reconsidering
their stance on short-lived certificates would be a meaningful way for
Symantec to address that misalignment, and I suggest that browsers open
this path for them to take.

-- Eric

[1] https://cabforum.org/pipermail/public/2017-February/009701.html

[Rick Andrews]

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

[Kurt Roeckx]

On Sun, May 07, 2017 at 03:09:10PM -0700, Rick Andrews via dev-security-policy wrote:
> We urge Symantec customers and the browser community to pause on decisions related to this matter until final proposals are posted and accepted.

You appear to be saying that Mozilla doesn't have anything to say
anymore and that it's just between Symantec and Google and that
Mozilla and the rest of the community would just have to agree with
that.

I'm in no way speaking for Mozilla, but that looks like unacceptable
to me. I suggest that if you have a proposal that you post it to
this list, or that Google posts it to their list, before it's
accepted.


Kurt

[Eric Mill]

On Sun, May 7, 2017 at 6:09 PM, Rick Andrews via dev-security-policy <
dev-secur...@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.

[Vincent Lynch]

Hi Rick,

Can you provide an estimate on when this new proposal will be publicly shared?

-Vincent

[okaphone.e...@gmail.com]

Hi Rick,

I don't see a "May 4th post". Where was it posted? Not here it seems.

Also it's reasonable that Symantec wants to "address impact to their customers" but what about impact to all of the browsers users? It may be a good idea to try and address (in your proposals) that to.

So far I have not seen much more than "trust us, we take it seriously and we'll do it right from now on". But what do you think of Eric's idea? He seems to suggest a way forward that may be used to turn the whole debacle into an advantage for you.

CU Hans

[paul.leo....@gmail.com]

Am Montag, 8. Mai 2017 00:09:19 UTC+2 schrieb Rick Andrews:

> We urge Symantec customers and the browser community to pause on decisions related to this matter until final proposals are posted and accepted. 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.

If you want to retain the community's trust, the community urges you to pause private discussion with Google while you are discussing with the community. Any proposals can be posted in open if you care about the community at all.

[tmcque...@gmail.com]

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

[Alex Gaynor]

Hi Rick,

Does Symantec plan to introduce new facts into the conversation, or is all
the information we are currently considering accurate and complete?

If there's no new information, I don't see why the community of
participants in m.d.s.p. should pause. I think it's a point of pride for
many of us that Mozilla operates a transparent root program, with strong
community input, and we want to continue that strong tradition.

Alex

On Sun, May 7, 2017 at 6:09 PM, Rick Andrews via dev-security-policy <
dev-secur...@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. The intent of both Google and Symantec

[uri...@gmail.com]

On Monday, May 8, 2017 at 7:21:46 AM UTC-4, okaphone.e...@gmail.com wrote:
> Hi Rick,
>
> I don't see a "May 4th post". Where was it posted? Not here it seems.

It's above--it links to https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue

[Vincent Lynch]

Hello Rick,

This weekend you asked "customers and the browser community to pause on

decisions related to this matter until final proposals are posted and
accepted."

More than 48 hours ago I asked if you could provide someone sort of
estimate on when this proposal would be ready to be shared with the public.

I understand that this is a complicated process that is likely taking up
much of your time and is not an exact science.

However, I believe it is extremely important the community have some idea
when this new proposal with Google will be shared if you are asking that we
all wait for it.

Should we expect to see this proposal later this week? Next week? The end
of May? I think it's safe to say a broad estimate is better than nothing.

Thank you,

Vincent

On Sun, May 7, 2017 at 6:09 PM Rick Andrews via dev-security-policy <
dev-secur...@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. 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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Vincent Lynch

[Steve Medin]

Symantec logs TLS server certificates that are intended to be trusted by Chrome to Certificate Transparency logs. Symantec does not systematically log other certificate types to CT, including Class 1, Class 2 and other types of user certificates.



The Adobe Approved Trust List intermediate CA does not issue TLS certificates. This subCA issues Adobe document digital signature certificates that identify people and organizations and as such they are not systematically included in CT logging.



See also:

https://helpx.adobe.com/acrobat/kb/approved-trust-list2.html

https://helpx.adobe.com/acrobat/kb/approved-trust-list2/_jcr_content/main-pars/download-section/download-1/file.res/aatl_technical_requirements_v14.pdf





From: Alex Gaynor [mailto:aga...@mozilla.com]
Sent: Friday, May 05, 2017 10:18 AM
To: Steve Medin <Steve...@symantec.com>
Cc: Gervase Markham <ge...@mozilla.org>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: [EXT] Symantec: Draft Proposal



To ask a substantive question, you have asserted that all certificates issued have been logged to CT; this Symantec CA currently has no publicly logged issued certificates: https://crt.sh/?sha256=68a9878d55ad42107cfeb758e34873686969b0a47c7468fb189991acb62da798&opt=mozilladisclosure<https://clicktime.symantec.com/a/1/DpMVeod7OdWoZrchhebweNegkGMPsUHp-1SWSqHLiWg=?d=Z1VSr8kRHw-swZNCE6n0F6PJqS6Dawy0ZRX24ox8r12BLpDUpmwr2X0yO-UqN1DccyjCinObo29F4evy4ZTl321EROz_CUwk2Ph-0yTAk7_QFo0UyMEIbnfZbjKKwoOKM57FZ2pYUpkFOpFhmST_wLeoBztL6ERQ3p_LHV3k2r7Zvwr0y4AMyFUV-bsZ4TcJ8IxShADpdauwBawRNGCpwxuCt2rPgjaoGvJ5MOiYZcwFM00xu7ZRLvkJ7o577ceGmn6MisHkhyHX_7MZqVMtpUVMwU5L_HfezBj76rliUXPk9o1HD_udc5oCBn2sSiOSGZGQznN6inakQDPVY3BqkLX-UvpTxecosycllppwkMG7_iMTqQOfAuKCDrxHzhWL000nMcOq-afUAfeaHNF_&u=https%3A%2F%2Fcrt.sh%2F%3Fsha256%3D68a9878d55ad42107cfeb758e34873686969b0a47c7468fb189991acb62da798%26amp%3Bopt%3Dmozilladisclosure>. Can you confirm that this CA has _never_ been used to issue a certificate? (There are several other similar Symantec intermediates for which there are no publicly logged certs about which I have the same question).