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
