[cabfpub] Ballot 161 - Notification of incorrect issuance

[Ryan Sleevi]

On Thu, Feb 4, 2016 at 9:34 AM, Doug Beattie <doug.beattie at globalsign.com>
wrote:

>
> >> On Wed, Feb 3, 2016 at 5:07 PM, Rick Andrews <Rick_Andrews at symantec.com>
> wrote:
> >> In summary, Symantec can’t support this ballot. Symantec instead
> recommends adoption of a
> >> new ballot that would require all publicly trusted CAs to log all their
> issued certificates in
> >> accordance with the Google EV/CT Plan. This requirement should provide
> CAs a reasonable
> >> amount of time to complete implementation, and to address privacy
> concerns, Symantec
> >> further recommends that all certificates be logged in
> 6962-bis-compliant CT log servers.
>
> > Given that no 6962-bis-compliant CT log servers exist, and 6962-bis
> continues to be
> > worked on as the lessons learned from CT are applied, what timeframe do
> you see as
> > reasonable? While it's understandable that Symantec is expected to
> comply with this
> > policy in four months, regardless of the status of 6962-bis, it would be
> helpful to know
> > what you believe is reasonable.
>
> GlobalSign endorses the plan presented by Rick and we would be ready to
> support a mandatory CT effective date of December 1, 2016 for compliance
> with the Google EV/CT Plan for all SSL certificates, provided 6962-bis is
> approved at least 4 months prior to this date and there are a sufficient
> number of CT logs to use with this updated RFC.  We would support earlier,
> interim dates for mandatory posting all DV certificates to CT logs post
> issuance (without included SCTs).  While this isn’t necessarily compliant
> with the Google EV/CT plan, it would improve transparency sooner and define
> a phased plan.
>
> We would also support the use of CAA to flag orders for manual review to
> further strengthen issuance processes with pre-issuance checks to
> supplement CT logging by December 1, 2016.
>

Doug, Rick,

While I find your endorsement of CT quite welcome, I do think they serve
separate purposes and goals. When it comes to a mandatory CT effective
date, we at Google have been incredibly sensitive to the needs of both CAs
and other browsers, to develop both consensus and experience with.

In what may or may not come as a surprise, I do not believe the Google
EV/CT plan is appropriate for the CA/B Forum. For example, the policy
presently requires disclosure in a Google log, and a quorum of
Google-recognized logs. While this unquestionably serves the interest of
Chrome's user base, it understandably is more problematic when you consider
an organization such as Mozilla or Microsoft. The disclosure requirement
within a Google log is, itself, an artifact of CT support continuing to
grow, but not yet fully fleshed out and finalized. That is, the handling of
SCTs and gossip and the cryptographic proof and detection of log
malfeasance is still at its early infancy, and a diverse set of
stakeholders are working through this, both in the IETF and at Google, on
how best to balance these needs.

Similarly, while the Chrome CT policy provides a framework for CT policies,
I would be remiss if I did not highlight that there are still multiple
deficiencies that we think limit it from being acceptable as a uniform
standard. For example, consider the recent example of Symantec, Comodo, and
several other CAs to discontinue participation in root programs, but not
discontinue issuance. This creates an interesting scenario for log
operators and monitors, which has yet to be fully resolved. That is, log
operators are interested with and concerned with preventing log spam, which
can not only disrupt log operations but also affect the ability of auditors
and monitors from making timely use of the log information. Yet
certificates from these "discontinued" (which seems an improper word, given
they're actively being used for issuance) roots may be used for spam
purposes, especially since the CAs have made it clear they no longer intend
to abide by the Baseline Requirements, in spirit or practice. Or consider
the impact upon monitors - monitors are now tasked with understanding the
nuance that a certificate issued from a Symantec CA, which, by all rights
would be considered "misissued" under the Baseline Requirements, is not
misissued in the view of Symantec. If a monitor alerts on that, they run
the risk of creating significant false positives, but if they don't, they
run the risk of missing real security risks. Similarly, a log operator that
decided to reject logging of certificates from these roots could also end
up masking misissuance.

Of course, there's also the more simple problem - if getting a BR audit
requires getting accepted by a log, but getting accepted by a log requires
a BR audit, you have a conundrum not easily resolved.

Finally, name redaction will still require time to work out on the
appropriate and acceptable policies, and from conversations, and from your
own suggestion, seem a key requirement. This is why Google has not been
pushing CT for DV aggressively. These are all part of the planned rollout,
these are problems which we did not view as critical to resolving prior to
EV adoption, and some are problems we didn't anticipate, but left ourselves
ample runway for.

Now certainly, one could suggest an alternative, which is simply that
certificates must be logged "somewhere." That's a proposal that had been
put forward in the Forum in the past. But that has a whole host of new
problems - no guarantees the logs are well-behaved, no guarantees the logs
are accessible, logs adopting policies that browsers would likely reject
(such as redacting to the point of "?.com"), and of course, the complexity
of standing up new logs to accommodate the CA's obligation.

The proposal - from you and from Rick - is I think far more aggressive than
needed, though exciting in its end goal, and would still leave significant
gaps in accountability and responsibility, potentially giving a year (or
more) of "undisclosed misissuance". While we absolutely remain committed to
CT, I hope you can see how Sigbjorn's proposal is a meaningful, small step
in the right direction towards greater transparency and accountability. The
impact is limited to that of misissuance, which in an ideal world, would
never happen, and so the risks would be minimal.

We should still progress with CT, but for the time being, I'm not
supportive of a mandate requiring it, as I've clarified several times in
past meetings.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160204/ee9cff3e/attachment-0003.html>