[Servercert-wg] Ballot SC20v2: Configuration Management

[Ryan Sleevi]

On Tue, Feb 4, 2020 at 12:55 PM Neil Dunbar via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> All,
>
> I began a conversation with Ryan thinking that it was to the list as
> well. Apologies for that. In order to allow others to comment on the
> changes I created a PR at https://github.com/neildunbar/documents/pull/1
> - by all means review and comment as you see fit.
>
> Ryan replied with some suggested changes, and I replied back per the
> text below:
>
> So here's my (not altogether well worked out) thoughts.
>
> We're not assuming "reasonable" people doing any interpretation here -
> we're assuming an almost pathological desire to twist the normal
> meanings of words to the advantage of the reader. So, is decoupling the
> multiple usage of the word "change" here going to have the effect we all
> want? Can we not also assume that someone would re-interpret the word
> "modification" to mean "those artifacts described within our change
> management process"?
>

So, it's not entirely that bad.

That is, given that we've seen the past year a number of CA incidents
resulting from confusion from requirements, I'm especially sensitive to
making sure things are unambiguous. I've certainly seen a number of folks
use "change" to mean the thing in their "change management system", and
that's the main ambiguity I'm trying to resolve, if people have their local
phrases.

Separately, there's the risk of malicious non-compliance, and that's
largely something this discussion is meant to help flesh out :)


> In which case, it strikes me that we could retain "configuration
> change", but codify it as "Configuration Change", with a definition
> which says something like "Configuration Change: alterations in
> transient or persistent data which have the effects of changing the
> programmed behaviour of any computer system as and when said system
> reads the altered data". That should then halt any creative
> interpretation of what "change" means.
>
> Which then might make it easier to define "Change Management Process" as
> being "Change Management Process: A protocol describing the reasoning,
> description, authorisation, predicted and observed (post-facto) effects
> of any proposed or actioned Configuration Change". That then orders the
> notion of "Change Management Process" as something which depends on
> "Configuration Change", meaning that our perverse adversary cannot rely
> on the phrase "Change Management Process" to give meaning to
> "Configuration Change"?
>
> Would that have the effect desired? Or does it have other side effects
> which are equally undesirable?
>

I was mostly going for light-weight, and mostly focusing on the "change" as
the "artifact in the system" confusion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200204/36d3d175/attachment.html>