Subject: Re: [pkix] An alternative proposal Was: Fwd: New Version

From: "Kyle Hamilton" <[email-masked]>
Date: Fri, 11 Nov 2011 16:21:39 -0800 (Pacific Standard Time)

On Thu, Nov 3, 2011 at 5:35 AM, Miller, Timothy J. <[email-masked]> wrote:
> On 11/3/11 4:22 AM, "Kyle Hamilton" <[email-masked]> wrote:
>
>>Have a self-signed certificate which contains everything -- not just one
>>certificate chain, but several certificate chains.  Not just one OCSP
>>response, but several OCSP responses.  Not just one timestamp, but
>>several timestamps.  Have provable signature chains, all of which end up
>>signing the self-certified key inside a certificate extension, which
>>self-certified key is used to authenticate TLS.  If any one of those
>>identity chains is trusted, then the ownership of the key can in fact be
>>determined and the connection meets browser https standards.
>
> Color me confused, but how is this different from SPKI delegation?
> Wouldn't that be simpler?

SPKI delegation only permits one authority, one root.

The structure I propose can do that and much more.  It permits simultaneous delegation from multiple PKI roots and authorities, and contains every OCSP response necessary for every certificate in each of those chains.

The idea is to allow businesses to give multiple certificate chains from multiple roots, any of which may or may not be trusted by the client.  In this way, CAs which are currently too big to be allowed to fail will no longer have a stranglehold on the browsers' inclusion policies.

-Kyle H

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 14 Nov 2011 01:47:38 +0000

>SPKI delegation only permits one authority, one root.

Um, WTF?  SPKI delegation is completely open.  I can delegate to as many
sub-keys as I choose, or have my key delegated to by as many authorities
as I need.  

What SPKI *doesn't* do is shove them all into a single data structure.
But so what?

-- T