Back in the 80s, when talk of securing USENET came up, we all agreed public key digital signature was too hard a problem to solve back then (in particular due to patent laws and export restrictions).
I suggested that there was one thing we could secure with private key systems, namely the cancel. The idea was to, when generating an article, generate a secret string, then encrypt (or one-way-hash) the secret string and include that hash with the article.
Then later, you could, by providing the original secret string, prove you were the original poster (or somebody on the path) and thus do an authenticated cancel. This has become known as the "cancel lock."
But at the same time I noted that this would open the doors for abuse. We would be unable to perform a 3rd party cancel without using public key digital signature. Spam was not yet a problem, but it would become one, and authenticated cancels without 3rd party cancels might do more harm than good.
Since we needed public key signed cancels from 3rd parties, there was no point, I advised, in doing the cancel lock, since once we had public key signed cancels we could just use those for the same function.
In the years since, public key digital signature has changed and it is now possible (though not yet implemented) to use it on USENET. Signature code can be exported, and there are (in theory) signature algorithms without patent concerns. There are also freely available crypto libraries that include digital signature code.
However at this time people are still proposing the use of the cancel lock. It has some pros and cons which I discuss here.
Whether we have cancel locks or not, public key signature is the only way to solve almost all the rest of USENET's security issues. It makes sense to define a general mechanism to sign articles (be they cancels, other control messages or ordinary postings) and combine that with certificates that certify various attributes and designated authorities.
We need that for things like newgroup -- and a basic PGP based system called pgpverify is already used to make this happen. We want it for moderated groups (a cancelbot system called pgpmoose is used by some moderators but it's better to have the moderator sign and sites check rather than have a cancelbot send signed cancels on unsigned articles.) We want it for other control messages. Eventually we want it for ordinary articles, so that we can create all-signed (but not moderated) newsgroups where forgery is not possible. All-signed newsgroups can also make spam very difficult, by putting brand new posters through a quick confirmation step. In fact, many groups today simulate this process by using a moderated group and a moderation robot. Digital signature lets this be done decentralized.
PK signed cancel can be used to allow people to cancel forgeries (they get the power to cancel anything with their name on it, not just what they posted.) It can allow sites to cancel postings from their site, either on behalf or users, or in repairing damage from users who violate terms of service. PK signed cancel can also, it turns out, be more efficient to process than cancel-lock authenticated cancel. (See below.)
Without 3rd party spam cancel, the cancel-lock in effect creates the article that can't be cancelled. Indeed, if one is a spammer and doesn't care about cancel, one will just add a random cancel-lock to spam, making it impossible for others to cancel it without some form of 3rd party PK signed cancel.
So we want and need the PK signed article (including cancel). The question is, should we also have the cancel-lock?
The cancel lock is simpler to implement. Indeed it's so much simpler than the PK system that the danger is it might be implemented on its own, without PK signed articles being done in parallel. This would create the danger of the cancelproof spam described above.
But it's simpler to code the sending of it, and most of all it doesn't require both the public key certificate system, and the creation of a signing key and certificate for the user. However, if we're going to already ahve the PK certificate system for other purposes, the main issue is the creation of a signing key and certificate for the user.
The cancel lock system simply has the program generate a store a secret string, and then use it whenever the user posts an article. This must be done when you post, so the user has to have new posting software at the time they post.
Checking the cancel lock is easy to code but bears one annoying complexity. The receiving site has to have a copy of the original article around to verify the cancel. This means either fetching it from disk, or putting the cancel in a special queue or database of "as yet unverified cancels" so that it can be then re-checked if and when the actual article arrives. Of course, the actual article rarely arrives -- that is the nature of cancelled messages.
The above facility is less complex than a full PK system -- unless you already are implementing the PK system for other reasons. As I will explain later, the PK signed cancel usually can be executed without having to fetch (or even have on file) the original article.
So the main simplicity is the user doesn't have to get a key and certificate.
If you feel that the world is generally going to adopt PK systems for all sorts of other things, including E-mail, then it may be the case that most people will already have a certificate for their E-mail address. In that case the only issue is one of finding and converting it to a USENET style certificate. This can be automated.
In most cases, users will not get their own keys and certificates. More commonly the site will get one for the site. If the site has a way of verifying its users, as most of the big ISPs do, the site can sign both articles and cancels on behalf of the user. The user need do nothing. Indeed, the user can even run 80s vintage USENET software. Site signing gives all the benefits of signing to all users at the site immediately. Other options, including cancel lock, require upgrades.
Generating a key is not too difficult. One takes some random input, keystrokes from the user, and makes the key and stores it. It's fine to store it on disk -- most people will accept that their USENET article security need be no more secure than their private disk files. Now one needs the certificate.
To get it, the program contacts a known issuer of E-mail address certificates (know as a Certificate Authority or CA). They can do this via the web or more simply via E-mail. They offer the public key and the E-mail address. The program also includes some instructions to be bounced back to the user, as well as destination file names etc. The CA writes a certificate and E-mails it to the certified address. Only a person capable of reading that E-mail will get the certificate. This is not full security. It means if somebody compromises your network or yor mailbox they can act on USENET as you. But it's good enough. If desired, more highly secured certs are possible at greater inconvenience. Secure DNS is also needed.
The user gets the E-mail. It has the certificate, probably as a mime attachment with pre-set filename on it for the location the news-poster uses to store certificates. It has instructions, in English (or whatever natural language) telling the user how to save the certificate. The user does.
And that's it. The posting/cancelling program now knows where to look to find certificates and it knows how to use them. This is the only added complexity for the user -- saving a single piece of E-mail.
However, if the user doesn't want to do this, there are other methods, noted below.
The cancel lock has to be present on articles when they are posted. That means adding 30 or so bytes to every article posted, whether it is cancelled or not. That's wasteful, though not dreadful. More to the point it requires you to have new posting software when you post what you want to cancel. Not only do you have to upgrade, you have to upgrade before you decide to cancel.
Because as you might guess, one rarely knows in advance that one intends to cancel an article. Usually you realize a mistake, and want to correct it -- after the fact. If you posted it with no cancel lock you are out of luck in the cancel lock system.
If your newsreader/poster doesn't have an upgrade yet available, you are also entirely out of luck.
With the PK signed cancel, you can cancel after the fact. You can download cancelling software (independent of your newsreader or news poster and whether it is upgraded) and go through the key process and issue a cancel. This much more closely matches how cancels happen, as an afterthought.
Note again your own newsreader need not have an upgrade available, you can do the cancel with another program, cutting and pasting the message-id.
The cancel-lock only works for the party that generated the article, or in theory those who handled it on the way to its path (the latter is both a feature and a security hole.) However, a PK signed cancel can apply not just to those articles, but to any article that has the user in the From, Reply-to, Sender or Approved line. This means you can cancel postings others have forged with your address on them, in any place. Ie. if somebody tries to mail-bomb you with a posting that legitimately says who it is from but redirects replies to you, you can cancel it.
That's also the case for the site, as noted. While it's not a must that we grant sites this power, it's likely we would. If you don't trust your site, post from another one. (Indeed, if you sign articles, and not just cancels, there's no reason not to have open posting injectors that take only signed articles, letting people chose the site they post through.)
This is perhaps what sites would like the most. If a net attack or spam is posted, with forged addresses at their site, they start taking the heat from all the "well meaning" complainers. Or for that matter if an attack is posted from their site with a real address of an abuser there. The site wants the ability to quickly fix the problem.
Almost all postings from a site come with message-ids ending in the site name. It turns out for various reasons it makes sense to actually allocate "ownership" of message-id space to sites and users. If this is done, then you can implement a simpler, much more efficient cancel.
A site or user can have, as part of their domain certificate, the right to cancel any message-id at all ending in their domain. If you don't want to give them that power, don't use a message-id with their domain. (For a user's message-id space, a slightly different syntax is needed.)
With such a certificate a cancel for a message-id in the domain can be executed immediately. You don't have to fetch the original article to verify it. You don't even have to have the article on hand. If you get a message saying, "I, certified owner of the aol.com domain and (implicitly) message-id space, wish to cancel the message <adfasdfasdf@aol.com>" you can execute it right away. No disk I/O.
So in fact the PK signed cancel usually executes more quickly than the cancel-locked cancel. And doesn't require 35 bytes on every message, just 300 bytes on the cancel itself.
Unfortunately, since the ability to cancel forgeries is so useful, you still might need to have a queue which stores cancels that arrive before their target article. But you would use it very rarely.
Eventually, at least in the case of newsgroups (such as moderated ones) where all messages are signed, not just the cancels, one could in fact not even implement the queue for such a net.
As noted, since many sites will do the signing of articles and cancels, most users won't need new software for all this to work. However, for users of software at sites with old software, there are two ways to give them the benefit of authenticated cancel. Cancel locks only work for users with new software, at sites with new software.
If the user needs to cancel, and knows they need a signed cancel, but don't want to get and store a key or have any special software at all, they can still do it. All they have to do is send the message-id of the message they wish to cancel to a special cancelbot, either by E-mail or on a web page.
That daemon then can create a signed cancel with its own more powerful 3rd party key cancel key. It can then provide that back to the user to post by E-mail. However, since the user probably doesn't know how to do that, it can simply send a challenge to the user with magic cookie. The user replies to that, with the cookie, and the daemon, having confirmed the cancel comes from the user of the mailbox, issues a 3rd party signed cancel.
If the daemon happens to have the original message on file, it can issue a 3rd party signed cancel that also indicates that the ID was confirmed, making this efficient for those executing it. Otherwise it would issue a more ordinary cancel that says, "Cancel message only if it is indeed from user X."
There is an even better solution. We can put the signed cancels in their own space. Sites noticing an unsigned cancel would re-write it, in a standard way, with a standard new message-id, and fail to propagate it to their downstream sites. Instead they propagate "control oldcancel" with the necessary data. Assuming most hubs upgrade to new software that does this, most unsigned cancels don't get very far in their raw form.
Eventually the oldcancel (along with several rejected redundant copies) makes its way to a daemon. The daemon then does challenge/response with the user as above, and issues the signed cancel.
In this system, even the users of the oldest software can do an authenticated cancel, and they don't even have to know anything special. They do the cancel in their newsreader, and not long after an E-mail arrives saying, "Did you really mean to cancel X? Reply if so." and the cancel is done.
Now everybody on the net has the benefit of secured cancel the moment this system is set up. Cancel-locks and other systems only give the benefit of secured cancel to the users who post with locks, at the sites that check locks.
Because the above system doesn't even propagate unsigned cancels outside of non-secured islands, everybody gets the benefits of security. For you see, a forged cancel hurts not just the author of the posting that was deleted. It hurts all of us, who read a net with messages improperly missing. A system that only helps the user is of much lower value.
Some have suggested that sites which inject articles might use cancel locks as well, adding them to the one the user provided, for a double lock. Indeed, with moderators and their sites this could amount to 3 or 4 locks on an article. While there is some argument that having users get public key certificates is a burden, this does not hold for site and moderators. The disadvantages of the cancel lock are far too strong to suggest that it be done to save site admins the hassle of getting a key and certificate.
The PK signed cancel uses far fewer bytes on the net (300 per cancel vs. 35 per article, with approximately 1000 articles posted per one cancelled.)
Most PK signed cancels can be checked more efficiently than Cancel-lock ones because you don't have to fetch the original article or even have it.
PK signed cancels can cancel after-the-fact, even if you posted with old software.
PK signed cancels can cancel with a standalone cancel program, even if your newsreader/poster does not have an upgrade available yet.
PK signed cancels allow cancel of articles posted in your name, not just those actually posted by you.
PK signed cancels allow sites to easily sign for their users, and as well to cancel abuse by their users. And again, even after the fact on a site that is running old software.
PK signed cancels allow challenge/response to bring authenticated cancel ability to all users of any software, again after the fact.
PK signed cancels of course support 3rd party anti-spam cancel.
By converting hubs to divert unsigned cancels for signing after confirmation, the whole net gets the benefit of authenticated cancel almost immediately. Cancel-lock system gives benefit only to users with new posting software that adds locks, at sites that check the locks. It's many years before most of the net gets benefit.