RE: [EXT] Symantec: Draft Proposal

[Steve Medin via dev-security-policy]

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:agay...@mozilla.com]
Sent: Friday, May 05, 2017 10:18 AM
To: Steve Medin <steve_me...@symantec.com>
Cc: Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@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=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_=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 ar
 e several other similar Symantec intermediates for which there are no publicly 
logged certs about which I have the same question).

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

Re: Symantec: Draft Proposal

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

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 

> 
> 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
> 
> 
> On Monday, 8 May 2017 00:09:19 UTC+2, Rick Andrews  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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Draft Proposal

[Alex Gaynor via dev-security-policy]

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-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. 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: Symantec: Draft Proposal

[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: Symantec: Draft Proposal

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

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


On Monday, 8 May 2017 00:09:19 UTC+2, Rick Andrews  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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Draft Proposal

[Eric Mill via dev-security-policy]

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: Symantec: Draft Proposal

[Kurt Roeckx via dev-security-policy]

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

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

Re: Symantec: Draft Proposal

[Eric Mill via dev-security-policy]

On Thu, May 4, 2017 at 11:30 PM, Steve Medin via dev-security-policy <
dev-security-policy@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

Re: Symantec: Draft Proposal

[Jakob Bohm via dev-security-policy]

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 

Re: Symantec: Draft Proposal

[Andrew Ayer via dev-security-policy]

On Fri, 5 May 2017 17:18:38 +0100
Gervase Markham via dev-security-policy
 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/2016110634/https://www.certisign.com.br/certificado-servidor/ssl-validacao-avancada

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

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

Re: Symantec: Draft Proposal

[Peter Bowen via dev-security-policy]

On Fri, May 5, 2017 at 9:18 AM, Gervase Markham  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

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

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

Re: Symantec: Draft Proposal

[Peter Bowen via dev-security-policy]

On Fri, May 5, 2017 at 9:02 AM, Gervase Markham via
dev-security-policy  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [EXT] Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

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

Re: Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

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

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
>  and in May 2015
>  - asserting to
> Mozilla that they had fully disclosed their subordinate certificates, and
> that those 

Re: Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

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

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

Re: [EXT] Symantec: Draft Proposal

[Alex Gaynor via dev-security-policy]

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


On Thu, May 4, 2017 at 11:30 PM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > -Original Message-
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> > Gervase Markham via dev-security-policy
> > Sent: Monday, May 01, 2017 10:16 AM
> > To: mozilla-dev-security-pol...@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
> .
>
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Draft Proposal

[Kurt Roeckx via dev-security-policy]

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

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

Re: [EXT] Symantec: Draft Proposal

[tmcqueen.old--- via dev-security-policy]

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

On Thursday, May 4, 2017 at 11:30: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
> > Gervase Markham via dev-security-policy
> > Sent: Monday, May 01, 2017 10:16 AM
> > To: mozilla-dev-security-pol...@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
> .

___
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

[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: [EXT] Symantec: Draft Proposal

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Monday, May 01, 2017 10:16 AM
> To: mozilla-dev-security-pol...@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
. 
 



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

Re: Symantec: Draft Proposal

[Ryan Sleevi via dev-security-policy]

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

Re: Symantec: Draft Proposal

[Alex Gaynor via dev-security-policy]

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-security-policy@lists.mozilla.org> wrote:

> On 01/05/2017 16:16, Gervase Markham 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-lU
>> PmatQZwx3Sn2NPz9jF8/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 :-)
>>
>>
> 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
> 

Re: Symantec: Draft Proposal

[Jakob Bohm via dev-security-policy]

On 01/05/2017 16:16, Gervase Markham 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 :-)



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

Symantec: Draft Proposal

[Han Yuwei via dev-security-policy]

So Mozilla think Symantec's issues are on t serious enough to lose trust 
entirely?
___
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

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> 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: [EXT] Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

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



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

RE: [EXT] Symantec: Draft Proposal

[Steve Medin via dev-security-policy]

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=symantec@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Monday, May 01, 2017 10:16 AM
> To: mozilla-dev-security-pol...@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=https%3A%2F%2Fd
> ocs.google.com%2Fdocument%2Fd%2F1RhDcwbMeqgE2Cb5e6xaPq-
> lUPmatQZwx3Sn2NPz9jF8%2Fedit%23
>
> 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec: Draft Proposal

[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: Draft Proposal

[Gervase Markham via dev-security-policy]

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

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

Re: Symantec: Draft Proposal

[Rob Stradling via dev-security-policy]

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

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

Re: Symantec: Draft Proposal

[Alex Gaynor via dev-security-policy]

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

On Mon, May 1, 2017 at 10:16 AM, Gervase Markham via dev-security-policy <
dev-security-policy@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
> ___
> 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

Symantec: Draft Proposal

[Gervase Markham via dev-security-policy]

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