Summary

  • A matching supported Cancel-Key and Cancel-Lock can authenticate a withdrawal request without every other lock also matching. Several lock values do not necessarily represent several actors.
  • A representative posting service has obligations to authenticate the original poster and supply working withdrawal credentials. Retaining its local secret can also retain power over an earlier cohort of articles.
  • Authentication does not sign the article’s content or require every receiving server to remove it. The operational exposure is distributed across credential custody, service practice and local policy.

The useful question about a second cancel lock is not whether it makes an article harder to withdraw. It is whether somebody else now has a working way to authenticate withdrawal. In Netnews, a mechanism with “lock” in its name can support alternative routes to that result. It does not turn the holders into a committee.

This matters at an unglamorous moment in a service relationship: departure. A customer moves its posting activity, closes an account or changes the organisation that handles its messages. New publications can use a new arrangement. Old articles already distributed through the network carry their existing authentication material. The commercial relationship may have ended while an old technical capability remains.

That is an operating scenario, not evidence of a particular provider’s behaviour. The source here is a protocol contract. RFC 8315, published in February 2018, defines Cancel-Lock and Cancel-Key for authenticating Netnews cancellation and supersession. It updates the earlier architecture in RFC 5537. Their rules expose a question for anyone buying a posting or archive service: does the service merely help the customer exercise withdrawal, or does it retain another path to authenticate it?

Alternative proofs are not additional votes

The original article carries a Cancel-Lock field containing one or more values derived from secret material. A later request supplies Cancel-Key material to be checked against those values. Section 3.5 of RFC 8315 allows verification to succeed when a supported key produces a matching lock under the same scheme. Once a match is found, the remaining comparisons may stop.

The distinction is logical before it is organisational. The rule is a match to an acceptable alternative, not a requirement to satisfy every element. Unsupported elements are skipped without invalidating the rest of the list. A service cannot infer “two approvals required” from seeing two values.

Nor does two values necessarily mean two people or organisations. One agent may supply several elements. Different supported schemes and distinct keys can coexist without creating independent decision-makers. An audit therefore needs to associate working proof paths with their custodians. Counting field entries is not an authority inventory.

Consider a hypothetical poster and an injecting service that each contribute a usable lock before injection. If each retains the corresponding capability, either may be able to provide a matching proof. That can improve continuity when one route is unavailable. It can also extend withdrawal authentication beyond the poster’s own custody. Whether a receiving server acts remains a separate question; the additional proof is not a command that overrides local policy.

The important boundary comes before distribution

RFC 8315 distinguishes a proto-article, still being processed before injection, from an article already injected into the network. Under section 3.2, an agent handling the proto-article up to and including the injector may append lock elements. After injection, the Cancel-Lock field must not be altered.

This is not an invitation for every relay to acquire withdrawal powers while forwarding a message. The point at which an additional path can be attached is constrained. An arrangement made during posting can become part of the article’s subsequent history; a downstream operator cannot legitimately rewrite that field to install a new path retrospectively.

The same distinction complicates exit. Switching the organisation responsible for tomorrow’s posts does not, by itself, replace the authentication material on yesterday’s distributed articles. That is an inference from the immutability rule, not an automatic revocation procedure specified by the RFC. A migration plan that describes only future posting leaves the older cohort unexplained.

A representative inherits a duty, not just a feature

Section 3.1 addresses posting agents that do not support the mechanism themselves. An injector or moderator acting as their representative must positively authenticate the original poster and automatically add working Cancel-Key values to that poster’s cancellation or supersession requests.

There are two obligations here. Recognising the customer is one. Producing a credential that actually matches the earlier article is another. A friendly support response or an active account does not establish the second. Conversely, possession of a useful secret does not establish that a particular incoming request was properly authenticated.

For a service buyer, this changes the shape of a continuity question. “Do you support cancellation?” is too broad. What evidence shows that an authenticated request from the original poster can still be connected to the correct historical key material? What happens after account closure, a moderation change or a move between service arrangements? Those are proposed due-diligence questions, not extra protocol requirements.

The representative can make a capability available to users who would otherwise lack it. That is a genuine benefit. The governance issue is the combination of assistance and custody, not a presumption that intermediaries are abusive. The same arrangement that reduces work for the poster can concentrate the knowledge needed to exercise withdrawal.

The secret has a longer history than the account

RFC 8315 section 4 recommends deriving article-specific keys from a local secret and article-related inputs using HMAC. This avoids maintaining a separate database of randomly generated keys for every article. The local secret and the article-specific value later disclosed for cancellation are not interchangeable.

Section 7 draws the security distinction. Exposure of a particular preimage concerns that proof. Compromise of the local secret can permit forged withdrawal credentials for the earlier articles whose keys were generated with it. The convenience of compact secret storage therefore has an archive-shaped consequence.

Periodic changes to the local secret can limit damage, as the RFC notes. But changing the secret used for new work does not rewrite previously injected lock fields. Keeping an old secret may preserve the ability to serve legitimate historical requests as well as the exposure associated with that cohort. Destroying it may reduce one retained capability while removing a useful service path. Neither choice establishes what other actors retained.

These are custody and continuity trade-offs, not a universal instruction to keep or destroy keys. The relevant unit is the set of articles served by a secret and the independently available alternatives. An account’s current status is a poor substitute for that map.

A valid withdrawal request is still a request

RFC 5537 section 5.1 leaves agents’ actions subject to local policy and does not require an agent to act on every control message. Section 5.3 describes a server that elects to honour cancellation: it should make the target article unavailable. If the cancellation arrives first, that server should remember the identifier and reject the target when it later arrives.

Those conditional rules do not establish universal erasure. A successful authentication check, one server’s action and observations at other servers are different evidence. The absence of a copy at one location is not a receipt for every copy. Equally, a retained copy does not by itself prove that a custodian failed authentication or acted maliciously.

Supersession introduces another separation. Under section 5.4, the withdrawal aspect follows the relevant cancellation checks, while the replacement article receives normal handling whether or not supersession is honoured. RFC 8315 does not provide article-content integrity. A matching withdrawal proof is not a signature over the original message or an endorsement of the replacement’s words.

The RFC Editor records, checked on 8 September 2026, list no matching errata for RFC 8315. RFC 5537 has verified corrections concerning Path wording and a newgroup example, alongside reported or held items; these do not replace the withdrawal decisions examined here. This analysis does not turn the 2018 document’s observations about particular algorithms into current cryptographic advice, and the sources do not establish present deployment prevalence.

Lu Heng’s Note 32 offers an agency lens for asking who controls a mechanism and who bears its consequences. Note 36 asks BTW to describe structure rather than advocate an outcome. Applied here, that means examining the actual retained capability without assuming that either a service provider or an owner is inherently the better custodian.

Sources