From: Brad Templeton (brad@templetons.com)
Date: Tue Oct 16 2001 - 14:56:21 CDT
On Tue, Oct 16, 2001 at 09:45:01AM +0000, Charles Lindsey wrote:
> In <20011015124918.D10181@main.templetons.com> Brad Templeton <brad@templetons.com> writes:
> That is not the key collapse system as you have usually advocated it. I
> can see some merit in it, but it removes the possibility for the
> individual user to check the complete chain, and it places even more
> reliance on what was already the weakest link in the chain (i.e. Tale in
> your example).
I wrote of two concepts. Certificate collapse is done by the signer.
I had also briefly written of signature collapse done by hub nodes, in order
to save downstreams the trouble of checking things. This was when people,
for whatever reason, thought that signature and certificate checking was
horribly expensive.
Of course you can't have it both ways. If you want to eliminate all the
certs and leave just the signature of your feed node, you lose the audit
trail that shows you how the authentication took place. If you keep it,
you carry the bytes. You could have logs available on the web I guess.
And you could have both -- the certificate chain and a final confirmation
by your trusted upstream.
But since then I've decided just to work on getting the main system at
a basic level of efficiency, and consider full signature collapse for later.
In a way, if you are a leaf subnet, and you trust your hub (which you
certainly do today!) you could in effect not check signatures, because
your hub would never send you anything with a signature that failed to check
out. The simple existence of the signature would be evidence the hub had
cleared it, as long as you were sure (from the verified path line) that
it came from the hub and not from inside.
> Yes, the original complete key is still needed, so that suspicious minds
> can check it.
Strictly, one could imagine a system where anybody who did strip out
information for efficiency put it up in a standard URL for the few who
want to check it. That makes sense in the modern internet world. Send
the basics over USENET, but make the extra information available on fetch
(rather than pushed) to avoid making 300,000 copies of it so that one
person can read it.
This applies to all audit trail information, not just signature chains that
were collapsed.
However, certificate collapse does not have this issue. The holders of
high level "keeper keys" (the keys that sites cache) are already trusted
to be moderators, so if they collapse one of their chains, this is not a
security leak per se.
Nonetheless, I only advocate collapse on very commonly used keys, ie. only
where having a chain would be a burden.
My estimate is about 1-2ms or so to check a certificate with C code, and
if stored compactly, about 300 bytes. (RFC 2704/Keynote certificates are
larger but can be compressed. SPKI could be reasonably compact. X.509
are huge and out of the question.)