[cabf_netsec] SC20 and Adversarial Interpretation

David Kluge kluge at google.com
Tue Feb 4 10:22:44 MST 2020


Thanks for creating the pull request Neil.
Ryan's comments look good to me. I would be fine accepting them as they are.

On Mon, Feb 3, 2020 at 9:00 PM Neil Dunbar via Netsec <netsec at cabforum.org>
wrote:

> Ryan has added some comments to
> https://github.com/neildunbar/documents/pull/1
>
> If folks would be good enough to take a look, perhaps we can tighten up
> the language. My initial feelings are that retitling "configuration
> change" to "modification" might just be a distinction without a
> difference. In other words, I'm not sure this particularly protects
> against the perverse interpretation; just because something is called a
> "change management process" doesn't automatically create a special
> meaning of the word "change", but prevent a special meaning of
> "modification".
>
> Regarding the capitalisation of Change Management Process - I wonder if
> defining it is just creating a rod for our own backs? I think it would
> be easier to simply lowercase the term, and let the CAs define their
> processes to their auditors.
>
> But that's just my initial feeling - I might well shift as I think on it
> some more.
>
> Cheers,
>
> Neil
>
> On 03/02/2020 18:04, Tobias S. Josefowitz wrote:
> > Hi Neil,
> >
> > On Mon, 3 Feb 2020, Neil Dunbar via Netsec wrote:
> >
> >> Reading through Ryan's comments on the main list, a couple of things
> >> are springing to mind.
> >>
> >> 1) Is there anything that can be done to shut out a perverse
> >> interpretation that a "change" to a system can be defined as
> >> "anything which goes through
> >
> > We worked on this a bit in the Pain-Points subgroup today and did not
> > quite find a way to express it so that it is not open to a perverse
> > interpretation. We considered the quite possibly best cause of action
> > might be to take Ryan up on his offer, create an SC20 pull request and
> > see what he comes up with.
> >
> >> 2) Should we decapitalise Change Management Process in 1(h), unless
> >> we truly wish it to be a defined term? Given that there are plethorae
> >> of systems capable of tracking changes, it might be problematic to
> >> come up with an all-encompassing definition. In 1(h) we are stating
> >> the characteristics which a change management system needs to
> >> demonstrate, rather than specifically nail down what one is;
> >> therefore might it be better to not make it appear as a defined term?
> >>
> >> Alternatively, we could simply define one:
> >>
> >> "Change Management Process: A protocol which catalogues proposed
> >> changes to systems within its scope, allowing such changes to be
> >> approved, rejected and reviewed"
> >>
> >> My problem with the above is that I'm sure it just creates a dozen
> >> more holes for bad actors to escape from!
> >
> > We came up with:
> >
> > Change Management Process: An established set of steps followed to
> > ensure that the intended system configuration and changes to it have
> > received appropriate levels of review and have been duly authorized.
> >
> > Anyway, should we create the pull request? I volunteer(ed) to take
> > care of it, and I stand by it, but given you are the proposer and
> > already have the commit and all and just need to click a button, maybe
> > you prefer to do it?
> >
> > Tobi
> _______________________________________________
> Netsec mailing list
> Netsec at cabforum.org
> http://cabforum.org/mailman/listinfo/netsec
>


-- 

David Kluge | Technical Program Manager | kluge at google.com |  +41 44 668 03
54 <+41%2044%20668%2003%2054>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20200204/142d3830/attachment-0001.html>


More information about the Netsec mailing list