<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Valid point. I suspect that many of us are operating from an intuitive notion of “Well, of course there must be a security perimeter”, which surreptitiously assumes everyone’s preferred private definition of *their* current perimeter.<div class=""><br class=""></div><div class="">From a Root CA perspective, I would have thought that there must be a physically defined site perimeter within which only authorised personnel are allowed (subject to logging, identification, secret knowledge demonstration, etc.) AND that there is an equipment perimeter which contains (at least) the equipment constituting the Root CA system (controlling computer, HSM, crosswired cables, dedicated network hub, serial cables, etc) [e.g. a locked cabinet]. There is thus a perimeter inside that cabinet which is the core Root CA equipment network (and in fact, may be the only equipment within that cabinet). This is the Root CA perimeter.</div><div class=""><br class=""></div><div class="">With that (verbose) description, I would say that, if any connection through the designated Root CA perimeter and *any* other equipment is possible, then that Root CA system is not air gapped. A connection being defined as an active piece of equipment capable of bearing data in real time to another piece of equipment without active, authorised, human participation.</div><div class=""><br class=""></div><div class="">So, that would mean that a Root CA controlling laptop with a powered Bluetooth or Wifi adapter (connected to an AP or not) is not air gapped. But it still leaves the ability to communicate data via a USB storage device which can then be used to export data (CRLs, signed certificates, etc.) as well as import (PKCS10 data, etc.), because that’s not “real time”. Although, I admit, it’s a somewhat arbitrary distinction to draw.</div><div class=""><br class=""></div><div class="">Now, whether such a description is workable or not as a requirement, I’m not sure.</div><div class=""><br class=""></div><div class="">Neil</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 8 Sep 2017, at 21:17, Tim Hollebeek <<a href="mailto:THollebeek@trustwave.com" class="">THollebeek@trustwave.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I think one of the problems with some of the discussion on the call is that we don’t really have a concept of a security perimeter for CA systems in the current requirements. This makes it hard to write requirements that don’t allow stupid things, like cables running to systems which, while not connected to the public internet, do not have the appropriate access controls.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">My thinking right now is that perhaps the best approach is to actually require an identified security perimeter, and then an air gapped system is a system that is not physically connected to any networks or devices outside the security perimeter, nor can it be accessed from outside of the security perimeter.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div></div></blockquote></div></div></body></html>