Internet Engineering Task Force (IETF) M. Baeuerle
Request for Comments: 8315 STZ Elektronik
Updates: 5537 February 2018
Category: Standards Track
ISSN: 2070-1721
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
取消Netnews文章中的锁定
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.
此文档定义了Netnews文章格式的扩展，可用于验证现有文章的撤回。本文件更新了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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................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
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).
本文件中定义的认证系统旨在用作验证物品撤回有效性的简单方法；也就是说，处理原始文章的海报、发帖代理、版主或注入代理已通过使用取消控制文章（[RFC5537]第5.3节）或替代标题字段（[RFC5537]第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.
此文档定义了两个新的标题字段：取消锁定和取消密钥。Cancel Lock标头字段包含机密数据的散列。可以稍后在“取消密钥头”字段中使用前映像来验证取消或取代请求。
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.
还有其他具有不同属性的身份验证系统。当每个人都应该能够验证发起者是谁时，例如控制文章添加或删除新闻组（[RFC5537]第5.2节），OpenPGP[RFC4880]签名是合适的。
Any term not defined in this document has the same meaning as it does in [RFC5536] or [RFC5537].
本文件中未定义的任何术语的含义与[RFC5536]或[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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
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].
本节介绍使用ABNF[RFC5234]的新标题字段的形式语法。[RFC5536]第3节定义了本文件中未定义的非终端。
The new header fields Cancel-Lock and Cancel-Key are defined by this document, extending the list of article header fields defined in [RFC5536].
本文档定义了新的标题字段Cancel Lock和Cancel Key，扩展了[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>：
scheme = "sha256" / "sha512" / 1*scheme-char / obs-scheme
scheme-char = ALPHA / DIGIT / "-" / "/"
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].
[RFC6234]中定义了<scheme>的哈希算法；MD5参见[RFC1321]和[RFC6151]，SHA1参见[RFC3174]，SHA2参见[SHA]。[RFC4648]第4节中定义了使用的Base64编码。
This document defines two values for <scheme>: "sha256" and "sha512". The hash algorithm "sha256" is mandatory to implement.
本文档为<scheme>定义了两个值：“sha256”和“sha512”。必须实现哈希算法“sha256”。
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>.
由于<scheme>的哈希算法无法协商，因此应避免不必要的哈希算法扩散。散列算法“sha224”和“sha384”仅添加到“Netnews取消锁定散列算法”注册表（第8.3节），因为存在支持它们的实现。实现不应使用哈希算法“sha224”和“sha384”来生成<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 "="
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.
CFWS中的注释（注释和/或折叠空格）可能会导致互操作性问题，因此不应生成注释，但必须接受。
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.
如果实现不支持<scheme>，则必须跳过相应的<c-lock>元素，并且不能忽略后续的<c-lock>元素。
<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):
<c-lock-string>是Base64编码密钥“K”的哈希操作（由<scheme>定义）的Base64编码输出，该哈希操作旨在对创建或处理（分别）原型物品直至注入（包括）的人员或代理进行身份验证：
Base64(hash(Base64(K)))
Base64(hash(Base64(K)))
Because of the one-way nature of the hash operation, the key "K" is not revealed.
由于散列操作的单向性，密钥“K”不会被显示。
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
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.
CFWS中的注释可能会导致互操作性问题，因此不应生成注释，但必须接受注释。
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.
如果实现不支持<scheme>，则必须跳过相应的<c-key>元素，并且不能忽略后续的<c-key>元素。
<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:
<c-key-string>是用于在原始文章的Cancel-lock标题字段正文（如本文档第2.1节所定义）中创建<c-lock>元素的Base64编码键“K”：
Base64(K)
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).
上述<c-key-string>的宽松语法定义是与不符合本规范的实现向后兼容所必需的。符合要求的实现应生成有效的Base64（即本文档第2.1节中定义的<c-lock-string>语法），并且必须接受<Base64八位字节>字符的字符串（即本文档第6节中定义的<obs-c-key-string>语法）。
Use cases:
用例：
o The poster of an article wants to cancel or supersede existing articles.
o 文章的海报想要取消或取代现有文章。
o A moderator wants the ability to cancel articles after approving them.
o 版主希望能够在批准文章后取消它们。
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 注射代理希望充当不支持本文档中描述的身份验证系统的过帐代理的代表。
o A news administrator wants the ability to cancel articles that were injected by its system (because, for example, they violate its abuse policy).
o 新闻管理员希望能够取消其系统注入的文章（例如，因为它们违反了其滥用策略）。
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.
海报或发布代理可以将取消锁定标题字段添加到原型文章中，并将包括一个或多个<c-Lock>元素。
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.
如果海报或发布代理没有向原型文章添加取消锁定标题字段，则注入代理（或版主）可以添加一个，包括一个或多个<c-Lock>元素。
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.
如果单个代理将多个<c-lock>元素添加到Cancel lock header字段，则每个<c-lock>元素必须使用唯一的密钥“K”来提高安全性。
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.
其他代理不得将此标题字段添加到他们处理的文章或原始文章中。
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.
如果取消锁定标题字段已经添加到原型文章中，则进一步处理原型文章直至注入代理（包括）的任何代理都可以向标题字段主体中已经存在的元素添加额外的<c-Lock>元素。
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.
如果单个代理将多个<c-lock>元素附加到Cancel lock标头字段，则每个<c-lock>元素必须使用唯一的密钥“K”来提高安全性。
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.
如果注射代理（或主持人）希望在不支持本文件中所述认证系统的情况下担任投递代理的代表，则与第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.
一旦文章被注入，则不得更改此标题字段。特别是，在注入剂之外的中继剂不得改变它。
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.
取消键标题字段可添加到包含控件的原型文章中，或由海报或发布代理取代标题字段，并将包括一个或多个<c-Key>元素。它们将对应于控件引用的文章中的部分或全部<c-lock>元素（使用[RFC5537]中定义的“取消”命令），或取代标题字段。
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.
如第3.1节所述，如果注射代理或主持人（作为投递代理的代表）向控件中列出的物品添加了取消锁定标题字段（使用[RFC5537]中定义的“取消”命令）或取代标题字段，则（假设它验证海报与原始文章的海报相同）它必须添加至少一个与该文章对应的<c-Key>元素的Cancel Key header字段。
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.
如果取消密钥头字段已经添加到原型文章中，则进一步处理原型文章直至注入代理（包括）的任何代理都可以向头字段主体中已经存在的元素添加额外的<c-Key>元素。
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.
如第3.2节所述，如果注射代理或主持人（作为投递代理的代表）扩展了控件中所列文章中的取消锁定标题字段（使用[RFC5537]中定义的“取消”命令）或取代标题字段，则（假设它验证海报与原始文章的海报相同）它必须使用至少一个与该文章对应的<c-Key>元素扩展Cancel Key header字段主体。
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 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.
当中继或服务代理接收到试图通过控件（使用[RFC5537]中定义的“取消”命令）取消或取代前一个项目或取代标题字段的项目时，本文档中定义的系统可用于身份验证。本文件不改变[RFC5537]中定义的包含此类尝试的物品的一般处理方式。
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).
要处理身份验证，收到的项目必须包含“取消密钥”标题字段，而原始项目必须包含“取消锁定”标题字段。如果不是这种情况，则无法进行身份验证（失败）。
For the authentication check, every supported <c-key> element from the received article is processed as follows:
对于身份验证检查，接收到的文章中每个受支持的<c-key>元素的处理如下：
1. The <c-key-string> part of the <c-key> element is hashed using the algorithm defined by its <scheme> part.
1. <c-key>元素的<c-key-string>部分使用其<scheme>部分定义的算法进行散列。
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.
2. 对于原始文章中具有相同<scheme>的每个<c-lock>元素，将其<c-lock-string>部分与计算的哈希进行比较。
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.
3. 如果<c-lock-string>部分等于计算出的散列，则通过身份验证并中止对其他元素的处理。
4. If no match was found and there are no more <c-key> elements to process, the authentication failed.
4. 如果未找到匹配项，并且没有更多的<c-key>元素要处理，则身份验证失败。
The following algorithm is RECOMMENDED to calculate the key "K" based on a local secret <sec>.
建议使用以下算法根据本地密钥<sec>计算密钥“K”。
The result of the function
函数的结果
K = HMAC(sec, uid+mid)
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.
消息ID<mid>属于用户ID（或UID）<UID>（例如，用户的登录名）的文章的键“K”。[RFC2104]中概述了哈希消息认证码（HMAC）。HMAC通过数据<uid+mid>（用“+”表示串联操作）计算，使用<sec>作为本地持有的密钥，可用于多个项目。此方法消除了对包含每篇文章所用密钥的每篇文章数据库的需要。
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).
发帖代理必须将消息ID标题字段添加到原始文章本身，并使用标题字段正文的内容作为<mid>（不包括空格，但包括文字尖括号）。
The User-ID <uid> must not contain angle brackets (to ensure that concatenation of different <uid> and <mid> elements cannot give the same results).
用户ID<uid>不能包含尖括号（以确保不同<uid>和<mid>元素的串联不能产生相同的结果）。
A posting agent that uses a dedicated local secret <sec> for every user should use an empty string for the <uid> part.
为每个用户使用专用本地机密<sec>的发布代理应为<uid>部分使用空字符串。
In general, different values for the secret <sec> must be used if multiple <c-lock> elements are added by a single agent.
通常，如果单个代理添加多个<c-lock>元素，则必须为secret<sec>使用不同的值。
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].
本地机密<sec>的长度应至少等于HMAC使用的哈希函数的输出大小（SHA256为256位/32八位字节），并且必须是加密随机值[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.
请注意，用作HMAC操作基础的哈希算法不需要与<scheme>指定的哈希算法相同。验证取消密钥标题字段正文的代理只需检查其<c-Key>元素之一是否与原始文章的取消锁定标题字段正文中具有相同<scheme>的<c-lock>元素之一匹配。
Common libraries like OpenSSL can be used for the cryptographic operations.
像OpenSSL这样的公共库可以用于加密操作。
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):
创建带有HMAC-SHA256和空字符串为<uid>的<c-lock>元素的示例数据（如第4节中针对过帐代理的建议）：
Message-ID: <12345@mid.example>
Message-ID: <12345@mid.example>
mid: <12345@mid.example>
sec: ExampleSecret
K : HMAC-SHA256(sec, mid) ;mid used as data, sec as secret key
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:
在POSIX shell中使用OpenSSL命令行工具计算Base64（K）：
$ printf "%s" "<12345@mid.example>" \
| openssl dgst -sha256 -hmac "ExampleSecret" -binary \
| openssl enc -base64
qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=
$ 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>.
这可以用作取消或替换文章的<c-key-string><12345@mid.example>.
Calculation of Base64(SHA256(Base64(K))) required for <c-lock-string> using the OpenSSL command-line tools in a POSIX shell:
在POSIX shell中使用OpenSSL命令行工具计算<c-lock-string>所需的Base64（SHA256（Base64（K））：
$ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \
| openssl dgst -sha256 -binary \
| openssl enc -base64
s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=
$ 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:
插入到文章的“取消锁定标题”字段正文中<12345@mid.example>，看起来是这样的：
Cancel-Lock: sha256:s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=
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:
插入到应取消或取代该文章的文章的“取消关键字标题”字段正文中<12345@mid.example>，看起来是这样的：
Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=
Cancel-Key: sha256:qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=
Example data for creation of a <c-lock> element with HMAC-SHA256 and "JaneDoe" as <uid> (as recommended in Section 4):
使用HMAC-SHA256和“JaneDoe”作为<uid>创建<c-lock>元素的示例数据（如第4节所建议）：
Message-ID: <12345@mid.example>
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
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:
在POSIX shell中使用OpenSSL命令行工具计算Base64（K）：
$ printf "%s" "JaneDoe<12345@mid.example>" \
| openssl dgst -sha256 -hmac "AnotherSecret" -binary \
| openssl enc -base64
yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=
$ 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>.
这可以用作取消或替换文章的<c-key-string><12345@mid.example>.
Calculation of Base64(SHA256(Base64(K))) required for <c-lock-string> using the OpenSSL command-line tools in a POSIX shell:
在POSIX shell中使用OpenSSL命令行工具计算<c-lock-string>所需的Base64（SHA256（Base64（K））：
$ printf "%s" "yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=" \
| openssl dgst -sha256 -binary \
| openssl enc -base64
NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=
$ 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:
插入到文章的“取消锁定标题”字段正文中<12345@mid.example>，看起来是这样的：
Cancel-Lock: sha256:NSBTz7BfcQFTCen+U4lQ0VS8VIlZao2b8mxD/xJaaeE=
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:
插入到应取消或取代该文章的文章的“取消关键字标题”字段正文中<12345@mid.example>，看起来是这样的：
Cancel-Key: sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=
Cancel-Key: sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=
Another matching pair of Cancel-Lock and Cancel-Key header fields:
另一对匹配的取消锁定和取消密钥标题字段：
Cancel-Lock: sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo=
Cancel-Key: sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=
Cancel-Lock: sha256:RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo=
Cancel-Key: sha256:sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=
With obsolete syntax (uses a <c-key-string> with invalid/missing Base64 padding):
使用过时语法（使用带有无效/缺少Base64填充的<c-key-string>）：
Cancel-Lock: sha1:bNXHc6ohSmeHaRHHW56BIWZJt+4=
Cancel-Key: ShA1:aaaBBBcccDDDeeeFFF
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
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.
请记住，<scheme>的解析必须不区分大小写。
Manual checks using the OpenSSL command-line tools in a POSIX shell:
在POSIX shell中使用OpenSSL命令行工具进行手动检查：
$ printf "%s" "qv1VXHYiCGjkX/N1nhfYKcAeUn8bCVhrWhoKuBSnpMA=" \
| openssl dgst -sha256 -binary \
| openssl enc -base64
s/pmK/3grrz++29ce2/mQydzJuc7iqHn1nqcJiQTPMc=
$ 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" "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" "sSkDke97Dh78/d+Diu1i3dQ2Fp/EMK3xE2GfEqZlvK8=" \
| openssl dgst -sha256 -binary \
| openssl enc -base64
RrKLp7YCQc9T8HmgSbxwIDlnCDWsgy1awqtiDuhedRo=
$ printf "%s" "aaaBBBcccDDDeeeFFF" \ | openssl dgst -sha1 -binary \ | openssl enc -base64 bNXHc6ohSmeHaRHHW56BIWZJt+4=
$ printf“%s”aaabbbccdddeefff“\| openssl dgst-sha1-binary\| openssl enc-base64 bnxhc6ohsmehahw56biwzjt+4=
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).
本规范早期草案版本的实现为<scheme>定义了与本版本不同的值。<scheme>的以下值现在已弃用，不应再生成。只要相应的散列函数不被认为是不安全的（详见第7节）或在“Netnews取消锁定散列算法”注册表（第8.3节）中已被标记为过时的，服务代理仍应在过渡期内接受它。
obs-scheme = "sha1"
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).
对于向后兼容性来说，<scheme>的不推荐值不要过早地被淘汰是很重要的。在选择从现有实现（或不在新实现中实现）中删除<obs scheme>之前，应仔细权衡安全性和兼容性问题。
Earlier draft versions of this specification allowed more liberal syntax for <c-key-string>:
本规范的早期草案版本允许对<c-key-string>使用更自由的语法：
obs-c-key-string = 1*base64-octet
base64-octet = ALPHA / DIGIT / "+" / "/" / "="
obs-c-key-string = 1*base64-octet
base64-octet = ALPHA / DIGIT / "+" / "/" / "="
<obs-c-key-string> SHOULD NOT be generated but MUST be accepted.
不应生成<obs-c-key-string>，但必须接受。
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.
本文档中定义的身份验证系统不提供完整性检查属性。无论是否存在“取消密钥”标题字段，都可以在文章通过网络时对其进行任意修改。接收包含带有匹配<c-Key>元素的Cancel Key header字段的文章的服务代理仅获取目标文章的撤回已由合法人员或代理批准的信息。
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.
示例：从取消控制项目中提取有效的<c-key>元素，并将其插入伪造的替代项目中。在取消控制项目之前接收伪造替代项目的网络上的所有服务器都应接受伪造替代项目。但是，由于每个人都可以在标题中发布带有伪造身份信息的文章（与垃圾邮件相同），因此，通过发送一篇伪造的新文章（完全不使用身份验证系统），也可以实现相同的结果。
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.
对于发起人和完整性检查，需要基于签名的身份验证系统（通常使用OpenPGP[RFC4880]）。这两种系统可以结合使用。
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.
用于<scheme>的hash函数的重要特性是前图像阻力。成功的前映像攻击要么显示真实的取消密钥（用于创建原始文章的取消锁定），要么提供不同的取消密钥（也与取消锁定匹配）。这将破坏本文档中定义的身份验证系统。
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.
用于<scheme>的哈希函数的抗冲突性不太重要。为Cancel key header字段查找两个与任意Cancel lock header字段的<c-lock>元素匹配的<c-key>元素无助于破坏本文档中定义的身份验证系统（如果将特定项目定义为目标）。仅可通过任意取消或取代造成附带损害。
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:
目前，还没有针对哈希函数SHA1的已知可行的前映像和第二前映像攻击。因此，不必急于更换。本文档指定SHA2系列哈希函数的原因如下：
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 本文档中定义的身份验证系统的先前规范--[USEFOR-CANCEL-LOCK]--已经有近二十年的历史了。客户端实现也进展非常缓慢（上个千年的新闻阅读器仍在大量使用）。今天的定义应该足以支撑未来二十年左右。
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 SHA1的抗碰撞性已经破坏；因此，它现在对于传输层安全（TLS）中使用的数字签名已经过时。本文档中定义的身份验证系统的实现可以共享用于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 第4节中推荐的HMAC的<scheme>和（作为基础）可以使用相同的哈希函数。HMAC-MD5和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.
o 加密库广泛支持SHA2哈希算法家族。相比之下，SHA3目前太晚了，还没有进行足够的研究，认为它比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.
第4节中建议的操作HMAC（sec，uid+mid）必须能够保护本地机密<sec>。消息ID<mid>是公共的（在消息ID头字段正文中），并且<uid>是可选的。想要窃取/使用本地机密的攻击者只需破坏此算法（无论<scheme>），因为取消密钥头字段是为每个取消或取代现有项目的请求显式发布的。
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.
即使HMAC-MD5和HMAC-SHA1今天不被认为是坏的，也希望在这里有更大的安全余量。中断<scheme>仅允许对单个伪造的取消或取代请求进行身份验证。有了<sec>，就可以伪造对所有包含取消锁定标题字段主体的项目的请求，这些字段主体中的元素过去是通过<sec>生成的。定期更改<sec>可用于减轻潜在损害。
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.
如果代理添加或附加了多个<c-lock>元素，则不能对它们使用相同的K（通过使用不同的机密（<sec>）。使用相同的<scheme>和相同的K添加多个<c-lock>元素没有意义（因为这将导致相同的<c-lock>元素）；因此，不同<scheme>值的情况是相关的：如果攻击者知道这些散列算法的输出是使用相同的输入创建的，则对不同散列算法的前映像攻击可能更容易。
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>.
如果实现选择不实现第4节中推荐的密钥计算算法，或基于与<scheme>不同的哈希函数使用HMAC实现，则使用的密钥大小应与<scheme>使用的哈希函数的输出大小相匹配。
IANA has registered the following header fields in the "Permanent Message Header Field Names" registry, in accordance with the procedures set out in [RFC3864]:
IANA已按照[RFC3864]中规定的程序，在“永久消息标题字段名称”注册表中注册了以下标题字段：
Header field name: Cancel-Lock
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): RFC 8315
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
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.
“Netnews取消锁定哈希算法”注册表由IANA维护。
The registry is available at <https://www.iana.org/assignments/netnews-parameters/>.
注册处可于<https://www.iana.org/assignments/netnews-parameters/>.
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.
IANA将按照BCP 26[RFC8126]中的定义，以先到先得的方式注册新的取消锁哈希算法名称。IANA有权拒绝明显虚假的注册请求，但不会对注册表格中的申请进行审查。
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>:
通过填写以下模板并通过电子邮件发送给IANA，请求注册Netnews取消锁定哈希算法<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.)
主题：注册Netnews取消锁定散列算法X Netnews取消锁定散列算法名称：安全注意事项：已发布规范（推荐）：联系以获取更多信息：预期用途：（常用、有限用途或过时）所有者/更改控制器：注：（作者认为相关的任何其他信息可在此添加。）
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.
可以使用符合Netnews取消锁定哈希算法语法的任何名称（参见第2节中<scheme>的定义）；特别是，Netnews取消锁定算法由字母、数字、连字符和/或斜杠组成的字符串命名。
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.
作者可以通过将他们提出的算法的规范发布为互联网草稿来寻求社区审查。适用时，应通过正常的IETF过程对广泛使用的Netnews取消锁定散列算法进行标准化。
The IESG is considered to be the owner of all Netnews Cancel-Lock hash algorithms that are on the IETF Standards Track.
IESG被认为是IETF标准轨道上所有Netnews取消锁哈希算法的所有者。
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.
一旦IANA发布了Netnews取消锁定哈希算法注册，所有者可以请求更改其定义。变更请求遵循与初始注册请求相同的程序。
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.
Netnews取消锁定散列算法的所有者可以通过通知IANA将该算法的责任转交给另一个人或机构；这可以在不进行讨论或审查的情况下完成。
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.
IESG可以重新分配Netnews取消锁定哈希算法的责任。最常见的原因是，当注册所有者去世、失去联系或无法进行对社区重要的更改时，可以对算法进行更改。
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.
不得删除Netnews取消锁定哈希算法注册。不再被认为适合使用的算法可以通过更改其“预期用途”字段宣布为过时；这些算法将在IANA发布的注册表中明确标记。
The IESG is considered to be the owner of all Netnews Cancel-Lock hash algorithms that are on the IETF Standards Track.
IESG被认为是IETF标准轨道上所有Netnews取消锁哈希算法的所有者。
This section gives a formal definition of the Netnews Cancel-Lock hash algorithms as required by Section 8.1 for the IANA registry.
本节给出了第8.1节针对IANA注册表要求的Netnews取消锁定哈希算法的正式定义。
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: 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: 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
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
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: 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: 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
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
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，DOI 10.17487/RFC3864，2004年9月<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>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<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>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<https://www.rfc-editor.org/info/rfc4648>.
[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>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<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>.
[RFC5536]Murchison，K.，Ed.，Lindsey，C.，和D.Kohn，“网络新闻文章格式”，RFC 5536，DOI 10.17487/RFC5536，2009年11月<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>.
[RFC5537]Allbery，R.，Ed.，和C.Lindsey，“网络新闻体系结构和协议”，RFC 5537，DOI 10.17487/RFC5537，2009年11月<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>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<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>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <https://www.rfc-editor.org/info/rfc1321>.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC 1321，DOI 10.17487/RFC1321，1992年4月<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>.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，DOI 10.17487/RFC2104，1997年2月<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>.
[RFC3174]Eastlake 3rd，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，DOI 10.17487/RFC3174，2001年9月<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>.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 4880，DOI 10.17487/RFC4880，2007年11月<https://www.rfc-editor.org/info/rfc4880>.
[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>.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 6151，DOI 10.17487/RFC6151，2011年3月<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>.
[SHA]国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS 180-4，DOI 10.6028/NIST.FIPS.180-42015年8月<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.
[USEFOR-CANCEL-LOCK]Lyall，S.，“Usenet文章中的取消锁定”，《正在进行的工作》，草稿-ietf-USEFOR-CANCEL-LOCK-01，1998年11月。
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.)
作者承认[USEFOR-Cancel-Lock]：Simon Lyall中记录的取消锁定认证系统的原始作者。Simon编写了原始文档，并批准将其作品用于此文档。这份文件主要基于他的工作。（最初打算作为修订版02，但由于USEFOR IETF工作组现已关闭，因此被重命名。）
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.
作者要感谢以下个人贡献了他们的想法并审查了本规范：Russ Allbery、Urs Janssen、Richard Kettlewell、Marcel Logen、Holger Marzen、Dennis Preiser和Emil Schuster。还要感谢Peter Faust和Alfred Peters提供了有关当前使用的算法的统计数据。
Special thanks to the Document Shepherd, Julien Elie; and to the responsible Area Director, Alexey Melnikov.
特别感谢文件牧羊人朱利安·埃利；以及负责区域的主任Alexey Melnikov。
Author's Address
作者地址
Michael Baeuerle STZ Elektronik Hofener Weg 33C Remseck, Baden-Wuerttemberg 71686 Germany
Michael Baeuerle STZ Elektronik Hofener Weg 33C Remseck，巴登伍尔滕堡71686德国
Fax: +49 7146 999061
Email: michael.baeuerle@stz-e.de
Fax: +49 7146 999061
Email: michael.baeuerle@stz-e.de