]> STZ Elektronik

Hofener Weg 33C 71686 Remseck Baden-Württemberg Germany +49 7146 999061 michael.baeuerle@stz-e.de

Applications and Real-Time Independent Submission Usenet Netnews Cancel-Lock This document defines an extension to the Netnews Article Format that may be used to authenticate the cancelling and superseding of existing articles. If approved, this document updates RFC5537.

The authentication system defined in this document is intended to be used as a simple method to verify that the withdrawal of an article is valid, that is to say either the poster, posting agent, moderator or injecting agent that processed the original article has required to withdraw it via the use of a cancel control article ( Section 5.3) or a Supersedes header field ( Section 5.4). One property of this system is that it prevents tracking of individual users. There are other authentication systems available with different properties. When everybody should be able to verify who the originator is, e.g. for control articles to add or remove newsgroups ( Section 5.2), an OpenPGP signature is suited.

Any term not defined in this document has the same meaning as it does in or . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Please write the letters "ae" in "Baeuerle" as an a-umlaut (U+00E4, "ä" in XML), the first letter in "Elie" with an acute accent (U+00C9, "É" in XML), the letters "ss" in Janssen as an eszett (U+00DF, "ß" in XML) and the letters "ue" in Baden-Wuerttemberg as an u-umlaut (U+00FC, "ü" in XML) wherever this is possible.

This section describes the formal syntax of the new header fields using ABNF . It extends the syntax in Section 3 of and non-terminals not defined in this document are defined there. The ABNF should be imported first before attempting to validate these rules. The new header fields Cancel-Lock and Cancel-Key are defined by this document, they follow the rules described in Section 2.2:

fields =/ *( cancel-lock / cancel-key )

Each of these header fields MUST NOT occur more than once in an article. Both new header field bodies contain lists of encoded values. Every entry is based on a <scheme>:

scheme = "sha256" / "sha512" / 1*scheme-char / obs-scheme scheme-char = ALPHA / DIGIT / "-" / "/"

The hash algorithms for <scheme> are defined in , see also and for MD5, for SHA1 and for the SHA2 family. The Base64 encoding used is defined in Section 4 of . This document defines two values for <scheme>: "sha256" and "sha512". The hash algorithm "sha256" is mandatory to implement. Because the hash algorithm for <scheme> cannot be negotiated, unnecessary proliferation of hash algorithms should be avoided. The hash algorithms "sha224" and "sha384" are only added to the Netnews Cancel-Lock hash algorithm registry () because implementations exist that supports them. Implementations SHOULD NOT use the hash algorithms "sha224" and "sha384" to generate <scheme>.

cancel-lock = "Cancel-Lock:" SP c-lock-list CRLF c-lock-list = [CFWS] c-lock *(CFWS c-lock) [CFWS] c-lock = scheme ":" c-lock-string c-lock-string = *(4base64-char) [base64-terminal] base64-char = ALPHA / DIGIT / "+" / "/" base64-terminal = 2base64-char "==" / 3base64-char "="

Comments in CFWS can cause interoperability problems, so comments SHOULD NOT be generated but MUST be accepted. If <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. <c-lock-string> is the Base64 encoded output of a hash operation (defined by <scheme>) of the Base64 encoded key "K" that is intended to authenticate the person or agent that created or processed respectively the proto-article up to injection (inclusively):

Base64(hash(Base64(K)))

Because of the one-way nature of the hash operation the key "K" is not revealed. If multiple <c-lock> elements are present in a <c-lock-list>, each <c-lock> element MUST use a unique key K.

cancel-key = "Cancel-Key:" SP c-key-list CRLF c-key-list = [CFWS] c-key *(CFWS c-lock) [CFWS] c-key = scheme ":" c-key-string c-key-string = c-lock-string / obs-c-key-string

Comments in CFWS can cause interoperability problems, so comments SHOULD NOT be generated but MUST be accepted. If <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. <c-key-string> is the Base64 encoded key "K" that was used to create the <c-lock> element in the Cancel-Lock header field body (as defined in of this document) of the original article:

Base64(K)

The relaxed syntax definition of <c-key-string> above is required for backward compatibility with implementations that are not compliant with this specification. Compliant implementations SHOULD generate valid Base64 (that is to say the syntax of <c-lock-string> as defined in 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 of this document).

The Cancel-Lock header field contains hashes of secret strings. This secret strings can later be used to authenticate a cancel or supersede request. Use cases: The poster of an article wants to cancel or supersede existing articles. A moderator wants the ability to cancel articles after approving them. An injecting agent acts representitive for posting agents without support for the autentication system described in this document. A news administrator wants the ability to cancel articles that were injected by its system (because they e.g. violate its abuse policy).

A Cancel-Lock header field MAY be added to a proto-article by the poster or posting agent which will include one or more <c-lock> elements. If 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. If an injecting agent (or moderator) wants to act representitive 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 it MUST be able to automatically add a working Cancel-Key header field for all proto-articles with cancelling or superseding attempts from that poster. Other agents MUST NOT add this header field to articles or proto-articles that they process.

If 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. If an injecting agent (or moderator) wants to act representitive for a posting agent without support for the authentication system described in this document, then the same requirements apply as mentioned in . Once an article is injected then this header field MUST NOT be altered. In particular, relaying agents beyond the injecting agent MUST NOT alter it.

The Cancel-Key header field contains one or more of the secret strings that were used to create the Cancel-Lock header field of the original article. Knowledge of at least one of the secret strings is required to create a match for successful authentication. A Cancel-Key header field MAY be added to a proto-article containing a Control or Supersedes header field by the poster or posting agent which will include one or more <c-key> elements. They will correspond to some or all of the <c-lock> elements in the article referenced by the Control (with a "cancel" command as defined in ) or Supersedes header field. If, as mentioned in , an injecting agent (or moderator) has added a Cancel-Lock header field to an article listed in the Control (with "cancel" command as defined in ) or Supersedes header field - representitive for the posting agent - 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. Other agents MUST NOT alter this header field.

If 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. If, as mentioned in an injecting agent (or moderator) has extended the Cancel-Lock header field in an article listed in the Control (with "cancel" command as defined in ) or Supersedes header field - representitive for the posting agent - 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. Once an article is injected then this header field MUST NOT be altered. In particular, relaying agents beyond the injecting agent MUST NOT alter it.

When a serving agent receives an article that attempts to cancel or supersede a previous article via Control (with a "cancel" command as defined in ) or Supersedes header field, the system defined in this document can be used for authentication. The general handling of articles containing such attempts as defined in is not changed by this document. To process the authentication, the received article must contain a Cancel-Key header field and the original article a Cancel-Lock header field. If this is not the case, the authentication is not possible (failed). For the authentication check, every supported <c-key> element from the received article is processed as follows: The <c-key-string> part of the <c-key> element is hashed using the algorithm defined by its <scheme> part. For all <c-lock> elements with the same <scheme> in the original article their <c-lock-string> part is compared to the calculated hash. If one is equal, the authentication is passed and the processing of further elements can be aborted. If no match was found and there are no more <c-key> elements to process, the authentication failed.

The following algorithm is RECOMMENDED to calculate the key "K" based on a local secret <sec>. The result of the function:

K = HMAC(uid+mid, sec)

is the key "K" for an article with Message-ID <mid> that belongs to the User-ID <uid> (e.g. the login name of the user). HMAC is outlined in . HMAC is computed over the data <uid+mid> (with '+' representing the concatenation operation), using <sec> as a secret key held locally that can be used for multiple articles. This method removes the need for a per-article database containing the keys used for every article. A posting agent must add the Message-ID header field to the proto-article itself and use the content of the header field body as <mid> (including literal angle brackets). The User-ID <uid> must not contain angle brackets (to ensure that concatenation of different <uid> and <mid> elements cannot give the same results). A posting agent, that uses a dedicated local secret <sec> for every user, should use an empty string for the <uid> part. In general every agent must not use the same secret <sec> if multiple <c-lock> elements are added. The local secret <sec> should have a length of at least the output size of the hash function that is used by HMAC (256 bit / 32 octets for SHA256) and must be a random value. Note that the hash algorithm used as base for the HMAC operation is not required to be the same as specified by <scheme>. An agent that verifies a Cancel-Key header field body simply checks whether one of its <c-key> elements matches one of the <c-lock> elements with the same <scheme> in the Cancel-Lock header field body of the original article. Common libraries like OpenSSL can be used for the cryptographic operations.

Example data for creation of a <c-lock> element with HMAC-SHA256 and empty string as <uid> (as suggested in for posting agents):

Message-ID: <12345@mid.example>

mid: <12345@mid.example> sec: ExampleSecret K : HMAC-SHA256(mid, sec) ;mid used as data, sec as secret key

Calculation of Base64(K) using the OpenSSL command line tools in a POSIX shell:

$ printf "%s" "<12345@mid.example>" \ | openssl dgst -sha256 -hmac "ExampleSecret" -binary \ | openssl enc -base64 qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=

This can be used as <c-key-string> for cancelling or superseding the article <12345@mid.example>. Calculation of Base64(SHA256(Base64(K))) required for <c-lock-string> using the OpenSSL command line tools in a POSIX shell:

$ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \ | openssl dgst -sha256 -binary \ | openssl enc -base64 s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=

Inserted into the Cancel-Lock header field body of article <12345@mid.example> it looks like this:

Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=

Inserted into the Cancel-Key header field body of an article that should cancel or supersede article <12345@mid.example> it looks like this:

Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=

Example data for creation of a <c-lock> element with HMAC-SHA256 and "JaneDoe" as <uid> (as suggested in ):

Message-ID: <12345@mid.example>

uid: JaneDoe mid: <12345@mid.example> sec: AnotherSecret K : HMAC-SHA256(uid+mid, sec) ;uid+mid as data, sec as secret key

Calculation of Base64(K) using the OpenSSL command line tools in a POSIX shell:

$ printf "%s" "JaneDoe<12345@mid.example>" \ | openssl dgst -sha256 -hmac "AnotherSecret" -binary \ | openssl enc -base64 yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=

This can be used as <c-key-string> for cancelling or superseding the article <12345@mid.example>. Calculation of Base64(SHA256(Base64(K))) required for <c-lock-string> using the OpenSSL command line tools in a POSIX shell:

$ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \ | openssl dgst -sha256 -binary \ | openssl enc -base64 NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=

Inserted into the Cancel-Lock header field body of article <12345@mid.example> it looks like this:

Cancel-Lock: sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=

Inserted into the Cancel-Key header field body of an article that should cancel or supersede article <12345@mid.example> it looks like this:

Cancel-Key: sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=

Other matching pair of Cancel-Lock and Cancel-Key header fields:

Cancel-Lock: sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= Cancel-Key: sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=

With obsolete syntax (uses a <c-key-string> with invalid/missing Base64 padding):

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

Let's assume that all the examples above are associated to the same article (e.g. created by different agents):

Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4= Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA= sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys= sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8= ShA1:aaaBBBcccDDDeeeFFF

Remember that <scheme> must be parsed case insensitive.

Manual checks using the OpenSSL command line tools in a POSIX shell:

$ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \ | openssl dgst -sha256 -binary \ | openssl enc -base64 s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc= $ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \ | openssl dgst -sha256 -binary \ | openssl enc -base64 NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE= $ printf "%s" "sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=" \ | openssl dgst -sha256 -binary \ | openssl enc -base64 RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo= $ printf "%s" "aaaBBBcccDDDeeeFFF" \ | openssl dgst -sha1 -binary \ | openssl enc -base64 bNXHc6ohSmeHaRHHW56BIWZJt+4=

Implementations of earlier drafts of this specification defined a different value for <scheme> than this version. The following value for <scheme> is now deprecated and SHOULD NOT be generated anymore. Serving agents SHOULD still accept it for a transition period as long as the corresponding hash function is not considered unsafe (see for details), or already marked as OBSOLETE in the Netnews Cancel-Lock hash algorithm registry ().

obs-scheme = "sha1"

It is important for backward compatibility that the deprecated value for <scheme> is not phased out too early. Security and compatibility concerns should be carefully weighed before choosing to remove <obs-scheme> from existing implementations (or not implementing it in new ones). Earlier drafts of this specification allowed more liberal syntax for <c-key-string>:

obs-c-key-string = 1*base64-octet base64-octet = ALPHA / DIGIT / "+" / "/" / "="

<obs-c-key-string> SHOULD NOT be generated but MUST be accepted.

The authentication system defined in this document provides no integrity checking properties. Arbitrary modifications can be applied to an article on its way through the network, regardless of the presence of a Cancel-Key header field. A serving agent, who receives an article that contains a Cancel-Key header field with a matching <c-key> element, only get the information that the withdrawal of the target article was approved by a legitimate person or agent. Example: A valid <c-key> element is extracted from a cancel control article and inserted into a forged supersede article. All servers on the network that receive the forged supersede article before the cancel control article should accept the forged supersede. But because everybody can post articles with forged identity information in the header (same as with spam e-mail), the same result can be achieved by sending a forged new article using no authentication system at all. For originator and integrity checks a signature based authentication system is required (normally OpenPGP is used for this purpose). Both systems can be combined. The important property of the hash function used for <scheme> is the preimage resistance. A successful preimage attack either reveals the real Cancel-Key (that was used to create the Cancel-Lock of the original article) or gives a different Cancel-Key (that matches a Cancel-Lock too). This would break the authentication system defined in this document. Collision resistance of the hash function used for <scheme> is less important. Finding two <c-key> elements for the Cancel-Key header field that match to a <c-lock> element of an arbitrary Cancel-Lock header field is not helpful to break the authentication system defined in this document (if a specific article is defined as target). Only collateral damage by arbitrary cancel or supersede is possible. Currently there is no known practicable preimage and second preimage attack against the hash function SHA1. Therefore there is no hurry to replace it. The reasons why this document specifies hash functions from the SHA2 family are: The last draft for the authentication system defined in this document is nearly two decades old. The client side implementations are moving forward extremely slowly too (newsreaders from the last millennium are still in heavy use). What is defined today should be strong enough for at least the next decades. The collision resistance of SHA1 is already broken, therefore it is now obsolete for digital signatures as used in TLS. It is intended that an implementation of the authentication system defined in this document can share the same cryptographic library functions that are used for TLS. It is intended that the same hash function can be used for <scheme> and (as base) for the HMAC that is suggested in . See notes below for HMAC-MD5 and HMAC-SHA1. The SHA2 family of hash algorithms is widely supported by cryptographic libraries. In contrast, SHA3 is currently not supported by e.g. OpenSSL. The operation HMAC(uid+mid, sec) as suggested in must be able to protect the local secret <sec>. The Message-ID <mid> is public (in the Message-ID header field body) and <uid> is optional. An attacker who wants to steal/use a local secret only need to break this algorithm (regardless of <scheme>), because Cancel-Key header fields are explicitly published for every request to cancel or supersede existing articles. Even if HMAC-MD5 and HMAC-SHA1 are not considered broken today, it is desired to have some more security margin here. Breaking <scheme> only allows to authenticate a single forged cancel or supersede request. With <sec> in hand it is possible to forge such requests for all articles that contain Cancel-Lock header field bodies with elements that are generated with this <sec> in the past. Changing <sec> in regular intervals can be used to mitigate the potential damage. If an implementation chooses to not implement the key calculation algorithm recommended in , or to implement it with HMAC based on a different hash function than <scheme>, the key size used should be at least 128 bit with "sha256" for <scheme> and at least 80 bit with "sha1" for <scheme>. Security review: Should these recommendations remain in the document, or does an RFC exist to refer to with regards to security recommendations?

IANA has registered the following header fields in the Permanent Message Header Field Repository, in accordance with the procedures set out in :

Header field name: Cancel-Lock Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document

Header field name: Cancel-Key Applicable protocol: netnews Status: standard Author/change controller: IETF Specification document(s): This document

The Netnews Cancel-Lock hash algorithm registry will be maintained by IANA. The registry will be available at <https://www.iana.org/assignments/netnews-parameters/ netnews-parameters.xhtml#cancel-lock-hash-algorithms>.

IANA will register new Cancel-Lock hash algorithm names on a First Come First Served basis, as defined in BCP 26 . IANA has the right to reject obviously bogus registration requests, but will perform no review of claims made in the registration form. Registration of a Netnews Cancel-Lock hash algorithm is requested by filling in the following template and sending it via electronic mail to IANA at <iana@iana.org>:

Subject: Registration of Netnews Cancel-Lock hash algorithm X Netnews Cancel-Lock hash algorithm name: Security considerations: Published specification (recommended): Contact for further information: Intended usage: (One of COMMON, LIMITED USE, or OBSOLETE) Owner/Change controller: Note: (Any other information that the author deems relevant may be added here.)

Any name that conforms to the syntax of a Netnews Cancel-Lock hash algorithm (see definition of <scheme> in ) can be used. Especially, Netnews Cancel-Lock algorithms are named by strings consisting of letters, digits, hyphens and/or slashes. Authors may seek community review by posting a specification of their proposed algorithm as an Internet-Draft. Netnews Cancel-Lock hash algorithms intended for widespread use should be standardized through the normal IETF process, when appropriate. The IESG is considered to be the owner of all Netnews Cancel-Lock hash algorithms that are on the IETF Standards Track.

Once a Netnews Cancel-Lock hash algorithm registration has been published by IANA, the owner may request a change to its definition. The change request follows the same procedure as the initial registration request. The owner of a Netnews Cancel-Lock hash algorithm may pass responsibility for the algorithm to another person or agency by informing IANA; this can be done without discussion or review. The IESG may reassign responsibility for a Netnews Cancel-Lock hash algorithm. The most common case of this will be to enable changes to be made to algorithms where the owner of the registration has died, has moved out of contact, or is otherwise unable to make changes that are important to the community. Netnews Cancel-Lock hash algorithm registrations MUST NOT be deleted; algorithms that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended usage" field; such algorithms will be clearly marked in the registry published by IANA. The IESG is considered to be the owner of all Netnews Cancel-Lock hash algorithms that are on the IETF Standards Track.

This section gives a formal definition of the Netnews Cancel-Lock hash algorithms as required by for the IANA registry.

Netnews Cancel-Lock hash algorithm name: md5 Security considerations: See corresponding section of this document Published specification: This document Contact for further information: Author of this document Intended usage: OBSOLETE Owner/Change controller: IESG <iesg@ietf.org> Note: Do not use this algorithm anymore

Netnews Cancel-Lock hash algorithm name: sha1 Security considerations: See corresponding section of this document Published specification: This document Contact for further information: Author of this document Intended usage: LIMITED USE Owner/Change controller: IESG <iesg@ietf.org> Note: This algorithm is intended for backward compatibility

Netnews Cancel-Lock hash algorithm name: sha224 Security considerations: See corresponding section of this document Published specification: This document Contact for further information: Author of this document Intended usage: LIMITED USE Owner/Change controller: IESG <iesg@ietf.org> Note: sha256 should be used instead, this is a truncated variant of it

Netnews Cancel-Lock hash algorithm name: sha256 Security considerations: See corresponding section of this document Published specification: This document Contact for further information: Author of this document Intended usage: COMMON Owner/Change controller: IESG <iesg@ietf.org> Note: This algorithm is mandatory to implement

Netnews Cancel-Lock hash algorithm name: sha384 Security considerations: See corresponding section of this document Published specification: This document Contact for further information: Author of this document Intended usage: LIMITED USE Owner/Change controller: IESG <iesg@ietf.org> Note: sha512 should be used instead, this is a truncated variant of it

Netnews Cancel-Lock hash algorithm name: sha512 Security considerations: See corresponding section of this document Published specification: This document Contact for further information: Author of this document Intended usage: COMMON Owner/Change controller: IESG <iesg@ietf.org> Note: This algorithm is optional

&rfc2119; &rfc3864; &rfc4648; &rfc5226; &rfc5234; &rfc5536; &rfc5537; &rfc6234; &rfc1321; &rfc2104; &rfc3174; &rfc4880; &rfc6151; National Institute of Standards and Technology

The author acknowledges the original author of the Cancel-Lock authentication system as documented in draft-ietf-usefor-cancel-lock: Simon Lyall. He has written the original draft and former version and approved the usage of his work for this document. This document is mostly based on his work and was originally intended as revision 02. It must be renamed because the USEFOR IETF WG is now closed. The author would like to thank the following individuals for contributing their ideas and reviewing this specification: Russ Allbery, Urs Janßen, Richard Kettlewell, Marcel Logen, Holger Marzen, Dennis Preiser, Emil Schuster. And Peter Faust and Alfred Peters for providing statistic data about the algorithms currently in use. Special thanks to the Document Shepherd, Julien Élie and to the Responsible Area Director, Alexey Melnikov.

Modified text in and to make it clear that an injecting agent only must be able to authenticate the poster if it wants to act representitive for him. Added/moved general description text to to make things easier to understand (suggested by GEN-Art Last Call review). Removed text for importance of second preimage resistance in (suggested by Secdir review). Added note that local secret must be random in (suggested by Secdir review). Added note that <uid> is not allowed to contain angle brackets in (suggested by Secdir review). Changed copyright notice (because Simon Lyall has licensed his work to the IETF Trust in the meantime). Fixed spelling in , , and (reported by Julien Élie). Changed proposed location of IANA registry in . Should be more consistent with existing registries now (suggested by Julien Élie) Added note to not use the same secret if multiple <c-lock> elements are added in and (suggested by Secdir review). Unified the term "cancel control article". Added notes for impersonation and content forging attacks in . Description text modified in .

Added note that the IESG is the owner of all Netnews Cancel-Lock hash algorithms that are on the IETF Standards Track in . Changed the algorithm from informative to RECOMMENDED in . Replaced "code-string" with "c-lock-string" for Step 2 in . Replaced "code-string" with "c-key-string" for Step 1 in . Added a short explanation in . Added a short explanation in . Replaced link to RFC2045 with link to RFC4648 in . Replaced normative reference RFC2045 (for Base64 algorithm) with RFC4648. Added case insensitivity note in . RFC6234 (listed in the downref registry) is now a normative reference (formerly informative) as recommended by Shepherd Write-Up. NIST SHS standard is now an informative reference (formerly normative) as recommended by Shepherd Write-Up. Added "sha224" and "sha384" schemes in (because implementations exists that supports them). Refer to instead of for hash algorithm registry. Fixed some typos. Fixed line length in .

Added note for change interval of <sec> in . Changed wording in . Splitted into multiple subsections. Added example with UID in . Changed "SHOULD NOT" to uppercase in . Reformatted , and . Fixed spelling in .

Added . Added note about algorithm names in . Added "/" to scheme-char in . Removed case sensitivity of scheme and normative reference to RFC7405 in again. Added "sha512" scheme in . Changed wording in . Fixed typo "canceling" in . Changed calculation formulas to use "Base64" in and . Added obsolete algorithm "md5" in . Added note that posting agents should add the Message-ID header field to proto-articles and use its content for <mid> in . Added <uid> part to key calculation in . Added note to generate CFWS without comments in and . Changed ABNF to allow CFWS at the beginning of header fields in and . Changed wording for "header"/"header field"/"header field body". Added . Changed wording in . Allowed additional whitespace at the beginning of header fields in and . Changed definition of "c-key-string" in . Added "obs-c-key-string" to . Fixed typo in ("c-lock" replaced by "c-key"). Added key length recommendation in . Renamed "sha-256" scheme to "sha256". Modified header and abstract section to list RFC5537 as updated by this document again. Added "USEFOR-CANCEL-LOCK" as informative reference. Changed wording in .

Changed wording in . Added example for HMAC calculation in . Changed wording in . Added use cases to . Replaced wording "injecting-agent" by "injecting agent". Added Definition for "LOWER" in . Added . Added . Added new entries for header field registry in . Removed recommendation that moderators and injecting agents should add only one Cancel-Lock or Cancel-Key resprectively to the list in , and . Added missing headerfield termination to and . Removed definition for "code-string" from . Added stricter definition "c-lock-string" to . Added backward compatible definition "c-key-string" to . Use different wording in . Changed wording to reflect that an injecting agent is allowed to create Cancel-Lock headerfields in . Fixed wording and typo in . Added normative reference to RFC7405 because case-sensitivity is used in ABNF. Added reference to RFC5536 (Section 2.2) in . Added references to RFC4880 and RFC5537 in . Replaced the wordings "remove" by "cancel" and "replace" by "supersede". Modified header and abstract section to no longer list RFC5536 and RFC5537 as updated by this document.

Added additional note that deprecated "scheme" values should be preserved for backward compatibility as long as reasonable. Removed deprectated scheme "md5" (not in use anymore). Added descriptions how to generate "code-string" to and . Removed length limitiation in ABNF of "scheme". Changed copyright notice to use text from TLP section 6.c.iii. Removed references from "abstract" section. Changed "SHOULD NOT" to uppercase in . Added line wraps to CLI commands in .

Renamed document because the USEFOR IETF WG is now closed. Added more details how to check Cancel-Key header fields in . Added more details to . Added updated ABNF for Cancel-Lock and Cancel-Key header fields. Deprecated "md5" and "sha1" schemes. Added "sha-256" scheme. Reworded the abstract section and added references. Added note to other authentication systems to . Added command line check examples to .

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 injection agents.