Obviously more that you think otherwise folks would not be working on CTJ
-----Original Message----- From: therightkey [mailto:therightkey-boun...@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.freema...@icloud.com> trevor.freema...@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
_______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey