RFC 8315 Proposed Standard Message format

Cancel-Locks in Netnews Articles

This document defines an extension to the Netnews Article Format that may be used to authenticate the withdrawal of existing articles. This document updates RFC 5537.

Status
Proposed Standard. On the standards track and stable enough to implement against. Most of the email stack stays at this level permanently.
Published
February 2018
Authors
M. Baeuerle
Read it
rfc-editor.org · DOI

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 13 must, 8 should, 5 may.

2 Header Fields

  • MUST NOTEach of these header fields MUST NOT occur more than once in an article.
  • SHOULD NOTImplementations SHOULD NOT use the hash algorithms "sha224" and "sha384" to generate <scheme>.

2.1 Cancel-Lock

  • SHOULD NOTComments in CFWS (comments and/or folding whitespace) can cause interoperability problems, so comments SHOULD NOT be generated but MUST be accepted.
  • MUSTIf <scheme> is not supported by an implementation, the corresponding <c-lock> element MUST be skipped and potential following <c-lock> elements MUST NOT be ignored.

2.2 Cancel-Key

  • SHOULD NOTComments in CFWS can cause interoperability problems, so comments SHOULD NOT be generated but MUST be accepted.
  • MUSTIf <scheme> is not supported by an implementation, the corresponding <c-key> element MUST be skipped and potential following <c-key> elements MUST NOT be ignored.
  • SHOULDCompliant implementations SHOULD generate valid Base64 (that is to say the syntax of <c-lock-string> as defined in Section 2.1 of this document) and MUST accept strings of <base64-octet> characters (that is to say the syntax of <obs-c-key-string> as defined in Section 6 of this document).

3.1 Adding an Initial Cancel-Lock Header Field to a Proto-Article

  • MAYA Cancel-Lock header field MAY be added to a proto-article by the poster or posting agent and will include one or more <c-lock> elements.
  • MAYIf the poster or posting agent doesn't add a Cancel-Lock header field to a proto-article, then an injecting agent (or moderator) MAY add one, including one or more <c-lock> elements.
  • MUSTIf multiple <c-lock> elements are added to the Cancel-Lock header field by a single agent, each <c-lock> element MUST use a unique key "K" to improve security.
  • MUSTIf an injecting agent (or moderator) wants to act as a representative for a posting agent without support for the authentication system described in this document, then it MUST be able to positively authenticate the poster and MUST be able to automatically add a working Cancel-Key header field for all proto-articles with cancelling or superseding attempts from that poster.
  • MUST NOTOther agents MUST NOT add this header field to articles or proto-articles that they process.

3.2 Extending the Cancel-Lock Header Field of a Proto-Article

  • MAYIf a Cancel-Lock header field has already been added to a proto-article, then any agent further processing the proto-article up to the injecting agent (inclusively) MAY append additional <c-lock> elements to those already in the header field body.
  • MUSTIf multiple <c-lock> elements are appended to the Cancel-Lock header field by a single agent, each <c-lock> element MUST use a unique key "K" to improve security.
  • MUST NOTOnce an article is injected, then this header field MUST NOT be altered.
  • MUST NOTIn particular, relaying agents beyond the injecting agent MUST NOT alter it.

3.3 Adding a Cancel-Key Header Field to a Proto-Article

  • MAYA Cancel-Key header field MAY be added to a proto-article containing a Control or Supersedes header field by the poster or posting agent and will include one or more <c-key> elements.
  • MUSTIf, as mentioned in Section 3.1, an injecting agent or moderator (acting as a representative for the posting agent) has added a Cancel-Lock header field to an article listed in the Control (with a "cancel" command as defined in [RFC5537]) or Supersedes header field, then (given that it authenticates the poster as being the same as the poster of the original article) it MUST add the Cancel-Key header field with at least one <c-key> element that corresponds to that article.
  • MUST NOTOther agents MUST NOT alter this header field.

3.4 Extending the Cancel-Key Header Field of a Proto-Article

  • MAYIf a Cancel-Key header field has already been added to a proto-article, then any agent further processing the proto-article up to the injecting agent (inclusively) MAY append additional <c-key> elements to those already in the header field body.
  • MUSTIf, as mentioned in Section 3.2, an injecting agent or moderator (acting as a representative for the posting agent) has extended the Cancel-Lock header field in an article listed in the Control (with a "cancel" command as defined in [RFC5537]) or Supersedes header field, then (given that it authenticates the poster as being the same as the poster of the original article) it MUST extend the Cancel-Key header field body with at least one <c-key> element that corresponds to that article.

4 Calculating the Key Data

  • RECOMMENDEDThe following algorithm is RECOMMENDED to calculate the key "K" based on a local secret <sec>.

6 Obsolete Syntax

  • SHOULD NOTThe following value for <scheme> is now deprecated and SHOULD NOT be generated anymore.
  • SHOULDServing agents SHOULD still accept it for a transition period as long as the corresponding hash function is not considered unsafe (see Section 7 for details) or already marked as OBSOLETE in the "Netnews Cancel-Lock Hash Algorithms" registry (Section 8.3).
  • SHOULD NOT<obs-c-key-string> SHOULD NOT be generated but MUST be accepted.

8.2 Change Control

  • MUST NOTNetnews Cancel-Lock hash algorithm registrations MUST NOT be deleted.

Every current email RFC