Re: TunRootCA2 root inclusion request
Hi Jonathan, Please find below the description of the technical and organizational controls required: 1) The currently process of certificates issuance is composed by 4 steps: step 1: Registration process: This step consists of the verification of the following items: •the subscriber identify •the accuracy of the certificate requests (RA is using currently this URL to check the CSR https://cryptoreport.websecurity.symantec.com/checker/views/csrCheck.jsp) •the possession of the domain names (who is, organization, validation phone,...) • After that, the RA operator insert all the required data in the RA interface, theses controls are implemented: •control of the syntax of the server name •control of the email of the server administrator •control of the identifier of the administrator •check of the CSR step2: Validation process: In this step, another registration operator (different of the first one), check all the inserted data. This check consists of the verification of inserted data against paper data. step3: Issuance of the certificate: In this step, the only control consists of the check of the data in the CSR against the inserted data. In the event of any error, the request is rejected. step4: Check of the issued certificate: In this step, another registration operator check the issued certificate before its delivery. 2) The deficiencies identified in those controls after the misissuance of each of these certificates are essentially: •controls on the field subject alternative names : o this field must not contains private addresses o this filed must not contain 127.0.0.1 address o this filed must not contain a local FQDN o this field must at least contain the CN 3) The implemented and planned improvements to the technical controls to prevent these errors from happening again: The NDCA is implementing a new system (Managed PKI solution) which includes such controls in different fields (CN, mail of administrator, check of CSR, check of subject alternative names, ...). Thanks Olfa ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Thank you, we received your email #M10366628
Thank you for your emailThis is an automatic message confirming that we received your email.Email responses typically occur within 8 business hours during normal operating times.During Holiday Seasons Mothers Day and Valentines Day responses to emails may take up to 5 business days. We appreciate your patience.Sincerely,Avas Flowers Message #M10366628. Please do not modify the subject when replying to this mail so we can assign your communication to the correct person.To modify your order click hereTo check the status of your order click hereTo contact us click hereFor Our Terms of Service and Policies click hereFor Our Customer Service Policies click hereAvas Flowershttp://www.AvasFlowers.Com877-638-3303 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Final Decision by Google on Symantec
On 28/07/2017 18:36, David E. Ross wrote: On 7/28/2017 6:34 AM, Alex Gaynor wrote: Frankly I was surprised to see Chromium reverse course on this -- they have a history of aggressive leadership in their handling of CA failures, it's a little disappointing to see them abandon that. I'd strongly advocate for us perusing an earlier date -- December 1st at the latest. Reasons: 1) Chromium's stated reason for avoiding dates around the holidays makes no sense -- organizations with change freezes they need to adhere to have a simple solution: obtain and deploy a new certificate at an earlier date! They have 4 months between now and December 1st, if you can't deploy a cert in 4 months, I submit you have larger problems. 2) It is important that CAs not be rewarded for the length of time this process takes. CAs should be encouraged and rewarded for active participation and engagement in this list. 3) Mandatory CT (well, mandatory for trust in Chromium) is a significant win for security and transparency. At the moment, even discussing the parameters of the distrust is complicated by the fact that we have limited visibility into the iceberg of their PKI before June 1st, 2016 (see the other thread where I attempt to discuss the count they provide of outstanding certs that would be impacted). Given the challenges we know exist in their legacy PKI, I think it's fair to say that continuing to trust these certs represents real risk for our users's security. Alex I strongly agree. The focus must be on protecting end-users, not on Symantec or on Symantec's customers. Symantec must know who has subscriber certificates that chain to Symantec's roots. Those customers could all be notified very quickly that their certificates are about to be distrusted. Those customers would then have ample time to obtain and install replacement subscriber certificates chaining to alternative roots of other certification authorities. As for any disruption of secure transactions, consider the abrupt termination of DigiNotar when that certification authority was found to have serious lapses in its operations. The world did not end. Note that DigiNotar was a country-local CA, not a global CA. The risk profile (for distrust, not for mis-issuance) was much lower. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: TunRootCA2 root inclusion request
Hi Olfa, On 31/07/17 11:55, Olfa Kaddachi wrote: > 2) The deficiencies identified in those controls after the misissuance of > each of these certificates are essentially: > •controls on the field subject alternative names : > o this field must not contains private addresses > o this filed must not contain 127.0.0.1 address > o this filed must not contain a local FQDN > o this field must at least contain the CN Given that some of these are BR requirements, why were these controls not in place already? From what date would you say that your CA has been compliant with the CAB Forum Baseline Requirements? > 3) The implemented and planned improvements to the technical controls to > prevent these errors from happening again: When will these improvements be implemented? And, given that these are only four possible ways a certificate can be messed up, what other checks are going to be implemented at the same time? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Final Decision by Google on Symantec
On 29/07/17 09:29, Nick Lamb wrote: > So I will expend my effort instead on pressing for Mozilla to handle > final distrust of the old Symantec CA roots in its usual fashion and > explicitly _not_ do as Symantec asked in leaving it enabled in the > NSS trust set we know is relied upon (whether wisely or not) by lots > of things other than web browsers. In accordance with the principles set down in messages in this group earlier in the process, the plan is to make the NSS trust store reflect, as closely as we can given its limited ability to encode arbitrarily complex decisions, the trust decisions made by Mozilla. Therefore, if Mozilla no longer trusts a root, it will not appear in the NSS trust store. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Final Decision by Google on Symantec
On 30/07/2017 00:45, Peter Bowen wrote: On Thu, Jul 27, 2017 at 11:14 PM, Gervase Markham via dev-security-policy wrote: Google have made a final decision on the various dates they plan to implement as part of the consensus plan in the Symantec matter. The message from blink-dev is included below. [...] We now have two choices. We can accept the Google date for ourselves, or we can decide to implement something earlier. Implementing something earlier would involve us leading on compatibility risk, and so would need to get wider sign-off from within Mozilla, but nevertheless I would like to get the opinions of the m.d.s.p community. I would like to make a decision on this matter on or before July 31st, as Symantec have asked for dates to be nailed down by then in order for them to be on track with their Managed CA implementation timetable. If no alternative decision is taken and communicated here and to Symantec, the default will be that we will accept Google's final proposal as a consensus date. Gerv, I think there three more things that Mozilla needs to decide. First, when the server authentication trust will bits be removed from the existing roots. This is of notable importance for non-Firefox users of NSS. Based on the Chrome email, it looks like they will remove trust bits in their git repo around August 23, 2018. When will NSS remove the trust bits? Second, how the dates apply to email protection certificates, if at all. Chrome only deals with server authentication certificates, so their decision does not cover other types of certificates. Will the email protection trust bits be turned off at some point? It was previously stated in this newsgroup that non-SSLServer trust would not be terminated, at least for now. Third, what the requirements are for Symantec to submit new roots, including any limit to how many may be submitted. https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport shows that there are currently 20 Symantec roots included. Would it be reasonable for them to submit replacements on a 1:1 basis -- that is 20 new roots? Those 20 old roots were the result of decades of mergers and acquisitions, causing lots of "duplicates". That said, it is better for overall security to have meaningful splits of root CAs for any new CAs. Most notably: - Issuing a new (cross-signed) root for each new signature algorithm. A full service CA should currently have roots for RSA-SHA256, RSA-SHA384, RSA-SHA512, and the ECDSA curves above 256 bits, each paired with the matching SHA size. Others would be added 6 to 24 months after becoming BR-permitted. - Due to current Mozilla implementation bugs, having separate roots for EV certificates is currently the only way to only accept EV certs from EV SubCAs. This is specific to Mozilla. - If Symantec wants to again set up a trust tree dedicated to cross- signing lots of outside parties (similar to the old "GeoRoot" program), it would be best to put that under separate roots. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Final Decision by Google on Symantec
On 29/07/17 23:45, Peter Bowen wrote: > First, when the server authentication trust will bits be removed from > the existing roots. This is of notable importance for non-Firefox > users of NSS. Based on the Chrome email, it looks like they will > remove trust bits in their git repo around August 23, 2018. When will > NSS remove the trust bits? The NSS trust store represents Mozilla's decisions about what is trustworthy. However, particularly if we match Chrome's dates, there is a slightly unusual situation as we have taken a decision on trustworthiness but, for other reasons, Firefox still trusts those certs for a period. So one might well ask, should the decision be implemented in NSS earlier than, or at the same time as, or even later than, Firefox implements it? A good question. > Second, how the dates apply to email protection certificates, if at > all. Chrome only deals with server authentication certificates, so > their decision does not cover other types of certificates. Will the > email protection trust bits be turned off at some point? Absent the bandwidth to spend more time on email-specific issues with our root store, I would expect to stop trusting all the same roots for email as well, at the same time. > Third, what the requirements are for Symantec to submit new roots, > including any limit to how many may be submitted. > https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport > shows that there are currently 20 Symantec roots included. Would it > be reasonable for them to submit replacements on a 1:1 basis -- that > is 20 new roots? No. A new submission would be treated as any new submission. My guess without talking to Symantec was that they might want four roots, for a 2x2 matrix of {RSA, ECC} and {EV, non-EV}. A figure in that ballpark would be acceptable. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Final Decision by Google on Symantec
On 31/07/17 15:00, Jakob Bohm wrote: > It was previously stated in this newsgroup that non-SSLServer trust > would not be terminated, at least for now. It was? Reference, please? > - Due to current Mozilla implementation bugs, Reference, please? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Miss-issuance: URI in dNSName SAN
On 25/07/17 18:13, Jeremy Rowley wrote: > I would also love to see a more standardized notice mechanism that is > universal to all CAs. Right now, notifying CAs is a pain as some have > different webforms, some use email, and some don't readily tell you how to > contact them about certificate problems. "Not readily telling" is a BR violation; if you come across a CA like that, please do let us know. The info should be in the CCADB and in the CAs report. I agree it would be nice to have something more standard, but we have what we have right now. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Miss-issuance: URI in dNSName SAN
I've been attempting to report a bunch of miss-issued certificates this weekend (hobbies are important!) I've primarily been using https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC&QuestionId=Q00028 as my reference (without which I would be totally lost!) So far I've encountered issues with: - DocuSign (OpenTrust/Keynectis) - who neglected to fill out that field - StartCom - who filled out "web publication", I don't know what that means To all the CAs who included a straightforward email or webform in there, thank you! Alex On Mon, Jul 31, 2017 at 10:10 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 25/07/17 18:13, Jeremy Rowley wrote: > > I would also love to see a more standardized notice mechanism that is > > universal to all CAs. Right now, notifying CAs is a pain as some have > > different webforms, some use email, and some don't readily tell you how > to > > contact them about certificate problems. > > "Not readily telling" is a BR violation; if you come across a CA like > that, please do let us know. The info should be in the CCADB and in the > CAs report. > > I agree it would be nice to have something more standard, but we have > what we have right now. > > 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: Final Decision by Google on Symantec
On 31/07/2017 16:06, Gervase Markham wrote: On 31/07/17 15:00, Jakob Bohm wrote: It was previously stated in this newsgroup that non-SSLServer trust would not be terminated, at least for now. It was? Reference, please? That was my general impression, I don't have a good way to search the list for this. I was just trying to be helpful. - Due to current Mozilla implementation bugs, Reference, please? I am referring to the fact that EV-trust is currently assigned to roots, not to SubCAs, at least as far as visible root store descriptions go. Since I know of no standard way for a SubCA certificate to state if it intended for EV certs or not, that would cause EV-trust to percolate into SubCAs that were never intended for this purpose by the root CA. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Final Decision by Google on Symantec
On Mon, Jul 31, 2017 at 7:17 AM, Jakob Bohm via dev-security-policy wrote: > On 31/07/2017 16:06, Gervase Markham wrote: >> >> On 31/07/17 15:00, Jakob Bohm wrote: >>> >>> - Due to current Mozilla implementation bugs, >> >> >> Reference, please? >> > > I am referring to the fact that EV-trust is currently assigned to roots, > not to SubCAs, at least as far as visible root store descriptions go. > > Since I know of no standard way for a SubCA certificate to state if it > intended for EV certs or not, that would cause EV-trust to percolate > into SubCAs that were never intended for this purpose by the root CA. This is common to every EV implementation I know about, not just Mozilla. Therefore I would not call this a bug. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Final Decision by Google on Symantec
Given that we're past the 7/31 deadline and the comments in support of following Chrome's lead, it sounds likely that that's what's happening. And I think that's an understandable conclusion for Mozilla to draw, given the compatibility risk Mozilla would be leading on for at least several months. However, I think Mozilla should consider the larger precedent being set by Mozilla deferring to such a significant relaxation in enforcement by Chrome in such a complete way. It's quite possible that Chrome's original proposed timetable was too aggressive, but their final proposed timetable is quite weak, and it seems like participants here generally agree that a partial distrust date in December, preceding the holiday season, would be a reasonable conclusion. I find it particularly disheartening that Symantec has been able to successfully deploy hardball tactics to obtain more favorable treatment from Google, and now likely Mozilla. As has been discussed amply on this list, Symantec engaged the bare minimum necessary with the Mozilla community, repeatedly missed or just made deadlines, and refused to answer follow-up questions from community participants. On at least one occasion, Symantec publicly pressured Mozilla to halt public discussion about independent enforcement in favor of waiting for Google's decision, from what appeared to be barely contained glee from managing to get Google executives involved to slow down the process and obtain a weaker proposal. I also want to point out that Symantec's customer communication from around July 11th, as shared on blink-dev: https://groups.google.com/a/chromium.org/d/msg/blink-dev/ eUAKwjihhBs/smcHvd2HAgAJ Instructs their customers to replace all of their certificates issued before June 2016 by August 8th: One aspect of Google’s proposal is that starting August 8, 2017, Chrome would gradually begin mistrusting all Symantec branded certificates issued before June 1, 2016. We urge you take prompt action in order to avoid the risk of having your certificates mistrusted by Google’s Chrome browser. At the end of this email is an instruction to identify your certificates that are at risk, and the date which Google has stated they may begin mistrusting them. We recommend that you replace these certificates prior to August 8, 2017 to minimize any disruption. Symantec is referencing dates from a previous Chrome proposal by Ryan Sleevi: https://groups.google.com/a/chromium.org/d/msg/blink-dev/ eUAKwjihhBs/ovLalSBRBQAJ But Chrome's proposal only references August 8th as the date Symantec should be issuing all certificates from their managed PKI. The proposal said that existing certs issued before June 2015 would be distrusted on August 31st, and existing certs issued before June 2016 would be issued in January 2018. The net effect of Symantec's customer communication is that Symantec sent its customers into a low-grade panic by waiting for almost 2 months from the May proposal date to send them an email that, for most customers, certainly appears to suggest that in 3 weeks, all their pre-June-2016 certs will start causing errors. The Symantec references a list of specific dates per-cert, which presumably match Chrome's specific proposal, but I can tell you that I have observed Symantec customers interpret this communication as an impending August 8th distrust date for existing Symantec certificates in Chrome. I find it quite plausible that Symantec deliberately encouraged unnecessary anxiety among their customer base by delaying this notice and overstating the severity of the distrust event, to validate their arguments about risk to internet service availability and to strengthen their negotiating position with Google. But even if their intent was not quite so bad-faith, Symantec's handling of this process was at the very least highly disorganized and belligerent, to the point that I think Mozilla would be within their rights to lose confidence in Symantec's future participation in the Mozilla root program. So whatever Mozilla chooses to do, I hope that it reflects Mozilla's independent assessment of the risk posed to their users by Symantec's current certificate corpus and their expected participation in the program, and that it reinforces Mozilla as an independent party in future negotiations with other members of their root program. -- Eric On Fri, Jul 28, 2017 at 2:14 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Google have made a final decision on the various dates they plan to > implement as part of the consensus plan in the Symantec matter. The > message from blink-dev is included below. > > Most of the dates have consensus - the dates for Symantec to implement > the Managed CA infrastructure are agreed by all, and the date for final > distrust of the old Symantec PKI is agreed by Google and Mozilla (to > within a week, at any rate). I proposed November 1st 2018. Google has > gone for October 23rd 2018;