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

It is always a mistake to imagine that political outcomes are the
product of rational analysis rather than the respective power
relationships and constraints.

For Google, the risk of consequences due to CA breach are arguably
higher than the consequences of end-entity breach which they have
controlled through shifting liability onto the CAs. But for the
typical Internet user, the risk due to end-entity breach is higher.

I didn't say we shouldn't do CT, what I said is that we have to make
revocation an equal priority.

Checkpointing revocation information in CT makes great sense for all concerned.

Had Harber-Stornetta catenate certificates been available on equitable
terms prior to the expiry of the patent we would probably have done
something like CT years ago. The reason we didn't do revocation before
was that we did not develop a technology that the browser providers
considered acceptable. And then we spend ten years trying to persuade
them that up was down rather than fixing the problem.

Not trying to assign blame here, I should have arrived at this
analysis ten years ago.

On Mon, Nov 17, 2014 at 12:07 PM, Trevor Freeman
<trevor.freeman99@icloud.com> wrote:
> 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
> <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
>
> therightkey@ietf.org
>
> https://www.ietf.org/mailman/listinfo/therightkey