[cabfpub] Ballot 161 - Notification of incorrect issuance

[Sigbjørn Vik]

Hi,

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 
standard.

 > 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.


-- 
Sigbjørn Vik
Opera Software