<div dir="ltr"><div>I'll readily admit that we're not entirely sure that 5l and 5m are good approaches.</div><div><br></div><div>That is, there is a world in which they absolutely make sense, and having 5a do the same might make sense, but it's not clear that's a world we're in.</div><div><br></div><div>One of the recurring issues with the NetSec subcommittee that we've tried to grapple with, on our side, is a confidence in logical security controls that can easily fall over (e.g. VLAN tagging by trusting the client to be honest, firewalls [like DigiNotar had] to limit ingress and egress traffic). The change in 1.c is one of those that while I think it's meant well, but perhaps highlights this disconnect. It moves from "physically separated (High Security Zone) and (in an offline state air-or gapped from all other networks)" to "kept offline or otherwise air-gapped and separated from other systems", which can either parse as "(kept offline) or (otherwise air-gapped and separated from other systems)" or "(kept offline or otherwise air-gapped) and (separated from other systems)".</div><div><br></div><div>This is particularly important when thinking of the logical security controls: because I can easily see a CA interpreting the changes in 1.c as meaning they can put their Root CAs on the same internal network, as long as they keep them offline "most of the time". There's no functional requirement for separation, and it seems for at least some members of NetSec, that's a feature, not a bug (I think we'd disagree).</div><div><br></div><div>As a consequence of this, wording like in 5.l/5.m would be itself a huge security regression, because it would mean periodically connecting to a (potentially) hostile network, yet only having to review when the organization determines they've "used" a CA (e.g. issued something), versus when they brought it online. Even a review of configuration may be too late for a DigiNotar-style compromise.</div><div><br></div><div>As I said, I think this is mostly meant well, but I think we need to "literal genie"-proof the overall thing a bit more. Assuming there was more robustness in place, I agree that something like 5.l/5.m might make sense for 5.a.</div><div><br></div><div>Yet, even then, the downside is one we've seen play out in countless CA incidents: "Due to human error, we failed to review the configuration for all changes made to the BRs since we last reviewed the configuration, and thus we misissued. Oops". The annual cadence, at least there, helps CAs create a bit more definition about the changes that need to be considered (exactly one years changes), rather than have it be variable based on usage (and possibly exceeding several years of changes).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 3, 2021 at 7:31 PM Aaron Gable <<a href="mailto:aaron@letsencrypt.org">aaron@letsencrypt.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Indeed! But to achieve that end, it could be phrased in the same manner as 5l and 5m: requiring that configuration be reviewed when (or more strictly, immediately prior to when) the air-gapped system is used, or on a yearly basis, whichever is less frequent.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 3, 2021 at 12:51 PM Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 3, 2021 at 3:46 PM Aaron Gable via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Thanks! Just one questions on specifics:</div><div dir="ltr"><br></div><div dir="ltr">> 5a. Review configurations of Air-Gapped CA Systems at least on an annual basis;</div><br><div>Regular review of configuration of air-gapped systems seems good, but this sounds like it requires CAs to retrieve and turn on air-gapped systems which would otherwise be able to remain untouched. Is there another form of configuration review which does not require access to the system itself that is intended here?</div></div></blockquote><div><br></div><div>How would you know they had indeed actually otherwise remained untouched? :) </div></div></div>
</blockquote></div>
</blockquote></div></div>