USEFOR Working Group S. Lyall
INTERNET-DRAFT November 1998
Expires May 1999
Cancel-Locks in Usenet articles.
Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
This document outlines a method that may be used by authors of successor
(or canceling) articles to authenticate their authorship of the original
As a proto-article article passes through various agents they may include
the hash of a secret string in a Cancel-Key header. Later if they wish to
use a standard mechanism to remove the original article (eg Cancel or
Supersede) they can include this string in the Cancel-Lock header to
verify that they are entitled to perform this operation.
Familiarity with the current News Article Format draft [ARTICLE] is
1. Introduction: The Cancel-Key & Cancel-Lock headers
These two headers MAY be used by posters, posting agents, moderators and
injecting agents in order to mark articles they process and to verify
canceling, superseding and replacing articles that may subsequently be
issued for those originals. They MUST NOT be altered or created by any
The scheme works by including a "Cancel-Lock: " header and contents in an
article. Further articles that wish to cancel, supersede or replace this
article can include a "Cancel-Key: " header which contains a code-string
that when hashed yields one of the code-strings in the "Cancel-Lock: "
header of the original article.
These headers are intended to be used as a simple method to verify that
the author of an article which removes another one is either the poster,
posting agent, moderator or injecting agent that processed the original
article when it was in its proto-article form.
Cancel-Lock-content = cancel-lock *( CFWS cancel-lock ) [CFWS]
Cancel-Key-content = cancel-key *( CFWS cancel-key ) [CFWS]
cancel-lock = scheme ":" code-string
cancel-key = scheme ":" code-string
scheme = token
code-string = 1*base64-octet
base64-octet = ALPHA / DIGIT / "+" / "/" / "="
2.1 The "scheme" element
The scheme is the format that is used to encode the code-string. This
document only defines the scheme of "SHA1" which corresponds to the
SHA1 algorithm [SHA1]. Other schemes MAY be defined by further IETF
standards. This element is case insensitive.
2.2 The "code-string" element
The code-string is a series of base-64-octets. The code-string in a
cancel-lock is the hash of the corresponding code-string in a cancel-key.
The encoding of the binary key or lock is performed in accordance with
the Base64 Transfer Encoding defined in [RFC-2045].
Under scheme "sha1" the code-string element of a cancel-lock is the
output of a hash operation (using the SHA1 algorithm) performed on the
code-string of the cancel-key.
In order for an article removal to be allowed under the Cancel-Lock method
the following takes place:
When a serving agent receives an article that attempts to remove a
previous article via Cancel, Supersedes or Replaces, then if the original
article contains a valid cancel-lock the replacing article MUST contain a
valid cancel-key (or keys) that corresponds to at least one of the
cancel-lock's in the original article.
3.1 Adding an initial "Cancel-Lock: " header to a proto-article
A Cancel-Lock header MAY be added to a proto-article by the poster
or posting agent which will include one or more cancel-locks in its
If the poster or posting agent does not add a Cancel-Lock header to an
article then an injecting-agent (or moderator) MAY add one provided that
it positively authenticates the author. The injecting-agent (or
moderator) MUST NOT add this header to an article unless it is able to
authenticate all cancels, replaces and supersedes from the poster and
automatically add the correct Cancel-Key header (and content) for such
Other agents MUST NOT add this header to articles or proto-articles that
3.2 Extending the "Cancel-Lock: " header of a proto-article
If a "Cancel-Lock: " header has already been added to a proto-article
then any agent (prior to the article being injected) further processing
the proto-article (ie moderators and injection-agents) MAY append a single
cancel-lock to those already in the header.
No more than one cancel-lock SHOULD be added by each agent that
processes the proto-article.
Once an article is injected then this header MUST NOT be altered. In
particular, relaying agents beyond the injecting agent MUST NOT alter it.
3.3 Adding a "Cancel-Key: " header to a proto-article.
The Cancel-Key header MAY be added to a proto-article containing a
"Cancel: ", "Replaces: " or "Supersedes: " header by the poster
or posting agent which will include one or more cancel-keys in its
Cancel-Key-content. These cancel-keys will correspond to some or all of
the cancel-locks in articles listed in the "Cancel: " , "Replaces: " and
"Supersedes: " headers.
If, as mentioned in 3.1 an injecting agent (or moderator) has added a
"Cancel-Lock: " header to an article listed in the "Cancel: " , "Replaces:
" or "Supersedes: " headers then (assuming it authenticates the poster as
being the same as the poster of the original article(s) ) it MUST add a
"Cancel-Key: " header with the cancel-key(s) that correspond to those
Other Agents MUST NOT alter this header.
4. Creating the cancel-lock
It is suggested that when creating a cancel-lock the function
HMAC(message-id+secret) be used, where HMAC is outlined in [HMAC],
message-id is the message-id of the article and secret is a secret key
This method removes the need for a per-article database containing the
cancel-lock used with every article.
5. Security Issues
General security issues with hash functions are discussed elsewhere, see
the references in [HMAC] for some pointers. The method outlined in
Section 4 is also vulnerable to the secret key being compromised or
The following are Cancel-Lock headers along with a Cancel-Key header
that matches them:
Cancel-Key: sha1:chW8hNeDx3iNUsGBU6/ezDk88P4= sha1:4srkWaRIzvK51ArAP
[ARTICLE] News Article Format. D Ritter. Internet Draft
draft-ietf-usefor-article-01 . 1998.
[HMAC] Keyed-Hashing for Message Authentication. H. Krawczyk, M.
Bellare, R. Canetti. February 1997. RFC 2104.
[SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, Apr 1995.
[RFC-2045] MIME, part 1 Freed, Ned; Borenstein, Nathaniel S.:
Multipurpose Internet mail extensions (MIME), part 1: format of
Internet message bodies. RFC 2045, Nov 1996.
8. Changes from previous draft.
- References to SHA-160 changed to SHA1
- "scheme" is now a case insensitive token and the number "1" has been
changed to "sha1".
- Added some examples and fixed the section numbering.
- Updated 2nd paragraph on section 2.2 to make clear what exactly is
being hashed and how.
- Changed paragraph 2 of 3.1 to discourage injection-agents from adding
- Removed the Clue-string as this complicated the scheme without adding
- moderators can now add these headers under the same conditions as
9. Author's Address
PO Box 6616,
Phone: +64 9 358 5067 ext 701