[cabf_netsec] Update to restructure draft

Tue Feb 13 15:57:08 UTC 2024

Hi Tim,

Thanks very much for the constructive feedback! Some more thoughts in-line below:

>> From: Tim Hollebeek <tim.hollebeek at digicert.com>
>> Subject: RE: [Netsec-management] Update to restructure draft
>> Date: February 2, 2024 at 8:18:39 AM PST
>> To: Clint Wilson <clintw at apple.com>
>> Cc: NetSec Management <netsec-management at 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 <clintw at apple.com> 
>> Sent: Thursday, February 1, 2024 9:52 PM
>> To: Tim Hollebeek <tim.hollebeek at digicert.com>
>> Cc: NetSec Management <netsec-management at 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.hollebeek at digicert.com <mailto:tim.hollebeek at 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-bounces at cabforum.org <mailto:netsec-management-bounces at cabforum.org>> On Behalf Of Clint Wilson via Netsec-management
>> Sent: Thursday, February 1, 2024 10:35 AM
>> To: NetSec Management <netsec-management at cabforum.org <mailto:netsec-management at 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 at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/netsec

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/netsec/attachments/20240213/80336c18/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3621 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/netsec/attachments/20240213/80336c18/attachment-0001.p7s>