[Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

[Bruce Morton]

Hi Ryan,

My understanding was that the ballot was being proposed as it has been determined that there is a problem with how some CAs are currently status is provided for precertificates. I agree that this needs to be fixed. I brought up the issue as the ballot does not provide significant time for a CA to fix the problem if they have the problem.

If this ballot was proposed similar to ballot SC21 which stated “to be EFFECTIVE ninety (90) days after completion of the IPR Review Period”, then there would probably have been no discussion.

Bruce.

From: Ryan Sleevi <sleevi at google.com>
Sent: Tuesday, October 8, 2019 6:01 PM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates



On Tue, Oct 8, 2019 at 5:40 PM Bruce Morton <Bruce.Morton at entrustdatacard.com<mailto:Bruce.Morton at entrustdatacard.com>> wrote:
Hi Ryan,

Entrust Datacard supports the intent of the ballot; however, we are asking that the ballot provide a reasonable time to implement.

I don’t think that the IP review period should be considered working time. My thinking is that the IP review period is to help organizations protect their IP. I don’t think the CAB Forum should count on the CAs to develop changes during a period where the ballot may be revoked.

In general, I would agree with this. However, just to make sure it's clear: You're asserting that there is an IP risk over the OCSP RFC itself. I think that's a fairly significant claim, and why we should evaluate each request for delay individually, rather than treating it as a general rule.

It has been suggested that ballots should include a period to allow the CAs to implement changes, both technical and procedural, and also allow effective testing as required. I do not think that 30 days as a default would be sufficient.

I think it's useful, specific to this Ballot, if you could enumerate the changes you anticipate. This is helpful in understanding the impact, intended or unattended, in changes.

Again, the issue is not with the general suggestion of this idea; it's about providing concrete data that helps better inform and build a collaborative approach. The proposed Ballot here is clarifying something that was discussed when the original Ballot was introduced, and correcting an issue of interpretation that was flagged as being problematic when the ballot was proposed.

It might be that Entrust doesn't know the impact; it could already be compliant with this requirement, but doesn't know until it looks. This should be trivial to determine: are you providing OCSP services for all serial-numbers Entrust has assigned? It already has to track the serial numbers it has assigned, to prevent duplicate serial number use, so this should not require the existence of additional data.

We know that common off-the-shelf and bespoke systems are already prepared. This only requires examining your serial number database and ensuring that you have OCSP responses provided for all serial numbers, regardless of the actual issuance of certificates. If that's a complex undertaking, it's incredibly useful to understand about that system architecture, so that we can both learn from it, understand the considerations, offer suggestions to mitigate delays, or learn from the ecosystem about how other CAs are approaching. This collaborative approach to sharing challenges helps the industry evolve, and that's why it's useful to share data, and not just requests for delays.

We should also consider that BR changes may impact all CA members and non-members such as third party subCAs, so the effectivity period should consider communication time. Finally, the effectivity period should consider the blackout period which occurs towards the end of the year.

Could you provide the Blackout Dates implemented by Entrust, and all of its sub-CAs, for the entire year? This is data that helps us build a better understanding about the request, and develop better ballots.

As it relates to Sub-CAs, I disagree that the existence of third-party sub-CAs should be a reason to delay. If anything, it should be a highlight of the risk of third-party sub-CAs, and why Root CAs should limit their issuance of them. They're an example of an internalized benefit (the CA gets the money from issuing them) while an externalized risk (the ecosystem is slowed to the slowest moving sub-CA). The best way to inform that risk/benefit trade-off would be to similarly share data from your sub-CAs.

I don’t think that 6 months should not be considered a long time. The effectivity period should allow CAs to address this type of change as a non-emergency issue. The period should allow proper design implementation and testing. The period should allow most CAs to be complete in a comfortable period before the deadline. In essence all CAs may not need 6 months, but I see no reason for CAs to implement in a blackout period or suffer the risk of being non-compliant for this type of issue.

Just to clarify: This is a clarification of an existing expectation of Root Stores, resulting from a poorly worded requirement added to the Baseline Requirements, which was noted back when it was proposed that this would not replace expectations of Root Stores. So the question of compliance/non-compliance is largely moot.

Regarding the security of users, I think that the CAs have addressed this issue with CT logging. Although the BRs do not require CT, the CAs support CT. Although the BRs do not require precertificates, most CAs issue precertificates. Unfortunately, the BRs state that a precertificate “shall not be considered to be a “certificate” subject to the requirements of RFC 5280.” My assumption is that this statement may just be a symptom of the problem that there has been misinterpretation as to how to provide the status of a precertificate. I assume this problem dates back to when we deployed CT at the start of 2015. However, since a precertificate has a poison extension, the risks to users of not knowing its status appears to be extremely limited.

No, this problem dates to problematic language introduced by Kirk Hall, then at Trend Micro, in Ballot 134. There was significant discussion about this issue on the list, particularly arising from the issue that the language could be abused by CAs to suggest that precertificates were not proof of equivalent issuance, or that they would confuse the expectations about the services provided. There was significant discussion on the list, which was part of the discussion Wayne referenced, and you'll find folks proposed language very similar to what Wayne is providing now, back then. The more precise language aligns the expectations that have been long-standing and are not changing here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191009/fce33a6a/attachment.html>