[cabfpub] Misissuance of certificates

[Sigbjørn Vik]

Dean, Phillip, Iñigo,

Happy to see the discussion pick up :)
Replies inline.

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 [1] 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
 > private
 > 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 
overall industry.
* 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
 > I
 > 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
requirements"
to
"In the event that a CA violates these requirements", to cover also 
non-issuance events.
If the ENISA procedure makes sense, we could implement that as part of 
the BRs.

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.


[1] 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.

-- 
Sigbjørn Vik
Opera Software