[cabf_netsec] Discussion Period Begins | Ballot NS-003: Restructure the NCSSRs

[Clint Wilson via Netsec]

Ballot NS-003 is proposed by Clint Wilson of Apple and endorsed by Trevoli 
Ponds-White of Amazon and David Kluge of Google Trust Services.

Please note, this ballot has set a 2 week Discussion Period.

Purpose of Ballot

This ballot proposes a comprehensive restructuring of the Network and 
Certificate System Security Requirements (NCSSRs), excepting Section 4. The 
current structure of the document has proven to be challenging for creating 
ballots, contains duplicated requirements, and separates similar requirements 
across the document. These issues have led to inefficiencies in managing and 
implementing security standards. Therefore, this proposal aims to streamline 
the document's structure, eliminate redundancies, improve comprehensibility, 
and enhance clarity and coherence.

Reasons for Proposal:

Complexity in Ballot Creation: The current document structure can make it 
difficult to create and manage ballots efficiently, leading to somewhat awkward 
updating processes, abandoned ballots, and a lack of confidence that ballots 
effect the intended changes.
Redundancy: Over time, some parts of the NCSSRs have touched on the same topic, 
leading to some duplication across the document and further to confusion and 
inconsistency in implementation.
Fragmentation: Similar requirements for different parts of a CA’s 
NCSSR-relevant infrastructure are scattered throughout the document, making it 
somewhat more difficult for to locate and comprehend a complete picture of 
these requirements effectively.
Minor Issues: The document contains other, more minor issues that also impede 
its usability and effectiveness, such as missing definitions, unclear list 
structures, and requirements that are more optional than they may currently 
appear.

Benefits of the Updated Document Structure:

Enhanced Clarity: The revised structure should improve the clarity and 
coherence of the document, making the requirements it represents easier to 
understand, as well as result in greater consistency when implementing or 
assessing its security requirements.
Future Updates: A more granular document structure should improve the process 
of creating and managing ballots in the future. Similarly, the improved 
proximity of related requirements should hopefully aid in identifying the areas 
the NCSSRs can most benefit from further attention.
Grouping and De-duplication of Similar Requirements: By consolidating 
duplicated requirements, the updated document should make it much easier to 
find, comprehend, assess, and implement related requirements.
Clearer Recommendations: The updated document includes a number of additional 
“SHOULD”-type stipulations, clarifying some of the language in the current 
NCSSRs such that it’s easier to identify where the NCSSRs impose a strict 
requirement as opposed to a strong recommendation.

Overall, this ballot proposal seeks to address existing challenges in updating 
the current version of the NCSSRs and pave the way for future improvements to 
the NCSSRs.

MOTION BEGINS

This ballot modifies the “Network and Certificate System Security Requirements” 
as follows, based on version 1.7:

https://github.com/cabforum/netsec/compare/c62a2f88e252de5c79b101fa3c9e9c536388639a...8bd66d27c07e30d1f4d9e6dd57b075bca499bf2e

MOTION ENDS

The procedure for approval of this ballot is as follows:

Discussion Period (14+ days)

Start Time: 2024-April-09 16:00 UTC
End Time: After 2024-April-23 15:59 UTC

Voting Period (7 days)

Start Time: TBD
End Time: TBD



smime.p7s
Description: S/MIME cryptographic signature
___
Netsec mailing list
Netsec@cabforum.org
https://lists.cabforum.org/mailman/listinfo/netsec

Re: [cabf_netsec] Updated Draft NS-003: Restructure NCSSRs

[Clint Wilson via Netsec]

Hi Antti,

> On Apr 8, 2024, at 10:52 PM, Backman, Antti  
> wrote:
> 
> Hi Clint
>  
> When reviewing the text I got wonder about couple of fairly minor things 
> within section 3.1.1, specifically following sections / language: 
>  
> 3.1.1.1, 3.1.1.2 and 3.1.2.1, 
>  
> Should we use the name for TLS BR as it is written in the BR document front 
> page “Baseline Requirements for the Issuance and Management of 
> Publicly-Trusted TLS Server Certificates”? I would think the name reference 
> is ambiguous as how it is now written in the text, due to the fact that we 
> have S/MIME BR, how would you see this. 

Great catch, I’ve updated these three instances to state "Baseline Requirements 
for the Issuance and Management of Publicly-Trusted TLS Server Certificates” 
instead of "Baseline Requirements for the Issuance and Management of 
Publicly‐Trusted Certificates”.

>  
> Then in regards to the links in the same sections to the TLS BR-document, is 
> it an official practice to make direct reference to the Github for the BRs? 
> I’ve understood that the published versions of the BRs are considered the 
> official version of the documents, thus should be used as reference point in 
> the language? I guess this is more for the clarity how such links should be 
> prepared and embedded in to the CA/B governed documents and to understand 
> that how stakeholders should treat the different copies of the same 
> documentation published by CA/B. 

I don’t believe there’s an official practice related to this. The EVGs don’t 
seem to include a link at all, rather just the section number and document 
title 
(https://github.com/cabforum/servercert/blob/main/docs/EVG.md#72-by-the-applicant).
 The SBRs do include a link to the specific section being referenced 
(https://github.com/cabforum/smime/blob/main/SBR.md#3221-validating-authority-over-mailbox-via-domain).
 Of the two methods of linking between documents, my personal preference is the 
SBR approach, but I’m not particularly opposed to removing the links or 
updating them if others feel strongly. For the moment, I’ve left them as-is.

I’ll push these changes later today, after the NSWG call in case there’s 
further discussion.

Cheers!
-Clint

>  
>  
>  
>  
> //Antti
>  
> From: Netsec  > on behalf of Clint Wilson via Netsec 
> mailto:netsec@cabforum.org>>
> Date: Monday, 8. April 2024 at 23.15
> To: NetSec CA/BF mailto:netsec@cabforum.org>>
> Subject: [cabf_netsec] Updated Draft NS-003: Restructure NCSSRs
> 
> Hi all,
>  
> I’ve pushed an update for NS-003 to address feedback received and add the 
> effective date discussed at last meeting. I have a few questions outstanding 
> that I'd appreciate feedback on.
>  
> 1. The effective date is currently set to 15 October 2024. I don’t think this 
> is quite the correct date, but would 15 November 2024 or 15 January 2025 be 
> more appropriate?
>  
> I’ve placed language at the top of the Requirements stating that 1) until the 
> effective date, either the version of the NCSSRs represented by this draft or 
> Version 1.7 of the NCSSRs must be followed and 2) as of the effective date, 
> this draft version of the NCSSRs must be followed.
>  
> 2. Is this the correct location for this language?
> 3. Is this the correct language to convey this future effective data?
> 4. Does this language work well for a future update to section 4?
>  
> The updated draft can be found here: 
> https://github.com/cabforum/netsec/compare/offline-hsms
> Latest commit: 
> https://github.com/cabforum/netsec/commit/251ac72ab8389e93018945a41f31779dae51aa5c
> Comparison between main and commit: 
> https://github.com/cabforum/netsec/compare/c62a2f88e252de5c79b101fa3c9e9c536388639a...251ac72ab8389e93018945a41f31779dae51aa5c
> Comparison between prior major commit (Oct 2023) and latest commit: 
> https://github.com/cabforum/netsec/compare/0d34f4ab148439130e28d4fa8128af7385fc21d3...251ac72ab8389e93018945a41f31779dae51aa5c
>  
> Thanks all!
> -Clint



smime.p7s
Description: S/MIME cryptographic signature
___
Netsec mailing list
Netsec@cabforum.org
https://lists.cabforum.org/mailman/listinfo/netsec