RE: CA generated keys

[Steve Medin via dev-security-policy]

Loosen the interpretation of escrow from a box surrounded by KRAs, KROs, and 
access controls with a rolling LTSK and escrow could describe what many white 
glove and CDN tier hosting operations do. The CDN has written consent, but the 
end customer never touches the TLS cert.


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve.medin=digicert@lists.mozilla.org] On Behalf Of Jeremy
> Rowley via dev-security-policy
> Sent: Monday, December 11, 2017 11:18 AM
> To: Gervase Markham ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: RE: CA generated keys
> 
> I think key escrow services are pretty rare related to TLS certs. However,
> there's lots of CAs and services that escrow signing keys for s/MIME certs.
> Although, I'm not sure how companies can claim non-repudiation if they've
> escrowed the signing key, a lot of enterprises use dual-use keys and want at
> least the encryption portion in case an employee leaves.
> 
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-
> bounces+jeremy.rowley=digicert.com@lists.mozilla
> .org] On Behalf Of Gervase Markham via dev-security-policy
> Sent: Monday, December 11, 2017 12:48 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: CA generated keys
> 
> Hi Tim,
> 
> The more I think about it, the more I see this is actually a interesting
> question :-)
> 
> I suspect the first thing Mozilla allowing this would do would be to make it
> much more common. (Let's assume there are no other policy
> barriers.) I suspect there are several simpler workflows for certificate
> issuance and installation that this could enable, and CAs would be keen to
> make their customers lives easier and reduce support costs.
> 
> On 09/12/17 18:20, Tim Hollebeek wrote:
> > First, third parties who are *not* CAs can run key generation and
> > escrow services, and then the third party service can apply for a
> > certificate for the key, and deliver the certificate and the key to a
> customer.
> 
> That is true. Do you know how common this is in SSL/TLS?
> 
> > I'm not
> > sure how this could be prevented.  So if this actually did end up
> > being a Mozilla policy, the practical effect would be that SSL keys
> > can be generated by third parties and escrowed, *UNLESS* that party is
> trusted by Mozilla.
> 
> Another way of putting it it: "unless that party were the party the customer
> is already dealing with and trusts". IoW, there's a much lower barrier for
> the customer in getting the CA to do it (trust and
> convenience) compared to someone else. So removing this ban would
> probably
> make it much more common, as noted above. If it's something we want to
> discourage even if we can't prevent it, the current ban makes sense.
> 
> > Second, although I strongly believe that in general, as a best
> > practice, keys should be generated by the device/entity it belongs to
> > whenever possible, we've seen increasing evidence that key generation
> > is difficult and many devices cannot do it securely.  I doubt that
> > forcing the owner of the device to generate a key on a commodity PC is
> > any better (it's probably worse).
> 
> That's also a really interesting question. We've had dedicated device key
> generation failures, but we've also had commodity PC key generation
> failures
> (Debian weak keys, right?). Does that mean it's a wash? What do the risk
> profiles look like here? One CA uses a MegaRNG2000 to generate hundreds
> of
> thousands of certs.. and then a flaw is found in it. Oops.
> Better or worse than a hundred thousand people independently using a
> broken
> OpenSSL shipped by their Linux vendor?
> 
> > With an increasing number of small devices running web servers, keys
> > generated by audited, trusted third parties under whatever rules
> > Mozilla chooses to enforce about secure key delivery may actually in
> > many circumstances be superior than what would happen if the practice
> is
> banned.
> 
> Is there a way to limit the use of this to those circumstances?
> 
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/7IiyfqIYVYHVo4yJwZ1gujE6ewgPbVhd
> eNR8nQYMk
> tE=?d=-Wn_VctZunngdEk_ioG0-
> YmJpPH0bSY7avkVy2G5jkppW7WbRwmFtauXnqI4GVKzIanQD2
> ZA6NInKdI3JGkcf9ryTq6n-s4c4pg5s3wE4vkp4yda03M7jQfN5_Ag8-
> 70lEsjQb45m2On8sIoG_
> dT07uGS0eLuIUFBs5Ejb7aU7SMDef-
> aiw2SMmHSy34HrobgXESUV5rtJhwEAyCZvSWTdlhTt2mUM
> XVuNXdmFtAYun19fEnhCuxZTm44Inip_9XUfKb73PIvmELdwusC79xu_Wg
> oRGUvPUEFfEYMZQJLz
> r1wo3PfgH3YtIhu55H4aSMlU8UOVe5JjW6WYG0wIKfKfGKta_cm5JB9HGO
> NmcRvB8nw-A2xd5kr6
> jSh2Pb6kH9EJMOhxcnioBU4Gm_IH7he9MnhbhTu2BATkoSNvbqOoNB
> =https%3A%2F%2Flists
> .mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

RE: [EXT] Re: DigiCert-Symantec Announcement

[Steve Medin via dev-security-policy]

We are not making any changes at this time.

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Adrian R. via dev-security-policy
> Sent: Friday, September 01, 2017 4:09 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Re: DigiCert-Symantec Announcement
>
> a small question:
> what's going to happen with [freessl.com]
>
> under Symantec's leadership it was intended for the site to become a free
> alternative to StartCom and LetsEncrypt, but it was not quite opened for
> issuance except for non-profits.
>
> Now with the transition of the CA activities to DigiCert i haven't seen
> anything about it, not even the site blog over there says anything about it.
> https://www.freessl.com/freessl/blog/
>
> Any news about it?
>
> Thanks,
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Update on SubCA Proposal

[Steve Medin via dev-security-policy]

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

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

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

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

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

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

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

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

There were no additional CAs selected to 

RE: [EXT] Symantec Update on SubCA Proposal

[Steve Medin via dev-security-policy]

1)  December 1, 2017 is the earliest credible date that any RFP respondent 
can provide the Managed CA solution proposed by Google, assuming a start date 
of August 1, 2017. Only one RFP respondent initially proposed a schedule 
targeting August 8, 2017 (assuming a start date of June 12, 2017). We did not 
deem this proposal to be credible, however, based on the lack of specificity 
around our RFP evaluation criteria, as compared to all other RFP responses 
which provided detailed responses to all aspects of the RFP, and we have 
received no subsequent information from this bidder to increase our confidence.

2)  We are using several selection criteria for evaluating RFP responses, 
including the depth of plan to address key technical integration and 
operational requirements, the timeframe to execute, the ability to handle the 
scope, volume, language, and customer support requirements both for ongoing 
issuance and for one-time replacement of certificates issued prior to June 1, 
2016, compliance program and posture, and the ability to meet uptime, interface 
performance, and other SLAs. Certain RFP respondents have distinguished 
themselves based on the quality and depth of their integration planning 
assumptions, requirements and activities, which have directly influenced the 
dates we have proposed for the SubCA proposal.

3)  The RFP was first released on May 26, 2017. The first round of bidder 
responses was first received on June 12, 2017.

4)  It is our longstanding policy not to comment on rumors or market 
speculation.





From: Alex Gaynor [mailto:agay...@mozilla.com]
Sent: Wednesday, July 19, 2017 10:25 AM
To: Steve Medin 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [EXT] Symantec Update on SubCA Proposal



Hi Steve,

Thank you for this update on Symantec's progress. I have a few follow-up
questions:

1) Did any of the RFP respondents indicate that they could provide the Managed
   CA solution in the timeframe originally proposed by Google? (August 8th)
   Alternatively, is December 1st, 2017 the earliest date that any RFP
   respondents can achieve?

2) What selection criteria is Symantec using in considering RFP responses?

3) On June 1st, Symantec wrote that "we are in the midst of a rigorous RFP
   process"
   
(https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal).
   In this mail you wrote that "Last month, we released a Request for Proposal
   (RFP)". How do you reconcile those?

4) There are currently rumors that Symantec is considering a sale of its CA
   business
   (https://www.reuters.com/article/us-symantec-divestiture-idUSKBN19W2WI). Do
   these timelines reflect that possibility, or should we expect requests to
   amend this timeline in the event of a change of ownership?

Thank you,
Alex



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

RE: [EXT] Symantec Update on SubCA Proposal

[Steve Medin via dev-security-policy]

We believe our proposed dates reflect an aggressive but achievable period of 
time to implement the SubCA proposal and allow impacted organizations the time 
needed to replace, test and operationalize replacement certificates in their 
infrastructure to mitigate interoperability and compatibility risk associated 
with this premature replacement of certificates, which is consistent with the 
intent of the SubCA proposal. Our proposed dates are informed by the RFP 
responses and follow-up discussions we have had with our prospective Managed CA 
partners.





From: Eric Mill [mailto:e...@konklone.com]
Sent: Wednesday, July 19, 2017 3:43 PM
To: Steve Medin <steve_me...@symantec.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [EXT] Symantec Update on SubCA Proposal







On Wed, Jul 19, 2017 at 11:31 AM, Steve Medin via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

   > -Original Message-
   > From: dev-security-policy 
[mailto:dev-security-policy-<mailto:dev-security-policy->
   > 
bounces+steve_medin=symantec@lists.mozilla.org<mailto:symantec@lists.mozilla.org>]
 On Behalf Of
   > Jakob Bohm via dev-security-policy
   > Sent: Tuesday, July 18, 2017 4:39 PM
   > To: 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
   > Subject: Re: [EXT] Symantec Update on SubCA Proposal
   >
   >
   > Just for clarity:
   >
   > (Note: Using ISO date format instead of ambiguous local date format)
   >
   > How many Symantec certs issued prior to 2015-06-01 expire after 2018-
   > 06-01, and how does that mesh with the alternative date proposed
   > below:
   >
   > On 18/07/2017 21:37, Steve Medin wrote:
   > > Correction: Summary item #3 should read:
   > >
   > > 3. May 1, 2018
   > > a. Single date of distrust of certificates issued prior to 6/1/2016.
   > (changed from August 31,2017 for certificates issued prior to 6/1/2015 and
   > from January 18, 2018 for certificates issued prior to 6/1/2016).
   > >

   Over 34,000 certificates were issued prior to 2015-06-01 and expire after 
2018-06-01. This is in addition to almost 200,000 certificates that would also 
need to be replaced under the current SubCA proposal assuming a May 1, 2018 
distrust date. We believe that nine months (from August 1, 2017 to May 1, 2018) 
is aggressive but achievable for this transition — a period minimally necessary 
to allow for site operators to plan and execute an orderly transition and to 
reduce the potential risk of widespread ecosystem disruption. Nevertheless, we 
urge the community to consider moving the proposed May 1, 2018 distrust date 
out even further to February 1, 2019 in order to minimize the risk of end user 
disruption by ensuring that website operators have a reasonable timeframe to 
plan and deploy replacement certificates.



   That's pretty close to saying that nothing should happen, since almost all 
the certificates will have expired by then. That certainly is the least 
disruptive, but it seems contrary to the intent of the proposal.



   -- Eric



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







   --

   
konklone.com<https://clicktime.symantec.com/a/1/AAH-mYCdy7I540ZoJM0XkW-CDP-fn5bw0sk2P0x4Bvw=?d=U4j3hHTn-UxZ1ZOfHXB7r1lDEq3pYTpkBXJxYkQlk96LvJvpQVJPahGolj9IF9urhtYGsaK_9Mffi6158JvklYeFSEsWRIpnJD82JAbPyGBp6h78ufI4ZGIR8UZNoRVvgyVmB_Lq39lujhD-qOpO1y9E3I2BCtUkhiN98DyEsGpFxqp2JqPiLWxpjzBUBE3IqSdY8Pq0ezPKtY4XG0-7KydvGYIUGOlZJnVxW6_xEJseIlanIDcdA28GGtACgaVDc2QZBHhwpJ8TUK0GgpMW2fu3QdoLf2Fq_yOaeJe1F4AMkzBFTjbk9GF9TNfXVA4dVafUoWb5IFaE6uOy6B6cXKXbZIgX-Ya4lJ0dZ2ZjCSdJSLW2NfhVWxc-FScig3WKjyr-PsV_0lY0ODqzD8M1fhjT-XPzPQ%3D%3D=https%3A%2F%2Fkonklone.com>
 | @konklone<https://twitter.com/konklone>

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

RE: [EXT] Symantec Update on SubCA Proposal

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> David E. Ross via dev-security-policy
> Sent: Wednesday, July 19, 2017 12:48 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [EXT] Symantec Update on SubCA Proposal
>
> On 7/19/2017 8:31 AM, Steve Medin wrote:
> >> -Original Message-
> >> From: dev-security-policy [mailto:dev-security-policy-
> >> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> >> Jakob Bohm via dev-security-policy
> >> Sent: Tuesday, July 18, 2017 4:39 PM
> >> To: mozilla-dev-security-pol...@lists.mozilla.org
> >> Subject: Re: [EXT] Symantec Update on SubCA Proposal
> >>
> >>
> >> Just for clarity:
> >>
> >> (Note: Using ISO date format instead of ambiguous local date format)
> >>
> >> How many Symantec certs issued prior to 2015-06-01 expire after
> 2018-
> >> 06-01, and how does that mesh with the alternative date proposed
> >> below:
> >>
> >> On 18/07/2017 21:37, Steve Medin wrote:
> >>> Correction: Summary item #3 should read:
> >>>
> >>> 3. May 1, 2018
> >>> a. Single date of distrust of certificates issued prior to 6/1/2016.
> >> (changed from August 31,2017 for certificates issued prior to
> >> 6/1/2015 and from January 18, 2018 for certificates issued prior to
> 6/1/2016).
> >>>
> >
> > Over 34,000 certificates were issued prior to 2015-06-01 and expire after
> 2018-06-01. This is in addition to almost 200,000 certificates that would
> also need to be replaced under the current SubCA proposal assuming a May
> 1, 2018 distrust date. We believe that nine months (from August 1, 2017 to
> May 1, 2018) is aggressive but achievable for this transition - a period
> minimally necessary to allow for site operators to plan and execute an
> orderly transition and to reduce the potential risk of widespread ecosystem
> disruption. Nevertheless, we urge the community to consider moving the
> proposed May 1, 2018 distrust date out even further to February 1, 2019
> in order to minimize the risk of end user disruption by ensuring that website
> operators have a reasonable timeframe to plan and deploy replacement
> certificates.
> >
>
> It appears that Symantec wants to delay distrusting certificates until all
> existing subscriber certificates reach their inherent expiration dates.
>

Our proposed distrust date (May 1, 2018) is based on an aggressive but 
achievable period of time to allow impacted organizations the time needed to 
replace, test and operationalize replacement certificates in their 
infrastructure.  More than 234,000 certificates are required to be replaced 
before their expiration dates assuming a distrust date of May 1, 2018. In fact, 
we urge the community to consider moving this distrust date out even further to 
February 1, 2019 in order to minimize the risk of end user disruption by 
ensuring that website operators have a reasonable timeframe to plan and deploy 
replacement certificates. This recommendation is echoed by our prospective 
Managed CA partners.

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

RE: [EXT] Symantec Update on SubCA Proposal

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Jakob Bohm via dev-security-policy
> Sent: Wednesday, July 19, 2017 12:22 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [EXT] Symantec Update on SubCA Proposal
> 
> On 19/07/2017 17:31, Steve Medin wrote:
> >> -Original Message-
> >> From: dev-security-policy [mailto:dev-security-policy-
> >> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> >> Jakob Bohm via dev-security-policy
> >> Sent: Tuesday, July 18, 2017 4:39 PM
> >> To: mozilla-dev-security-pol...@lists.mozilla.org
> >> Subject: Re: [EXT] Symantec Update on SubCA Proposal
> >>
> >>
> >> Just for clarity:
> >>
> >> (Note: Using ISO date format instead of ambiguous local date format)
> >>
> >> How many Symantec certs issued prior to 2015-06-01 expire after
> 2018-
> >> 06-01, and how does that mesh with the alternative date proposed
> >> below:
> >>
> >> On 18/07/2017 21:37, Steve Medin wrote:
> >>> Correction: Summary item #3 should read:
> >>>
> >>> 3. May 1, 2018
> >>>  a. Single date of distrust of certificates issued prior to 6/1/2016.
> >> (changed from August 31,2017 for certificates issued prior to
> >> 6/1/2015 and from January 18, 2018 for certificates issued prior to
> 6/1/2016).
> >>>
> >
> > Over 34,000 certificates were issued prior to 2015-06-01 and expire after
> 2018-06-01. This is in addition to almost 200,000 certificates that would
> also need to be replaced under the current SubCA proposal assuming a May
> 1, 2018 distrust date. We believe that nine months (from August 1, 2017 to
> May 1, 2018) is aggressive but achievable for this transition — a period
> minimally necessary to allow for site operators to plan and execute an
> orderly transition and to reduce the potential risk of widespread ecosystem
> disruption. Nevertheless, we urge the community to consider moving the
> proposed May 1, 2018 distrust date out even further to February 1, 2019
> in order to minimize the risk of end user disruption by ensuring that website
> operators have a reasonable timeframe to plan and deploy replacement
> certificates.
> >
> 
> So when and why did Symantec issue 34,000 WebPKI certificates valid
> longer than 3 years, that would expire after 2018-06-01 ?
> 
> Are these certificates issued before 2015-04-01 with validity periods longer
> than 39 months?
> 
> Are they certificates issued under "special circumstances" ?
> 
> Are they certificates with validity periods between 36 and 39 months?
> 
> 

The vast majority of these certificates were issued prior to April 1, 2015 and 
were subject to the 60 month rule that was in effect at the time of issuance. 
This population also includes several thousand that are for <39 month validity.



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: [EXT] Symantec Update on SubCA Proposal

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Jakob Bohm via dev-security-policy
> Sent: Tuesday, July 18, 2017 4:39 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [EXT] Symantec Update on SubCA Proposal
>
>
> Just for clarity:
>
> (Note: Using ISO date format instead of ambiguous local date format)
>
> How many Symantec certs issued prior to 2015-06-01 expire after 2018-
> 06-01, and how does that mesh with the alternative date proposed
> below:
>
> On 18/07/2017 21:37, Steve Medin wrote:
> > Correction: Summary item #3 should read:
> >
> > 3. May 1, 2018
> > a. Single date of distrust of certificates issued prior to 6/1/2016.
> (changed from August 31,2017 for certificates issued prior to 6/1/2015 and
> from January 18, 2018 for certificates issued prior to 6/1/2016).
> >

Over 34,000 certificates were issued prior to 2015-06-01 and expire after 
2018-06-01. This is in addition to almost 200,000 certificates that would also 
need to be replaced under the current SubCA proposal assuming a May 1, 2018 
distrust date. We believe that nine months (from August 1, 2017 to May 1, 2018) 
is aggressive but achievable for this transition — a period minimally necessary 
to allow for site operators to plan and execute an orderly transition and to 
reduce the potential risk of widespread ecosystem disruption. Nevertheless, we 
urge the community to consider moving the proposed May 1, 2018 distrust date 
out even further to February 1, 2019 in order to minimize the risk of end user 
disruption by ensuring that website operators have a reasonable timeframe to 
plan and deploy replacement certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Symantec Update on SubCA Proposal

[Steve Medin via dev-security-policy]

Correction: Summary item #3 should read:

3. May 1, 2018
   a. Single date of distrust of certificates issued prior to 6/1/2016. 
(changed from August 31,2017 for certificates issued prior to 6/1/2015 and from 
January 18, 2018 for certificates issued prior to 6/1/2016).

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Steve Medin via dev-security-policy
> Sent: Tuesday, July 18, 2017 2:23 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Symantec Update on SubCA Proposal
>
> *Progress Update on SubCA RFP, Partner Selection, and Execution*
>
>
>
> Since June 1, Symantec has worked in earnest to operationalize the SubCA
> proposal outlined by Google and Mozilla and discussed in community
> forums.  The core of this proposal is to transfer the authentication and
> issuance of certificates to a set of new SubCAs that are operated by
> "Managed CAs", with the eventual end state being a move from the existing
> Symantec PKI to a modernized platform. We are providing this update to
> share our initial findings of our efforts to implement the SubCA proposal,
> and as previously posted, propose aggressive but achievable dates for
> certain aspects of the SubCA proposal.
>
>
>
> Last month, we released a Request for Proposal (RFP) that covered all
> aspects of the SubCA proposal, including key management, technical
> integration, staffing, training, compliance, support, and the end-to-end
> coordination of operations. This RFP was sent to the CAs that we felt best
> met the browser requirements and had the potential to successfully fulfill
> the scope and volume of our CA authentication and issuance activities.
>
>
>
> After receiving RFP responses, we met with the prospective Managed CAs
> to discuss and refine their proposed approach, clarify intent and answer
> questions impacting their proposals, which addressed their approach to
> and schedule for integration, staffing, compliance, support, and other
> operational aspects.  Over the last two weeks, we have continued to receive
> detailed responses from RFP respondents and hold meetings with the
> prospective Managed CAs to review their proposals in order to select the
> final Managed CA partner(s) that will be able to best execute on the plan
> proposed by Google and Mozilla. We appreciate the CAs who have replied
> and recognize that drafting the proposals required a tremendous amount
> of time and effort as part of this accelerated process.
>
>
>
> We continue to work through implementation details with our prospective
> Managed CA partners, to understand the depth of analysis that has gone
> into their development schedules and staffing plans, and to assess the
> feasibility of those plans.  We expect to complete the selection process
> within the next 2 weeks. After selecting the final Managed CA partner(s), we
> will work aggressively towards the execution of an agreement and
> integration plan.
>
>
>
> As we finalize the selection process, our development team is actively
> working towards the transition.  Currently, we are shifting from design to
> implementation of a common set of APIs across platforms to simplify the
> integration with one or more Managed CAs.
>
>
>
> Based on the RFP responses, internal planning, and discussions with RFP
> respondents to date, we are still concerned with the implementation
> timing. Based on both our own internal scoping and the RFP responses, we
> see a practical, aggressive transition being achievable between early-
> December and late-February, depending on the specific Managed CA(s) and
> the unknowns that come with an effort of this magnitude.  This timeframe
> is based on the Managed CAs' RFP responses regarding how long it will take
> to integrate our existing customer portals (front-ends) with the Managed
> CA validation and issuance systems. The transition timeline also
> incorporates the effort required for the Managed CAs to build out support
> for scalable domain validation (both automated and manual), CAA record
> checking, CT logging, and certificate management functions.  The primary
> factors we heard from potential Managed CA partners are the need to scale
> their operations to the certificate volumes currently sup  ported by
> Symantec, the need for integration, and the time required to prepare and
> process key ceremonies on both ends.  Some of the prospective Managed
> CAs have proposed supporting only a portion of our volume (some by
> customer segment, others by geographic focus), so we are also evaluating
> options that involve working with multiple Managed CAs.
>
>
>
> *Timing Proposal Based

Symantec Update on SubCA Proposal

[Steve Medin via dev-security-policy]

*Progress Update on SubCA RFP, Partner Selection, and Execution*



Since June 1, Symantec has worked in earnest to operationalize the SubCA 
proposal outlined by Google and Mozilla and discussed in community forums.  The 
core of this proposal is to transfer the authentication and issuance of 
certificates to a set of new SubCAs that are operated by "Managed CAs", with 
the eventual end state being a move from the existing Symantec PKI to a 
modernized platform. We are providing this update to share our initial findings 
of our efforts to implement the SubCA proposal, and as previously posted, 
propose aggressive but achievable dates for certain aspects of the SubCA 
proposal.



Last month, we released a Request for Proposal (RFP) that covered all aspects 
of the SubCA proposal, including key management, technical integration, 
staffing, training, compliance, support, and the end-to-end coordination of 
operations. This RFP was sent to the CAs that we felt best met the browser 
requirements and had the potential to successfully fulfill the scope and volume 
of our CA authentication and issuance activities.



After receiving RFP responses, we met with the prospective Managed CAs to 
discuss and refine their proposed approach, clarify intent and answer questions 
impacting their proposals, which addressed their approach to and schedule for 
integration, staffing, compliance, support, and other operational aspects.  
Over the last two weeks, we have continued to receive detailed responses from 
RFP respondents and hold meetings with the prospective Managed CAs to review 
their proposals in order to select the final Managed CA partner(s) that will be 
able to best execute on the plan proposed by Google and Mozilla. We appreciate 
the CAs who have replied and recognize that drafting the proposals required a 
tremendous amount of time and effort as part of this accelerated process.



We continue to work through implementation details with our prospective Managed 
CA partners, to understand the depth of analysis that has gone into their 
development schedules and staffing plans, and to assess the feasibility of 
those plans.  We expect to complete the selection process within the next 2 
weeks. After selecting the final Managed CA partner(s), we will work 
aggressively towards the execution of an agreement and integration plan.



As we finalize the selection process, our development team is actively working 
towards the transition.  Currently, we are shifting from design to 
implementation of a common set of APIs across platforms to simplify the 
integration with one or more Managed CAs.



Based on the RFP responses, internal planning, and discussions with RFP 
respondents to date, we are still concerned with the implementation timing. 
Based on both our own internal scoping and the RFP responses, we see a 
practical, aggressive transition being achievable between early-December and 
late-February, depending on the specific Managed CA(s) and the unknowns that 
come with an effort of this magnitude.  This timeframe is based on the Managed 
CAs' RFP responses regarding how long it will take to integrate our existing 
customer portals (front-ends) with the Managed CA validation and issuance 
systems. The transition timeline also incorporates the effort required for the 
Managed CAs to build out support for scalable domain validation (both automated 
and manual), CAA record checking, CT logging, and certificate management 
functions.  The primary factors we heard from potential Managed CA partners are 
the need to scale their operations to the certificate volumes currently sup
 ported by Symantec, the need for integration, and the time required to prepare 
and process key ceremonies on both ends.  Some of the prospective Managed CAs 
have proposed supporting only a portion of our volume (some by customer 
segment, others by geographic focus), so we are also evaluating options that 
involve working with multiple Managed CAs.



*Timing Proposal Based on Key Activities*



Based on the key activities and customer dependencies associated with the 
transition (additional details provided at the end of this post), we believe 
that the following adjustments to the current SubCA proposal timelines are 
appropriate and necessary. These adjustments will allow us to work toward 
deadlines that are as close as possible to the original dates and take into 
account the full scope of the required implementation efforts while 
prioritizing moving to full authentication by the Managed CAs for new 
certificates.



New Certificate Issuance: We believe the dates for transition of validation and 
issuance to the Managed CA that are both aggressive and achievable are as 
follows:

- Implement the Managed CA by December 1, 2017 (changed from August 8, 2017);

- Managed CA performs domain validation for all new certificates by December 1, 
2017 (changed from November 1, 2017); and

- Managed CA performs full validation for all 

RE: [EXT] Mozilla requirements of Symantec

[Steve Medin via dev-security-policy]

> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Wednesday, June 07, 2017 2:51 PM
> To: Steve Medin ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Cc: Kathleen Wilson 
> Subject: [EXT] Mozilla requirements of Symantec
>
> Hi Steve,
>
> I'm writing to you in your role as the Primary Point of Contact for Symantec
> with regard to the Mozilla Root Program. I am writing with a list of Mozilla-
> specific additions to the consensus remediation proposal for Symantec, as
> documented by Google.
>
> We note that you have raised a number of objections and queries with
> regard to the consensus proposal. As you know, we are considering our
> responses to those. We reserve the right to make additional requests of
> Symantec in relation to any changes which might be made to that proposal,
> or for other reasons.
>
> However, we have formulated an initial list of Mozilla-specific addenda to
> the consensus proposal and feel now is a good time to pass them on to
> Symantec for your official consideration and comment. We would prefer
> comments in mozilla.dev.security.policy (to which this notice has been
> CCed), and in any event by close of business on Monday 12th June.
>
> 1) Mozilla would wish, after the 2017-08-08 date as documented in the
> consensus proposal, to alter Firefox such that it trusts certificates issued 
> in
> the "new PKI" directly by embedding a set of certs or trust anchors which
> are part of that PKI, and can therefore distrust any new cert which is issued
> by the old PKI on a "notBefore" basis. We therefore require that Symantec
> arrange their new PKI and provide us with sufficient information in good
> time to be able to do that.
>

Symantec supports creation of a new PKI. Limiting Firefox trust of new 
certificates to those issued off of the new PKI is a practical path forward, 
due to Firefox’s contained scope and auto-update capabilities.

The same does not hold true for the removal of current PKI roots from NSS and 
the entirety of NSS dependents.

We understand the cutoff date to mean that any end entity cert issued after 
that date from the current PKI would not be trusted, but this date would have 
no effect on the trust of existing current PKI certs, their issuers, or their 
roots. Mozilla has not yet chosen the notBefore milestone date, and we 
interpret your proposal as intent to set a date and announce that date with 
enough advance notice to support public notice to affected parties. To that 
end, based on our research, we believe the 2017-08-08 date is not achievable 
given the magnitude of the transition that would need to occur and we propose 
that Mozilla not conclude on final dates for Symantec certificates at this time.

In response to the Google proposal, Symantec is currently evaluating a third 
party “SubCA” approach, which requires substantial operational changes. We have 
conducted outreach to candidate partners (SubCAs) to understand the potential 
constraints, timelines and the integration work that might be needed. We have 
also formalized and issued an RFP with specific questions around timing, 
logistics and dependencies. We expect to have the required feedback to inform a 
project plan by the end of June, at which time we will come back to Mozilla and 
the community regarding suggested dates that are both aggressive and achievable 
under this approach, by Symantec and the SubCA(s).

> 2) Mozilla would wish, at some point in the future sooner than November
> 2020 (39 months after 2017-08-08, the date when Symantec need to be
> doing new issuance from the new PKI), to be certain that we are fully
> distrusting the old PKI. As things currently stand technically, distrusting 
> the
> old PKI would mean removing the roots, and so Symantec would have to
> move their customers to the new PKI at a rate faster than natural certificate
> expiry. Rather than arbitrarily set a date here, we are willing to discuss 
> what
> date might be reasonable with Symantec, but would expect it to be some
> time in 2018.
>
> As you know, Firefox currently does not act upon embedded CT
> information, and so CT-based mechanisms are not a suitable basis for us to
> determine trust upon. Were that to change, we may be able to consider a
> continued trust of CT-logged certs, but would still want to dis-trust non-CT-
> logged certs sooner than November 2020.
>

We think it is critically important to distinguish potential removal of support 
for current roots in Firefox versus across NSS. Limiting Firefox trust to a 
subset of roots while leaving NSS unchanged would avoid unintentionally 
damaging ecosystems that are not browser-based but rely on NSS-based roots such 
as code signing, closed ecosystems, libraries, etc.

As one example, we note that libraries that rely on NSS in non-browser based 
applications, many of which are not easily updated, may have unintended 
negative impact in automobiles, 

RE: [EXT] Symantec response to Google 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: Friday, June 02, 2017 10:54 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Symantec response to Google proposal
> 
> https://www.symantec.com/connect/blogs/symantec-s-response-google-
> s-subca-proposal
> 
> Symantec have responded to the Google proposal (which Mozilla has
> endorsed as the basis for further discussion) with a set of inline
comments
> which raise some objections to what is proposed.
> 
> Google will, no doubt, be evaluating these requests for change and
deciding
> to accept, or not, each of them. But Mozilla can make our own independent
> decisions on these points if we choose. If Google and Mozilla accept a
> change, it is accepted. If Google accepts it but we decline to accept, we
can
> add it to our list of additional requirements for Symantec instead.
> 
> Therefore, I would appreciate the community's careful consideration of the
> reasonableness of Symantec's requests for change to the proposal.
> 
> Gerv

Thank you for posting this, Gerv.  We intended to post the following here.
 


Posting on behalf of Symantec.
 
Today, after thoroughly reviewing Google's proposal and weighing its merits
against feedback we've heard from the broader community, including our CA
customers, we shared our response with Google and the community, and also
posted our full response on our blog at
https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-pr
oposal 

We anticipate that Google and the community will need some time to review
our feedback and share their reactions, and we welcome their continued input
as we work to reach an agreed-upon plan that can be implemented in a
reasonable timeframe and ensures minimal disruption for our customers. We
thank our customers and the community for their valuable contributions to
this important discussion, and we will continue working toward what we
believe is the best path forward for all stakeholders.


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: [EXT] Google Plan for Symantec posted

[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: Friday, May 19, 2017 11:42 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Google Plan for Symantec posted
>
> Hi m.d.s.p.,
>
> Google have posted their updated plan for Symantec in the blink-dev forum
> (copied below).

Posting on behalf of Symantec.

Google’s latest proposal follows collaborative and constructive community 
discussions. Our goal has been to reach a solution that minimizes disruption 
for our customers and is in the best interests of the entire Internet community.

While there remain details to be considered, we believe Google has put forth a 
new proposal that limits business disruption for customers as compared to prior 
proposals. Notably, Google’s revised proposal would not require Symantec to 
move to shorter-term validity certificates beyond what was approved by the CA/B 
forum in Ballot 193 for all CAs and Symantec’s Extended Validation certificates 
would remain intact. Given the potential impact of any changes that might be 
implemented, we are carefully reviewing this proposal and will respond shortly 
with feedback for the community’s consideration.

We thank our customers and the community for their patience and participation 
in this important discussion.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Re: Draft further questions for Symantec

[Steve Medin via dev-security-policy]

Replacement link:  https://bugzilla.mozilla.org/attachment.cgi?id=8867892

Sorry, I had the PDF cached.

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> urijah--- via dev-security-policy
> Sent: Monday, May 15, 2017 3:41 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [EXT] Re: Draft further questions for Symantec
> 
> The link in footnote [1]
> https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t
> 000Gmi3AAC=File__Body__s
> 
> gives me a 404 error.
> 
> 
> On Monday, May 15, 2017 at 11:09:41 AM UTC-4, Steve Medin wrote:
> > Gerv,
> >
> > Our response to the recent questions is posted at:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8867735
> >
> > Kind regards,
> > Steve
> >
> > > -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: Wednesday, May 10, 2017 7:06 AM
> > > To: mozilla-dev-security-pol...@lists.mozilla.org
> > > Subject: [EXT] Re: Draft further questions for Symantec
> > >
> > > On 08/05/17 13:24, Gervase Markham wrote:
> > > > 8) Please explain how the Management Assertions for your December
> > > > 2014
> > > 
> > >
> > > Strike this question; it's based on a misunderstanding of how audits
> > > are done.
> > >
> > > Let's add:
> > >
> > > 10) Do you agree that, during the period of time that Symantec
> > > cross-signed the Federal PKI (Issue L), it was technically possible
> > > for issuers inside the FPKI to issue EV certs by inserting Symantec's
EV
> OID?
> > >
> > > 11) If, in the Symantec Issues list or any other document relating
> > > to this matter we may publish in future, we have drawn a conclusion
> > > or inference about Symantec's PKI, actions or behaviour which is
> > > incorrect, we expect you to draw that to our attention, even if the
> > > truth is not as favourable to Symantec. Are there any incorrect
> > > inferences or conclusions in the Issues List which need to be
corrected?
> > >
> > > 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


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: [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 
Cc: Gervase Markham ; 
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.
 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: [EXT] Re: Symantec Conclusions and Next Steps

[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 Ryan
> Sleevi via dev-security-policy
> Sent: Tuesday, April 25, 2017 6:50 PM
> To: Ryan Sleevi 
> Cc: mozilla-dev-security-policy  pol...@lists.mozilla.org>; Gervase Markham 
> Subject: [EXT] Re: Symantec Conclusions and Next Steps
> 
> Continuing to look through the audits, I happened to notice a few other
> things that stood out, some more pressing than others.
> 
> More pressing:
> I can find no disclosure with Salesforce or crt.sh of at least two CAs
that are
> listed 'in scope' of the audit report, as part of
> https://www.symantec.com/content/en/us/about/media/
> repository/Symantec-NFSSP-WTCA_11-30-2016.pdf
> 
> This audit report identifies the "SureID Inc. CA2" and "SureID Inc. Device
CA2"
> as within scope for this audit. It would be useful to understand their
lack of
> disclosure, relative to the audits and to Section 5.3.2 of the inclusion
policy.
> 

The two SureID CAs are now disclosed. They were inadvertently omitted.

https://mozillacacommunity.force.com/001o016Uc20 
https://mozillacacommunity.force.com/001o016Uc6M 

Based on https://crt.sh/mozilla-disclosures#undisclosedsummary, we also
disclosed an additional version of the CSC Device CA - G2. Both versions are
signed by the VeriSign Class 3 SSP Intermediate CA - G2. The previously
disclosed CSC Device CA - G2 expires on August 14, 2021.

Existing: https://mozillacacommunity.force.com/001o00p4Sf2 
New: https://mozillacacommunity.force.com/001o016UfuS 

We further updated CCADB to ensure it mirrors the PKI Map we are creating.
As part of that effort we posted:

-   39 entries that chain to roots no longer trusted by Mozilla
-   10 which chain to the revoked VeriSign Class 3 SSP Intermediate CA
-   13 which are either technically constrained by EKU or software
constrained in Symantec operated systems, limiting issuance to code signing
or time stamping authority certificates.
-   Additional entries to capture different versions of the same subCA,
even in cases where the versions were never deployed and/or never issued end
entity certificates.


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: [EXT] Re: Draft further questions for Symantec

[Steve Medin via dev-security-policy]

Gerv,

Our response to the recent questions is posted at: 
https://bugzilla.mozilla.org/attachment.cgi?id=8867735

Kind regards,
Steve

> -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: Wednesday, May 10, 2017 7:06 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Re: Draft further questions for Symantec
>
> On 08/05/17 13:24, Gervase Markham wrote:
> > 8) Please explain how the Management Assertions for your December 2014
> 
>
> Strike this question; it's based on a misunderstanding of how audits are
> done.
>
> Let's add:
>
> 10) Do you agree that, during the period of time that Symantec cross-signed
> the Federal PKI (Issue L), it was technically possible for issuers inside the 
> FPKI
> to issue EV certs by inserting Symantec's EV OID?
>
> 11) If, in the Symantec Issues list or any other document relating to this
> matter we may publish in future, we have drawn a conclusion or inference
> about Symantec's PKI, actions or behaviour which is incorrect, we expect you
> to draw that to our attention, even if the truth is not as favourable to
> Symantec. Are there any incorrect inferences or conclusions in the Issues List
> which need to be corrected?
>
> 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: [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: [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

[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 Conclusions and Next Steps

[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: Friday, April 21, 2017 6:17 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Symantec Conclusions and Next Steps
> 
[snip]
> 
> Symantec have also written to Mozilla to say the following:
> 
> "We have been working hard on a thorough and thoughtful proposal that
> responds to community questions and concerns regarding our compliance
> and issuance practices. In drafting this proposal, we’ve thoughtfully
> considered the feedback posted on the Mozilla forums along with comments
> on the Google forums and other community feedback. We’ve also solicited
> input from our customers who are the ones that would bear the impact of
> changes, whether as a result of our proposal or any other.
> 
> We plan to send a proposal for Mozilla’s and the community’s consideration
> on Wednesday April 26th that addresses these important areas:
> 
> * The Integrity of our EV Validation Process
> * Validity of Existing Certificates
> * Increased Transparency
> * Move to Shorter Validity Certificates
> * Continuous Improvement of our CA Operations"
> 
> This date is in the middle of next week. We permitted WoSign to propose a
> remediation plan; I think it is reasonable to do the same for Symantec. So we
> will wait to hear what they have to say, and then discuss appropriate action 
> in
> the light of it.
> 
> Gerv
> 

Symantec CA Response to Google Proposal and Community Feedback

We take our role as a key player in the trust ecosystem of the Internet very 
seriously. We believe that secure and compliant issuance of SSL/TLS 
certificates is fundamental to the security of the Internet and that we have a 
responsibility to collaborate with our customers and the broader community to 
continuously improve industry standards, and specifically our practices, for 
certificate issuance. 

On March 23, Google posted a blog outlining a proposal to change how Symantec’s 
SSL/TLS certificates are recognized in Chrome. Their proposal stemmed from 
prior certificate mis-issuances that occurred in our Certificate Authority (CA) 
business, which we have taken extensive remediation measures to correct. We 
have carefully reviewed Google’s proposal and sought input from the broader 
browser and user community on this topic, which has informed our continuous 
improvement planning. This post outlines important measures that we propose to 
implement in our CA business. We believe our proposal addresses the concerns 
raised by Google about our CA business without imposing undue business 
disruption on our customers and Chrome users that we believe would result if 
Google implements its proposal. 

Feedback from our Enterprise Customers 

In addition to our review of public commentary on these issues, we have also 
sought input and feedback from Symantec customers on the compatibility and 
interoperability impact of the significant changes that could result from the 
implementation of Google’s proposal. These customers include many of the 
largest financial services, critical infrastructure, retail and healthcare 
organizations in the world, as well as many government agencies. This cohort is 
an important constituency that we believe has been under-represented to date in 
the public commentary that has been posted to the Google and Mozilla boards 
since large organizations rarely authorize employees to engage in such public 
discussions, particularly in an area related to security. We first solicited 
feedback to understand the disruption that a browser-initiated trust change, 
like the one proposed by Google, would cause organizations that opt to replace 
their existing SSL/TLS certificates in order to maintain interoperability with 
all browsers. We learned that these organizations’ publicly facing web 
applications, while extensive, only represent a fraction of their dependency on 
publicly trusted Symantec roots. Many large organizations have complex, and 
potentially undocumented and little-known dependencies on their certificate 
infrastructure. Examples of complex dependencies on Symantec public roots that 
our customers have shared or we have identified include:

- Embedded devices that are pinned to certificates issued by a Symantec public 
root to communicate to resources over the Internet or Intranet. Replacing these 
certificates would result in immediate failures and the need to recode and 
reimage the firmware for these devices.
- Mobile applications that have pinned certificates. Replacing server 
certificates would require these applications to be recoded, recompiled and 
redistributed.
- Critical infrastructure organizations that use certificates issued off of 
Symantec roots to validate internal and external resources. In many cases the 
applications being used are pinned to Symantec certificates.
- Some large 

RE: [EXT] Re: Questions for Symantec

[Steve Medin via dev-security-policy]

> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Tuesday, April 11, 2017 6:42 AM
> To: Steve Medin ; Rick Andrews
> ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: [EXT] Re: Questions for Symantec
> 
> Hi Steve and Rick,
> 
> Just to confirm: even after reviewing your extensive responses to the issues
> list, I feel that all the 8 questions on my questions list are still 
> outstanding and
> require answers.
> 
> Thanks :-)
> 
> Gerv

Answer 1:

A. See Symantec response for Issue V 
[https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Ga1bfOiJr70].
B. This was a continuation of the first paragraph, referring to Intel, Aetna, 
Unicredit, Google, & Apple. See issue V.
C. For both the RA program and the GeoRoot program clarified in Issue V, KPMG 
focused on our receipt of audit reports from these third parties, continuity 
from previous periods, the audit opinions, and in the cases where there were 
issues identified, Symantec’s plan of action to remediate.

In this case, Symantec and KPMG failed to note that we were missing some of the 
required audits.

Answer 2:

The start dates of our SSL/TLS RA partnerships are all prior to 2010 when 
Symantec acquired the Trust Services business from VeriSign and prior to the 
BRs going into effect. During the period of 2011-2014 we significantly reduced 
the number of these RA partners that could issue SSL/TLS certificates and 
restricted all but CrossCert, Certisur, Certisign, and CertSuperior to perform 
validation for SSL/TLS certificates. We imposed technical measures to prevent 
all SSL/TLS validation and issuance capabilities by all RA’s except for these 
four partners, In 2017 we took the additional step of removing the ability of 
these remaining four partners to issue SSL/TLS certificates which represented a 
complete wind-down of the SSL/TLS RA program.
 
See Item W for more details of the RA program: 
[https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Ga1bfOiJr70].

The following affiliates operated as an RA for Symantec SSL/TLS certificates, 
conducting authentication and issuance activities. This list does not include 
additional partners who had been terminated prior to the acquisition of the 
Trust Services business from VeriSign, Inc. in August 2010 as there are no 
unexpired certificates issued by these former partners. The end date referenced 
below is the date of the last SSL/TLS authentication event by the affiliate 
within a customer’s Enterprise RA account. 

As of April 19, 2017 all certificates counted below were certificates issued 
out of domain-constrained Enterprise RA accounts originally authenticated by 
the affiliate. Numbers represent still active certificates issued using the 
authentication work by the affiliate. That issuance, subsequent to the 
affiliate SSL/TLS termination, has been possible leveraging the 39-month data 
validity rule for OV/DV certificates. 

End date in 2017:
Audits at https://bugzilla.mozilla.org/show_bug.cgi?id=1334377

CrossCert
End date: January 19, 2017
Active certificates: 10,603

CertSuperior
End date: April 4, 2017
Active certificates: 4,430

CertiSign
End date: April 11, 2017
Active certificates: 13,521

CertiSur
End date: April 14, 2017
Active certificates: 2,935

-
End date between 2011 - 2014:
These RA for SSL/TLS relationships were wound down as the BR’s went into 
effect. We do not have audits for them. 

Note, while no longer authorized as affiliate RAs for SSL/TLS, many of these 
partners continue to offer SSL/TLS for sale as Symantec resellers. 

Adacom S.A.
End date: November 15, 2012 
Active certificates: 2 

Comsign, Ltd
End date: February 14, 2013 
Active certificates: 15

e-Sign S.A.
End date: March 4, 2013 
Active certificates: 16

iTrusChina
End date: January 11, 2013 
Active certificates: 52

NamITech
End date: November 7, 2012
Active certificates: 167

Telefonica S.A.
End date: February 5, 2014
Active certificates: 88
* Note, in our response on issue T indicated that the RA program for SSL/TLS 
was wound down in 2013. That should have stated 2014 to reflect Telefonica.

MSC Trustgate.com Sdn Bhd
End date: February 8, 2013 
No active certificates

mySecureSign, Inc. 
End date: August 22, 2011 
No active certificates

Safescrypt Ltd
End date: June 25, 2012
No active certificates

NIFTeTrust
End date:  September 6, 2013 
No active certificates

With the exception of Telefonica, all previous org/domain validation data is 
now outside of the 39 month rule. In the case of Telefonica, we are disabling 
use of previously validated org/domain information otherwise still valid under 
the 39 month rule. After this update Symantec will solely authenticate new 
certificate issuance for all of these customer accounts originally 
authenticated by these partners.  

There were also questions regarding issuance controls on RA certificates. In 
our infrastructure 

RE: [EXT] Re: Questions for Symantec

[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: Tuesday, April 04, 2017 9:06 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: [EXT] Re: Questions for Symantec
>
> On 03/04/17 13:11, Gervase Markham wrote:
> > Hi Steve and Rick,
>
> Q8) The accountant's letters for the 2015-2016 audits are dated February 28th
> 2017. The audits were supplied to Mozilla, and published, on the 1st of April
> 2017. Why the delay?
>
> Gerv

Proofreading of the reports, corrections, and clarifications took an additional 
four weeks. KPMG provided an explanation of the delay in their explanatory 
letter which has been provided, and which centered on the large scope and 
resulting sheer volume of audits.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [EXT] Re: Questions for Symantec

[Steve Medin via dev-security-policy]

> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Thursday, April 13, 2017 9:13 AM
> To: Steve Medin ; Rick Andrews
> ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: [EXT] Re: Questions for Symantec
>
> On 03/04/17 13:11, Gervase Markham wrote:
> > Hi Steve and Rick,
>
> Q9) Can you please tell us which audit covers the following two intermediate
> CAs, which are subordinates of or cross-certified by VeriSign Universal Root
> Certification Authority?
>

These Intermediate CAs are sub-CAs under the Verisign Universal Root CA. They 
are covered under Symantec’s Non-Fed SSP audits, and the latest unqualified 
audits that we just received are being published.

The customer-specific CAs (the subordinate ICAs) signed by these sub-CAs are 
path length constrained and operate fully within Symantec’s infrastructure. 
Under the Non-Federal SSP program, they are used to issue certificates for 
Microsoft Windows domain controllers and IPSec endpoints. End entity 
certificates issued under this program are designed only to contain Federal PKI 
policy OIDs and to exclude any CA/B Forum required policy OIDs.

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

RE: [EXT] Re: Questions for Symantec

[Steve Medin via dev-security-policy]

Gerv,

In the interest of an easy to read set of responses to your questions and many 
submitted in response to our recent posts, we have prepared a PDF and attached 
it to the Bugzilla tracking this discussion.

That PDF is available at https://bugzilla.mozilla.org/attachment.cgi?id=8860216.


> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Thursday, April 13, 2017 9:13 AM
> To: Steve Medin ; Rick Andrews
> ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: [EXT] Re: Questions for Symantec
>
> On 03/04/17 13:11, Gervase Markham wrote:
> > Hi Steve and Rick,
>
> Q9) Can you please tell us which audit covers the following two intermediate
> CAs, which are subordinates of or cross-certified by VeriSign Universal Root
> Certification Authority?
>
> VeriSign Class 3 SSP Intermediate CA - G2
>
> Symantec Class 3 SSP Intermediate CA - G3
>
>
> The following period-of-time audit is the most recent one which covers the
> VeriSign Universal Root Certification Authority:
> https://www.symantec.com/content/en/us/about/media/repository/18_Sy
> mantec_STN_WTCA_period_end_11-30-2016.pdf
> However, these certificates are not on the accompanying list of
> intermediates.
>
> Is it correct that these intermediates are unconstrained and fully capable of
> issuing server authentication (SSL/TLS) certificates which are trusted by
> Mozilla browsers?
>
> Thanks,
>
> Gerv

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

Symantec Response X

[Steve Medin via dev-security-policy]

Issue X: Incomplete RA Program Remediation (February - March 2017)

The only Symantec RAs capable of authorizing and issuing publicly trusted 
SSL/TLS certificates are: CrossCert, Certisign, Certsuperior and Certisur. 
Symantec continues to maintain a partner program for non-TLS certificates. 
E-Sign SA and MSC Trustgate are amongst these partners.

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

Symantec Response T

[Steve Medin via dev-security-policy]

Issue T: RA Program Misissuances (January 2010 - January 2017)

Program Background:

Symantec has operated an RA program designed to deliver a superior customer 
experience in global markets where language skills, understanding of local 
business requirements, and physical local presence are necessary. RA partners 
have supported various certificate types, including those for publicly trusted 
SSL/TLS.

The RA program for publicly trusted SSL/TLS authorized appropriately trained 
personnel at select RA partners to complete all steps for authentication, 
review, and certificate issuance.

In 2011, prior to ratification of the CA/Browser Forum Baseline Requirements, 
Symantec scaled back the scope of the RA program for publicly trusted SSL/TLS 
to support only those partners whose scale of business and investment in the 
future success of that business warranted the additional cost associated with 
supporting the then-new BRs. Since 2013, there have been only 4 RA partners 
still capable of processing and issuing publicly trusted SSL/TLS certificates: 
CrossCert, Certisign, Certsuperior, and Certisur.

Symantec has had multiple controls in place to ensure these RAs' compliance 
with the BRs:

Documentation:
1. Symantec operates an internal Knowledge Base ("KB") for its authentication 
staff and RA partners that contains detailed step-by-step procedures for 
performing each of the tasks required to validate the identity asserted in a 
certificate request.
2. The KB reinforces acceptable and unacceptable sources of validation 
information and processes using a subset of the information in the BRs.
3. The KB explains request flagging, flag reasons, and flag clearing procedures.

Training & Exams:
1. Topics include BR changes, CPS changes, process changes resulting from 
industry incidents regardless of the CA involved, and a review of Symantec's 
procedures that extend the Baseline Requirements.
2. Exams are modified and retaken annually as criteria to renew individual 
access certificates or after significant internal or external process changes.

Technology During Authentication:
1. Each request is screened for trade compliance, high-risk names, potential 
phishing (strings used in scam domains, high-profile brands), and other 
potentially risky content such as "test". Potential failures are flagged, 
preventing RA issuance, until and unless further review and analysis is 
completed.
2. Risk flags require manual override by authentication personnel - internal or 
RA personal as appropriate - for certificate issuance to proceed. Flag clearing 
privileges are only granted to personnel who are have completed the requisite 
training and passed appropriate exams.

Technology Pre- and Post- Issuance:
1. Each request is screened to ensure elements outside of the subject 
information are BR compliant (e.g. SAN fields are complete, proper validity 
limits are in place, 2048 bit or higher key lengths are used, etc.). This scan 
is done after Authentication personnel approve the request and before it is 
issued. These checks cannot be overridden.
2. Daily, we rescan all certificates issued on the prior day using these same 
checks.

Audit:
1. We requested independent WebTrust audit reports from RAs and assessed them 
for material findings pursuant to BR 8.4 regarding WebTrust audited Delegated 
Third Parties. See issue V addressing audits.

Customer-Facing Controls:
1. Symantec supports Certification Authority Authorization, putting control of 
authorized CAs in the hands of customers.
2. Symantec logs publicly trusted certificates to Certificate Transparency Logs 
and offers a CT monitor to provide visibility for all customers to enable 
detection of suspect certificates.

CrossCert Test Certificate Issue:

On January 19, 2017, Andrew Ayer, an independent researcher posted the results 
of an analysis of public Certificate Transparency logs through which he 
identified roughly 270 instances of suspicious certificates issued by multiple 
CAs, including Symantec, containing the words "test" or "example" in the 
subject information.

Symantec determined that 127 of these certificates were issued from Symantec 
operated CAs and that all 127 had been issued by the RA CrossCert. All but 31 
had already expired or been revoked.

Immediate Response
Andrew Ayer's report was a certificate problem report under BR 4.9.5 which 
required us to begin an investigation within 24 hours, which we did. We 
determined that 127 certificates were in scope of the problem report.

1. On January 19, 2017, after becoming aware of this issue, Symantec disabled 
issuance privileges for all CrossCert staff.
2. On January 20, 2017, Symantec revoked the 31 still valid and active 
certificates. These certificates had been issued between December 28, 2016 and 
January 18, 2017.
3. Symantec promptly took over validation and issuance for all pending and new 
orders submitted through CrossCert. Since then, Symantec's authentication team 
has continued to 

Symantec Response V

[Steve Medin via dev-security-policy]

Issue V: RA Program Audit Issues (2013 or earlier - January 2017)

Symantec has had two different programs that involve delegated third parties 
associated with publicly trusted TLS and subject to third-party audits: our 
GeoRoot program and our RA/Affiliate program.

GeoRoot refers to our program under which intermediate CAs have been created 
for the sole use and independent operation by specific customers at premises 
under their control. RA/Affiliate for publicly trusted SSL/TLS refers to our 
program under which we authorize appropriately trained personnel at select RA 
partners to complete all steps of authentication, review and certificate 
issuance.

We refer to the following section of Issue V of the Mozilla post:

"Symantec's RAs appear to have had a history of poor compliance with the BRs 
and other audit requirements, facts which were known to Symantec but not 
disclosed to Mozilla or dealt with in appropriately comprehensive ways.

Over multiple years (2013-12-01 to 2014-11-30, 2014-12-01 to 2015-11-30), 
Symantec's "GeoTrust" audits were qualified to say that they did not have 
proper audit information for some of these RAs. This information was in their 
management assertions, and repeated in the audit findings. So the poor audit 
situation was ongoing and known. Also, other audit reports, despite being in 
hierarchies accessible for issuance by the same RAs, did not have similar 
qualifications (Symantec Trust Network, 2014-12-01 to 2015-11-30)."

The audit findings referred to above are specifically related to audits under 
our GeoRoot program, not our RA program. Because GeoRoot only operates under 
GeoTrust roots and the associated CPS, the Symantec Trust Network and Thawte 
audits are fairly stated.

In the GeoTrust WebTrust BR 2015-2016 period in time audit, there were five 
references to external partners' subordinate CAs, including: Intel, Aetna, 
UniCredit, Google, and Apple.

Intel: https://crt.sh/?sha1=924b357fc7b9d8c9d26e41d4af4dc6c4babe90e5
Aetna: https://crt.sh/?id=33549
UniCredit: https://crt.sh/?CN=UniCredit+Subordinate+External
Google: https://crt.sh/?CN=Google+Internet+Authority+G2
Apple: https://crt.sh/?CN=Apple+IST+CA%25

Separately, Symantec operates two subordinate CAs solely for NTT DoCoMo in an 
enterprise PKI application. These subordinate CAs had been considered part of 
the "GeoRoot" program as well, and we had therefore excluded them (similar to 
the above externally operated ones) from the list of Symantec CAs in our 
audits. After reviewing our approach, our compliance team determined that they 
should be included going forward. As such, for the 2016-2017 Period in Time, 
these subordinate CAs are included in the GeoTrust WebTrust for CA and BR 
audits.

For the organizations that externally operate subordinate CAs, the previous 
audit issues centered on Intel, Aetna, and UniCredit. Intel's subordinate CA, 
which expired in 2016, was not subject to audits either contractually or by 
previous agreements with both Mozilla and Microsoft given its limited use. 
Symantec encountered challenges in getting audits for Aetna and UniCredit, as 
identified in our 2015-2016 Period in Time audit. After receiving a qualified 
audit for Aetna, dated May 11, 2016, and an assessment dated March 9, 2016 
rather than a WebTrust or ETSI audit for UniCredit, we held discussions with 
both companies regarding termination of their issuance privileges for new 
certificates and complete termination of all use as of November 30, 2016. 
UniCredit violated the requirements that Symantec placed on it for transition 
and Symantec thereafter promptly revoked its subordinate CA. Aetna's 
subordinate CA was revoked on November 30, 2016 because they complied with the 
ter
 ms of their CRL-only wind down period.

Symantec provided the letter quoted below to Google, Mozilla, Microsoft, and 
Apple when we shared the Point in Time Audits on September 6, 2016 to 
specifically address the GeoRoot audit status and remediation plan. That cover 
letter outlined the plan to wind down the Aetna and UniCredit subordinate CAs.  
Symantec received no reponse to our letter to the browser firms and 
subsequently executed the plan. This activity, along with the final wind down 
in 2016 of the Intel subordinate CA, were in the scope of our latest audits.

"Dear Browser Community:
The WebTrust Point in Time audit reports have now been issued by KPMG, which 
had no material findings.  The Point In Time is as of June 15, 2016.  You can 
find electronic copies of the reports here: 
https://www.symantec.com/about/legal/repository.jsp?tab=Tab3.

Please note that the last WebTrust Period in Time audit that covered December 
1, 2014 through November 30, 2015, identified two audit reports for partner 
subordinate CAs signed by the GeoTrust Global CA that were received but were 
not in accordance with permitted audit schemes.  The actions to address these 
audit reports from the partner subordinate CAs were in progress 

Symantec Response R

[Steve Medin via dev-security-policy]

Issue R: Insecure Issuance API (2013 or earlier - November 2016)

In April 2015, security consultant Chris Byrne responsibly disclosed two 
potential vulnerabilities related to our Quick Invite feature, which enables a 
reseller to invite pre-selected customers to enroll for certificates, via 
customized emails to the customer that contain deep links for enrollment, 
specific to the invitee. Consistent with Symantec's commitment to taking action 
when issues arise, Symantec promptly commenced an investigation following this 
April 2015 disclosure. As a result, both issues identified in this disclosure 
were remediated by May 20, 2015.

As there currently seems to be some confusion around this disclosure, we want 
to provide clarification. First, it is inaccurate to conflate the April 2015 
disclosure and the recent RA topic [Mozilla Issue T]. The Quick Invite feature 
is not an issuance API, and is unrelated to the RA delegated authentication 
capabilities.

Second, third-party reporting on Mr. Byrne's March 24, 2017 post has suggested 
that private keys were potentially accessible. Not only is this inaccurate, 
it's technically not feasible. This is because Symantec does not have access to 
our customers' TLS server private keys.

The first issue identified in this disclosure only occurred in the case that an 
invite deep link was intentionally exposed or an attacker had control over a 
victim's email account, allowing the attacker to click on that link and enable 
submission of a CSR to the reseller as if they were the legitimate invitee. 
Even in this scenario, proper domain vetting still happened and the attacker 
would have still needed to have ownership or control of the domain in the 
attacker's requested cert before the cert would be issued. Importantly, we do 
not believe that there was any danger of a cert being issued without proper 
demonstration of ownership or control of the domain. Nevertheless, as a result 
of this April 2015 disclosure, and consistent with our effort to continually 
improve our processes, policies and controls, we now require manual approval in 
cases where data reuse rules would have previously enabled us to issue based on 
prior approvals.

The second April 2015 issue was related to the TTL (Time-To-Live) of deep links 
associated with certificate lifecycle management for our resellers' customers. 
In this case, if the deep link was somehow exposed or the email account was 
compromised, an attacker could perform lifecycle operations on that 
certificate. While our resellers control the TTL of the Quick Invite deep link, 
which can be set to as little as one day, Symantec controls the TTL of the 
certificate lifecycle management deep links, which are only sent to the email 
address associated with the certificate. We proactively changed the TTL of 
these deep links from five days to two hours in order to reduce the window of 
exposure in the event the deep links are inappropriately exposed. In both 
situations, Symantec responded quickly and decisively to remediate the issues 
at hand and to enhance our overall security measures.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec Response P

[Steve Medin via dev-security-policy]

Issue P: UniCredit Sub CA Failing To Follow BRs (April - October 2016)

We are committed to keeping our customers, partners and ecosystem informed and 
taking action when necessary.  We recognize that there are issues we are 
accountable for, such as our March 2016 CA Communication response indicating we 
had disclosed all subordinate CAs. The omission of UniCredit was an oversight, 
it should have been disclosed as part of this March 2016 response. However, we 
were taking appropriate actions to address the underlying compliance issues.

We worked with UniCredit over a long period of time to enforce their compliance 
with audit requirements. In July 2016, we received an assessment that did not 
meet WebTrust audit standards. We then took action, helping UniCredit 
transition to a managed PKI solution for their certificate needs that did not 
require an audit. In parallel, we notified them of termination of their 
subordinate CA.

Because our customers are our top priority, we attempted to minimize business 
disruption while they transitioned by permitting UniCredit to operate only its 
CRL service until November 30, 2016, at which point we would revoke the 
UniCredit subordinate CA. In October 2016, UniCredit issued one new certificate 
in violation of the terms of that transition plan. Following that, Symantec 
promptly revoked the UniCredit subordinate CA on October 18, 2016.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec Response Q

[Steve Medin via dev-security-policy]

Issue Q: Symantec Audit Issues 2016 (December 2015 - November 2016)

In our 2014-2015 audits, certain issues were identified that we promptly took 
action on, including addressing the test certificate incident. We continued 
these efforts until the Point in Time audit was conducted. We split the 
2015-2016 audit reports in order to be fully transparent with the community 
about our operations after that work was completed. When viewing these sets of 
audits together, the community can see the steady progress we have made over 
the past 18 months, in line with our commitment to continually improving and 
enhancing our processes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec Response L

[Steve Medin via dev-security-policy]

Issue L: Cross-Signing the US Federal Bridge (February 2011 - July 2016)

Symantec, as well as VeriSign, has participated in the FPKI since 2006, and we 
take our responsibility as a participant of this program very seriously. When 
Symantec began participating in FPKI, FPKI rules required two-way 
cross-certification in a networked PKI model. In addition, FPKI rules mandated 
multiple assurance levels, which we mapped to our Class 1, Class 2 and Class 3 
roots. Class 3 roots are the only ones that have ever been enabled for TLS 
server certificate issuance.

In February 2016, Eric Mill prompted discussions with Symantec and the 
community about why the cross-certification resulted in some FPKI certs being 
trusted in browsers at https://github.com/18F/fpki-testing/issues/1. That 
discussion highlighted that browsers didn't process certificate policy 
extensions content during path building, while FPKI made extensive use of 
policy processing. We had already engaged with FPKI personnel to address this 
concern, and further engaged to determine if one-way cross-certification from 
FPKI to Symantec was sufficient, such that we could remove the 
cross-certification from Symantec to FPKI. On July 5, 2016,  FPKI notified 
Symantec that the cross-certificate, which was set to expire July 31, 2016, 
would not be required.

Because we have a responsibility to our customers to ensure their businesses 
remain uninterrupted, we knew that communication and giving them adequate time 
to adjust to the unscheduled change in trust was critical. In order to effect 
minimal disruption, we allowed the cross-certificate to expire on July 31, 
2016, rather than revoking it sooner.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec Response N

[Steve Medin via dev-security-policy]

Issue N: Premature Manual Signing Using SHA-1 (July 2016)

This matter represents the first time any CA attempted to follow the exception 
process which was developed over the course of weeks, beginning at the Bilbao 
CABF face-to-face meeting in May 2016, and with the input of our partners. 
Google initially proposed this exception process, which was later modified 
following input from other CABF members. Our internal process did not clearly 
specify to our PKI Operations team to stop at the point of TBS creation, which 
subsequently resulted in the creation of signed certificates instead of TBS 
Certificates. Importantly, our audit process promptly identified the error, and 
Symantec never released the certificates. We also promptly improved our 
internal process.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec Response E

[Steve Medin via dev-security-policy]

Issue E: Domain Validation Vulnerability (October 2015)

With respect to Issue E, Symantec has no additional comments regarding the 
perspective outlined in the summary. Please see 
https://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory=security_advisory==20160204_00
 for further detail on Symantec's previous commentary on this matter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec Response H

[Steve Medin via dev-security-policy]

Issue H: SHA-1 Issuance After Deadline (January 2016)

With respect to Issue H, Symantec has no additional comments regarding the 
perspective outlined in the summary. Please see 
https://cabforum.org/pipermail/public/2016-January/006519.html for further 
detail on Symantec's previous commentary on this matter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec Response B

[Steve Medin via dev-security-policy]

Issue B: 1024-bit Certificate Issued Directly From Root (Dec 2013 - Jan
2014)

The customer in question informed us of an issue in December 2013 that
threatened to seriously disrupt their primary business, and they sought our
assistance. The customer's non-browser implementation required a certificate
that was back-dated to support its boot phase, not chained through an
intermediate, and that used a 1024-bit key. This would replace a similar
certificate that was due to expire on December 31, 2013.

The BRs in effect at the time (1.1.6) allowed for issuance directly from a
root if five criteria were met, which occurred in this case. As the client
and server required a back-dated certificate during initial boot phase
communication, back-dating was a necessary action in order to prevent
serious business interruption during their peak business. While the
inclusion of our BR OID was an oversight, it was a rule violation rather
than a source of material risk and, as such, did not materially cause harm.
The lack of adequate entropy in the serial number was not a BR violation at
the time (it was a SHOULD). While this lack of adequate entropy in the
serial number was a violation of Microsoft's root policy requirements, the
manager of Microsoft's root program granted us a verbal waiver.

In order to be granted a verbal waiver by Microsoft, we engaged directly
with them to discuss this matter. However, we did not engage the broader
browser community due to the time pressure around the holiday. We seriously
weighed the security risks, and we believed that issuance of this cert
didn't impose risk on anyone but this specific customer, who was willing to
accept it. Further, it's important to understand that this action did not
threaten browser users, as the site wasn't used by browsers. We stand by our
decision to help our customer safeguard their business in this instance, in
a risk responsible manner when they needed us most. 

We didn't immediately disclose the issuance due to a contractual obligation
to protect the customer's privacy, which remains in force. We discussed this
obligation with our customer. In line with our commitment to disclosing
these events to the web security community with as much transparency as
possible, we posted our announcement on a Mozilla bug report on February 1,
2014, without using our customer's name.


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: [FORGED] Criticism of Mozilla Re: Google Trust Services roots

[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 Peter
> Gutmann via dev-security-policy
> Sent: Friday, March 10, 2017 4:15 AM
> To: Gervase Markham ; Peter Kurrasch
> 
> Cc: MozPol 
> Subject: Re: [FORGED] Criticism of Mozilla Re: Google Trust Services roots
> 
> Kurrasch via dev-security-policy 
> writes:
> 
> >* Types of transfers:  I don't think the situation was envisioned where
> >a single root would be transferred between entities in such a way that
> >company names and branding would become intermingled.
> 
> This has happened many times in the past, root certs have been sold and re-
> sold for years.

But I read Peter K's nuance as transfer of less than all the roots owned by a 
CA and/or less than all of the roots in a given brand. When GMO bought 
GlobalSign from Ubizen/Cybertrust, the entire brand went and 
GTE/Baltimore/Betrusted remained with Cybertrust. When Verizon transferred to 
DigiCert, the entire browser trust portfolio moved.

> 
> >* Manner of transfer:  As we learned from Ryan H., a second HSM was
> >introduced for the transfer of the private key meaning that for a
> >period of time 2 copies of the private key were in existence.
> 
> I would be surprised if only two copies were in existence, given the value of
> root keys I'd hope CAs have multiple backup copies.
> 

In my past experience, backups, rather than temporary transfer artifacts, are 
logically, physically, and geographically isolated at rest.

CAs that have been going concerns for many years may assume they intend to 
remain the owners of their roots until they expire. A shortcut results, 
certainly in the case of nCipher security worlds, where keys of common purpose 
and policy are mingled on common hardware, logically isolated by distinct m of 
n operator cardsets under an umbrella admin cardset.

By design, that becomes a split between what is transacting and what is not. At 
some point in time, witnessed by an auditor, in an environment secured 
commensurate with the presence of enabled root keys, transferred keys may need 
to be extracted and tested before the original copies are destroyed with 
witness of that destruction and to the satisfaction of the root buyer. During 
that test window, two copies exist.

Two copies should exist for that moment. Hot transfer of root keys from an HSM 
remaining in control of the seller and an HSM leaving with the buyer puts an 
entire PKI at risk. Copy, test, destroy is a recoverable scenario if a bad 
transfer and test occur.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Symantec: Next Steps

[Steve Medin via dev-security-policy]

In the case of CrossCert, where we have evidence of failure to properly 
document their work, we are NOT relying on their previous work and have begun 
fully revalidating all active certificates. In the cases of the other 3 RAs, 
our focus is reviewing all of the work previously done to verify that it can, 
in fact, be relied upon and/or determine where full revalidation, without 
relying on the prior work of the RA, is warranted, if at all.


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Ryan
> Sleevi via dev-security-policy
> Sent: Wednesday, March 08, 2017 11:37 AM
> To: Gervase Markham 
> Cc: Ryan Sleevi ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: Symantec: Next Steps
> 
> 
> I highlight this, because at least one of these DTPs failed to maintain
> sufficient audit logs, and Symantec has stated it plans to continue using this
> information - information improperly secured, improperly maintained, and
> with improper access controls - for the issuance of certificates.
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Misissued/Suspicious Symantec Certificates

[Steve Medin via dev-security-policy]

Our fourth response to questions is posted at Bugzilla, 
https://bugzilla.mozilla.org/show_bug.cgi?id=1334377.



It includes two attachments at that bug:

https://bugzilla.mozilla.org/attachment.cgi?id=8843448

https://bugzilla.mozilla.org/attachment.cgi?id=8843449





From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Wednesday, February 22, 2017 11:33 PM
To: Steve Medin <steve_me...@symantec.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org; r...@sleevi.com; Gervase 
Markham <g...@mozilla.org>
Subject: Re: Misissued/Suspicious Symantec Certificates



Hi Steve,



Thanks for your continued attention to this matter. Your responses open many 
new and important questions and which give serious question as to whether the 
proposed remediations are sufficient. To keep this short, and thereby allow 
Symantec a more rapid response:



1) Please provide the CP, CPS, and Audit Letter(s) used for each RA partner 
since the acquisition by Symantec of the VeriSign Trust Services business in 
2010.







On Fri, Feb 17, 2017 at 8:32 PM, Steve Medin via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

   Our third response to questions, including these two below, is posted at 
Bugzilla, and directly at 
https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825<https://clicktime.symantec.com/a/1/maIs7jXt0tqwnz1Jx0AxZjkA8GILUQI09uuEhZICWEQ=?d=7ylIQcW9MI3sm23dlF9kH0iQJbyD55FBGhRKwcFXib_4hIAJwQhgd3_24qB0coAv-SdkMKlUr1dYe3ULlJgm969yhZKu4ZLoTqyM3AhvyrmRjBijxx3oSZPweXl_MrKyswyJA1YgFpcKGlUTjUSxotLtqPMZn4tj-_2nsHC7tdtHzA9HmVLZRFXR2Ty6fDlHgYxN5haET45fGSzWiPA8P-VLtfS-ypJqHrmea4f-tKogptm9DGWQ3s-zZjo7FB1wGZL29RK8Xht9YbsSKN7HoJ0DcrJCTqWKwAapOYXopyC1Pf6hUe049AYjSS_wYcu7YAYcbfx2aEyndOFglqSVO7862-3Ny98IiKnskPeYE4pqtE1wHuEAeXC4OopLbVI1LP28GRXPjy8GPSImqgPdjyvD-hmSUJJt=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%3D8838825>.





   From: Ryan Sleevi [mailto:r...@sleevi.com<mailto:r...@sleevi.com>]
   Sent: Friday, February 17, 2017 6:54 PM
   To: Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>>
   Cc: Gervase Markham <g...@mozilla.org<mailto:g...@mozilla.org>>; 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>;
 Steve Medin <steve_me...@symantec.com<mailto:steve_me...@symantec.com>>
   Subject: Re: Misissued/Suspicious Symantec Certificates



   Hi Steve,



   Two more question to add to the list which is already pending:



   In [1], in response to question 5, Symantec indicated that Certisign was a 
WebTrust audited partner RA, with [2] provided as evidence to this fact. While 
we discussed the concerns with respect to the audit letter, specifically in 
[3], questions 3 - 6, and while Symantec noted that it would case to accept 
future EY Brazil audits, I have confirmed with CPA Canada that at during the 
2016 and 2017 periods, EY Brazil was not a licensed WebTrust practitioner, as 
indicated at [4].



   Given that EY Brazil was not a licensed WebTrust auditor, it appears that 
Symantec failed to uphold Section 8.2 of the Baseline Requirements, v1.4.1 [5], 
namely, that "(For audits conducted in accordance with the WebTrust standard) 
licensed by WebTrust", which is a requirement clearly articulated in Section 
8.4 of the Baseline Requirements, namely, that "If the CA is not using one of 
the above procedures and the Delegated Third Party is not an Enterprise RA, 
then the CA SHALL obtain an audit report, issued under the auditing standards 
that underlie the accepted audit schemes found in Section 8.1, ..."



   1) Was Symantec's compliance team involved in the review of Certisign's 
audit?

   2) Does Symantec agree with the conclusion that, on the basis of this 
evidence, Symantec failed to uphold the Baseline Requirements, independent of 
any action by a Delegated Third Party?



   [1] 
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933<https://clicktime.symantec.com/a/1/vG4MDB3hNsGYUc24ZpW7pdrPIan-c_b-D8RRJ1NfRP4=?d=7ylIQcW9MI3sm23dlF9kH0iQJbyD55FBGhRKwcFXib_4hIAJwQhgd3_24qB0coAv-SdkMKlUr1dYe3ULlJgm969yhZKu4ZLoTqyM3AhvyrmRjBijxx3oSZPweXl_MrKyswyJA1YgFpcKGlUTjUSxotLtqPMZn4tj-_2nsHC7tdtHzA9HmVLZRFXR2Ty6fDlHgYxN5haET45fGSzWiPA8P-VLtfS-ypJqHrmea4f-tKogptm9DGWQ3s-zZjo7FB1wGZL29RK8Xht9YbsSKN7HoJ0DcrJCTqWKwAapOYXopyC1Pf6hUe049AYjSS_wYcu7YAYcbfx2aEyndOFglqSVO7862-3Ny98IiKnskPeYE4pqtE1wHuEAeXC4OopLbVI1LP28GRXPjy8GPSImqgPdjyvD-hmSUJJt=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%3D8831933><https://clicktime.symantec.com/a/1/6wJmuz5H2ktURSIGjev34ZuuQTad1LRVz1nIlADR7XE=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9wd5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntAWmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-4oZ1OAUbs4kCgGUxt8c
 
WaB75e0ZDlR_f

RE: Misissued/Suspicious Symantec Certificates

[Steve Medin via dev-security-policy]

Our third response to questions, including these two below, is posted at 
Bugzilla, and directly at 
https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825.





From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Friday, February 17, 2017 6:54 PM
To: Ryan Sleevi 
Cc: Gervase Markham ; 
mozilla-dev-security-pol...@lists.mozilla.org; Steve Medin 

Subject: Re: Misissued/Suspicious Symantec Certificates



Hi Steve,



Two more question to add to the list which is already pending:



In [1], in response to question 5, Symantec indicated that Certisign was a 
WebTrust audited partner RA, with [2] provided as evidence to this fact. While 
we discussed the concerns with respect to the audit letter, specifically in 
[3], questions 3 - 6, and while Symantec noted that it would case to accept 
future EY Brazil audits, I have confirmed with CPA Canada that at during the 
2016 and 2017 periods, EY Brazil was not a licensed WebTrust practitioner, as 
indicated at [4].



Given that EY Brazil was not a licensed WebTrust auditor, it appears that 
Symantec failed to uphold Section 8.2 of the Baseline Requirements, v1.4.1 [5], 
namely, that "(For audits conducted in accordance with the WebTrust standard) 
licensed by WebTrust", which is a requirement clearly articulated in Section 
8.4 of the Baseline Requirements, namely, that "If the CA is not using one of 
the above procedures and the Delegated Third Party is not an Enterprise RA, 
then the CA SHALL obtain an audit report, issued under the auditing standards 
that underlie the accepted audit schemes found in Section 8.1, ..."



1) Was Symantec's compliance team involved in the review of Certisign's audit?

2) Does Symantec agree with the conclusion that, on the basis of this evidence, 
Symantec failed to uphold the Baseline Requirements, independent of any action 
by a Delegated Third Party?



[1] 
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933

[2] 
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929

[3] 
https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487

[4] 
http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx

[5] 
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

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

RE: Intermediates Supporting Many EE Certs

[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 Nick
> Lamb via dev-security-policy
> Sent: Tuesday, February 14, 2017 12:14 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Intermediates Supporting Many EE Certs
> 
> On Tuesday, 14 February 2017 13:47:51 UTC, Steve Medin  wrote:
> > -  PKCS#7 chains are indeed not a requirement, but see point 1. It’s
> probably no coincidence that IIS supports it given awareness of the demands
> placed on enterprise IT admins.
> 
> 
> Not once have I thought "This would be easier with PKCS#7". Literally I've
> never even had to walk a user through how to make a PKCS#7 file, because it
> never comes up. In addition to PEM they've needed JKS and PKCS#12 and ZIP
> files but never PKCS#7.
> 

But Nick, you carry PKI around in your back pocket. Any of us reading this know 
JKS, CAPI, apache mod-ssl directives and prefer a manifest of separate files.

I mention P7 because IIS inhales them in one click and ensures that the 
intermediate gets installed. There is an audience that likes that. In my last 
version, my enrollment portal asked for server type at request time and 
delivered target-friendly files on fulfillment with a link to other formats at 
a download center.


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: Intermediates Supporting Many EE Certs

[Steve Medin via dev-security-policy]

Top comments for readability.

 

-  IT professionals, server administrators, are humans, often 
overworked, who need care, assistance, and attention. In my past version, I 
offered helpdesk to helpdesk support and lost business that demanded helpdesk 
to end user server admin.

-  The caching I’m talking about is not header directives, I mean how 
CAPI and NSS retain discovered path for the life of the intermediate. One 
fetch, per person, per CA, for the life of the CA certificate.

-  AIA CAI URIs pushed to CDN? Mindless, one click.

-  I use the term user agent intentionally acknowledging that if all it 
took was 6 contracts, we’d have to run CABF meetings in convention centers.

-  When Microsoft first supported dynamic path discovery using AIA, we 
all fielded the support questions: why does IE work and X does not? We all 
pulled our AIA CAI extensions because the confusion wasn’t worth the benefit.

-  Ever since Vista, CAPI’s root store has been pulled over a wire upon 
discovery. Only kernel mode driver code signing roots are shipped.

-  Once the mass market UAs enable dynamic path discovery as an option, 
server admins can opt in based on analytics.

-  PKCS#7 chains are indeed not a requirement, but see point 1. It’s 
probably no coincidence that IIS supports it given awareness of the demands 
placed on enterprise IT admins.

 

At this point, I may as well be hitting tennis balls off a cliff. You’re dug in.

 

 

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Monday, February 13, 2017 6:45 PM
To: Steve Medin 
Cc: r...@sleevi.com; Patrick Figel ; 
mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham 

Subject: Re: Intermediates Supporting Many EE Certs

 

 

 

On Mon, Feb 13, 2017 at 2:39 PM, Steve Medin  > wrote:

With de facto use of AIA, there is no issuer installation on the server that 
could be improper. Proper is defined at the moment, either by cache or 
discovery hints.

 

I think this may be the crux of our disagreement. I believe that an ideal 
configuration is one that is the most efficient for the most users. Anything 
less - that is, things that slow connections or require all clients to 
introduce additional logic - is an improper configuration. This is similar to 
an HTTP server that always forced an extra redirect or which failed to use 
modern cryptographic algorithms or which sent along an extra 40KB of non-gzip'd 
JS. It may be valid in the protocol, but it's an improper configuration.

 

Some improper configurations - however valid - can cause breakage. Others can 
be papered over. Any time it's papered over, that's a "hack", not a desired end 
state.

 

We all understand that microseconds are core to your business model. We’re 
talking about one hit every N years or N-thousand certificates. You’re going to 
earn back the time spent through smaller TLS payload no longer sending 
intermediates that are already cached.

 

In practice, we don't, given CAs' poor responsiveness for AIA fetches and the 
poor configurations for cache lifetimes. In theory, yes. In practice, no.

 

 

We can deploy AIA CA Issuers support across user agents faster than we can 
deploy PKCS#7 support across servers.

 

This is false for most values, because "user agents" extend beyond the Big Five 
browsers (Chrome, Edge/IE, Firefox, Safari, Opera). Consider software such as 
curl, or clients such as Python or Perl. In those scenarios, your deployment 
scenario is as-bad-or-worse than the server support, but focusing on server 
support is a several orders of magnitude less work for implementation or 
deployment. Also, to be clear, the deployment of intermediates in no way 
requires PKCS#7 support.

 



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: Intermediates Supporting Many EE Certs

[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 Nick
> Lamb via dev-security-policy
> Sent: Monday, February 13, 2017 6:37 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Intermediates Supporting Many EE Certs
> 
> On Monday, 13 February 2017 22:40:45 UTC, Steve Medin  wrote:
> > With de facto use of AIA, there is no issuer installation on the server
that
> could be improper. Proper is defined at the moment, either by cache or
> discovery hints.
> 
> Much as I should like ubiquitous ambient Internet to be a ground truth,
the
> reality is that clients connecting to a TLS server today don't necessarily
have
> access in order to resolve URLs baked into AIA. Indeed in many cases
> (including for products sold by your own company, Symantec) the whole
> reason the client is talking to this particular server is in order to get
access
> _to_ the Internet.

Locally resolved on access points, gateways and egress inspection devices by
full chain installation, not the problem I'm working.


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: Intermediates Supporting Many EE Certs

[Steve Medin via dev-security-policy]

Patrick, thanks, it appears my attempt at brevity produced density.

- No amount of mantra, training, email notification, blinking text and
certificate installation checkers make 100% of IT staff who install
certificates on servers aware that issuing CAs change and need to be
installed with the server certificate when they do.
- Many servers do not support PKCS#7 installation.
- When you roll an intermediate issuer and you modify the end entity
certificate's AIA CA Issuers URI at the same time, the server presents an EE
to the browser that provides a remedy to path validation failure.
- The browser does its normal path discovery using cached discovered
intermediates.
- At rollover, the browser doesn't find the EE's issuer cached locally.
- The browser chases AIA to the issuer that the EE asserts is its issuer,
validates that, and caches the issuer for another  years.
It's a one-validation latency cost per end user given cached path discovery.

Recently, we renewed a subordinate under the Federal Bridge CA and we
deployed trust across the community by updating a JBoC PKCS#7 file
referenced by the CA Issuers AIA. Granted, this is what some may call a
cross-certificate rather than subordination, but my point is that the end
entities that point to the .p7c enable peers and clients to discover path of
FBCA > SSP Gen 1 CA > EE as easily as FBCA > SSP Gen 2 CA > EE. 


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Patrick Figel via dev-security-policy
> Sent: Monday, February 13, 2017 2:10 PM
> To: r...@sleevi.com
> Cc: Gervase Markham <g...@mozilla.org>; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: Intermediates Supporting Many EE Certs
> 
> On 13/02/2017 18:25, Ryan Sleevi via dev-security-policy wrote:
> > On Mon, Feb 13, 2017 at 8:17 AM, Steve Medin via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> Getting all user agents with interest is issuance limits to implement
> >> the CA Issuers form of AIA for dynamic path discovery and educating
> >> server operators to get out of the practice of static chain
> >> installation on servers would make CA rollovers fairly fluid and less
> >> subject to operator error of failing to install the proper
intermediate.
> >
> >
> > Can you explain more to support that statement?
> >
> > The issue that Gerv is discussing is primarily related to intermediate
> > issuance; a CA an easily roll over to a new intermediate and provide
> > their customers a holistic chain that represents a path to a Mozilla
> > root. The issue you describe - with AIA fetching - is one primarily
> > restricted to handling _root_ rollover, not _intermediate_ rollover;
> > that is, when you're constructing an alternative trust path for a set
> > of existing certificates, rather than, as Gerv raised, ensuring that
> > new certificates come from a single ('new') trust path once the
> > existing intermediate has been 'exhausted'.
> >
> > While a strong proponent of AIA, I don't believe your argument here is
> > relevant, although I'm quite happy to understand what technical
> > criteria exist that make you believe it would be beneficial to address
> > this specific problem.
> 
> I suspect many CAs would be reluctant to rotate intermediates regularly
> because updating the intermediate certificate would be yet another thing
> that server administrators can get wrong during renewal. Data from Chrome
> shows that incorrect or missing intermediates account for 10-30% of all
> certificate validation errors depending on platform[1], though I'm
guessing
> missing intermediates would account for most of that.
> 
> Let's Encrypt switched to a new intermediate certificate about a year ago.
> Despite plenty of warnings that it may change at any time and a protocol
that
> allowed retrieving the intermediate certificate programmatically, there
were
> still a number of clients and guides with static intermediates out there,
which
> caused breakage for some sites once they renewed. This is the main reason
> why later versions of the ACME draft switched to delivering the end-entity
> certificates and intermediates as one file by default.
> 
> Having support for AIA fetching in all major browsers would reduce the
> impact of such misconfigurations. IIRC the only browsers that currently
don't
> do this are Firefox and Chrome on Android, though the latter seems to have
> plans to change this.
> 
> Something else that needs to be considered is how it affects HPKP
> deployment. I don't know if there are any CAs out there who recommend
> pinning to (not-customer-sp

RE: Intermediates Supporting Many EE Certs

[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, February 13, 2017 7:23 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Intermediates Supporting Many EE Certs
>
>
> What can be done about the potential future issue (which might happen with
> any large CA) of the need to untrust a popular intermediate?
> Suggestions welcome.
>
> Gerv
>

Either timespan or total certificates issued limits, as ballots, accounting for 
quantity growth from the end entity certificate lifespan reduction proposals, 
would be an approach.

Getting all user agents with interest is issuance limits to implement the CA 
Issuers form of AIA for dynamic path discovery and educating server operators 
to get out of the practice of static chain installation on servers would make 
CA rollovers fairly fluid and less subject to operator error of failing to 
install the proper intermediate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Misissued/Suspicious Symantec Certificates

[Steve Medin via dev-security-policy]

A response is now available in Bugzilla 1334377 and directly at:
https://bugzilla.mozilla.org/attachment.cgi?id=8836487


> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Thursday, February 09, 2017 4:56 AM
> To: Steve Medin ; mozilla-dev-security-
> pol...@lists.mozilla.org
> Cc: r...@sleevi.com
> Subject: Re: Misissued/Suspicious Symantec Certificates
>
> On 09/02/17 03:07, Ryan Sleevi wrote:
> > We appreciate your attention to these questions and will thoughtfully
> > consider a response to these questions if received no later than
> > 2017-02-13
> > 00:00:00 UTC.
>
> Mozilla also requests answers to these excellent questions under the same
> terms and, for the avoidance of doubt, interprets the above as the point in
> time between Sun 2017-02-12 and Mon 2017-02-13, rather than the point in
> time between Mon 2017-02-13 and Tue 2017-02-14.
>
> Gerv

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