1717001 - Disig: CPS does not refer to BR domain validation methods

Status: RESOLVED INVALID

(CA Program :: CA Certificate Compliance, task)

Description

[George [:fozzie]]

Disig's CPS (archive) does not refer to the subsections of 3.2.2.4 in the BRs. This is contrary to MRSP 2.2.3:

The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with.

For example, the method outlined in section 3.2.2.4.1 of Disig's CPS looks to be referring to BR section 3.2.2.4.2 but this is unclear.

Comment 1

[Peter Miskovic]

Hi George,
we acknowledge receipt of this notification and will post a full report soon.

Thank you for pointing out this ambiguity in our CPS. After a brief analysis, I found that this resulted from my not very correct interpretation of the requirements, as written in section MRSP 2.2.3 in combination with section 3.2.2.4 of the CA / Browser Forum of the current version of the basic release requirements. and managing publicly trusted certificates. As you have rightly noted, what is stated in section 3.2.2.4.1 of our CPS corresponds to the method described in section 3.2.2.4.2 of the BR. The CPS will be updated to comply with the requirements set out in the section in MRSP 2.2.3

Regards
Peter Miskovic

Comment 2

[Peter Miskovic]

1) How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

Answer: We were notified of the ambiguity in the published CPS on June 17, 2021 at 16:08 by e-mail from Bugzilla @ Mozilla <[e-mail]> that a bug had been opened in Bugzilla.

2) A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

Answer:
June 17: Immediately after being notified of the new bug, we analyzed the part of the CPS in question and found that it was in fact misleading in terms of the methods we use to verify ownership and control the domain are divided into separate subchapters, which was incorrect and the entire content had be exclusively in section 3.2.2.4.
In this sense, we have acknowledged receipt of the notification and have also informed in advance that the ambiguity will be resolved by updating the CPS.

3) Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

Answer: The issuance of TL / SSL certificates was not affected by this ambiguity.

4) A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
Answer: The problem is no concerning issued TLS/SSL certificates

5) The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
Answer: The problem is no concerning issued TLS/SSL certificates

6) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Answer:
As already written in the preliminary report, it was a misinterpretation of the requirement and an unfortunate division of the two methods used into two subchapters, not realizing that the subchapters have the same numbering as the subchapters in section 3.2.2.4 of the current CAB forum BR requirements , with different content. This meant that the methods used were not described directly in section 3.2.2.4 but separately in sections 3.2.2.4.1 and 3.2.2.4.2 as the two methods we use.

7) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

Answer: The chapter in question in the CPS will be updated so that the entire content and description of the methods used will be given exclusively in section 3.2.2.4 and subchapters 3.2.2.4.1 and 3.2.2.4.2 will be deleted. For each method, a reference to the corresponding method will be provided in section 3.2.2.4 of the current CAB forum BR requirements. The CPS update will be performed and published tomorrow (June 18, 2021).

Comment 3

[George [:fozzie]]

Thanks for the quick incident report and the quick proposed fix. However, I feel like there is a lack of detail in some specific areas, notably, why did it take a third party report specifically targeted towards Disig for this to be discovered?

I'd like to know what Disig is doing to monitor incidents posted here on Bugzilla, as well as threads posted on m.d.s.p. Bug 1705480 was opened 2 months ago about SECOM having this exact same issue. Why did Disig not read that bug and then check their own CPS to make sure it complied with the MRSP?

If Disig missed that bug, then they still had the chance to evaluate their CPS before this bug was opened, when Corey started this thread roughly a month later on m.d.s.p.

This seems like a pretty significant failure from a CA as they have failed to monitor bugs posted both to Bugzilla and m.d.s.p. and have failed to evaluate their own infrastructure to see if it affected them.

Can you explain how you missed these two early warning signs, and what Disig is going to do to minimise risk in the future? Not just related to this specific issue, but to other issues which may be posted here which could affect Disig too.

Comment 4

[Peter Miskovic]

George, I can assure you that I am closely monitoring incidents published at Bugzilla.
The fact that I did not deal with a problem similar to the one described in Bug 1705480 has a simple cause. I did not expect anyone to read the policies and rules we published without taking into account their interconnectedness and hierarchy. If that were the case, he would certainly notice that in the Disig Certificate Policy, version 5.5 of 20.5.2021, section 3.2.2.4, are clearly defined two methods that Disig employees shall perform when verifying domain ownership and control, including with reference to the relevant parts of the requirements set out in the current version of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates published by CA/Browser forum, chapter 3.2.2.4.
In the Certificate Practice Statement Part: Registration Authority, version 5.5 from 20.5.202 chapter 3.2.2.4, to which you refer, these two methods are then described in more detail for the needs of the staff of our registration authorities. The only problem is that if someone opens only the second mentioned document, they may have the impression that chapter 3.2.2.4 does not clearly declare compliance with the requirements of the CA/Browser Forum Baseline Requirements, whereas details of the methods are described not in section 3.2.4.2 directly, but in subchapters 3.2.2.4.1 and 3.2.2.4.2. This can be confusing in terms of comparing the content and numbering of chapters in the CPS document with the content and numbering of chapters in CA/Browser forum BR. I realized this only when bug 1717001 was opened, and based on that, I realized the need to modify the chapter in the CPS document to eliminate this ambiguity.

Comment 5

[Peter Miskovic]

The new version on CPS (version 5.6) was published at June 18, 2021 on the

Comment 6

[Peter Miskovic]

A new version of CPS CA Disig version 5.6 has been published at CPS CA Disig, version 5.6.

The previous version 5.5 has been moved to CPS CA Disig, version 5.5.

Comment 7

[Ryan Sleevi]

Thanks Peter, and thanks for pointing out that your CP covered these.

George: Looking at the CP mentioned, it does seem to meet the requirement of expectations. Mozilla policy states CP/CPS, and it seems like the issue at play here is whether that's "either/or" or "both/and". Historically, I believe such requirements have been interpreted as "either/or", which is why tools like CCADB allow for multiple disclosures, as well as separate disclosure for both CP and CPS.

Have I overlooked anything? I think this might be WontFix/Invalid, but I could be missing an important detail.

Comment 8

[George [:fozzie]]

Thanks Peter for updating the CPS too to remove some ambiguity.

Ryan: I was treating the RA CPS as separate to the CA CP as I was assuming that it was using different methods of validation (thus also needing a commitment to the BR subsections) as many other sections on the RA CPS simply mentions "See section x CP CA Disig.". It seems strange to me that if the same exact validations are being used, it wouldn't then refer to the CA CP as it does with other sections. However, if you feel like by having the CA CP cover this for the RA CPS it means it is not a violation of MRSP, I don't mind closing this as INVALID. It seems like any ambiguity has now been swiftly fixed by Disig so the issue is fixed anyhow.

Comment 9

[Ryan Sleevi]

Yeah, I think you've accurately captured the concern here with split CP/CPSes that I certainly am very familiar with from doing CP/CPS reviews: trying to figure out what's complementary and what's contradictory. The CPS is supposed to explain the "how" to meet the CP's "what", but that isn't always followed in a clear way.

Definitely, the call is for Ben/Kathleen, so I'll N-I Ben here, but I'm personally comfortable as closing this as WontFix/Invalid, with an agreement that the confusion seems to have been addressed by the updated language, and that this might be something worth nailing down more in MRSP in the future (i.e. explicitly stating the CP needs to include these details, so that we have at least a consistent place to look for the necessary information)

Comment 10

[Ben Wilson]

I have created an issue in the Github repository to track this ambiguity in "CP/CPS" to resolution in the MRSP. See https://github.com/mozilla/pkipolicy/issues/227. I think this can be closed as INVALID based on the ambiguity presented by the use of "CP/CPS" in section 2.2 of the MRSP.