[cabfpub] Misissuance of certificates

[Phillip Hallam-Baker]

> On Nov 9, 2015, at 11:01 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Mon, Nov 9, 2015 at 10:38 AM, Phillip Hallam-Baker <philliph at comodo.com <mailto:philliph at comodo.com>>wrote:
> 
> Given the circumstances we were forced to assume that the attacker had all seven certificates and later we released the certificates as it turned out these would be necessary to block them in some cases. That was probably the right response in those particular circumstances.
> 
> While the facts and description surrounding the past event are not something I'm calling into question, I do think situations such as Diginotar, India CCA, and, more recently, Symantec, call into question whether or not the CA is in a good place to reasonably and reliably assure the public that "Attacker downloaded only one of the certificates”

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.



> While in theory, it is possible, the nature of both attacks and systemic failures are such that I take the point of view that we MUST assume the attacker has full control over all the certificates, has received them (if they were signed), and we must take appropriate action under that assumption.

I agree we must assume the attacker has full control for purposes of response but I don’t see the need to give the attacker full control if there is a good chance they haven’t got it already.

One should always assume that a gun is loaded. But that doesn’t mean you should always keep the gun loaded.


> I strongly believe that the mitigation for such solutions is not to embrace the notion of 'privacy' as means to avoiding transparency and disclosure. Instead, we can and should work to make the revocation system a more reliable system (and while I realize this may invite opportunities for Omnibroker evangelism, I'm more speaking about OCSP must-staple, short-lived certificates, etc)

Omnibroker still requires revocation, its just a change in where that is processed :)

How about compressed CRLs :) :)


> As far as I am concerned, we want to consider ‘issue’ of a certificate to occur when it is signed for purposes of the BRs. But the attacker can’t use a mis-issued certificate until publication. So these are actually two distinct events as far as response goes.
> 
> While they may be disjoint, my above remarks are meant to call into serious question whether or not anyone - CA or otherwise - can really make a qualified assertion that publication has not directly or indirectly happened. The continued - and, unfortunately, recent - failures in the CA ecosystem calls into question the ability for CAs to make analysis about the scope of impact or of breach, and considering how serious such a miscalculation can be, I feel we MUST treat them as the same.

I think we need to treat them as equivalent in severity and different for the purpose of planning remediation.


>  
> I don’t think we should assume CT is going to work in one particular way either. When we get into CFRG ECC signed certificates and short lived certs, some interesting new options open up.
> 
> Indeed, but, and I realize this may go to an unrelated tangent, I don't think short-lived certs obviates or avoids CT requirements at all :)

I was referring to some of the crypto capabilities that ECC opens up and the fact that the move to the CFRG signature scheme will be a discontinuous change. 

So for example, inserting a RSA2048 signed object in an X.509 extension is probably a nonstarter. ECC sigs are rather more manageable. Rather than enrolling every short lived cert, we could enroll just a x25519 signed template and embed the sig in the cert.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151110/90792d42/attachment-0003.html>