doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc8315.txt b/doc/rfc/rfc8315.txt
new file mode 100644
index 0000000..af7cb0d
--- /dev/null
+++ b/doc/rfc/rfc8315.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       M. Baeuerle
+Request for Comments: 8315                                STZ Elektronik
+Updates: 5537                                              February 2018
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                    Cancel-Locks in Netnews Articles
+
+Abstract
+
+   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 of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8315.
+
+Copyright Notice
+
+   Copyright (c) 2018 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+Baeuerle                     Standards Track                    [Page 1]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................3
+   2. Header Fields ...................................................3
+      2.1. Cancel-Lock ................................................4
+      2.2. Cancel-Key .................................................4
+   3. Use .............................................................5
+      3.1. Adding an Initial Cancel-Lock Header Field to a
+           Proto-Article ..............................................5
+      3.2. Extending the Cancel-Lock Header Field of a Proto-Article ..6
+      3.3. Adding a Cancel-Key Header Field to a Proto-Article ........6
+      3.4. Extending the Cancel-Key Header Field of a Proto-Article ...7
+      3.5. Check a Cancel-Key Header Field ............................7
+   4. Calculating the Key Data ........................................8
+   5. Examples ........................................................9
+      5.1. Without UID ................................................9
+      5.2. With UID ..................................................10
+      5.3. Other Examples ............................................11
+      5.4. Manual Checks .............................................12
+   6. Obsolete Syntax ................................................12
+   7. Security Considerations ........................................13
+   8. IANA Considerations ............................................15
+      8.1. Algorithm Name Registration Procedure .....................16
+      8.2. Change Control ............................................16
+      8.3. Registration of the Netnews Cancel-Lock Hash Algorithms ...17
+   9. References .....................................................18
+      9.1. Normative References ......................................18
+      9.2. Informative References ....................................19
+   Acknowledgements ..................................................20
+   Author's Address ..................................................20
+
+1.  Introduction
+
+   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 the poster, posting agent, moderator, or
+   injecting agent that processed the original article has requested to
+   withdraw it via the use of a cancel control article
+   ([RFC5537] Section 5.3) or a Supersedes header field
+   ([RFC5537] Section 5.4).
+
+   This document defines two new header fields: Cancel-Lock and
+   Cancel-Key.  The Cancel-Lock header field contains hashes of secret
+   data.  The preimages can later be used in the Cancel-Key header field
+   to authenticate a cancel or supersede request.
+
+
+
+
+
+Baeuerle                     Standards Track                    [Page 2]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   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
+   ([RFC5537] Section 5.2), an OpenPGP [RFC4880] signature is
+   appropriate.
+
+1.1.  Conventions Used in This Document
+
+   Any term not defined in this document has the same meaning as it does
+   in [RFC5536] or [RFC5537].
+
+   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
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Header Fields
+
+   This section describes the formal syntax of the new header fields
+   using ABNF [RFC5234].  Non-terminals not defined in this document are
+   defined in Section 3 of [RFC5536].
+
+   The new header fields Cancel-Lock and Cancel-Key are defined by this
+   document, extending the list of article header fields defined in
+   [RFC5536].
+
+   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 [RFC6234]; see also
+   [RFC1321] and [RFC6151] for MD5, [RFC3174] for SHA1, and [SHA] for
+   the SHA2 family.  The Base64 encoding used is defined in Section 4 of
+   [RFC4648].
+
+   This document defines two values for <scheme>: "sha256" and "sha512".
+   The hash algorithm "sha256" is mandatory to implement.
+
+
+
+
+
+Baeuerle                     Standards Track                    [Page 3]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   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 Algorithms" registry (Section 8.3) because
+   implementations exist that support them.  Implementations SHOULD NOT
+   use the hash algorithms "sha224" and "sha384" to generate <scheme>.
+
+2.1.  Cancel-Lock
+
+      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 (comments and/or folding whitespace) 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.
+
+2.2.  Cancel-Key
+
+      cancel-key   = "Cancel-Key:" SP c-key-list CRLF
+      c-key-list   = [CFWS] c-key *(CFWS c-key) [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.
+
+
+
+
+Baeuerle                     Standards Track                    [Page 4]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   <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 Section 2.1 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 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.  Use
+
+   Use cases:
+
+   o  The poster of an article wants to cancel or supersede existing
+      articles.
+
+   o  A moderator wants the ability to cancel articles after approving
+      them.
+
+   o  An injecting agent wants to act as a representative for a posting
+      agent that has no support for the authentication system described
+      in this document.
+
+   o  A news administrator wants the ability to cancel articles that
+      were injected by its system (because, for example, they violate
+      its abuse policy).
+
+3.1.  Adding an Initial Cancel-Lock Header Field to a Proto-Article
+
+   A 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.
+
+   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 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.
+
+
+
+
+
+
+Baeuerle                     Standards Track                    [Page 5]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   If 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.
+
+   Other 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
+
+   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 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.
+
+   If 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 the same requirements apply as those
+   mentioned in Section 3.1.
+
+   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.
+
+3.3.  Adding a Cancel-Key Header Field to a Proto-Article
+
+   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
+   and 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 [RFC5537]) or
+   Supersedes header field.
+
+
+
+
+
+
+
+
+Baeuerle                     Standards Track                    [Page 6]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   If, 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.
+
+   Other agents MUST NOT alter this header field.
+
+3.4.  Extending the Cancel-Key Header Field of a Proto-Article
+
+   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 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.
+
+   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.
+
+3.5.  Check a Cancel-Key Header Field
+
+   When a relaying or serving agent receives an article that attempts to
+   cancel or supersede a previous article via a Control (with a "cancel"
+   command as defined in [RFC5537]) 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
+   [RFC5537] is not changed by this document.
+
+   To process the authentication, the received article must contain a
+   Cancel-Key header field and the original article must contain a
+   Cancel-Lock header field.  If this is not the case, the
+   authentication is not possible (failed).
+
+
+
+
+
+
+
+Baeuerle                     Standards Track                    [Page 7]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   For the authentication check, every supported <c-key> element from
+   the received article is processed as follows:
+
+   1.  The <c-key-string> part of the <c-key> element is hashed using
+       the algorithm defined by its <scheme> part.
+
+   2.  For each <c-lock> element with the same <scheme> in the original
+       article, its <c-lock-string> part is compared to the calculated
+       hash.
+
+   3.  If a <c-lock-string> part is equal to the calculated hash, the
+       authentication is passed and the processing of further elements
+       can be aborted.
+
+   4.  If no match was found and there are no more <c-key> elements to
+       process, the authentication failed.
+
+4.  Calculating the Key Data
+
+   The following algorithm is RECOMMENDED to calculate the key "K" based
+   on a local secret <sec>.
+
+   The result of the function
+
+      K = HMAC(sec, uid+mid)
+
+   is the key "K" for an article with a Message-ID <mid> that belongs to
+   the User-ID (or UID) <uid> (e.g., the login name of the user).  The
+   Hashed Message Authentication Code (HMAC) is outlined in [RFC2104].
+   The 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> (excluding whitespace but 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, different values for the secret <sec> must be used if
+   multiple <c-lock> elements are added by a single agent.
+
+
+
+Baeuerle                     Standards Track                    [Page 8]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   The local secret <sec> should have a length of at least the output
+   size of the hash function that is used by the HMAC
+   (256 bits / 32 octets for SHA256) and must be a cryptographically
+   random value [RFC4086].
+
+   Note that the hash algorithm used as the base for the HMAC operation
+   is not required to be the same as that 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.
+
+5.  Examples
+
+5.1.  Without UID
+
+   Example data for creation of a <c-lock> element with HMAC-SHA256 and
+   an empty string as <uid> (as recommended in Section 4 for posting
+   agents):
+
+      Message-ID: <12345@mid.example>
+
+      mid: <12345@mid.example>
+      sec: ExampleSecret
+      K  : HMAC-SHA256(sec, mid) ;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>.
+
+
+
+
+
+
+
+
+
+
+
+
+Baeuerle                     Standards Track                    [Page 9]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   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 the 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 the article <12345@mid.example>, it looks
+   like this:
+
+      Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=
+
+5.2.  With UID
+
+   Example data for creation of a <c-lock> element with HMAC-SHA256 and
+   "JaneDoe" as <uid> (as recommended in Section 4):
+
+      Message-ID: <12345@mid.example>
+
+      uid: JaneDoe
+      mid: <12345@mid.example>
+      sec: AnotherSecret
+      K  : HMAC-SHA256(sec, uid+mid) ;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>.
+
+
+
+
+
+
+
+
+
+
+Baeuerle                     Standards Track                   [Page 10]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   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 the 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 the article <12345@mid.example>, it looks
+   like this:
+
+      Cancel-Key: sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=
+
+5.3.  Other Examples
+
+   Another 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 parsing for <scheme> must be case insensitive.
+
+
+
+
+
+
+Baeuerle                     Standards Track                   [Page 11]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+5.4.  Manual Checks
+
+   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=
+
+6.  Obsolete Syntax
+
+   Implementations of earlier draft versions 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 Section 7 for details) or already marked as
+   OBSOLETE in the "Netnews Cancel-Lock Hash Algorithms" registry
+   (Section 8.3).
+
+      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).
+
+
+
+
+
+
+
+
+
+Baeuerle                     Standards Track                   [Page 12]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   Earlier draft versions 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.
+
+7.  Security Considerations
+
+   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 that
+   receives an article that contains a Cancel-Key header field with a
+   matching <c-key> element only gets 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 email), 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 [RFC4880] 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 the
+   target).  Only collateral damage by arbitrary cancel or supersede is
+   possible.
+
+
+
+
+
+Baeuerle                     Standards Track                   [Page 13]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   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:
+
+   o  The previous specification of the authentication system defined in
+      this document -- [USEFOR-CANCEL-LOCK] -- 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 the
+      next two decades or so.
+
+   o  The collision resistance of SHA1 is already broken; therefore, it
+      is now obsolete for digital signatures as used in Transport Layer
+      Security (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.
+
+   o  It is intended that the same hash function can be used for
+      <scheme> and (as the base) for the HMAC that is recommended in
+      Section 4.  See notes below for HMAC-MD5 and HMAC-SHA1.
+
+   o  The SHA2 family of hash algorithms is widely supported by
+      cryptographic libraries.  In contrast, SHA3 is currently too
+      recent and has not been studied enough to be considered more
+      secure than SHA2.
+
+   The operation HMAC(sec, uid+mid) as recommended in Section 4 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 needs 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 a greater margin for security here.  Breaking
+   <scheme> only allows the authentication of 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 were generated with this <sec> in the past.
+   Changing <sec> at regular intervals can be used to mitigate potential
+   damage.
+
+
+
+
+
+
+
+
+Baeuerle                     Standards Track                   [Page 14]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   If an agent adds or appends multiple <c-lock> elements, it must not
+   use the same K for them (by using different secrets (<sec>)).  Adding
+   multiple <c-lock> elements with the same <scheme> and the same K
+   makes no sense (because it would result in identical <c-lock>
+   elements); therefore, the case of different <scheme> values is
+   relevant: a preimage attack on the different hash algorithms may be
+   easier if the attacker knows that the output of those hash algorithms
+   was created with the same input.
+
+   If an implementation chooses to not implement the key calculation
+   algorithm recommended in Section 4 or to implement it with the HMAC
+   based on a different hash function than <scheme>, the key size used
+   should match the output size of the hash function used for <scheme>.
+
+8.  IANA Considerations
+
+   IANA has registered the following header fields in the "Permanent
+   Message Header Field Names" registry, in accordance with the
+   procedures set out in [RFC3864]:
+
+      Header field name: Cancel-Lock
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF
+      Specification document(s): RFC 8315
+
+      Header field name: Cancel-Key
+      Applicable protocol: netnews
+      Status: standard
+      Author/change controller: IETF
+      Specification document(s): RFC 8315
+
+   The "Netnews Cancel-Lock Hash Algorithms" registry is maintained by
+   IANA.
+
+   The registry is available at
+   <https://www.iana.org/assignments/netnews-parameters/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baeuerle                     Standards Track                   [Page 15]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+8.1.  Algorithm Name Registration Procedure
+
+   IANA will register new Cancel-Lock hash algorithm names on a First
+   Come First Served basis, as defined in BCP 26 [RFC8126].  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 the definition of <scheme> in Section 2) can be used;
+   in particular, 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.
+
+8.2.  Change Control
+
+   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.
+
+
+
+
+
+
+
+Baeuerle                     Standards Track                   [Page 16]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   The IESG may reassign responsibility for a Netnews Cancel-Lock hash
+   algorithm.  The most common reason for this would 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.
+
+8.3.  Registration of the Netnews Cancel-Lock Hash Algorithms
+
+   This section gives a formal definition of the Netnews Cancel-Lock
+   hash algorithms as required by Section 8.1 for the IANA registry.
+
+      Netnews Cancel-Lock hash algorithm name: md5
+      Security considerations: See Section 7 of this document
+      Published specification: RFC 8315
+      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 Section 7 of this document
+      Published specification: RFC 8315
+      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 Section 7 of this document
+      Published specification: RFC 8315
+      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
+
+
+
+
+
+
+
+
+
+Baeuerle                     Standards Track                   [Page 17]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+      Netnews Cancel-Lock hash algorithm name: sha256
+      Security considerations: See Section 7 this document
+      Published specification: RFC 8315
+      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 Section 7 of this document
+      Published specification: RFC 8315
+      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
+
+      Netnews Cancel-Lock hash algorithm name: sha512
+      Security considerations: See Section 7 of this document
+      Published specification: RFC 8315
+      Contact for further information: Author of this document
+      Intended usage: COMMON
+      Owner/Change controller: IESG <iesg@ietf.org>
+      Note: This algorithm is optional
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
+              Procedures for Message Header Fields", BCP 90, RFC 3864,
+              DOI 10.17487/RFC3864, September 2004,
+              <https://www.rfc-editor.org/info/rfc3864>.
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+              <https://www.rfc-editor.org/info/rfc4648>.
+
+
+
+
+
+Baeuerle                     Standards Track                   [Page 18]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
+              Syntax Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5536]  Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews
+              Article Format", RFC 5536, DOI 10.17487/RFC5536,
+              November 2009, <https://www.rfc-editor.org/info/rfc5536>.
+
+   [RFC5537]  Allbery, R., Ed., and C. Lindsey, "Netnews Architecture
+              and Protocols", RFC 5537, DOI 10.17487/RFC5537,
+              November 2009, <https://www.rfc-editor.org/info/rfc5537>.
+
+   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
+              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
+              DOI 10.17487/RFC6234, May 2011,
+              <https://www.rfc-editor.org/info/rfc6234>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+              RFC 2119 Key Words", BCP 14, RFC 8174,
+              DOI 10.17487/RFC8174, May 2017,
+              <https://www.rfc-editor.org/info/rfc8174>.
+
+9.2.  Informative References
+
+   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+              DOI 10.17487/RFC1321, April 1992,
+              <https://www.rfc-editor.org/info/rfc1321>.
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
+              Keyed-Hashing for Message Authentication", RFC 2104,
+              DOI 10.17487/RFC2104, February 1997,
+              <https://www.rfc-editor.org/info/rfc2104>.
+
+   [RFC3174]  Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
+              (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
+              <https://www.rfc-editor.org/info/rfc3174>.
+
+   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+              Thayer, "OpenPGP Message Format", RFC 4880,
+              DOI 10.17487/RFC4880, November 2007,
+              <https://www.rfc-editor.org/info/rfc4880>.
+
+
+
+
+Baeuerle                     Standards Track                   [Page 19]
+
+RFC 8315                      Cancel-Locks                 February 2018
+
+
+   [RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
+              for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
+              RFC 6151, DOI 10.17487/RFC6151, March 2011,
+              <https://www.rfc-editor.org/info/rfc6151>.
+
+   [SHA]      National Institute of Standards and Technology, "Secure
+              Hash Standard (SHS)", FIPS 180-4,
+              DOI 10.6028/NIST.FIPS.180-4, August 2015,
+              <http://nvlpubs.nist.gov/nistpubs/FIPS/
+              NIST.FIPS.180-4.pdf>.
+
+   [USEFOR-CANCEL-LOCK]
+              Lyall, S., "Cancel-Locks in Usenet articles.", Work in
+              Progress, draft-ietf-usefor-cancel-lock-01, November 1998.
+
+Acknowledgements
+
+   The author acknowledges the original author of the Cancel-Lock
+   authentication system, as documented in [USEFOR-CANCEL-LOCK]: Simon
+   Lyall.  Simon wrote the original document and approved the usage of
+   his work for this document.  This document is mostly based on his
+   work.  (It was originally intended as revision 02 but was 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 Janssen, Richard Kettlewell, Marcel Logen, Holger
+   Marzen, Dennis Preiser, and Emil Schuster.  Thanks also to Peter
+   Faust and Alfred Peters for providing statistical data about the
+   algorithms currently in use.
+
+   Special thanks to the Document Shepherd, Julien Elie; and to the
+   responsible Area Director, Alexey Melnikov.
+
+Author's Address
+
+   Michael Baeuerle
+   STZ Elektronik
+   Hofener Weg 33C
+   Remseck, Baden-Wuerttemberg  71686
+   Germany
+
+   Fax:   +49 7146 999061
+   Email: michael.baeuerle@stz-e.de
+
+
+
+
+
+
+
+Baeuerle                     Standards Track                   [Page 20]
+