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 < [email protected]> wrote: > On Tue, Jan 23, 2018 at 7:47 PM, Wayne Thayer via dev-security-policy < > [email protected]> 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
