Hi Antti, > On Apr 8, 2024, at 10:52 PM, Backman, Antti <antti.back...@teliacompany.com> > 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 <netsec-boun...@cabforum.org > <mailto:netsec-boun...@cabforum.org>> on behalf of Clint Wilson via Netsec > <netsec@cabforum.org <mailto:netsec@cabforum.org>> > Date: Monday, 8. April 2024 at 23.15 > To: NetSec CA/BF <netsec@cabforum.org <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
