Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!usenet.ins.cwru.edu!tut.cis.ohio-state.edu!n8emr!colnet!res
From: res@colnet.uucp (Rob Stampfli)
Newsgroups: news.software.b
Subject: Re: Ideas for Message-ID's
Message-ID: <1991Apr23.042025.14287@colnet.uucp>
Date: 23 Apr 91 04:20:25 GMT
References: <3434@litchi.bbn.com> <1991Apr16.174706.4963@nic.funet.fi> <1991Apr17.212354.12236@zoo.toronto.edu>
Organization: Little to None
Lines: 29

While we are on the subject of Message-IDs, how about this:

Choose any workable standard for message-IDs you like, provided it has some
randomness to it (already a good idea for other reasons).  Then pass this
format thru a one-way authenticating function (one that is hard to invert)
which produces a one-to-one mapping of inputs to outputs.  Use the output
of this function, suitably reformatted to match the specification for the
Message-ID field, in the Message-ID field of the message being posted.
Finally, save the unencrypted Message-ID at the site in a file accessible
only to the News software.

Because of the one-to-one mapping, it can be guaranteed that encrypted
Message-IDs will be unique if they are generated from a subset of unique
unencrypted Message-IDs.

Now, once this is in place, change the News software to demand that the
unencrypted Message-ID be sent along with any cancel message (define a new
"Authentication: " field) if a cancel request is for a Message-ID which
matches the format of an encrypted Message-ID.

The result is that cancel messages can no longer be forged.  Only the
poster or the News administrator at the site the message originates
at can cancel it.  Of course, a given site can kill the message locally
(and for downstream sites), but it cannot purge the message globally.

I think such a scheme would have significant advantages in the anarchy
we call Usenet.
-- 
Rob Stampfli, 614-864-9377, res@kd8wk.uucp (osu-cis!kd8wk!res), kd8wk@n8jyv.oh