[cabfpub] Ballot 161 - Notification of incorrect issuance
sigbjorn at opera.com
Fri Feb 5 19:36:12 UTC 2016
Responses to Rick, Iñigo and Doug below.
On 04.02.2016 02:07, Rick Andrews wrote:
> Some customers do not want information related to these private certificates to be publicly disclosed and they may not be aware that this ballot could lead to such disclosure. Further, the ballot does not include a process or timeframe to allow these customers to replace their existing private certificates where needed.
Then you have missed the part in the ballot where existing certificates
are exempt from parts of the reporting.
> We think the ballot also fails to consider important security concerns related to rapid publication of the underlying causes of mis-issued certificates. The ballot could be interpreted to require a CA to publicize a mis-issued certificate and its root cause potentially before it has time to remediate a technical issue that led to the mis-issuance, perhaps allowing others to exploit a technical flaw.
The ballot will give CAs one week before sending a report. If the CA
cannot fix the issue in this time, it could stop issuing certificates
(and probably should, if it has exploitable security issues in the
issuance process, it shouldn't issue certificates), or at least flag
relevant certificates for manual vetting. To stop issuance, or flag some
certificates for manual vetting, can easily be done in a week.
On 29.01.2016 13:45, "Barreira Iglesias, Iñigo" wrote:
> So, I´m not against of the goal of this proposal but as an EU CA I´m
> not developing two procedures for the same issue, so I´d like to have
> the option to just have one and use it, and inform the CABF, the
> browsers or whoever using the same procedure and if possible, the
> same tool.
That is already supported in the ballot. The ballot lies no restrictions
on the reporting format. It says it must contain some minimal
information, must be public, and that a link be sent to an email
address. The report itself can easily be the exact same as sent
elsewhere. You do not need two reporting tools.
On 05.02.2016 12:50, Doug Beattie wrote:
> For real misissuance when a certificate was falsely approved or a bug
exploited to receive a certificate, sure, I have no issue with that. But
if the reporting needs to include typos, the improper encoding of a
field, minor non-compliance with referenced specs like RFC5280 then no,
this is not something I can support.
Typos, encodings and minor non-compliance can all hide serious issues.
What if a subscriber abused lax CA vetting to get a certificate for a
company with a similar name?
Some years ago, a minor non-compliance was discovered, which posed a
serious security threat. Null characters were allowed by some CAs into
certain fields, making browsers and CAs disagree on which sites the
certificates were for.
> The CABF would be flooded with irrelevant notices of misissuance
which would make it harder to understand the real ones.
It is easy to write a tool to filter the issues. Statistics over all
issues makes it a lot easier to understand the real issues, including
those issues which only in retrospect are important. A flooding of
notices is certainly preferable to no notices at all, as is the current
> CAs need to think hard about voting for this ballot because the
increased scope of misissuance will lead to increased WT audit findings
So what you are saying is that if auditors actually knew about all the
misissuances that happen, CAs would drown in work. And that to avoid
drowning in work, they should vote against this, so auditors won't know
about the mistakes?
Note that the scope of misissuance is not changed in any way by this ballot.
More information about the Public