<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">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></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Tim<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Public [mailto:public-bounces@cabforum.org] <b>
On Behalf Of </b>Neil Dunbar via Public<br>
<b>Sent:</b> Friday, September 8, 2017 5:18 AM<br>
<b>To:</b> CA/Browser Forum Public Discussion List <public@cabforum.org><br>
<b>Subject:</b> [cabfpub] Definitions of Air Gapped and Offline Systems<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">In the NetSec group, we’re updating the definitions suitable to Root CA systems, so that the definitions are both practical and robust. We’d like to solicit opinions from the broader public list.<br>
<br>
In particular, we’re looking at the definitions of “Offline” and “Air Gapped” systems, which apply to the HSMs and controlling computers which form the Root CA certificate systems.<br>
<br>
The desired security property is this: the equipment should not facilitate the injection of malicious data into the controlled Root CA system. The attack surface for any component of a Root CA system should be very low, extremely difficult to penetrate and
the good state of the system should be demonstrable (and thus auditable) throughout the operational lifespan of the equipment.<br>
<br>
Here are the current working definitions:<o:p></o:p></p>
<blockquote style="margin-left:30.0pt;margin-right:0in">
<p class="MsoNormal">Air Gapped: Physically and logically connected, at the most, only to a single utility network (without physical connectivity to the internet) and connected to no other network. (requires physical presence or physical proximity).<o:p></o:p></p>
</blockquote>
<blockquote style="margin-left:30.0pt;margin-right:0in">
<p class="MsoNormal"><br>
Tobias Josefowitz suggested this alternative:<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Air Gapped: Physically and logically disconnected from all other networks, interaction of any kind requires physical presence in proximity. If the system is built of several components, network technology may be used to connect them as
long as network equipment and all systems connected are themselves otherwise Air Gapped.<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">and for Offline:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="margin-left:30.0pt;margin-right:0in">
<div>
<p class="MsoNormal">Offline State: A Certificate System or component that is not available via any external connection (e.g. powered down or unplugged)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<p class="MsoNormal">The notion being that a Root CA system should ideally be in both Air Gapped and Offline when not in active use.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Now, there are all sorts of notions about components being in known good state, and being not amenable to contagion while in operation and so on, but for the moment we want to concentrate on how to show that your Root CA system upholds
the principle of being Air Gapped (and perhaps normally Offline). It was pointed out, for instance, that even having a Wifi kernel module active in a component (not connected to an AP) could still be a vector for attack because of weaknesses in firmware, exploitable
via beacon broadcasts. Clearly, then, merely saying “Oh yes, this laptop could do Wifi, but we just don’t" is not enough - it’s still in a potentially bridged state, and therefore not Air Gapped. You would need to ensure that the EFI/BIOS and kernel did not
activate the Wifi adapter in the boot sequence.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So - can we get some improvements to the definitions which are:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">a) robust, i.e., not amenable to someone using excessive lawyer parsing to say that an architecture technically obeys the rules, but which in reality violate the security property<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">b) practical, i.e., that can be built and operated within a reasonable commercial operation, and have the salient properties demonstrated to an auditor; and that auditor could faithfully represent that the system under test does indeed
adhere to the requirements?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Neil<o:p></o:p></p>
</div>
</div>
</body>
</html>