Hello all, This thread was unintentionally started on the NetSec Management list, but is more suited to the public list. With permission, I’m forwarding the thread so far.
Cheers, -Clint > Begin forwarded message: > > From: Tim Hollebeek <tim.holleb...@digicert.com> > Subject: RE: [Netsec-management] Update to restructure draft > Date: February 2, 2024 at 8:18:39 AM PST > To: Clint Wilson <cli...@apple.com> > Cc: NetSec Management <netsec-managem...@cabforum.org> > > Yes, I agree with your analysis. Key points: > > I agree that most if not all of this mess exists or is even worse in the > current NCSSRs, so the work so far is already an improvement. > Exactly how much of that we need to fix before we can pass an update is a > very tough question. Even having the same requirements expressed in a > different format will be quite a bit of churn for auditors to get their heads > around, so I think we do need to get it to a point where it will solve enough > problems to justify the churn. > I agree that there is always a balance between expressing the security > goal/requirements, and detailed procedural requirements (“You MUST do it This > Way, by following these steps …”). There are advantages and disadvantages to > each approach. There’s a third one (example below) where you write > requirements about the maturity of the process and transparency, to allow > better oversight. Over time, I’m increasingly fond of the “you can do what > you want (within hard boundaries), but you have to tell us what you’re doing” > model. > The reason I’m balking on the use of ‘appropriate’ in 1.1.1.1 is because > there isn’t enough meat there that provides any guidance about the security > goal, the target security level, and so on, so “appropriate” will just be > CAs, auditors, and root programs arguing about opinions. And “whose opinion > is better?” is almost always guaranteed to be an unproductive discussion. > There are plenty of useful uses for ‘appropriate’, but sometimes it’s just a > dodge to avoid tackling the hard problems that need to be tackled. > On 1.1.1.2, I think a SHOULD would be quite appropriate. There are other > approaches available that are stronger, for example: “The design MUST be > based on a documented security analysis, which MUST take into account and > mention the following principles …” Sometimes just requiring people to have > a rational and documented security posture is already an improvement … > And yes, I do think 1.3 looks quite good. I’m sure we might have some > quibbles with the details, but I like that section. > > Bindi will probably also have a lot more comments and feedback once she gets > up to speed … she actually has real operational security experience in this > area, and I’ve asked her to assist with the NCSSR development process in the > hopes that having an additional security resource available will help > accelerate the development process. > > Also we should probably move off the management list. > > -Tim > > From: Clint Wilson <cli...@apple.com> > Sent: Thursday, February 1, 2024 9:52 PM > To: Tim Hollebeek <tim.holleb...@digicert.com> > Cc: NetSec Management <netsec-managem...@cabforum.org> > Subject: Re: [Netsec-management] Update to restructure draft > > Hi Tim, > > Thanks very much for the input here. I think you’re spot on with regards to > where we need to get the NCSSRs, but I also don’t know that I believe this > ballot to be the best place to address some of these issues — both from my > personal opinion and from what I’ve heard expressed in NSWG meetings. > > The primary goal of the draft is to restructure the NCSSRs in a way that > makes them more maintainable and easier to expand upon in the future. In the > course of restructuring the document, it became clear that there was a need > to make some changes to content and wording in order to have an end product > that made sense (for example, moving some requirements into more applicable > sections and deduplicating requirements). This was pursued based on feedback > from the NSWG last year indicating a rough consensus that it was a direction > the group supported (of course, I’m certainly not ruling out that I may have > misunderstood something in the 3-4 meetings where such a discussion took > place). That said, it has also remained my intent to try to minimize the > number and depth of changes between the functional expectations represented > by a) the current and b) these draft requirements. > > Unfortunately, I think a number of your concerns are present in the current > NCSSRs and very much highlight why, at least in my opinion, it’s necessary to > update the document’s structure so that 1) these issues are easier to > identify and 2) these issues are easier to fix. > > FWIW, I’m increasingly confident that this draft does accomplish these 2 > things based on my personal experience so far in writing the draft; it’s hard > to describe how much easier it is to work with the text now compared to when > I started this process. > > (More below in-line) > > > On Feb 1, 2024, at 12:59 PM, Tim Hollebeek <tim.holleb...@digicert.com > <mailto:tim.holleb...@digicert.com>> wrote: > > It would be useful to know when people feel portions of this document are > stable enough for a deep review, as such reviews are pretty time consuming > given the scope and nature of the issues. > > As a data point, I took a quick read through, and my opinion is we’re not > there yet, and that’s because I have serious concerns about the auditability > of these requirements. > > 1.1.1.1 “appropriate and applicable” is code for “CAs, auditors, and > browsers will have lots of unproductive discussions about what this means in > practice” > > I think there’s a balance necessary here (and more generally in our > requirements documents) between a) prescribing/proscribing specific behaviors > or implementation requirements and b) describing reasonable expectations > which can be met multiple ways. I believe it’s necessary, at least presently, > for some aspects of documents like the NCSSRs to provide clear guidance > regarding the outcome of adherence, while still allowing for differences in > exactly how a CA meets the requirement. > > Perhaps surprisingly(?), I think it’s healthy for CAs, auditors, browsers, > and other industry participants to have discussions about what this > requirement would mean in practice (I hope they’re productive and I’m not > sure why they couldn’t be, though I definitely get that they’re far from > guaranteed to be). Those discussions could result in identifying patterns in > different implementations which map to improved security that can in turn be > incorporated into the NCSSRs as (more) specific criteria. That would be > fantastic! > As of right now, however, I think the reality of what is “appropriate and > applicable” is different for quite literally every single Certificate Issuer > in the CA/B Forum. > > FWIW and as I understand it, “appropriate” is a relatively common component > of controls and requirements the NSWG reviewed when comparing the NCSSRs to > other documents of varying levels of similarity (and, in particular, it’s > peppered throughout the Cloud Controls Matrix). > > All that said, if there are any wording changes or specific actions you (or > anyone) would recommend, including if you feel like the above simply doesn’t > address your concerns meaningfully and 1.1.1.1 should just be dropped, I > would appreciate hearing your thoughts. > > > 1.1.1.2 I don’t think it’s auditable whether network segmentation meets > what are essentially just design principles, no matter how thoughtfully they > are articulated > > The above applies here as well, but I also wanted to add that this section > was specifically added based on sentiments shared in the NSWG that we should > convey these kinds of expectations in the NCSSRs more frequently. I do > believe this to be an auditable requirement, but am certainly open to being > corrected on that understanding. At one point I was pondering whether this > requirement should be a SHOULD instead of a MUST and the (limited) feedback I > received at the time was to keep it a MUST, but I’m curious if you think > changing this to a SHOULD would address your concern at all? (I’m guessing > not by much, but I don’t want to assume.) > > > 1.2.1. Much better. > 1.2.2. Again, I don’t think “unnecessary” and “Principle of Least Privilege” > are auditable. > > This is currently part of the NCSSRs (a combination of parts of 1.f, 1.g, and > 2.e); while the wording is different (e.g. “identified as necessary” instead > of “minimizes unnecessary”), I believe the actual requirement is the same. > So… I hope it’s auditable :) > > BUT(!) I would absolutely love to improve these requirements. I tried to do > so to a small extent by defining “Principle of Least Privilege”, which was > previously undefined in its usage within 2.e, but I felt more/larger changes > here would be going against the primary goal/intent of this draft. > > > 1.2.3. What is “equivalent security”? How is it measured? > > This is intended to be only a slight re-wording and clarification of the > current NCSSR requirement 1.b. Would it be preferable to keep the current > wording instead? (I think the same issue would still exist, but perhaps > there’s nuance I’m failing to see.) > > > 1.3. This section is a good example of how much specificity and detail is > desirable and needed. > > This section took a lot of time, trying to pull in the explicit and implicit > requirements of 1.h, 2.a, and 3.a into a comprehensible set of expectations > around change management. I’m genuinely very glad that you approve (I think > you do, at least; I don’t mean to put words in your mouth). Especially 3.a is > quite overloaded; quite the interesting challenge to figure out an > appropriate balance of specificity here that would provide enough detail of > 1) what’s actually expected and 2) the scope those expectations apply to > without unnecessarily constraining a CA’s ability to meet the requirements in > a way that makes sense for their organization, team structure, resource > allocation, etc. > > This is also a good example of what I mean when I say I think that > restructuring the NCSSRs, as this draft attempts to do, will help enable and > hasten fixes to the myriad of (mostly) small and (some) big issues latent in > the current NCSSRs — I don’t believe I could have drafted such a set of > requirements while fitting them into the current style and format of the > NCSSRs. > > Thank you again for your feedback and I hope to hear more! > Cheers, > -Clint > > > > Those are the sorts of things I would like to see addressed before I run this > by our networks and operations folks for a deep review. > > -Tim > > From: Netsec-management <netsec-management-boun...@cabforum.org > <mailto:netsec-management-boun...@cabforum.org>> On Behalf Of Clint Wilson > via Netsec-management > Sent: Thursday, February 1, 2024 10:35 AM > To: NetSec Management <netsec-managem...@cabforum.org > <mailto:netsec-managem...@cabforum.org>> > Subject: [Netsec-management] Update to restructure draft > > Hi all, > > Thanks for the fantastic discussion on Tuesday :) > I’ve updated my branch based on what I understood, but please let me know if > I missed anything. I’m reasonably happy with the outcome, though there’s > always room for improvement. > > The branch remains available at > https://github.com/cabforum/netsec/tree/offline-hsms. > Further a couple (hopefully useful) diffs are: > Comparison between main and commit: > https://github.com/cabforum/netsec/compare/c62a2f88e252de5c79b101fa3c9e9c536388639a...8706d87d049baee0faa668b03e7c5b8e330339d7 > Comparison between prior major commit (Oct 2023) and latest commit: > https://github.com/cabforum/netsec/compare/0d34f4ab148439130e28d4fa8128af7385fc21d3...8706d87d049baee0faa668b03e7c5b8e330339d7 > > I haven’t fully updated > https://docs.google.com/document/d/1mOEiNZ-R_D4l_8OgScqx8mhcUwBPoXkNjlBpY5g29Dg > with descriptions of these changes, but will try to do so soon. > > My sense is that sections 1-3 of this draft are stabilizing, so I would > appreciate any feedback on whether that’s the case (and identification of > latent issues would be most welcome). > > Next on my list is to make an attempt at addressing our historical > discussions surrounding Physically Secure Environment/Root CA System > separation within this document structure. > > Please let me know of any thoughts or input you may have. Cheers! > -Clint
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Netsec mailing list Netsec@cabforum.org https://lists.cabforum.org/mailman/listinfo/netsec
