[要約] RFC 8315は、Netnews記事のキャンセルロックに関するガイドラインであり、記事のキャンセルロックの目的は、誤ったキャンセルを防ぎ、記事の信頼性と整合性を確保することです。
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 Article Formatの拡張を定義しています。このドキュメントはRFC 5537を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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）またはSupersedesヘッダーフィールド（[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とCancel-Keyという2つの新しいヘッダーフィールドを定義しています。 Cancel-Lockヘッダーフィールドには、秘密データのハッシュが含まれています。プリイメージは、後でCancel-Keyヘッダーフィールドで使用して、キャンセルまたは優先リクエストを認証できます。
One property of this system is that it prevents tracking of individual users.
このシステムの1つの特性は、個々のユーザーの追跡を妨げることです。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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.
これらの各ヘッダーフィールドは、1つの記事で複数回出現してはなりません。
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 / "-" / "/"
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].
<scheme>のハッシュアルゴリズムは[RFC6234]で定義されています。 MD5については[RFC1321]と[RFC6151]、SHA1については[RFC3174]、SHA2ファミリについては[SHA]も参照してください。使用されるBase64エンコーディングは、[RFC4648]のセクション4で定義されています。
This document defines two values for <scheme>: "sha256" and "sha512". The hash algorithm "sha256" is mandatory to implement.
このドキュメントでは、<scheme>の2つの値「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 Cancel-Lock Hash Algorithms"レジストリ（セクション8.3）にのみ追加されます。実装では、<scheme>の生成にハッシュアルゴリズム「sha224」および「sha384」を使用しないでください。
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>要素の可能性を無視してはなりません（MUST）。
<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)))
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
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>は、元の記事の（このドキュメントのセクション2.1で定義されている）Cancel-Lockヘッダーフィールドの本文に<c-lock>要素を作成するために使用されたBase64エンコードキー「K」です。 ：
Base64(K)
Bassier64（C）
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-octet>文字の文字列（つまり、<の構文）を受け入れる必要があります（SHOULD）。このドキュメントのセクション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.
Cancel-Lockヘッダーフィールドは、投稿者または投稿エージェントによってプロト記事に追加される場合があり、1つ以上の<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.
ポスターまたは投稿エージェントがプロト記事にCancel-Lockヘッダーフィールドを追加しない場合、注入エージェント（またはモデレーター）は1つ以上の<c-lock>要素を含めて1つ追加することができます（MAY）。
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ヘッダーフィールドに追加される場合、各<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.
他のエージェントは、処理する記事またはプロト記事にこのヘッダーフィールドを追加してはなりません（MUST NOT）。
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.
Cancel-Lockヘッダーフィールドが既にプロトアーティクルに追加されている場合、プロトアーティクルをさらに処理するエージェントは、注入エージェントまで（包括的に）ヘッダーフィールドにすでにあるものに追加の<c-lock>要素を追加できます（MAY）。体。
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.
Cancel-Keyヘッダーフィールドには、元の記事のCancel-Lockヘッダーフィールドを作成するために使用された秘密の文字列が1つ以上含まれています。認証を成功させるには、少なくとも1つの秘密文字列の知識が必要です。
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.
Cancel-Keyヘッダーフィールドは、ポスターまたは投稿エージェントによって、ControlまたはSupersedesヘッダーフィールドを含むプロト記事に追加される場合があり、1つ以上の<c-key>要素が含まれます。これらは、コントロール（[RFC5537]で定義されている "cancel"コマンドを使用）またはSupersedesヘッダーフィールドによって参照される記事の<c-lock>要素の一部またはすべてに対応します。
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で定義されている「キャンセル」コマンドを使用して、コントロールにリストされている記事にCancel-Lockヘッダーフィールドを追加した場合]）またはSupersedesヘッダーフィールド、その後（元の記事のポスターと同じであるとポスターを認証する場合）、それに対応する少なくとも1つの<c-key>要素を含むCancel-Keyヘッダーフィールドを追加する必要があります。論文。
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.
Cancel-Keyヘッダーフィールドがプロトアーティクルにすでに追加されている場合、エージェントは、プロトアーティクルをさらに注入エージェントまで（包括的に）処理します。ヘッダーフィールドにすでにあるものに追加の<c-key>要素を追加できます（MAY）。体。
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で述べたように、注入エージェントまたはモデレーター（投稿エージェントの代表として行動）が、コントロールにリストされている記事の[Cancel-Lock]ヘッダーフィールドを拡張した場合（[RFC5537 ]）またはSupersedesヘッダーフィールド、その後（元の記事のポスターと同じであるとポスターを認証する場合）、それに対応する少なくとも1つの<c-key>要素でCancel-Keyヘッダーフィールドの本文を拡張する必要があります。その記事。
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]で定義されている "cancel"コマンドを使用して）コントロールまたはSupersedesヘッダーフィールドを介して以前の記事をキャンセルまたは置き換えようとする記事を受け取った場合、このドキュメントで定義されているシステムは、認証。 [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).
認証を処理するには、受信した記事にCancel-Keyヘッダーフィールドが含まれ、元の記事にCancel-Lockヘッダーフィールドが含まれている必要があります。そうでない場合、認証は不可能です（失敗）。
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)
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.
User-ID（またはUID）<uid>（たとえば、ユーザーのログイン名）に属するMessage-ID <mid>を持つ記事のキー「K」です。ハッシュメッセージ認証コード（HMAC）は、[RFC2104]で概説されています。 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).
投稿エージェントは、Message-IDヘッダーフィールドをproto-article自体に追加し、ヘッダーフィールドの本文のコンテンツを<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).
User-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>要素が単一のエージェントによって追加される場合は、秘密の<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>で指定されたものと同じである必要はないことに注意してください。 Cancel-Keyヘッダーフィールドの本文を検証するエージェントは、その<c-key>要素の1つが、元のCancel-Lockヘッダーフィールドの本文にある同じ<scheme>を持つ<c-lock>要素の1つと一致するかどうかを確認するだけです。論文。
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>
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シェルのOpenSSLコマンドラインツールを使用したBase64（K）の計算：
$ 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>.
これは、記事<12345@mid.example>をキャンセルまたは置き換えるための<c-key-string>として使用できます。
Calculation of Base64(SHA256(Base64(K))) required for <c-lock-string> using the OpenSSL command-line tools in a POSIX shell:
POSIXシェルのOpenSSLコマンドラインツールを使用して<c-lock-string>に必要なBase64（SHA256（Base64（K）））の計算：
$ 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ヘッダーフィールドの本文に挿入すると、次のようになります。
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ヘッダーフィールド本文に挿入すると、次のようになります。
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>
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シェルのOpenSSLコマンドラインツールを使用したBase64（K）の計算：
$ 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>.
これは、記事<12345@mid.example>をキャンセルまたは置き換えるための<c-key-string>として使用できます。
Calculation of Base64(SHA256(Base64(K))) required for <c-lock-string> using the OpenSSL command-line tools in a POSIX shell:
POSIXシェルのOpenSSLコマンドラインツールを使用して<c-lock-string>に必要なBase64（SHA256（Base64（K）））の計算：
$ 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ヘッダーフィールドの本文に挿入すると、次のようになります。
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ヘッダーフィールド本文に挿入すると、次のようになります。
Cancel-Key: sha256:yM0ep490Fzt83CLYYAytm3S2HasHhYG4LAeAlmuSEys=
Another matching pair of Cancel-Lock and Cancel-Key header fields:
Cancel-LockおよびCancel-Keyヘッダーフィールドの別の一致するペア：
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
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.
<scheme>の解析では大文字と小文字を区別しないことに注意してください。
Manual checks using the OpenSSL command-line tools in a POSIX shell:
POSIXシェルのOpenSSLコマンドラインツールを使用した手動チェック：
$ 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=
$ printf "％s" "aaaBBBcccDDDeeeFFF" \ | openssl dgst -sha1 -binary \ | openssl enc -base64 bNXHc6ohSmeHaRHHW56BIWZJt + 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>の次の値は非推奨になり、もう生成されるべきではありません（SHOULD NOT）。対応するハッシュ関数が安全でないと見なされない限り（詳細についてはセクション7を参照）、「Netnews Cancel-Lock Hash Algorithms」レジストリ（セクション8.3）ですでにOBSOLETEとしてマークされている限り、サービスエージェントは移行期間中それを受け入れる必要があります。
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> 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.
このドキュメントで定義されている認証システムには、整合性チェックプロパティはありません。 Cancel-Keyヘッダーフィールドの存在に関係なく、ネットワークを通過する途中の記事に任意の変更を適用できます。対応する<c-key>要素を持つCancel-Keyヘッダーフィールドを含む記事を受け取るサービングエージェントは、対象記事の撤回が正当な人物またはエージェントによって承認されたという情報のみを取得します。
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>要素がキャンセルコントロール記事から抽出され、偽造された置き換え記事に挿入されます。キャンセルコントロールアーティクルが偽造された置き換えを受け入れる前に、偽造された置き換えの記事を受信するネットワーク上のすべてのサーバーは、偽造された置き換えを受け入れる必要があります。ただし、誰もがヘッダーに偽造されたID情報を含む記事を投稿できるため（スパムメールと同じ）、認証システムをまったく使用せずに偽造された新しい記事を送信しても同じ結果が得られます。
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>に使用されるハッシュ関数の重要な特性は、プリイメージ耐性です。プレイメージ攻撃が成功すると、実際のキャンセルキー（元の記事のキャンセルロックの作成に使用された）が明らかになるか、別のキャンセルキー（キャンセルロックにも一致する）が与えられます。これにより、このドキュメントで定義されている認証システムが破損します。
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-Lockヘッダーフィールドの<c-lock>要素に一致するCancel-Keyヘッダーフィールドの2つの<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に対する既知の実用的なプリイメージおよび2番目のプリイメージ攻撃はありません。したがって、交換する必要はありません。このドキュメントで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]-は、ほぼ20年前のものです。クライアント側の実装も非常にゆっくりと進んでいます（最後のミレニアムからのニュースリーダーはまだ頻繁に使用されています）。今日定義されていることは、今後20年ほどの間十分に強いはずです。
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 <scheme>と（ベースとして）セクション4で推奨されているHMACに同じハッシュ関数を使用できることを目的としています。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>を保護できなければなりません。 Message-ID <mid>は（Message-IDヘッダーフィールドの本文で）パブリックであり、<uid>はオプションです。ローカルシークレットを盗んだり使用したりする攻撃者は、（<scheme>に関係なく）このアルゴリズムを解読するだけで済みます。Cancel-Keyヘッダーフィールドは、既存の記事をキャンセルまたは置き換えるリクエストごとに明示的に公開されるためです。
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>で生成された要素を持つCancel-Lockヘッダーフィールド本文を含むすべての記事に対するそのようなリクエストを偽造することが可能です。定期的に<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]:
IRFは、[RFC3864]で定められた手順に従って、「Permanent Message Header Field Names」レジストリに次のヘッダーフィールドを登録しました。
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.
「Netnews Cancel-Lock Hash Algorithms」レジストリは、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>:
Netnews Cancel-Lockハッシュアルゴリズムの登録は、次のテンプレートに入力して電子メールで<iana@iana.org>のIANAに送信することによって要求されます。
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 Cancel-Lockハッシュアルゴリズムの登録X Netnews Cancel-Lockハッシュアルゴリズム名：セキュリティに関する考慮事項：公開された仕様（推奨）：詳細については連絡先：使用目的：（COMMON、LIMITED USE、またはOBSOLETEのいずれか）所有者/変更コントローラー：注：（著者が関連すると見なすその他の情報をここに追加できます。）
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 Cancel-Lockハッシュアルゴリズムの構文（セクション2の<scheme>の定義を参照）に準拠する任意の名前を使用できます。特に、NetnewsのCancel-Lockアルゴリズムは、文字、数字、ハイフン、またはスラッシュで構成される文字列によって名前が付けられます。
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.
著者は、提案されたアルゴリズムの仕様をインターネットドラフトとして投稿することにより、コミュニティレビューを求めることができます。広範な使用を目的としたNetnewsのCancel-Lockハッシュアルゴリズムは、必要に応じて、通常のIETFプロセスを通じて標準化する必要があります。
The IESG is considered to be the owner of all Netnews Cancel-Lock hash algorithms that are on the IETF Standards Track.
IESGは、IETF Standards TrackにあるすべてのNetnews Cancel-Lockハッシュアルゴリズムの所有者と見なされます。
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.
NetnewsのCancel-Lockハッシュアルゴリズムの登録がIANAによって公開されると、所有者はその定義の変更を要求できます。変更要求は、最初の登録要求と同じ手順に従います。
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のCancel-Lockハッシュアルゴリズムの所有者は、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 Cancel-Lockハッシュアルゴリズムの責任を再割り当てする場合があります。これの最も一般的な理由は、登録の所有者が死亡した、連絡が取れなくなった、またはコミュニティにとって重要な変更を行うことができない場合に、アルゴリズムを変更できるようにすることです。
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のCancel-Lockハッシュアルゴリズムの登録は削除しないでください。使用に適しているとは考えられなくなったアルゴリズムは、「使用目的」フィールドを変更することにより、廃止と宣言できます。そのようなアルゴリズムは、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 Standards TrackにあるすべてのNetnews Cancel-Lockハッシュアルゴリズムの所有者と見なされます。
This section gives a formal definition of the Netnews Cancel-Lock hash algorithms as required by Section 8.1 for the IANA registry.
このセクションでは、IANAレジストリのセクション8.1で要求されているNetnewsのCancel-Lockハッシュアルゴリズムの正式な定義を示します。
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
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
[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.、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>.
[RFC4648] Josefsson、S。、「The 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、「Netnews Article Format」、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、「Netnews Architecture and Protocols」、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、「US Secure Hash Algorithms（SHA and SHA-based HMAC and 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]コットン、M。、レイバ、B。、およびT.ナルテン、「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。、「The MD5 Message-Digest Algorithm」、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：Keyed-Hashing for Message Authentication」、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、「US Secure Hash Algorithm 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]ターナー、S。およびL.チェン、「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]米国国立標準技術研究所、「Secure Hash Standard（SHS）」、FIPS 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年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記事のキャンセルロック」、Work in Progress、draft-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]に記載されているように、Cancel-Lock認証システムの最初の作成者であるSimon Lyallに謝意を表します。 Simonは元のドキュメントを作成し、このドキュメントに対する彼の作業の使用を承認しました。この文書は主に彼の研究に基づいています。 （当初はリビジョン02として意図されていましたが、USEFOR IETF WGが現在閉じているため、名前が変更されました。）
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.
Document ShepherdのJulien Elieに特に感謝します。そして担当エリアディレクターのアレクセイ・メルニコフへ。
Author's Address
著者のアドレス
Michael Baeuerle STZ Elektronik Hofener Weg 33C Remseck, Baden-Wuerttemberg 71686 Germany
Michael Baeuerle STZ Electronics Hofener Weg 33C Remseck、Baden-Wuerttemberg 71686 Germany
Fax: +49 7146 999061
Email: michael.baeuerle@stz-e.de