[cabfpub] Misissuance of certificates

[Ryan Sleevi]

On Mon, Nov 9, 2015 at 10:38 AM, Phillip Hallam-Baker <philliph at comodo.com>
wrote:

>
> On Nov 9, 2015, at 9:16 AM, Ryan Sleevi <sleevi at google.com> wrote:
>
>
>
> On Mon, Nov 9, 2015 at 5:29 AM, Dean Coclin <Dean_Coclin at symantec.com>
> wrote:
>
>> Sig,
>>
>> 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.
>>
>
> If a cert transitively chains to a publicly trusted root, it should be
> public, technically constrained subordinate CA notwithstanding.
>
>
> I disagree.
>
> When we had the Iranian folk attack our affiliate, we had the following
> sequence of events.
>
> * Attacker generated keypairs and requested issue of 7 certificates.
> * 7 certificates were issued and released to the affiliate
> * Attacker downloaded one of the certificates via the logged API
>
> 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"

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 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)


> 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 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151109/abd5a762/attachment.html