On Tue, Mar 20, 2018 at 2:46 PM, Ryan Sleevi <r...@sleevi.com> wrote:
> > > On Tue, Mar 20, 2018 at 4:15 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Tue, Mar 20, 2018 at 8:19 AM, Ryan Sleevi <r...@sleevi.com> wrote: >> >> > >> > Looking through [1], it seems like the Compliance Date has only differed >> > from the Publication Date once (with 2.0). >> > >> It's not clear to me that the 2.5 failure to adoption was related to >> > ambiguity around compliance dates versus, say, CAs not being in >> compliance >> > until directly chastised for non-compliance. >> > >> > I believe both causes factored into the 2.5 compliance issues, but agree >> that this change only helps with ambiguity around Compliance Dates. >> >> Thus, the deferral of 2 months is not entirely clear as to the reasoning. >> > Could you speak more to the thinking behind that? >> > >> > To begin, I hope we can agree, even if we don't like it, that changes >> like >> this often get done just before the deadline (I believe there is an >> incentive for this behavior, but all that is necessary here is to accept >> that it happens regularly). Then the question becomes "what is the >> deadline?", and of course the answer is the Compliance Date. Then I ask >> how >> the Compliance Date is set and communicated to CAs, and that's where I see >> the problem. For the 2.5 version there was a discussion around phase-in >> periods for specific changes [1], but as best I can tell the Publication >> Date (and hence the Compliance Date) was not communicated in advance [2], >> meaning that CAs had no deadline to work toward. In addition, there was no >> indication that the policy changes were finalized prior to the Publication >> Date, so CAs didn't have a stable policy to implement prior to the >> Publication Date, at which point they were expected to already have >> complied. >> >> My thinking is that this situation encourages CAs to ignore the Compliance >> Date and work on their own schedules, and that communicating a Compliance >> Date that is some reasonable amount of time after the Publication Date >> clarifies our expectations. > > > So, in general, I think Mozilla policy has focused on actions CAs must > take (such as notify Mozilla of incidents), rather than the profile of > their certificates or a chance in scope of the BRs. The 10 blessed methods > was an exception to that, as was the scope of audits for S/MIME - but those > were exceptions, rather than the rule, and called out as such. > > I think it's reasonable - especially in light of the discussion being had > regarding 2.6 and 3.2.2.4/3.2.2.5 - that when there are restrictions on > the technical actions a CA must take or can use, that there be a phase in > time, and what you say makes sense. But I think that's probably going to be > the exception, and so it may be better to set the Compliance Date == > Publication Date by default, and then use the information gathering and > discussion phase (which Mozilla policy requires all CAs to monitor) to > identify if there are any surprises regarding phasing in changes. > > I am specifically thinking of CP/CPS updates, which were a major part of the problem with version 2.5 compliance. There are a few proposals in the 2.6 queue that also require CP/CPS updates. Would you expect those to trigger an exception as described above? As a concrete example, consider the policy changes requiring CAs to follow > m.d.s.p. That seems like something perfectly reasonable to expect immediate > compliance to, and indeed, highly desirable (for any incidents that emerge > within those two months until Compliance Date). Naively, it doesn't seem > like it should take two months for a CA to be able to monitor m.d.s.p., or > if it did, that may signal more problematic practices at play. > Again, the problem with this is that there is effectively no deadline when policies are assumed to begin immediately upon publication. The same CAs who take two months to begin monitoring m.d.s.p. when given a future deadline are just as likely to begin monitoring it whenever they get around to implementing the new policy during their next audit cycle if the compliance deadline has already passed by the time they see that the policy has been published. > > To be clear, I'm fully onboard with integrating the compliance date to > publication date, to avoid ambiguity. I am just putting forward the > notation that, by default, Compliance Date == Publication Date, and then if > there are reasonable concerns about the impact/challenges that might > present, raised during the discussion, then prior to finalization and > Publication, setting the Compliance Date out 30-60 days from that. > > I think we both agree that compliance with 2.5 was a problem that we'd like to address. I've put forth the argument that having Compliance Date > Publication Date could help to improve that. Do you disagree with my assertion, or simply feel that on balance it is better to have new policies enacted sooner but with less compliance? Maybe a better solution would be to ask CAs to attest to their compliance via a survey each time we publish a new policy version? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
