[cabf_netsec] Voting Results of Ballot NS-003: Restructure the NCSSRs
Voting Results of Ballot NS-003: Restructure the NCSSRs The voting period for Ballot NS-003: Restructure the NCSSRs has ended and the Ballot has Passed. The following votes were cast: 4 votes by Certificate Consumers 4 Yes votes: Apple, Google, Microsoft, Mozilla 0 No votes: 0 Abstain votes: 100% of voting Certificate Consumers voted in favor 18 votes by Certificate Issuers 18 Yes votes: Amazon Trust Services, Buypass, Chunghwa Telecom, Disig, Fastly, GDCA, GlobalSign, GoDaddy, HARICA, Kamu SM, OISTE, Sectigo, SSL.com, SwissSign, Telia Company, TrustAsia, TWCA, VikingCloud 0 No votes: 0 Abstain votes: 100% of voting Certificate Issuers voted in favor Bylaw Requirements Bylaw 2.3(6) requires: a "yes" vote by two-thirds of Certificate Issuer votes and 50%-plus-one Certificate Consumer votes for approval. Votes to abstain are not counted for this purpose. This requirement was met for both Certificate Issuers and Certificate Consumers. at least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was met for both Certificate Issuers and Certificate Consumers. Bylaw 2.3(7) requires: a ballot result will be considered valid only when more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining a quorum. Half of currently active Members as of the start of voting was 7, so quorum was 8 votes 22 votes were received This requirement was met. smime.p7s Description: S/MIME cryptographic signature ___ Netsec mailing list Netsec@cabforum.org https://lists.cabforum.org/mailman/listinfo/netsec
Re: [cabf_netsec] Voting Period Begins | Ballot NS-003: Restructure the NCSSRs
Apple votes YES on Ballot NS-003. > On Apr 23, 2024, at 8:59 AM, Clint Wilson via Netsec > wrote: > > 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. > > 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: 2024-April-23 15:59 UTC > > Voting Period (7 days) > > Start Time: 2024-April-23 16:00 UTC > End Time: 2024-April-30 16:00 UTC > ___ > 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
[cabf_netsec] Voting Period Begins | Ballot NS-003: Restructure the NCSSRs
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. 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: 2024-April-23 15:59 UTC Voting Period (7 days) Start Time: 2024-April-23 16:00 UTC End Time: 2024-April-30 16:00 UTC smime.p7s Description: S/MIME cryptographic signature ___ Netsec mailing list Netsec@cabforum.org https://lists.cabforum.org/mailman/listinfo/netsec
[cabf_netsec] Discussion Period Begins | Ballot NS-003: Restructure the NCSSRs
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
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 <mailto:netsec-boun...@cabforum.org>> 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
[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
[cabf_netsec] Updated Restructure Draft
Hi All, The draft changes we’ve been working on have been updated to address all outstanding feedback that I’m aware of. The current PR is at https://github.com/cabforum/netsec/compare/offline-hsms. I’m interested in any final feedback prior to allocating a ballot number and commencing an official discussion period. Thanks! -Clint smime.p7s Description: S/MIME cryptographic signature ___ Netsec mailing list Netsec@cabforum.org https://lists.cabforum.org/mailman/listinfo/netsec
Re: [cabf_netsec] Update to restructure draft
g. 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 > <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 > <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
[cabf_netsec] Fwd: Update to restructure draft
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 <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 <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