From: Brad Templeton (brad@templetons.com)
Date: Tue Oct 16 2001 - 14:14:28 CDT
On Tue, Oct 16, 2001 at 09:35:54AM +0000, Charles Lindsey wrote:
> >1) I have not proposed that every injecting site need a key, nor every
> >user need a key for USENET in general.
>
> You have stated that every injecting site should be able to cancel any
> article injected through it. You have resisted suggestions that this
> should be done by means of Cancel-Locks.
>
> Ergo, every injecting site needs its own public key.
An injecting site would need a key if it wished to cancel articles coming
from its site. This is something only a relatively small minority of sites do
so no, _every_ injecting site does not need a key.
(In addition, an injecting site could, instead of getting a key, have a
relationship, pre-arranged or otherwise, with a trusted 3rd party canceller,
in either event.)
However, a key difference between the systems is that if an injector is one
of that group that needs to do a cancel, it can get a key to do so _after_
the fact, and it can apply cancels not just to the articles that were
injected through it, but also to ones that forge the domain of the site.
This is a pretty major advantage. To use cancel locks requires that the
injector get new software _before_ it is abused, and it must be new
production injector software.
With the use of a signed key for a domain, it is possible to download an
independent program which will issue the cancels. This is much easier to
do in an emergency situation than to change production software.
How hard getting a key is depends on how much security we want on it.
If we write a secured "uncancel" into the spec, which I recommend, cancel
becomes a less dangerous operation and thus needs less security.
(UNDO is always a good idea if it's not hard to implement.)
The simplest way to get a key would be to request the certifier to mail
the certificate back to one of the contacts in the WHOIS record for the
domain. This level of security is far from military-grade, but it is
the level used to secure control of domains themselves, which is far more
important than cancel ability.
A stronger level (that's coming) will be simply converting the certificates
that are planned for secure DNS.
So the process can be automated, and as I said, would only be done by the
few (far from all) sites which wish to issue a cancel, and done after
the illicit articles have gone out from any injector. You would download
a cancelling program (probably written in perl for portability.) That
program would generate a key for you and send a request to the CA. Upon
receipt of the mail with the cert in under a minute, you would save it
in a file, and run the cancelling program with that file and the message-ids
you wish to cancel.
Voila -- secure site cancel, in a standalone program. And what you really
want if you see a big spam has been posted with your domain in it.
Of course, you could also use this key full-time, putting it into a
modern injector, so that you can sign all articles from your site, including
user's cancels and site cancels. Not a requirement, though. I would,
however, expect big sites like AOL to do this as they are often targets of
forgeries.
> I grant you that the need for every individual user to have a key arose
> from Ralph's impractical suggestion, and not from you.
Actually, I do imagine for a later stage, that we will create authenticated
but unmoderated groups, where each person posting there must either:
a) Have a key, or
b) Post through an injector that has a key, or
c) Go through a moderator or robo-moderator
Though because of option (c), having a key would not be required.
>
>
> The depth of the tree of certicifactes is proportional to the logarithm of
> the total number of keys involved. The breadth of the tree (actually, a
> directed graph) is hard to quantify (how many top-level trusted parties
> are needed?), but may be linear in that number. The size of the databases
> kept by the certificate authorities worldwide is certainly at least
> linear. With a billion keys ... ?
Again, you continue to post major misapprehension of how these systems work.
A considerable majority of your assertions are wrong, and I hope I can
convince you to re-read the materials in this area.
Certificate authorities do not need to keep databases. A certificate
chain validates itself. The main reason certificates were invented
was to eliminate the database problems of key management. You seem to
write as though you are unaware of this.
CAs may very well keep an audit trail of what they do, but there is no
need to. When presented with a certificate they signed, they can tell
if they signed it. They don't have to check a database.
If they are a high quality CA, they might keep a database to provide
customer service, such as reminding people to renew, etc. but there is
no technical requirement. That is the true elegance of the invention.