I didn't say it was easy, and I don't disagree that there are ways in which it can be improved (e.g. to include server side checks). However, there are some inescapable limitations in such approaches (e.g. users who cannot contact the Mozilla servers that govern such flags), thus there's always some code change necessary to ensure both a sane/predictable default (in the event of persistent DoS to an update server) and a configurable flag for that which matters.
On Wed, Jan 24, 2018 at 9:24 AM, James Burton <j...@0.me.uk> wrote: > There is no easy way to temporary sanction non-compliant CAs for lateness > of documents, incidents and etc. > There needs to be a switch developed which allows program members to > disable features such as EV without messing around in code. > > James > > > On Wed, Jan 24, 2018 at 1:56 PM, Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Tue, Jan 23, 2018 at 7:47 PM, Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> > Hi Everyone, >> > >> > I have reviewed the responses we received from the November 2017 CA >> > Communication [1], and I have the following comments to share: >> > >> > * Beginning with the good news, no new concerns related to the suspected >> > .tg Registry compromise were reported (Action #8) >> > * The deadline for submitting the survey was 15-December, but Amazon, >> > DSV-Gruppe, and Web.com required repeated prodding in January before >> they >> > responded. It may be that mid-December is not the best time of the year >> for >> > a survey deadline, but the response we received fell short of our >> > expectations. >> > * In action #1, CAs were asked to confirm that they comply with version >> 2.5 >> > of the Mozilla root store policy. This policy took effect last June [2], >> > but a number of CAs stated that they needed more time to bring their CPS >> > into compliance. Most CAs said they would comply by 1-March, but some >> > requested much more time. Microsec Ltd. stated that “The next version of >> > our public documents will contain the exact reference to these BR >> sections >> > which will be issued by 2018-09-30.” I expect CAs to update their CPS >> much >> > more frequently when requirements change. I propose that we require CAs >> to >> > update their CPS to comply with version 2.5 of the Mozilla root store >> > policy no later than 15-April 2018. >> > >> >> This seems to be a perennial problem with CAs, and doesn't inspire >> confidence in them or their operations. I am also concerned that an >> extension of this nature does not inspire confidence in the Mozilla Root >> Program, either as relying parties (CAs that are not competent are allowed >> to continue to be incompetent) or for competent CAs (Mozilla's >> requests/requirements are not actual requirements, but merely suggestions) >> >> I am specifically concerned about the CP/CPS updates and the impact they >> have to global trust. Am I mistaken in evaluating >> https://github.com/mozilla/pkipolicy/compare/2.4.1...2.5 that the >> substance >> of those changes are: >> 1) Documenting which of the 10 Blessed Methods a CA does not use >> 2) Updating the version number and adding a dated change log >> >> 2 should be inconsequential, but 1 has a very real effect - unless/until >> the CA updates their CP/CPS to explicitly state what methods they are >> using >> (implicitly disavowing the 'any other method'), then a CA can receive a >> fully compliant audit, despite actively issuing certificates using 'any >> other method', in contravention of Mozilla Policy. >> >> That seems concerning, and the effect is that delaying such updates to >> 15-April-2018 would mean the community is being asked to accept, based on >> the honor system, a CA's word that they're not issuing certificates using >> arbitrary methods. >> >> Is my concern misplaced? This seems fairly critical to security, and given >> the number of CA incidents over the past year, I have very little faith >> that CAs are in compliance, and that some form of 'human error or >> oversight' didn't cause them to 'forget' they were using Any-Other-Method. >> >> Does Mozilla plan to sanction non-compliant CAs, either now or in the >> future? Certainly, it seems the removal of any EV status would be >> appropriate for any CA still needing time to update their CP/CPS, as the >> level of assurance provided by these CAs regarding their validation >> methods >> surely does not rise to the high levels of assurance EV is presumed to >> convey. But more importantly, should new certificates be distrusted until >> such a time as the CA can demonstrate compliance? I cannot help but think >> that is the only way to ensure timely compliance - any CA found to need >> more time to adjust to policy changes will have trust in their >> certificates >> immediately disabled, and for some fixed period (which may grow if the >> incidents are repeated). 6 months seems an appropriate start. >> _______________________________________________ >> 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
