I don't think that's terribly germane to the discussion here, but you can see more details at https://cabforum.org/pipermail/public/2018-January/012851.html
As it relates to *this* discussion, however, is an understanding that the current set of CA/Browser Forum issues with respect to adhering to its Bylaws has a negative affect on the policy objectives and understanding, and thus bear consideration in the CA communications. On Fri, Jan 26, 2018 at 4:00 PM, James Burton <[email protected]> wrote: > 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 < > [email protected]> wrote: > >> On Fri, Jan 26, 2018 at 5:43 AM Gervase Markham <[email protected]> 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 >> [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
