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. 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. 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
