Having read more, CP/CPS is in my life, and I cared to admit to it is my opinion that better to not duplicate or spread information around and instead redirect to elsewhere as proposed by Arron.
I believe the objective of a CP/CPS is to clearly communicate performance with the associated requirements. Making the CPS digestible and self consistent is part of how we meets that objective. In my opinion that is better accomplished with clear concise non-repeated language covering each topic, this requires backward linking. On Fri, Dec 1, 2023 at 2:18 AM 'Aaron Gable' via [email protected] <[email protected]> wrote: > To provide some additional context, I'm currently conducting a thought > experiment around the following question: What would a CP/CPS look like if > it dedicated one sentence to every requirement (MUST/SHALL/etc) in the BRs, > in the same section that the requirement appears? > > A CP/CPS with this format would be very easy to check for compliance with > the requirements, including in contexts like the CCADB Self-Assessment. It > would also be very easy to update when the requirements change. > > However, in the process of thinking this through, I've found a number of > places where the "in the same section that the requirement appears" bit > becomes difficult. > > For example, the requirement in Section 2.2 stating that Section 4.2 must > contain specific content led me to file this bug > <https://github.com/cabforum/servercert/issues/466>, since it seems like > information regarding CAA should appear in 3.2.2.8, not 4.2. Or for another > example, Section 4.9.3 says that CAs must "provide clear instructions... > through a readily-accessible online means..." (great! Section 4.9.3 of our > CP/CPS is readily accessible online, we can fulfill this requirement right > here and now!) "...and in Section 1.5.2 of their CPS" (wait, so I have to > duplicate the information? that seems inefficient). > > On Thu, Nov 30, 2023 at 4:09 PM Wayne Thayer <[email protected]> wrote: > >> My recollection is that the intent of this statement was to make it so >> that one doesn't need to search/scroll through a CPS to find the CA's >> problem reporting mechanism. In that context, a reference is undesirable. >> > > Thanks, that context is helpful! I was interpreting these requirements > less as "it needs to be in this *specific* place so it's easy to find", > and more as "it needs to be in your CP/CPS, and this is the best place we > can think of for it". > > On Thu, Nov 30, 2023 at 4:31 PM Matt Palmer <[email protected]> wrote: > >> Take, for example, linking 1.5.2 to 4.9.3. There's no requirement for >> 4.9.3 >> to contain contact information in a form suitable for satisfying the >> requirements of 1.5.2, and while a CPS' 4.9.3 may initially satisfy the >> requirements of 1.5.2, someone revising 4.9.3 in the future, inadvertently >> failing to bear in mind the "link", may modify 4.9.3 in such a way that it >> no longer satisfies the requirements of 1.5.2. >> > > I totally get this line of thinking in general, but for me I have to weigh > it against the similar possibility of duplicating the information, and then > having someone in the future update only one instance and create a > contradiction within the document. (See Let's Encrypt's 90d+1s incident for > an example of how having the same information in multiple places can lead > to problems.) > > (Also, the example you're using here isn't quite what I'm proposing. > Section 1.5.2 of the CP/CPS would still have the necessary link as required > by Section 1.5.2 of the BRs. It just wouldn't have the *additional* > certificate > problem reporting details which are required by Section 4.9.3; it would > just contain a pointer back to Section 4.9.3 for those.) > > Since we have two differing opinions expressed so far, I'd still love to > hear from more folks! Thanks, > Aaron > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErdRR%2BR1XaNoWQtzjeKG-p%2BfFn3HYwzk7u-mjP3EF39_NQ%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErdRR%2BR1XaNoWQtzjeKG-p%2BfFn3HYwzk7u-mjP3EF39_NQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwa5VZd_C0Uhq%2By259-uud1iVarMdtgw52Ej9OEWjVF4%3Dg%40mail.gmail.com.
