On Thu, Jul 13, 2017 at 7:13 PM, Jeremy Rowley <[email protected]> wrote: > Why tell the CA that their Subscriber was compromised, rather than the > Subscriber themselves? Alternatively, if the Subscriber _is_ compromised, then > it's absolutely the correct incentive for the researcher to report this > directly to the CA, so that Relying Parties are not mislead, regardless of > what steps the Subscriber steps. > > [JR] We often get involved directly with our customers on the certificate > management and deployment-side. Thinking of the CA as only the certificate > manufacture undervalues the services some CAs provide. Forcing CAs out of the > advisory role and solely into the issuance role eliminates a lot of the value > provided. Therefore, we would like to get involved early in the process with > both the researchers and the Subscribers to advise on all PKI issues. > Although subscribers have an obligation under the agreement to report > certificate issues, we know this doesn't always happen. Take Heartbleed for > example. We received minimal prior notification of the event. However, when > the event was announced, we released a tool that detected certificate > impacted. With advanced notice, we can assist customers in navigating both > industry and internal events.
I'm sure you can understand, however, that having the CA in the advisory role and the issuance role creates a perverse incentive, in which they're aligned to the issuance and non-revocation of certificates. This is because the relationship is with the site operator, not relying parties, and as such, there's a strong incentive to align with the local incentives of the site operators, rather than those of relying parties or the overall ecosystem. SHA-1 is an excellent example of how these incentives play out - to the harm of users and the overall ecosystem. I still struggle to find the issue with timely and prompt revocation, but I do hope you can see the overall negative effect if relying parties no longer have assurances that the information from CAs in accurate and trustworthy, which is what this level of flexibility and discretion would ultimately result in. >> For non-public issues, I'd rather work with the customers earlier than wait >> to be brought in until 24 hours before the revocation occurs. > > Could you explain or provide an example of this? As the CA - a service > provider role - naturally being brought in the end of a customer-impacting > issue is the right way to handle it. > [JR] There's a consulting role involved as well as a certificate issuance > role. Many of our customers approach us with questions on the use of PKI and > best practices. Heartbleed is an example. We'd like to remain a consultant in > the framework. Another consideration is the CA is easy for a researcher to > contact and report issues to. We have dedicated emails and personnel who > handle these issues. For example, Hanno emailed me directly about compromised > private keys. I have no problem with this. To my knowledge, he did not reach > out to the subscribers themselves. I also have no problem with this. As the > CA, we generally are the ones helping our customers with the certificate > needs, including helping them through the revocation process. Well, as the CA, isn't your duty first and foremost to ensure the information attested in honest and accurate? In the case of DV, this is primarily about ensuring the binding between the key and domain (hence the deprecation of "any equivalent method"), and in the case of OV/EV, it's an obligation to ensure that all the secondary information attested is both correct _and_ was obtained via the allowed means (that is, it's active misissuance if the information is correct, but was obtained via improper means). I can totally understand the desire, as a business, to be customer oriented, but first and foremost the duty of the CA is to be a trustworthy binder of keys and identities, and that means serving the larger Relying Party population before serving any customers. I hope that's not controversial to state the priorities in that order. >> Could we balance the issue to say within 24 hours of public disclosure or >> within two weeks of receiving a certificate problem report where the CA >> confirms that one of the reasons under Section 4? > > When we past discussed this, my understanding of the conclusion was that the > CA would be afforded up to two weeks to investigate the problem report (with > the requirement additional details about why the delay occurred being made > public), but that upon determining it met one of the revocation reasons, was > obligated to make the timely revocation under 4.9.1.1/4.9.1.2. > [JR] What if the certificate was deployed to 1000+ servers? If the private key > is not disclosed, but there is a need to revoke, giving them time to manage > the revocation minimizes the impact on relying parties. I generally don't need > two weeks to investigate the problem. What I need is two weeks to migrate the > customer to a better practice, which is then followed by revocation. > > If I understand your proposal, it would be that if a CA determines the > Subscriber (or Subordinate CA) meets the requirements of 4.9.1.1, they could > still delay for up to two weeks before revoking, is that correct? > > [JR] Sort of - I propose 4.9.1.1(1) and 4.9.1.1(2) (and corresponding sections > under 4.9.2.2) require revocation within 24 hours. In both cases, the customer > requested revocation. That really should be immediate. What I'm proposing is > the CA could delay two weeks for things like a subscriber agreement breach or > if certificate information changes (such as a change in address). Well, we either believe this information is valuable and worthwhile to Relying Parties - in which case, at all points, we should strive to maintain its accuracy - or we believe it is not useful to Relying Parties, and we should seek to forbid CAs from introducing information, such as addresses, that may mislead them. I'm not sure that we can both have and eat our certificate cake - if we want the bindings to be used, they need to be timely and accurate. If we don't believe the bindings need to be timely and accurate, we should not allow them to be added. > How does that benefit Relying Parties? > [JR] It prevents critical systems from being shut off before the server > operator can migrate to a new certificate. It's an attempt to balance risk of > misuses (a non-public event is less risky) with the desire to keep all > infrastructure secured. The result of revocation is usually a move to no > encryption rather than some new encryption - especially if revocation was for > something like a change in address. I don't believe we should weaken revocation to address this issue. That is, even as proposed, a server operator still must be prepared to rotate certificates within 24 hours under certain circumstances. So really, we should be focusing on making it easier for server operators to perform such rotations - and year round, so that we don't fall into the trap of holiday freezes, and can instead let robust automated systems do the work. I have trouble with the argument that non-public events are less risky - that seems to be arguing security through obscurity - but perhaps I've misunderstood your point. In some ways, you seem to be arguing that the status quo is good - that hand-installed certificates or manual difficulties with revocation are desirable properties to support - but shouldn't we, as an industry, instead hold to the principles (that the binding in a certificate is worthwhile and meaningful), and help the industry understand and adapt to that, rather than weaken the security afforded in order to accommodate those who otherwise lack incentive to invest in sufficient security? _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
