On 21/03/2018 10:43, Ryan Sleevi wrote:
On Tue, Mar 20, 2018 at 8:27 PM, Wayne Thayer via dev-security-policy <
[email protected]> wrote:
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?
Yup, I think it totally makes sense to phase those in, since they first
need to be finalized (via Publication) before CAs can fully update to be
conformant.
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.
I'm not sure I understand this point. The deadline is immediate. I was
trying to highlight that with an immediate deadline, there's no excuse for
taking two months to monitor m.d.s.p. - but that's ok, because it doesn't
seem reasonable to take two months to begin with. Any CA out of compliance
is in an egregious breach of confidence at that point - especially if they
wait until their next audit cycle.
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?
I don't think having Compliance Date > Publication Date will, in general,
help for situations of CAs being non-compliant. I think it will help with
some things - if their non-compliance was due to, for example, updating
systems or CP/CPSes - but I think it will harm other things - e.g. CAs
monitoring m.d.s.p. or disclosing certain things.
Regarding CAs attesting to compliance, I think that will help, but not
because of the Compliance Date or Publication Date. Rather, it will help
because no matter what we do or say, there are a subset of CAs who simply
will not and do not spend time following m.d.s.p. and only reply to emails
and only after several emails have gone by and only after being shamed at
the risk of distrust.
I would say that a implementation deadline of 0 will be instantly
violated by anyone not already in compliance (by chance).
Something like "follow m.d.s.p" (which includes subscribing to the mail
version if applicable, but also assigning one or more employees to the
task), could be done in a week or so, maybe a month if the deciding
boss is on holiday on the publication date.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
