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

Obviously more that you think otherwise folks would not be working on CTJ

-----Original Message-----
From: therightkey [mailto:therightkey-bounces@ietf.org] On Behalf Of Phillip
Hallam-Baker
Sent: Sunday, November 16, 2014 12:30 PM
To: Trevor Freeman
Cc: Massimiliano Pala; therightkey@ietf.org
Subject: Re: [therightkey] [pkix] Proposal for working on PKIX revocation
open issues

On Sun, Nov 16, 2014 at 1:53 PM, Trevor Freeman <
<mailto:trevor.freeman99@icloud.com> trevor.freeman99@icloud.com> 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 :)

_______________________________________________

therightkey mailing list

 <mailto:therightkey@ietf.org> therightkey@ietf.org

 <https://www.ietf.org/mailman/listinfo/therightkey>
https://www.ietf.org/mailman/listinfo/therightkey