RE: CA generated keys
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&u > =https%3A%2F%2Flists > .mozilla.org%2Flistinfo%2Fdev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-s
RE: [EXT] CAs not compliant with CAA CP/CPS requirement
Our Policy Management Authority completed review of this and numerous other changes on September 8. The GeoTrust and Thawte CPS updated that day. The Symantec CP and CPS were updated the following day Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of > Andrew Ayer via dev-security-policy > Sent: Friday, September 08, 2017 3:25 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: [EXT] CAs not compliant with CAA CP/CPS requirement > > The BRs state: > > "Effective as of 8 September 2017, section 4.2 of a CA's Certificate Policy > and/or Certification Practice Statement (section 4.1 for CAs still conforming > to RFC 2527) SHALL state the CA's policy or practice on processing CAA > Records for Fully Qualified Domain Names; that policy shall be consistent > with these Requirements. It shall clearly specify the set of Issuer Domain > Names that the CA recognises in CAA 'issue' or 'issuewild' records as > permitting it to issue. The CA SHALL log all actions taken, if any, consistent > with its processing practice." > > Since it is now 8 September 2017, I decided to spot check the CP/CPSes of > some CAs. > > At time of writing, the latest published CP/CPSes of the following CAs are > not compliant with the above provision of the BRs: > > Amazon > (https://clicktime.symantec.com/a/1/NmZ9sYttj7vKv6t18I35QRQ0FMHxkP > NpP8WSJXL-eYo=?d=zu- > OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9- > gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij > SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ > BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S > IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO > RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK- > 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh- > o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s > 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fwww.amazontrust.com% > 2Frepository%2F) - Does not check CAA > > Comodo > (https://clicktime.symantec.com/a/1/7dk4IPNLHeQgWaoO8HJ5ksv2_spTr > Mwd0vsOAxU735E=?d=zu- > OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9- > gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij > SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ > BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S > IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO > RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK- > 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh- > o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s > 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fwww.comodo.com%2Fab > out%2Fcomodo-agreements.php) - Does not specify issuer domain names > > DigiCert > (https://clicktime.symantec.com/a/1/xlVibpoycRtW78OkiI3usE639u_3QGd > RehxP5QhPWPs=?d=zu- > OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9- > gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij > SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ > BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S > IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO > RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK- > 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh- > o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s > 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fwww.digicert.com%2Flega > l-repository%2F) - Does not specify issuer domain names, and processing is > not compliant with BRs ("If a CAA record exists that does not list DigiCert as > an authorized CA, DigiCert verifies that the applicant has authorized > issuance, despite the CAA record.") > > Google Trust Services > (https://clicktime.symantec.com/a/1/FDXLCPoMms9u5GaLDCj2Qk1jqwAV > PQjmvvu2wergGPg=?d=zu- > OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9- > gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij > SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ > BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S > IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO > RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK- > 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh- > o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t_YpQBoP6s > 1eRu6EjgQZ7KQ%3D%3D&u=https%3A%2F%2Fpki.goog%2F) - Does not > check CAA > > Identrust (https://clicktime.symantec.com/a/1/- > hcYCELwi2ejxzoC9hWCgVYMAFr-ZM4ljorelCgIGqk=?d=zu- > OWyaepWo9aCiMKjwr_Mpk4cgBKZV809pQKiSOuM3HCRZv0YTyzv9- > gtKYjE_ERhEPC5j03wspJwAD4li2UOxAGHhETJWCGtzKlfXxGQLL2HNwx5Xqij > SYUlRc5C1CkmOZFwcAwAZvkRfXUWHpJfR33lZYK3iYtpD8t39Q7rqXydnBQ > BL618AIpfNXYKPDaQJCqQlYMht4TC2jgbN3Rjgop8ONMaQi52cLQecwyH_S > IHxrAuOmMYlc6mR9d9rhGxg_OtQjib6ZG8F1wAwDcLX7L3PuzzQ7HSw3PO > RbIh6pk4zjCf82u_iftEUSCG3OQrrwYYOZkdGhTM592FLJ4VHMfK- > 4eLpWYyI9-34iNLgu-RMpKedB_9X7prQsOgeQIvH-9jN6T4OyOQeh- > o00JBr6kYjJXpNaIaUfWYo1GjkxmdtxeLK4brTdhhPD2BpC1Q9t
RE: [EXT] Re: DigiCert-Symantec Announcement
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
> -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
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
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 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 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&u=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
> -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
> -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
> -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
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 Base
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 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 certi
RE: [EXT] Mozilla requirements of Symantec
> -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 re
RE: [EXT] Symantec response to Google proposal
> -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
> -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
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&field=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
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&opt=mozilladisclosure<https://clicktime.symantec.com/a/1/DpMVeod7OdWoZrchhebweNegkGMPsUHp-1SWSqHLiWg=?d=Z1VSr8kRHw-swZNCE6n0F6PJqS6Dawy0ZRX24ox8r12BLpDUpmwr2X0yO-UqN1DccyjCinObo29F4evy4ZTl321EROz_CUwk2Ph-0yTAk7_QFo0UyMEIbnfZbjKKwoOKM57FZ2pYUpkFOpFhmST_wLeoBztL6ERQ3p_LHV3k2r7Zvwr0y4AMyFUV-bsZ4TcJ8IxShADpdauwBawRNGCpwxuCt2rPgjaoGvJ5MOiYZcwFM00xu7ZRLvkJ7o577ceGmn6MisHkhyHX_7MZqVMtpUVMwU5L_HfezBj76rliUXPk9o1HD_udc5oCBn2sSiOSGZGQznN6inakQDPVY3BqkLX-UvpTxecosycllppwkMG7_iMTqQOfAuKCDrxHzhWL000nMcOq-afUAfeaHNF_&u=https%3A%2F%2Fcrt.sh%2F%3Fsha256%3D68a9878d55ad42107cfeb758e34873686969b0a47c7468fb189991acb62da798%26amp%3Bopt%3Dmozilladisclosure>. Can you confirm that this CA has _never_ been used to issue a certificate? (There 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
> -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
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
> -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
> -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
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&u=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
> -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 organ
RE: [EXT] Re: Questions for Symantec
> -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 inf
RE: [EXT] Re: Questions for Symantec
> -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
> -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
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
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
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 f
Symantec Response V
it reports from the partner subordinate CAs were in progress before the point in time audit started. Symantec has begun the process to terminate the agreements with both partners. One partner has ceased issuance of new certificates and the other will stop as of September 30, 2016. In both cases, Symantec will permit continued use of the subordinate CAs solely for the purpose of signing CRLs through November 30, 2016. Please reach out to Steve Medin for any questions." We do not believe we received feedback from the browsers listed above on this approach until March 31, 2017, more than seven months later. We refer to the following section of Issue V of the Mozilla post: "We currently know of four RAs who were in Symantec's program - CrossCert, Certisign, Certsuperior, and Certisur..." CrossCert, Certisign, Certsuperior and Certisur were the RA partners authorized to authenticate and issue SSL/TLS certificates. The collection of their audits was incomplete. All of Certisign's audits are both WebTrust for CAs and SSL Baseline and were unqualified. Certsuperior's audits state that their scope was WebTrust for SSL Baseline but do not state WebTrust for CAs. Prior to 2016, Certsuperior provided WebTrust SSL Baseline audits from an unlicensed auditor. Symantec's compliance organization identified the issue in 2016. For 2016, Certsuperior provided a qualified audit by Deloitte, a WebTrust licensed auditor in Mexico. Certsuperior's audit led to immediate sanction to solve the issues detected within 90 days and to provide a Point in Time audit. They provided such audit and it was unqualified. Further, Deloitte is required to examine certificate issuance as a normal part of the WebTrust program and they did not cite any problems with Certsuperior's validation work in either audit. Accordingly, we believe certificate issuance was inspected. Symantec's compliance organization has requested that Certsuperior's next audit explicitly include the criteria in both WebTrust for CAs and WebTrust Baseline. Certisur's audits were WebTrust for CAs only. Symantec's compliance organization identified the issue and has requested that Certisur's next audit for calendar year 2016 explicitly include the criteria in both WebTrust for CAs and WebTrust Baseline. All audits received were unqualified and performed by a licensed WebTrust auditor. CrossCert's audits were WebTrust for CAs only through 2015. For 2015-2016 CrossCert provided both WebTrust for CAs and WebTrust BR audits. These audits were all unqualified and all performed by a licensed WebTrust auditor. We subsequently identified an issue with the scope of the 2015-2016 audits which is discussed in our response to issue T. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Symantec Response R
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
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
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
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
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 J
Issue J: SHA-1 Issuance After Deadline, Again (February 2016) On February 29, 2016, a CT pre-certificate was generated using a SHA-1 hash. The system checks we had in place at the time prevented new enrollments with SHA-1; however, the enrollment associated with this particular pre-cert specified SHA-256 when it originated in our systems. As part of our assessment of the situation, we discovered that an enterprise customer used a deprecated, enterprise-only interface that historically allowed them to change the algorithm requested from SHA-256 to SHA-1 after the initial enrollment. While this use case with the deprecated interface was missed during testing, it was promptly patched. Specifically, we quickly removed the historic interface that allowed algorithm changes after enrollment, and conducted a review to identify any other deprecated interfaces that could cause the same or related issues. We acknowledge that this CT pre-certificate was a BR violation. The final certificate was not generated, as it was rejected during administrator review prior to issuance. Our prior public updates about this matter can be found here: https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/symantec$20sha1%7Csort:relevance/mozilla.dev.security.policy/siHOXppxE9k/NNwjrMJ6BAAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Symantec Response E
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&pvid=security_advisory&year=&suid=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
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 D
Issue D: Test Certificate Misissuance (April 2009 - September 2015) Symantec has provided complete investigation results for this issue. They can be found at https://www.symantec.com/page.jsp?id=test-certs-update# We would like to further clarify the following statement in this issue summary: "Some of the test certificates (including one for www.google.com) left Symantec's network because they were logged in CT; Symantec claims no others did." We believe this statement is inaccurate for two reasons. First, the action of logging certificates to CT does not necessarily mean that the certificates left Symantec's network. Beginning January 1, 2015, Symantec began logging all EV certificates in CT log servers. Given that certificates are logged in CT at the time of creation in our system, any distribution of certificates that we issue is a second, independent step. Moreover, at the time we investigated this incident, we conducted multiple scans for domains used in test certificates. Following a thorough investigation process, we found no evidence that these certificates were used on external servers. Accordingly, we have no evidence that any of the test certificates involved in this investigation left Symantec's network. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Symantec Response F
Issue F: Symantec Audit Issues 2015 (December 2014 - November 2015) With respect to Issue F, Symantec has no additional comments regarding the perspective outlined in the summary. Please see https://www.symantec.com/about/legal/repository.jsp?tab=Tab3 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
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
> -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
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
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 Cc: mozilla-dev-security-pol...@lists.mozilla.org; r...@sleevi.com; Gervase Markham 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 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&u=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 mailto:r...@sleevi.com>> Cc: Gervase Markham mailto:g...@mozilla.org>>; mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>; Steve Medin 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&u=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_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvKsUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%3D&
RE: Misissued/Suspicious Symantec Certificates
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<https://clicktime.symantec.com/a/1/6wJmuz5H2ktURSIGjev34ZuuQTad1LRVz1nIlADR7XE=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9wd5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntAWmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvKsUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%3D&u=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%3D8831933> [2] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929<https://clicktime.symantec.com/a/1/pfZiLBH0rxpzxfeiB5YSfvWdOjwpHC72M_rUahZJxKQ=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9wd5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntAWmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvKsUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%3D&u=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%3D8831929> [3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487<https://clicktime.symantec.com/a/1/80dDdC7HC5yMdzxfwRS0saqQ2kS5Tvwuo_kNWaXWLCI=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9wd5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntAWmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvKsUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%3D&u=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%3D8836487> [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<https://clicktime.symantec.com/a/1/7AUAkdAzUJ1un022RuP_TfjD3UiY12QGLjanVeGgxhk=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9wd5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntAWmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvKsUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%3D&u=https%3A%2F%2Fcabforum.org%2Fwp-content%2Fuploads%2FCA-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
> -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
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 mailto:steve_me...@symantec.com> > 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
> -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
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. CA Issuers AIA resolution of EE to issuer is good enough for government work, and fortunately the market offers software that consumes it. I don’t consider the Federal Bridge papered over or the FPKI PA an authority that papers over their solutions. We can roll issuing CAs with less operator error if we can reliably use AIA and educate that the issuing chain does not need to be installed, maintained, or passed in the TLS payload. 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. We can deploy AIA CA Issuers support across user agents faster than we can deploy PKCS#7 support across servers. From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, February 13, 2017 3:35 PM To: Steve Medin Cc: Patrick Figel ; r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham Subject: Re: Intermediates Supporting Many EE Certs As mentioned, I'm a strong proponent of AIA - I think it serves a valuable role in ecosystem agility for root migrations - but I don't think it's necessarily good for users when it's used to paper over (clear) server misconfigurations, which is the situation you describe - where the path from the EE to the Intermediate is improper. I'm more thinking about situations for where the Intermediate to Root path may change, in order to accommodate changes in the Root (from Root 1 to Root 2). 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
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 ; 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 w
RE: Intermediates Supporting Many EE Certs
> -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
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
RE: Misissued/Suspicious Symantec Certificates
Our response to questions up to January 27, 2017 has been posted as an attachment to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1334377. The direct attachment link is: https://bugzilla.mozilla.org/attachment.cgi?id=8831933. The bug report contains additional documentation supporting our response. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, January 30, 2017 12:36 PM To: Ryan Sleevi Cc: Steve Medin ; Andrew Ayer ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Misissued/Suspicious Symantec Certificates Steve, As captured in our private mail exchange last week, Symantec's report fails to meaningfully address each or any of the questions I raised. Google considers it of utmost urgency that Symantec share the answers to these questions, posed a week ago, and based on Symantec's multiple public statements regarding the previous misissuance. Please confirm your receipt of these questions and your intent to provide an answer to the community by end of day, so that we can consider Symantec's answers when considering appropriate next steps to protect our users. In the absence of timely information from a CA following a misissuance, it's both necessary and reasonable to consider the worst as plausible. For your reference, https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/chC7tXDgCQAJ 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: Misissued/Suspicious Symantec Certificates
Symantec's auditors, KPMG, completed a scan of CrossCert certificates to detect potential mis-issuance. On Thursday, January 26, 2017 at 4:08pm PST, KPMG provided a report that listed 12 problem certificates that were not in Andrew Ayer's report. We began an investigation into that certificate problem report at 6:30pm PST Thursday. Six of the certificates contained numbers in the locality, two were street addresses and four were Bangladeshi postal codes appended to the city name. Six contained the word "test" in the organization, but were false positives for legitimate organization names. We completed our investigation of these 12 certificates by requesting archived documentation. CrossCert was unable to produce documentation to prove their validation as required under BR 5.4.1. We revoked all 12 certificates within 24 hours of becoming aware of CrossCert's BR 5.4.1 non-compliance. Our investigation continues. Links: https://crt.sh/?id=16869385 https://crt.sh/?id=11199825 https://crt.sh/?id=11633501 https://crt.sh/?id=11281299 https://crt.sh/?id=11283579 https://crt.sh/?id=12504637 https://crt.sh/?id=42016028 https://crt.sh/?id=13161832 https://crt.sh/?id=13161834 https://crt.sh/?id=13161835 https://crt.sh/?id=25211067 https://crt.sh/?id=47456180 Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation 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: Misissued/Suspicious Symantec Certificates
Here is an attached PDF update regarding this certificate problem report. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Steve > Medin > Sent: Saturday, January 21, 2017 9:35 AM > To: Andrew Ayer ; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: RE: Misissued/Suspicious Symantec Certificates > > The listed Symantec certificates were issued by one of our WebTrust audited > partners. We have reduced this partner's privileges to restrict further > issuance while we review this matter. We revoked all reported certificates > which were still valid that had not previously been revoked within the 24 > hour CA/B Forum guideline - these certificates each had "O=test". Our > investigation is continuing. > 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: Misissued/Suspicious Symantec Certificates
The listed Symantec certificates were issued by one of our WebTrust audited partners. We have reduced this partner's privileges to restrict further issuance while we review this matter. We revoked all reported certificates which were still valid that had not previously been revoked within the 24 hour CA/B Forum guideline - these certificates each had "O=test". Our investigation is continuing. > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of > Andrew Ayer > Sent: Thursday, January 19, 2017 4:46 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Misissued/Suspicious Symantec Certificates > > I. Misissued certificates for example.com > > On 2016-07-14, Symantec misissued the following certificates for > example.com: > > https://clicktime.symantec.com/a/1/LyhH99FiQBwyOqKcts8QGJ75k6 > TPEC_N7jOPRSjGhkA=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3DA8F14F52CC1282D7153A13316E7DA39E6AE37B1A10C16288B902 > 4A9B9DC3C4C6 > https://clicktime.symantec.com/a/1/_X1- > P9bvSq0r_QG43YQ6BwhHeeRl4IrY8ebwWh9HWiQ=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3D8B5956C57FDCF720B6907A4B1BC8CA2E46CD90EAD5C061A426C > F48A6117BFBFA > https://clicktime.symantec.com/a/1/1ux2sxPZpTNuRjN4JV5qOj0550 > RDi16i7NLrqi0eFaY=?d=6VMu_T-sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3D94482136A1400BC3A1136FECA3E79D4D200E03DD20B245D19F0E > 78B5679EAF48 > https://clicktime.symantec.com/a/1/YT02EQBzJ13G0VwF_VLruHbKA > Ep4LXe40icNc0DLwUA=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3DC69AB04C1B20E6FC7861C67476CADDA1DAE7A8DCF6E23E15311 > C2D2794BFCD11 > > I confirmed with ICANN, the owner of example.com, that they did not > authorize these certificates. These certificates were already revoked at the > time I found them. > > > II. Suspicious certificates for domains containing the word "test" > > On 2016-11-15 and 2016-10-26, Symantec issued certificates for various > domains containing the word "test" which I strongly suspect were > misissued: > > https://clicktime.symantec.com/a/1/_0lsjfT3DHqxu1QJl2eBU5zx948r > qJmGy-bHkTlww3c=?d=6VMu_T-sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3Db81f339b971eb763cfc686adbac5c164b89ad03f8afb55da9604fd0 > d416bbd21 > https://clicktime.symantec.com/a/1/uF90PPzN7N3_lTMmPb8YzXKK > AfWPKKNmpvo_prjlE3Y=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N
RE: Compliance with 7.1.4.2.1 (internal names revocation)
Symantec has an additional disclosure regarding internal name certificates valid after October 1. First, we disclose 3 certificates that remained valid after October 1 but expired prior to our previous report. Second, we disclose 3 certificates that were revoked as a result of our analysis but not included in our initial report. The cause of both issues is the execution of a query to inform us what action needed to be taken within 24 hours. That result excluded revoked and expired certificates. This led to our initial report of additional certificates revoked along with the one reported to us by Nick Lamb. The specific cause of the additional revoked but not disclosed certificates is proactive effort by a team member to consult with two customers with relationship/enterprise accounts concurrent with other efforts to work with individual certificate owners. The revoked relationship/enterprise account certificates we disclose today were revoked prior to execution of the report and the report was used as the basis for our prior disclosure. Disclosure: https://crt.sh/?q=3518624 https://crt.sh/?q=78728901 https://crt.sh/?q=78728902 https://crt.sh/?q=78728903 https://crt.sh/?q=78728904 https://crt.sh/?q=78728905 > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Rick > Andrews > Sent: Wednesday, January 11, 2017 10:26 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Compliance with 7.1.4.2.1 (internal names revocation) > > We conducted a search of our databases in September 2016, in which we > examined every CN and SAN in every certificate still valid at the time. Each > CN and SAN was examined to see if it contained no dot or an invalid DNS > suffix; if so, the certificate was classified as an internal server cert and > revoked. For all remaining CNs and SANs, those were checked against our > internal list of TLDs built from information provided by ICANN and IANA. That > list had a status value associated with each TLD, and our mistake was in > excluding TLDs with certain status values. > > Our scans conducted this week discovered three additional certificates that > had not been revoked as of October 2016. These, and the certificate > discovered by Nick, have now been revoked. Here are the links to those > certificates: > > https://clicktime.symantec.com/a/1/zaK1Ry0U7rpBU7N7oUg8VKvELOYaomC > 6td_b_grLhtQ=?d=1Tjdh1nkBUvl3Ieoed4QOfdma64XoBtRI7P4FrBClOZzIPZC6 > gloJVNfUNg7YuoczOU1s5h2FQEikj_V4Ek5gom- > nUsaD5z1M_mr1BK_8M5KQx5C4M6oPnnIGHObc6tL3ilL07CqP7riK7XrmNexc > _jukzroGa-ablqJpuYEfAsJXEkYRZLKsjUdW5nvTQ8rdmamWA6T_- > 7CR8rpZFMtJ3OUHyIBvnFwqBIeteRjXzTHckwBBi3RZ8XQIlN8WokwyTFhO9otr > lKAPBNSs9Y_kKCnwrJ7cl_y7enkSqc8A4Fmu57zdPIvh1c4sxaFQEBSyPTztGqi1L > ai72GG1ArkQrZrGwBYvLscIjca4dTCi6JyGANQtcoumZ5Dzk6G4WK2SkVtDPMT > pZ9YT1Hr16bXatTxRll3mWVHnROQDbDnmyzKOC_1uYVyyZTfj_HYA90Z4htBg > MyBCz_rhfAbwqHhXd6ijIZdKd_pHhu_WA%3D%3D&u=https%3A%2F%2Fcrt. > sh%2F%3Fsha256%3DA642406A2BDF92DF8C9FB9322A81736506DDED79A20A > 7CD33CBEFD2AD2581167 > https://clicktime.symantec.com/a/1/0- > oGgxxfVZ5MoF1oKVElUpBOfhFQcamcIpg21Ex6nNI=?d=1Tjdh1nkBUvl3Ieoed > 4QOfdma64XoBtRI7P4FrBClOZzIPZC6gloJVNfUNg7YuoczOU1s5h2FQEikj_V4E > k5gom- > nUsaD5z1M_mr1BK_8M5KQx5C4M6oPnnIGHObc6tL3ilL07CqP7riK7XrmNexc > _jukzroGa-ablqJpuYEfAsJXEkYRZLKsjUdW5nvTQ8rdmamWA6T_- > 7CR8rpZFMtJ3OUHyIBvnFwqBIeteRjXzTHckwBBi3RZ8XQIlN8WokwyTFhO9otr > lKAPBNSs9Y_kKCnwrJ7cl_y7enkSqc8A4Fmu57zdPIvh1c4sxaFQEBSyPTztGqi1L > ai72GG1ArkQrZrGwBYvLscIjca4dTCi6JyGANQtcoumZ5Dzk6G4WK2SkVtDPMT > pZ9YT1Hr16bXatTxRll3mWVHnROQDbDnmyzKOC_1uYVyyZTfj_HYA90Z4htBg > MyBCz_rhfAbwqHhXd6ijIZdKd_pHhu_WA%3D%3D&u=https%3A%2F%2Fcrt. > sh%2F%3Fsha256%3D12B3CCC45D66B9CB2206DEF1C5A24B062CCC938694C92 > A0806D1D34845C0FC19 > https://clicktime.symantec.com/a/1/UzPJvyQ4_OFDb- > clEVONu_2vV6i20nAXDeD9Ur9jZvw=?d=1Tjdh1nkBUvl3Ieoed4QOfdma64Xo > BtRI7P4FrBClOZzIPZC6gloJVNfUNg7YuoczOU1s5h2FQEikj_V4Ek5gom- > nUsaD5z1M_mr1BK_8M5KQx5C4M6oPnnIGHObc6tL3ilL07CqP7riK7XrmNexc > _jukzroGa-ablqJpuYEfAsJXEkYRZLKsjUdW5nvTQ8rdmamWA6T_- > 7CR8rpZFMtJ3OUHyIBvnFwqBIeteRjXzTHckwBBi3RZ8XQIlN8WokwyTFhO9otr > lKAPBNSs9Y_kKCnwrJ7cl_y7enkSqc8A4Fmu57zdPIvh1c4sxaFQEBSyPTztGqi1L > ai72GG1ArkQrZrGwBYvLscIjca4dTCi6JyGANQtcoumZ5Dzk6G4WK2SkVtDPMT > pZ9YT1Hr16bXatTxRll3mWVHnROQDbDnmyzKOC_1uYVyyZTfj_HYA90Z4htBg > MyBCz_rhfAbwqHhXd6ijIZdKd_pHhu_WA%3D%3D&u=https%3A%2F%2Fcrt. > sh%2F%3Fsha256%3DE90AFAE4998D2B8103058ADF35810D87CCE5E98A0E1D6 > 91D2A558A6A4E115BAC > > Thanks again to Nick for discovering this and pointing it out. > > ___ > 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/list
RE: Misissued/Suspicious Symantec Certificates
Andrew, thank you for your efforts to report this issue. We are investigating and will report our resolution, cause analysis, and corrective actions once complete. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of > Andrew Ayer > Sent: Thursday, January 19, 2017 4:46 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Misissued/Suspicious Symantec Certificates > > I. Misissued certificates for example.com > > On 2016-07-14, Symantec misissued the following certificates for > example.com: > > https://clicktime.symantec.com/a/1/LyhH99FiQBwyOqKcts8QGJ75k6 > TPEC_N7jOPRSjGhkA=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3DA8F14F52CC1282D7153A13316E7DA39E6AE37B1A10C16288B902 > 4A9B9DC3C4C6 > https://clicktime.symantec.com/a/1/_X1- > P9bvSq0r_QG43YQ6BwhHeeRl4IrY8ebwWh9HWiQ=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3D8B5956C57FDCF720B6907A4B1BC8CA2E46CD90EAD5C061A426C > F48A6117BFBFA > https://clicktime.symantec.com/a/1/1ux2sxPZpTNuRjN4JV5qOj0550 > RDi16i7NLrqi0eFaY=?d=6VMu_T-sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3D94482136A1400BC3A1136FECA3E79D4D200E03DD20B245D19F0E > 78B5679EAF48 > https://clicktime.symantec.com/a/1/YT02EQBzJ13G0VwF_VLruHbKA > Ep4LXe40icNc0DLwUA=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3DC69AB04C1B20E6FC7861C67476CADDA1DAE7A8DCF6E23E15311 > C2D2794BFCD11 > > I confirmed with ICANN, the owner of example.com, that they did not > authorize these certificates. These certificates were already revoked at the > time I found them. > > > II. Suspicious certificates for domains containing the word "test" > > On 2016-11-15 and 2016-10-26, Symantec issued certificates for various > domains containing the word "test" which I strongly suspect were > misissued: > > https://clicktime.symantec.com/a/1/_0lsjfT3DHqxu1QJl2eBU5zx948r > qJmGy-bHkTlww3c=?d=6VMu_T-sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D&u=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3Db81f339b971eb763cfc686adbac5c164b89ad03f8afb55da9604fd0 > d416bbd21 > https://clicktime.symantec.com/a/1/uF90PPzN7N3_lTMmPb8YzXKK > AfWPKKNmpvo_prjlE3Y=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xR
RE: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)
This certificate was just revoked. Kyle, thanks for bringing this to our attention - we were able to start work once you posted here at m.d.s.policy. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o rg] On Behalf Of Steve Medin Sent: Tuesday, September 06, 2016 7:27 PM To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham ; Kyle Hamilton Subject: RE: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust) Agree, regardless of 4.9.5's investigation gap, in this case 4.9.1.1(3) clearly applies as well as other clauses. At this point, revocation is less harm than the key compromise. It may be an effective way to get the message to the affected device operators who have not replaced the default certificate with a purchased one. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation -Original Message- From: Jeremy Rowley [mailto:jeremy.row...@digicert.com] Sent: Tuesday, September 06, 2016 7:06 PM To: Steve Medin Cc: Gervase Markham ; Kyle Hamilton ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust) BRs require revocation within 24 hours of notice. It's a terrible timeline but one the browsers have strictly enforced for even wide spread deployments. > On Sep 6, 2016, at 4:30 PM, Steve Medin wrote: > > We have become aware of this certificate and its key compromise, thank > you for this information. We are contacting the owner to understand > impact to the deployed devices, but with clear intent to revoke. We > will provide updates while we make progress. > > Kind regards, > Steven Medin > PKI Policy Manager, Symantec Corporation > > > > > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o > rg] On Behalf Of Gervase Markham > Sent: Tuesday, September 06, 2016 2:02 PM > To: Kyle Hamilton ; > mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Compromised certificate that the owner didn't wish to > revoke (signed by GeoTrust) > >> On 06/09/16 18:25, Kyle Hamilton wrote: >> Aruba chose not to notify GeoTrust that it needed to be revoked due >> to compromised private key. I am notifying because I believe it >> violates the Basic Requirements for someone other than the identified >> subject to possess the private key for a publicly-trusted certificate. > > It does; have you notified GeoTrust using whatever mechanism they make > available for such notifications? They are supposed to have one, > according to the BRs. I'm not sure posting here would count. > > 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: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)
Agree, regardless of 4.9.5's investigation gap, in this case 4.9.1.1(3) clearly applies as well as other clauses. At this point, revocation is less harm than the key compromise. It may be an effective way to get the message to the affected device operators who have not replaced the default certificate with a purchased one. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation -Original Message- From: Jeremy Rowley [mailto:jeremy.row...@digicert.com] Sent: Tuesday, September 06, 2016 7:06 PM To: Steve Medin Cc: Gervase Markham ; Kyle Hamilton ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust) BRs require revocation within 24 hours of notice. It's a terrible timeline but one the browsers have strictly enforced for even wide spread deployments. > On Sep 6, 2016, at 4:30 PM, Steve Medin wrote: > > We have become aware of this certificate and its key compromise, thank you > for this information. We are contacting the owner to understand impact to > the deployed devices, but with clear intent to revoke. We will provide > updates while we make progress. > > Kind regards, > Steven Medin > PKI Policy Manager, Symantec Corporation > > > > > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o > rg] On Behalf Of Gervase Markham > Sent: Tuesday, September 06, 2016 2:02 PM > To: Kyle Hamilton ; > mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Compromised certificate that the owner didn't wish to revoke > (signed by GeoTrust) > >> On 06/09/16 18:25, Kyle Hamilton wrote: >> Aruba chose not to notify GeoTrust that it needed to be revoked due to >> compromised private key. I am notifying because I believe it >> violates the Basic Requirements for someone other than the identified >> subject to possess the private key for a publicly-trusted certificate. > > It does; have you notified GeoTrust using whatever mechanism they make > available for such notifications? They are supposed to have one, according > to the BRs. I'm not sure posting here would count. > > 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: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)
We have become aware of this certificate and its key compromise, thank you for this information. We are contacting the owner to understand impact to the deployed devices, but with clear intent to revoke. We will provide updates while we make progress. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o rg] On Behalf Of Gervase Markham Sent: Tuesday, September 06, 2016 2:02 PM To: Kyle Hamilton ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust) On 06/09/16 18:25, Kyle Hamilton wrote: > Aruba chose not to notify GeoTrust that it needed to be revoked due to > compromised private key. I am notifying because I believe it > violates the Basic Requirements for someone other than the identified > subject to possess the private key for a publicly-trusted certificate. It does; have you notified GeoTrust using whatever mechanism they make available for such notifications? They are supposed to have one, according to the BRs. I'm not sure posting here would count. Gerv ___ 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: Request to enable EV for VeriSign Class 3 G4 ECC root
Hi Kathleen, The WT/BR audit covering this root is at https://www.symantec.com/content/en/us/about/media/repository/Symantec-Thawte-WTBR-2015.pdf. You'll find it listed as the fourth entry in the left column on page 6. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Kathleen Wilson Sent: Monday, July 18, 2016 7:26 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Request to enable EV for VeriSign Class 3 G4 ECC root On 5/18/16 2:51 PM, Kathleen Wilson wrote: > Here is a summary of this discussion so far about Symantec's request to > enable EV treatment for the "VeriSign Class 3 Public Primary Certification > Authority - G4" root certificate that was included via bug #409235, and has > all three trust bits enabled. > > 1) The "Symantec AATL ECC Intermediate CA" needs to be revoked and added to > OneCRL. The intermediate cert has been added to Salesforce. > I'm assuming we may proceed with this request, as long as the cert is added > to OneCRL before EV treatment is actually enabled in a Firefox release. It’s been revoked. https://bugzilla.mozilla.org/show_bug.cgi?id=1287592 > 2) Questions were raised about wildcard certs in regards to the BRs. But it > sounds like for now Symantec's use of wildcard certs is not breaking any BRs. > Question for Symantec: Are any of the issued wildcard certs EV? Symantec responded to say that they have not issued EV wildcard certs.' > 3) Question raised: What technical controls are in place to ensure that > systems which issue S/MIME certs "in this CA hierarchy" are not capable of > issuing an SSL server certificate? > Answer from Symantec: We have a technical control in place for systems that > issue S/MIME certs in this CA hierarchy. Our systems use static cert > templates from which end-entity certs are issued. Those templates include an > EKU value, but do not use the serverAuth or anyExtendedKeyUsage values. Symantec's further responses: We will be stopping SHA1 ICA usage by the end of 2016 for SMIME. We plan to use a new ICA that has a compliant EKU to issue SMIME certificates by the end of 2016. For SHA-1 signed S/MIME certificates, the serial number is a 128-bit random number, which makes the certificate contents unpredictable. > 4) Intermediate certificates for this root have been loaded into Salesforce, > and are available at the following links: > https://wiki.mozilla.org/CA:SubordinateCAcerts and https://wiki.mozilla.org/CA:RevokedSubCAcerts I believe that all of the questions/concerns raised during this discussion have been resolved. So I am about ready to wrap up this discussion and recommend approval of this request. However, I am not finding the current WTBR audit statement for this root certificate. I am finding the other Symantec audit statements in the "Roots & Audit Reports" tab of https://www.symantec.com/about/legal/repository.jsp And I have exchanged email with the auditor to confirm the authenticity of the audit statements. Sanjay, Please let me know which of the audit statements on the website contain the WTBR audit statement covering this root certificate. Thanks, Kathleen ___ 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