[cabfpub] Ballot 100: Extend Deadline - OCSP Good Response

[Brian Smith]

Steve Roylance wrote:
> We know that Microsoft CA 2003 will not be compatible as OCSP was
> only introduced with Server 2008. So SubCAs that use this need to
> upgrade to get OCSP at all, never mind about OCSP database based
> responses. But even if they upgrade to Server 2008, or 2008R2,
> or 2013 then ADCS doesn't yet support database based OCSP responses.
> This list alone represents a large %age of the community out there.
> Tag on to that the fact that EJBC and Corestreet don't support and
> you end up with quite a few who need to take action. I happen to
> know Ascertia supports but don't know about Entrust yet.

I think it is fine for the affected external sub-CAs to get an exception from this requirement if and only if they are name constrained to domains that they are in control of, as described in item #8 the Mozilla CA Inclusion Policy:

    http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

Name constraints would be a reasonable way to solve the problem because the name constraints will ensure that the sub-CAs can only hurt themselves (assuming the unconstrained certificates are revoked in an effective way) and their users/customers, without requiring any modifications by PKI server vendors.

I think it would be very bad to predicate any change in the baseline requirements on whether or not any particular vendor's server-side software supports the functionality needed to comply with the requirement. Every CA (including often external sub-CAs) needs to be able to make substantial technical changes, including implementing not-yet-standardized features, given *months* of notice, not *years* of notice. (Sub-)CAs need to implement their infrastructure and choose vendors in a way that makes it reasonable for them to meet deadlines. And, CAs that issue external sub-CA certificates need to give their customers enough notice for their customers to get into compliance on time. Getting into compliance may often mean switching software stacks.

We (Mozilla) have already heard from a few CAs that many of their customers have switched from running their own in-house sub-CA to managed systems in the last year or so. It seems customers using those solutions will meeting the requirement thanks to the work of the CA managing the infrastructure. Comodo has offered another way to get into compliance with this requirement specifically. Both of these options, along with actually actually complying with the requirement and/or adding name constraints for sub-CAs, are moving things in the right direction.

Based on the availability of these options, and the amount of lead time everybody was given (and the amount of lead time still left!), nobody should be considered to be unable to meet the requirement on time--only unwilling. Being unwilling to meet this requirement is evidence that the (sub-)CA won't be willing to try to meet future deadlines on time. I would consider it strong evidence, in general, that the (sub-)CA does not respect the work that this group is doing to improve the trustworthiness of this system, and that the (sub-)CA is not fit to operate in an unconstrained manner. So, extending the deadline to accommodate such CAs would be moving in the wrong direction.

With all that in mind, I suggest we scrap this ballot. If an exemption or extension is necessary, then let's create a new ballot that exempts (or extends the deadline for) only name-constrained (as described in Mozilla's policy) sub-CAs.

Cheers,
Brian