Re: [pkix] An alternative proposal Was: Fwd: New Version Notification for draft-hamilton-cmr-00.txt

["Miller, Timothy J." <[e-mail]>]

On 11/3/11 8:10 AM, "Rob Stradling" <[e-mail]> wrote:

>On Thursday 03 Nov 2011 12:57:14 Miller, Timothy J. wrote:
>> On 11/3/11 7:37 AM, "Phillip Hallam-Baker" <[e-mail]> wrote:
>>>In the DigiNotar case, whitelisting could have allowed the issue to be
>> >detected much earlier.
>> 
>> Ok, how?  Give me a scenario.
>
>http://isc.sans.edu/diary.html?storyid=11512
>
>"Some of the CA servers have had parts of their logs deleted, leading to
>DigiNotar not knowing what certificates were issued."
>
>"The OCSP server's working at DigiNotar has been reversed since Sept 1st.
>Normally these servers respond with good to all certificates except those
>on 
>the CRL (a blacklist). The OCSP now operates in whitelist mode: it will
>call 
>all unknown certificates signed by DigiNotar as revoked (a whitelist).
>Hence we need to make sure to use the OCSP server to validate DigiNotar
>certificates -should we want/need to- and not rely on the published CRLs
>anymore."

This is a valid *response* strategy in the DigiNotar case because of the
specifics of the attack; switching DigiNotar's responder to whitelisting
essentially functions as a bulk revocation of everything but certs issued
prior to the compromise (which are assumed valid) without having to
positively identify those certs individually.  This is necessary because
the corrupted CA data meant that the attacker-issued certs simply can't be
identified; even given external data with which to validate an issuance,
the issuance data is missing, so revocation simply can't be done.

However, from a *pre-attack detection* standpoint, I don't see how
whitelisting helps.  The attacker corrupted the CA data for unknown
reasons; indeed, he may simply have been erasing record of the intrusion,
and cast too wide a net.  A more careful attacker may not do this, in
which case whitelisting doesn't yield a benefit as the attacker-issued
certs *are on the whitelist*.  Further, whitelisting would not be
necessary as a response in cases where the CA data is preserved because
the data to support revocation is available, as we see in Comodo's case. I
won't dispute that it may still be convenient.

What's most telling to me in the DigiNotar case is that whitelisting was
accomplished with no change to the standard or client implementation;
DigiNotar simply altered the behavior of the responder.  This tells me
that a whitelisting feature of the protocol simply isn't needed.  If you
want to run your responder as a whitelist you already have everything you
need, just plop a statement or two in your CP and/or CPS and get on with
it.

-- T