Hi Tim, Thanks very much for the constructive feedback! Some more thoughts in-line below:
>> 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 strongly agree here, and it’s been one of the motivations for this draft being built up methodically with frequent “check-ins” with the WG to confirm whether it’s progressing the way folks want to see it progress. If there are specific things that should be reverted to their v1.7 wording or items that should be fixed to ensure that value justification, I would greatly appreciate hearing those thoughts/opinions from anyone. >> 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. For the most part, I also agree. There are often instances where those boundaries need to be clarified (the DTP discussion leading to SC-070 is a decent example), but taking every one of those instances as an indicator that there’s an ocean in need of boiling would be detrimental to our ability to get anything useful done. >> 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. Fair enough. If you have thoughts on how to re-word/re-work 1.1.1.1, I’d love to hear, but I’ll try to propose an alternative phrasing in the next update as well. >> 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 … That sounds reasonable to me and I’d lean towards your examples of improving the wording such that it can remain a MUST. I’ll update this, but would welcome concrete suggestions in the meantime. Thanks again! -Clint >> 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 > > _______________________________________________ > Netsec mailing list > Netsec@cabforum.org > https://lists.cabforum.org/mailman/listinfo/netsec
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Netsec mailing list Netsec@cabforum.org https://lists.cabforum.org/mailman/listinfo/netsec
