CP/CPS intra-document cross-references

[Aaron Gable]

The Baseline Requirements have a few places where they require that a CA include specific information in a specific section of their CP/CPS. Two examples:

Section 2.2 Publication of information

> Section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement SHALL state the CA's policy or practice on processing CAA Records for Fully-Qualified Domain Names...

Section 4.9.3 Procedure for revocation request

> The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS.

In cases like these, is it acceptable for the identified section of the CP/CPS to say "See Section such-and-such for..."?

Specifically, would it be acceptable for Section 4.2 of a CP/CPS to say "See Section 3.2.2.8 CAA Records for details of the CA's policy on processing CAA records"? Or similarly, would it be acceptable for Section 1.5.2 to say "See Section 4.9.3 for instructions on how to make a revocation request or submit a certificate problem report"?

Or does that kind of intra-document cross-reference not satisfy the above requirements?

I'm curious what other members of this community think.

Thanks,

Aaron

[Wayne Thayer]

Hi Aaron,

On Thu, Nov 30, 2023 at 4:17 PM 'Aaron Gable' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

The Baseline Requirements have a few places where they require that a CA include specific information in a specific section of their CP/CPS. Two examples:

Section 2.2 Publication of information

> Section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement SHALL state the CA's policy or practice on processing CAA Records for Fully-Qualified Domain Names...

Section 4.9.3 Procedure for revocation request

> The CA SHALL publicly disclose the instructions through a readily accessible online means and in Section 1.5.2 of their CPS.

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.

In cases like these, is it acceptable for the identified section of the CP/CPS to say "See Section such-and-such for..."?

Specifically, would it be acceptable for Section 4.2 of a CP/CPS to say "See Section 3.2.2.8 CAA Records for details of the CA's policy on processing CAA records"? Or similarly, would it be acceptable for Section 1.5.2 to say "See Section 4.9.3 for instructions on how to make a revocation request or submit a certificate problem report"?

Or does that kind of intra-document cross-reference not satisfy the above requirements?

In my opinion a reference does not satisfy the requirement as written, but I can understand how others may have different interpretations.

- Wayne

[Matt Palmer]

On Thu, Nov 30, 2023 at 03:17:15PM -0800, 'Aaron Gable' via dev-secur...@mozilla.org wrote:
[...]

> In cases like these, is it acceptable for the identified section of the
> CP/CPS to say "See Section such-and-such for..."?
>
> Specifically, would it be acceptable for Section 4.2 of a CP/CPS to say
> "See Section 3.2.2.8 CAA Records for details of the CA's policy on
> processing CAA records"? Or similarly, would it be acceptable for Section
> 1.5.2 to say "See Section 4.9.3 for instructions on how to make a
> revocation request or submit a certificate problem report"?
>
> Or does that kind of intra-document cross-reference not satisfy the above
> requirements?
>
> I'm curious what other members of this community think.

In theory, I believe that a reference to another piece of text would satisfy the
spirit of the requirements. Practically, though, I'd worry that it would be
very easy for the destination reference to "lose" the relevant information
over time. The cause I'm thinking of is when the destination reference is
edited, the person making the change may not take into account the
requirements in the linked-from section when making revisions, and only
satisfy the letter of the changed section.

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.

In short, I don't think it's disallowed, but if I were running a CA I think
I'd err on the side of caution and not do it for normative references.

- Matt

[Aaron Gable]

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, 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 <wth...@gmail.com> 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 <mpa...@hezmatt.org> 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

[Roman Fischer]

Hi Aaron,

 

(Speaking as myself and not for my employer here.)

I don’t think many people read these documents. So as long as the content is there and is properly referenced, it’s OK for me.

 

Rgds

Roman

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnEredGSLoMgwOpJvwVaSVLHUUXrsKMKr2VZEZe%2BXehteXrw%40mail.gmail.com.

[Ryan Hurst]

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.

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

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.