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

Ryan Sleevi sleevi at google.com
Tue Oct 8 15:00:59 MST 2019

On Tue, Oct 8, 2019 at 5:40 PM Bruce Morton <
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/20191008/6fc0ada0/attachment.html>

More information about the Servercert-wg mailing list