Re: [therightkey] [pkix] Proposal for working on PKIX revocation open issues

[Phillip Hallam-Baker <[e-mail]>]

On Sun, Nov 16, 2014 at 1:53 PM, Trevor Freeman
<[e-mail]> wrote:
> Hi Max,
>
> I think we first need a consensus of the unmitigated threats this work would
> look to address. That would help assess the technical options. Top of my
> list of unmitigated threats would be compromised CA issuing  user
> certificates outside of the normal process e.g. attackers use some tool to
> sign the certificate direly using the CA key so no log exists of the
> issuance.

Seriously?

How often does this happen?

How often does an administrator sell a machine without zeroing the
hard drive where a live key is stored? How often does a corrupt admin
sell a private key? How often does a machine without a TPM with a cert
get rooted?


End entity breach is a daily occurrence.

> For example, if there is consensus on that as a threat to be addressed, OCSP
> does not help much in that you want a "known to be good" assertion, not a
> "know to be bad" assertion that revocation checking provides. Certificate
> reissuance has been long been cited as an alternative to revocation in that
> you get a restatement of the goodness which is what you need, but it does
> tax the CAs. If you are targeting server validation scenarios, then a Valid
> Certificate List which was similar to CRLs but a list of good certificates
> could scale much better as Phil points out. Given we know all too well what
> does not work well with CRLs, we should be able to avoid the mistakes i.e.
> use hashs to identify certificates not issue\serial number, mandate support
> for partitions etc., etc.

I much prefer using hash based mechanisms to issuer/serial. But in a
pinch, I will use hash of the issuer/serial :)