[cabfpub] Misissuance of certificates

Dean Coclin Dean_Coclin at symantec.com
Thu Nov 12 22:45:45 UTC 2015


Here is the example mentioned on the call today which Gerv wanted to hear more about:

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/368362/set-installation.pdf

Apparently, the UK Tax authority requires  customers to obtain SSL certificates to exchange information with them. Those certificates are of the form
 	[employer tax ID].from.their.domain
 	[employer tax ID].to.their.domain
where the tax ID is all numeric.

This is a use case where people are specifically advised that getting 
a cert from a public CA is a good idea but where the contents of the 
certificate are not necessarily for public consumption.

Admittedly I haven't read this thoroughly yet but just wanted to pass it on in the context of today's call.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Sigbjørn Vik
Sent: Wednesday, November 11, 2015 6:55 AM
To: public at cabforum.org
Subject: Re: [cabfpub] Misissuance of certificates

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
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151112/f891e21b/attachment-0001.p7s>


More information about the Public mailing list