USEFOR Working Group                                             S. Lyall
                                                         Expires February 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 (Africa),
     (Northern Europe), (Southern Europe),
     (Pacific Rim), (US East Coast), or
     (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 pre-injected 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 ,
canceling, superseding and replacing articles they that may subsequently be
issued for those originals. They MUST NOT be altered or created by any
other agents.

The scheme works by included including a "Cancel-Lock: " header and contents in an
article. Further articles that wish to cancel, supersede or replace this
article are required to 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 a 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.

2. Format

   Cancel-Lock-content = [CFWS] cancel-lock *( CFWS cancel-lock ) [CFWS]
    Cancel-Key-content = [CFWS] cancel-key *( CFWS cancel-key ) [CFWS]
           cancel-lock = scheme ":" code-string
            cancel-key = scheme ":" code-string [ ":" clue-string ]
                scheme = 1*DIGIT token
           code-string = 1*base64-octet
             clue-string = 2base64-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 "1" "SHA1" which corresponds to the
SHA1 algorithm [SHA-160]. [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 1 scheme "sha1" the code-string element of a cancel-lock is the
output hash of the SHA algorithm.

2.3 The "clue-string" element

The clue-string is an optional element that MAY be included in a
cancel-key. It consists of hash operation (using the first two base64-octets of SHA1 algorithm) performed on the
code-string of the cancel-lock to which the cancel-key corresponds.

The clue-string is intended the reduce searching time where multiple
cancel-lock's may be referred to by a single cancel-key.

3. Use


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 (or more) 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. However this practice is The injecting-agent (or
moderator) MUST NOT
recommended since the poster will be unable to create a cancel-key add this header to
remove the an article later without unless it is able to
authenticate all cancels, replaces and supersedes from the co-operation of poster and
automatically add the injecting agent. correct Cancel-Key header (and content) for such

Other agents MUST NOT add this header to articles or proto-articles that
they process.

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 in 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 or 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
held locally.

This method removes the need for a per-article database containing the
cancel-lock used with every article.. 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


6. Examples

The following are Cancel-Lock headers along with a Cancel-Key header
that matches them:

Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4=
Cancel-Key: sha1:aaaBBBcccDDDeeeFFF

Cancel-Lock: SHA1:H7/zsCUemvbvSDyARDaMs6AQu5s=
Cancel-Key: sha1:chW8hNeDx3iNUsGBU6/ezDk88P4=  sha1:4srkWaRIzvK51ArAP

Cancel-Lock: sha1:JyEBL4w9/abCBuzCxMIE/E73GM4=
Cancel-Key: sha1:K4rkWRjRcXmIzvK51ArAP

7. References

[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
  the header.

- Removed the Clue-string as this complicated the scheme without adding
  realistic functionality

- moderators can now add these headers under the same conditions as

9. Author's Address

Simon Lyall, Lyall
PO Box 6616,
New Zealand.

Phone: +64 9 358 5067 ext 701