You really should set up a emergency conference call with all members of the CAB Forums and talk about these issues with chair. If you and other members feel that the answers are not satisfactory then you can vote to remove the Chair for dereliction of duty and place the sub-Chair in charge of the forums until the end of current term or until you appoint new chair.
James On Fri, Jan 26, 2018 at 1:58 PM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Fri, Jan 26, 2018 at 5:43 AM Gervase Markham <g...@mozilla.org> wrote: > > > On 24/01/18 13:56, Ryan Sleevi wrote: > > >> 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. > > > > I think Ryan is right here; the deadline for complying with most of the > > new changes was "immediately" - in part, that was due to the nature of > > the changes, in that this was possible, and also we put out a call for > > "does anyone need an implementation period for any of these things", and > > the only response was from Globalsign, which led to the modification of > > the email intermediate compliance dates. > > > > I realise that updating one's CPS to match changes in practice can't be > > done overnight - there are change control procedures - but taking 15 > > months is ridiculous. We should get back to Microsec and tell them that > > this is unacceptable. If we do set a "new" deadline for CPS updates, it > > should be closer than mid-April, and we should update our policy to make > > it clear how fast we expect CPSes to be updated in the wake of > > "immediate" new requirements - either from a new version of the policy, > > or from some emergency action we take. > > > > > 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. > > > > Ryan: I thought you had previously made the case that all CAs actually > > had to abide by the latest version of the BRs? If that is so, then > > surely your point above is incorrect? > > > The CA/Browser Forum chair - an employee of Entrust - has been > irresponsibly derelict in his duties as Chair. He has failed to exercise > the Bylaws as required of him, has failed to inform the Forum about the IP > notices received (if any) or to update the Public Mail List and Public Web > Site, and as a result, created a situation where it is defensibly ambiguous > as to whether only the “10 Blessed Methods” are used. > > It is unclear whether this is due to incompetence or malice, but the > consequence is such that a CA, such as Entrust, could attempt to argue that > the CA/Browser Forum did not declare a version of the BRs post-Ballot 190 > as Final, and thus avoid triggering that clause. > > The above remarks I highlighted would have allowed for a defense in depth > from the CA/Browser Forum chair failing or abusing their position, by > ensuring clear and unambiguous statements by CAs for security critical > matters. > _______________________________________________ > 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
