[cabfpub] Misissuance of certificates

[Sigbjørn Vik]

On 01-Dec-15 19:10, Rick Andrews wrote:
> 1. Define one or more ways in which CAs will distinguish publicly used certificates from internally used certificates (Ex. use designated intermediate CAs or designated root CAs for internal-only used certificates).

We could presumably remove the requirement for certificates issued by
technically constrained intermediate certificates. If the intermediate
itself was incorrectly issued, details would have to be released, but if
certificates issued from it were incorrect, some details could be left
out. Would that take care of your use case?

Note that the CA could operate the technically constrained intermediate
on behalf of the customer, the customer does not need to run such
services on their own. This also means a report would need to publish
the full chain, as the technically constrained intermediate might
otherwise not be public knowledge.

> 2. Define an implementation date following which newly issued internal-only certificates would be distinguished per above and/or customers are aware of how these new rules relate to the future disclosure of publicly-accessible certificates.
> 
> 3. Define the specific certificate details that must be disclosed before and after that implementation date:
> 	A. For certificates issued prior to the implementation date, all end-entity certificate details EXCLUDING Subject Distinguished Name fields and subjectAltName extension values.
> 	B. For certificates issued after the implementation date, all entity certificate details for the CAs used for publicly accessible certificates.

Agreed, dates needs clarification. Having the strictest rules only for
certificates issued after a certain date is fine if it will aid adoption
of the ballot.

Another issue which also needs clarification is how to notify the
CABForum. Sending an email to public at cabforum was intended to be an easy
way to ensure a minimal public notification, but that email address is
not open for all. So we need some clarification there. Maybe send a mail
to the cabforum chair who will forward, or some other solution.

A reworded proposal would then be e.g.:

====
2.2.1 Information of incorrect issuance

In the event that a CA issues a certificate in violation of these
requirements, the CA SHALL publicly disclose a report within one week of
becoming aware of the violation.

public at cabforum.org SHALL be informed about the report, if the CA cannot
post directly, it SHALL inform the CA/B Forum chair who SHALL inform the
list.

The report SHALL include details about what the error was, what caused
the error, time of issuance and discovery, and public certificates for
all issuer certificates in the trust chain.

The report SHALL contain the full public certificate, with the following
exceptions:
a) For certificates issued prior to 01-Mar-16 the report MAY leave out
Subject Distinguished Name fields and subjectAltName extension values.
b) For certificates issued from a Technically Constrained Subordinate CA
Certificate,  the report MAY leave out Subject Distinguished Name fields
or subjectAltName extension values, which match a dnsName in the issuer.

The report SHALL be made available to the CAs Qualified Auditor for the
next Audit Report.
===

(Still waiting for minutes from the phone conference discussion to see
if there are any other concerns.)


> 
> With respect to the concerns about CT, we continue to favor name redaction as the way to protect the privacy rights of customers and as a preferred option vs. opt-out.
> 
> -Rick
> 
> -----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 3: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