[cabfpub] Misissuance of certificates
sigbjorn at opera.com
Wed Nov 11 11:55:06 UTC 2015
Dean, Phillip, Iñigo,
Happy to see the discussion pick up :)
On 09.11.2015 14:29, Dean Coclin wrote:
> You made a statement in another email which, if I'm remembering correctly, said something like this: If a cert is issued from a public root, for public domains, for use by the public, then its contents is automatically public.
The contents are automatically of public interest, even if they are not
public. In common scenarios, there may be reasons not to publicize all
(e.g. name redaction), but in the event of a misissuance, the contents
are an exception, especially worthy of public interest and publication.
> Also, I think Inigo raised some privacy concerns that may make the above a violation of local laws. Your text below doesn't address that. That may be problematic for a 1 week timeline, especially if there are many domain owners that need to be consulted.
It is  unlikely that this would violate local laws. If this were to
be illegal, the CA would be faced with a choice: Violate the local law
by publishing the certificate and face legal repercussions, or violate
the BR and face root store repercussions. Note that the CA has already
violated the BRs once, and that a BR violation does not automatically
mean root store expulsion. What the proposed text does is put the burden
of proof on the CA, to convince any root stores that publishing the
contents are illegal, and the CA should not be punished from withholding
some of the contents.
Consulting the domain owners is unrelated, and does not change the law.
If need be, make a statement in the subscriber contract that details may
have to be disclosed, and the consultation then changes nothing.
> In the future, when name redaction is allowed for OV/DV, publishing the full certificate negates the value of name redaction. So for example, consider a case where the cert was issued to the right recipient, but the misissuance was the addition of a misleading OU field, or a "MUST INCLUDE" extension is omitted. The proposal would force CAs to reveal the redacted names.
Yes. That is a good thing. The subscriber expects the CA to carefully
handle its confidential data. If the CA fails to do this, notification
of this is important. This will allow subscribers to carefully choose
which CA they want to do business with, taking into consideration past
behaviour. This will increase transparency and competition among CAs,
rewarding the more secure CAs, which I presume is something we all want.
This proposal would force CAs to be more diligent in certificate
issuance, with real repercussions for CAs which fail to do so.
In extreme cases, note that the CA has the option not to disclose, just
as above. It is unlikely that root store operators would be as
sympathetic in this case, as the above one.
On 09.11.2015 19:38, Phillip Hallam-Baker wrote:
> But it is quite possible to imagine circumstances in which the
> certificate has not become public and the attacker only has the
> key. I do not think we want to adopt rules that require a remediation
> process that allows the attacker to complete their attack.
So you are saying the scenario is that the CA has A) misissued a
certificate, and B) lost control of the private key and C) states that
it still has control of the public key, correct?
First of all, many people would not trust the C) statement, and this
industry requires trust to operate, so taking that statement at face
value is a no-starter.
Second, in this case, the CA would still be obliged to revoke the
certificate. This means publishing the serial number and the public key
for e.g. browsers being able to blacklist it. These are the only random
values in the certificate, and the rest of them can be guessed. So for
any motivated attacker, they can already generate the public
certificate. Keeping it secret protects nobody.
> That is as may be but what does seeing the actual certificate help?
> I can’t see anything that is actually gained by putting a certificate
> into public circulation.
This proposal has several benefits, and publication is key to that:
* Openness and transparency benefits the industry at large, in
particular in getting the public to trust it.
* Full details allows researchers to look for patterns and find weak
spots, or tempting targets.
* It allows e.g. browsers to implement targeted protections.
* It allows stakeholders to better understand what happened, and ask
relevant follow-up questions.
* It allows CAs to learn from each other, which will strengthen the
* It gives CAs a real incentive to avoid misissuance.
* It gives subscribers a way to check on CAs past history.
* It gives subscribers an incentive to pick secure CAs over cheap CAs.
On 10.11.2015 10:01, "Barreira Iglesias, Iñigo" wrote:
> I can make a report of what I did wrong technically and explain the
> whole world my fault but if the issue was related to some “private”
> information of the company that I didn´t do correctly, and I´m afraid
> can´t publish/mention that information in the report because I can be
> accused/sue by that company.
The company trusts the CA to handle its confidential information
securely. If the CA then doesn't do this, the company has every right to
be angry, regardless of the certificates being published or not. If it
has the right to sue or not would depend on the subscriber contract. The
CA will face a similar choice as above: Publish and face company
repercussions, or withhold and face root store repercussions. The CA has
messed up by not handling the confidential information properly, I don't
see why the CA should be immune from repercussions of this.
Companies, and the Web PKI at large, would want to avoid insecure CAs.
In the long run, the community is best served by having a CA focus on
avoiding misissuance, which this would ensure.
> OTOH, I wonder if this is only about this particular issue, the
> mis-issuance of certificates, or can be in a wider proposal, about
> any security breach, having in mind this is a security breach.
I would certainly be for this. Defining a "security breach" is slightly
harder than defining a "BR violation" though, and might require some
more discussions. My proposal could certainly be amended from
"In the event that a CA issues a certificate in violation of these
"In the event that a CA violates these requirements", to cover also
If the ENISA procedure makes sense, we could implement that as part of
However, to keep the discussion focused, I suggest we keep it simple at
first. If wanted, it is easy enough to expand the scope later.
 The local laws Iñigo refers to are privacy laws in Europe. Privacy
is related to information identifying an individual. Company information
and domain names are not privacy related.
More information about the Public