[要約] RFC 8933は、暗号化メッセージ構文（CMS）のアルゴリズム識別子保護を更新するものです。この文書の目的は、セキュリティを強化し、潜在的な脆弱性を減少させるために、アルゴリズム識別子の使用方法を改善することにあります。主に、デジタル署名、暗号化メッセージの交換、認証プロセスなどのセキュリティが重要な場面で利用されます。
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 8933 Vigil Security
Updates: 5652 October 2020
Category: Standards Track
ISSN: 2070-1721
Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection
アルゴリズム識別子保護のための暗号メッセージ構文（CMS）への更新
Abstract
概要
This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed-data and authenticated-data content types are adequately protected.
この文書は、署名付きデータおよび認証データコンテンツタイプのアルゴリズム識別子が適切に保護されていることを確認するために、RFC 5652で指定された暗号化メッセージ構文（CMS）を更新します。
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/rfc8933.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8933で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 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）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Required Use of the Same Hash Algorithm
3.1. RFC 5652, Section 5.3
3.2. RFC 5652, Section 5.4
3.3. RFC 5652, Section 5.6
3.4. Backward Compatibility Considerations
3.5. Timestamp Compatibility Considerations
4. Recommended Inclusion of the CMSAlgorithmProtection Attribute
4.1. RFC 5652, Section 14
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Author's Address
This document updates the Cryptographic Message Syntax (CMS) [RFC5652] to ensure that algorithm identifiers in signed-data and authenticated-data content types are adequately protected.
このドキュメントは、符号付きデータと認証データコンテンツタイプのアルゴリズム識別子が適切に保護されていることを確認するために、暗号化メッセージ構文（CMS）[RFC5652]を更新します。
The CMS signed-data content type [RFC5652], unlike X.509 certificates [RFC5280], can be vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm identifier or the parameters associated with the algorithm identifier to change the verification process used by the recipient. The X.509 certificate structure protects the algorithm identifier and the associated parameters by signing them.
CMS署名データコンテンツタイプ[RFC5652]は、X.509証明書[RFC5280]とは異なり、アルゴリズム置換攻撃に対して脆弱になる可能性があります。アルゴリズム置換攻撃では、攻撃者はアルゴリズム識別子またはアルゴリズム識別子に関連するパラメータを変更して、受信者によって使用される検証プロセスを変更します。X.509証明書構造は、それらに署名してアルゴリズム識別子と関連パラメータを保護します。
In an algorithm substitution attack, the attacker looks for a different algorithm that produces the same result as the algorithm used by the originator. As an example, if the signer of a message used SHA-256 [SHS] as the digest algorithm to hash the message content, then the attacker looks for a weaker hash algorithm that produces a result that is of the same length. The attacker's goal is to find a different message that results in the same hash value, which is called a cross-algorithm collision. Today, there are many hash functions that produce 256-bit results. One of them may be found to be weak in the future.
アルゴリズム置換攻撃では、攻撃者は発信者によって使用されるアルゴリズムと同じ結果を生み出す別のアルゴリズムを探します。一例として、メッセージの署名者がメッセージの内容をハッシュするためのダイジェストアルゴリズムとして使用されたメッセージの署名者が、同じ長さの結果を生み出すより弱いハッシュアルゴリズムを探す。攻撃者の目標は、同じハッシュ値をもたらす別のメッセージを見つけることです。これは、クロスアルゴリズムの衝突と呼ばれます。今日、256ビットの結果を生み出すハッシュ関数がたくさんあります。そのうちの1つは将来弱いことがわかっているかもしれません。
Further, when a digest algorithm produces a larger result than is needed by a digital signature algorithm, the digest value is reduced to the size needed by the signature algorithm. This can be done both by truncation and modulo operations, with the simplest being straightforward truncation. In this situation, the attacker needs to find a collision with the reduced digest value. As an example, if the message signer uses SHA-512 [SHS] as the digest algorithm and the Elliptic Curve Digital Signature Algorithm (ECDSA) with the P-256 curve [DSS] as the signature algorithm, then the attacker needs to find a collision with the first half of the digest.
さらに、ダイジェストアルゴリズムがデジタル署名アルゴリズムによって必要とされるよりも大きい結果を生成するとき、ダイジェスト値は署名アルゴリズムによって必要とされるサイズに減少する。これは、最も簡単な切り捨てで、切り捨てとモジュロ操作によって行うことができます。この状況では、攻撃者はダイジェスト値の減少と衝突を見つける必要があります。一例として、メッセージ署名者がダイジェストアルゴリズムとしてSHA-512 [SHS]を使用し、P-256カーブDSSを署名アルゴリズムとしてP-256曲線DSSを使用している場合は、攻撃者が見つける必要があります。ダイジェストの前半と衝突する。
Similar attacks can be mounted against parameterized algorithm identifiers. When randomized hash functions are employed, such as the example in [RFC6210], the algorithm identifier parameter includes a random value that can be manipulated by an attacker looking for collisions. Some other algorithm identifiers include complex parameter structures, and each value provides another opportunity for manipulation by an attacker.
パラメータ化されたアルゴリズム識別子に対して同様の攻撃をマウントすることができます。[RFC6210]の例などのランダム化ハッシュ関数が採用されている場合、アルゴリズム識別子パラメータは、衝突を探して攻撃者によって操作することができるランダムな値を含む。他のいくつかのアルゴリズム識別子は複雑なパラメータ構造を含み、各値は攻撃者による操作のための別の機会を提供する。
This document makes two updates to CMS to provide protection for the algorithm identifier. First, it mandates a convention followed by many implementations by requiring the originator to use the same hash algorithm to compute the digest of the message content and the digest of signed attributes. Second, it recommends that the originator include the CMSAlgorithmProtection attribute [RFC6211].
このドキュメントは、アルゴリズム識別子の保護を提供するためにCMSに2つの更新を行います。第1に、それは創始者に同じハッシュアルゴリズムを使用してメッセージ内容のダイジェストと符号付き属性のダイジェストを計算することを要求することによって多くの実装を義務付ける。次に、発信者にCMSalgorithmProtection属性[RFC6211]が含まれることをお勧めします。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This section updates [RFC5652] to require the originator to use the same hash algorithm to compute the digest of the message content and the digest of signed attributes.
このセクションでは、[RFC5652]を更新して、発信者に同じハッシュアルゴリズムを使用してメッセージコンテンツのダイジェストと符号付き属性のダイジェストを計算する必要があります。
Change the paragraph describing the digestAlgorithm as follows:
次のように、ダイジェストアルゴリズムを説明する段落を変更します。
OLD:
古い：
| digestAlgorithm identifies the message digest algorithm, and any
| associated parameters, used by the signer. The message digest is
| computed on either the content being signed or the content
| together with the signed attributes using the process described in
| Section 5.4. The message digest algorithm SHOULD be among those
| listed in the digestAlgorithms field of the associated SignerData.
| Implementations MAY fail to validate signatures that use a digest
| algorithm that is not included in the SignedData digestAlgorithms
| set.
NEW:
新着：
| digestAlgorithm identifies the message digest algorithm, and any
| associated parameters, used by the signer. The message digest is
| computed on either the content being signed or the content
| together with the signedAttrs using the process described in
| Section 5.4. The message digest algorithm SHOULD be among those
| listed in the digestAlgorithms field of the associated SignerData.
| If the signedAttrs field is present in the SignerInfo, then the
| same digest algorithm MUST be used to compute both the digest of
| the SignedData encapContentInfo eContent, which is carried in the
| message-digest attribute, and the digest of the DER-encoded
| signedAttrs, which is passed to the signature algorithm.
| Implementations MAY fail to validate signatures that use a digest
| algorithm that is not included in the SignedData digestAlgorithms
| set.
Add the following paragraph as the second paragraph in Section 5.4.
セクション5.4の2番目の段落として次の段落を追加します。
ADD:
追加：
| When the signedAttrs field is present, the same digest algorithm
| MUST be used to compute the digest of the encapContentInfo
| eContent OCTET STRING, which is carried in the message-digest
| attribute and the digest of the collection of attributes that are
| signed.
Change the paragraph discussing the signed attributes as follows:
符号付き属性について説明する段落を次のように変更します。
OLD:
古い：
| The recipient MUST NOT rely on any message digest values computed
| by the originator. If the SignedData signerInfo includes
| signedAttributes, then the content message digest MUST be
| calculated as described in Section 5.4. For the signature to be
| valid, the message digest value calculated by the recipient MUST
| be the same as the value of the messageDigest attribute included
| in the signedAttributes of the SignedData signerInfo.
NEW:
新着：
| The recipient MUST NOT rely on any message digest values computed
| by the originator. If the SignedData signerInfo includes the
| signedAttrs field, then the content message digest MUST be
| calculated as described in Section 5.4 using the same digest
| algorithm to compute the digest of the encapContentInfo eContent
| OCTET STRING and the message-digest attribute. For the signature
| to be valid, the message digest value calculated by the recipient
| MUST be the same as the value of the messageDigest attribute
| included in the signedAttrs field of the SignedData signerInfo.
The new requirement introduced above might lead to incompatibility with an implementation that allowed different digest algorithms to be used to compute the digest of the message content and the digest of signed attributes. The signatures produced by such an implementation when two different digest algorithms are used will be considered invalid by an implementation that follows this specification. However, most, if not all, implementations already require the originator to use the same digest algorithm for both operations.
上記の新しい要件は、異なるダイジェストアルゴリズムを使用してメッセージ内容のダイジェストと符号付き属性のダイジェストを計算することを可能にする実装との不適合性をもたらすかもしれません。2つの異なるダイジェストアルゴリズムが使用されている場合にそのような実装によって生成された署名は、この仕様に続く実装によって無効と見なされます。ただし、ほとんどの場合、すべての場合、実装は既にオリジネーターに両方の操作に同じダイジェストアルゴリズムを使用する必要があります。
The new requirement introduced above might lead to compatibility issues for timestamping systems when the originator does not wish to share the message content with the Time Stamping Authority (TSA) [RFC3161]. In this situation, the originator sends a TimeStampReq to the TSA that includes a MessageImprint, which consists of a digest algorithm identifier and a digest value. The TSA then uses the originator-provided digest in the MessageImprint.
上記の新しい要件は、発信者がメッセージ内容をタイムスタンプ局（TSA）[RFC3161]と共有したくない場合、タイムスタンプシステムの互換性の問題につながる可能性があります。この状況では、発信者は、ダイジェストアルゴリズム識別子とダイジェスト値で構成されているMessageImprintを含むTIMESTAMPREQをTSAに送信します。その後、TSAはMessageImprintで発信者提供のダイジェストを使用します。
When producing the TimeStampToken, the TSA MUST use the same digest algorithm to compute the digest of the encapContentInfo eContent, which is an OCTET STRING that contains the TSTInfo, and the message-digest attribute within the SignerInfo.
TimesTampTokenを作成するとき、TSAは、encapcontentInfo Econtentのダイジェストを計算するために同じダイジェストアルゴリズムを使用する必要があります。これは、TSTINFOを含むオクテット文字列、およびsignerInfo内のメッセージダイジェスト属性です。
To ensure that TimeStampToken values that were generated before this update remain valid, no requirement is placed on a TSA to ensure that the digest algorithm for the TimeStampToken matches the digest algorithm for the MessageImprint embedded within the TSTInfo.
このアップデートが有効なままになる前に生成されたタイムスタートされた値が確実になるように、TIMESTAMPTOKEのダイジェストアルゴリズムがTSTINFO内に埋め込まれたMessageImprintのダイジェストアルゴリズムと一致するように、TSA上に必要ありません。
This section updates [RFC5652] to recommend that the originator include the CMSAlgorithmProtection attribute [RFC6211] whenever signed attributes or authenticated attributes are present.
このセクションでは、署名された属性または認証済み属性が存在するときはいつでもCMSALGorithmProtection属性[RFC6211]を含むことを推奨する。
Add the following paragraph as the eighth paragraph in Section 14:
次の段落を第8段落として第14項目に追加します。
ADD:
追加：
| While there are no known algorithm substitution attacks today, the
| inclusion of the algorithm identifiers used by the originator as a
| signed attribute or an authenticated attribute makes such an
| attack significantly more difficult. Therefore, the originator of
| a signed-data content type that includes signed attributes SHOULD
| include the CMSAlgorithmProtection attribute [RFC6211] as one of
| the signed attributes. Likewise, the originator of an
| authenticated-data content type that includes authenticated
| attributes SHOULD include the CMSAlgorithmProtection attribute
| [RFC6211] as one of the authenticated attributes.
This document has no IANA actions.
この文書にはIANAの行動がありません。
The security properties of the CMS [RFC5652] signed-data and authenticated-data content types are updated to offer protection for algorithm identifiers, which makes algorithm substitution attacks significantly more difficult.
CMS [RFC5652]のセキュリティプロパティ署名付きデータと認証データコンテンツタイプは、アルゴリズム識別子の保護を提供するように更新され、アルゴリズムの置換攻撃を大幅に困難にします。
For the signed-data content type, the improvements specified in this document force an attacker to mount a hash algorithm substitution attack on the overall signature, not just on the message digest of the encapContentInfo eContent.
署名付きデータコンテンツタイプの場合、このドキュメントで指定された改善は、EncapContentInfo Econtentのメッセージダイジェストだけでなく、ハッシュアルゴリズム置換攻撃をハッシュアルゴリズム置換攻撃をマウントするように強制します。
Some digital signature algorithms have prevented hash function substitutions by including a digest algorithm identifier as an input to the signature algorithm. As discussed in [HASHID], such a "firewall" may not be effective or even possible with newer signature algorithms. For example, RSASSA-PKCS1-v1_5 [RFC8017] protects the digest algorithm identifier, but RSASSA-PSS [RFC8017] does not. Therefore, it remains important that a signer have a way to signal to a recipient which digest algorithms are allowed to be used in conjunction with the verification of an overall signature. This signaling can be done as part of the specification of the signature algorithm in an X.509v3 certificate extension [RFC5280] or some other means. The Digital Signature Standard (DSS) [DSS] takes the first approach by requiring the use of an "approved" one-way hash algorithm.
一部のデジタル署名アルゴリズムは、シグネチャアルゴリズムへの入力としてダイジェストアルゴリズム識別子を含めることによってハッシュ関数の置換を防止しています。[Hashid]で説明したように、そのような「ファイアウォール」は、新しい署名アルゴリズムを用いて効果的でも可能ではないかもしれない。たとえば、RSASSA-PKCS1~V1_5 [RFC8017]ダイジェストアルゴリズム識別子を保護しますが、RSASSA-PSS [RFC8017]はしません。したがって、署名者が、全体的な署名の検証と組み合わせてダイジェストアルゴリズムを使用することが許可される受信者に信号を送信する方法を有することは重要なままである。このシグナリングは、X.509V3証明書拡張[RFC5280]またはその他の手段でのシグネチャアルゴリズムの仕様の一部として行うことができます。デジタル署名標準（DSS）[DSS]は、「承認された」一方向ハッシュアルゴリズムの使用を要求することによって最初のアプローチを取ります。
For the authenticated-data content type, the improvements specified in this document force an attacker to mount a MAC algorithm substitution attack, which is difficult because the attacker does not know the authentication key.
認証されたデータコンテンツタイプの場合、このドキュメントで指定された改善は、攻撃者にMACアルゴリズム置換攻撃をマウントするように強制します。これは攻撃者が認証キーを知らないため困難です。
The CMSAlgorithmProtection attribute [RFC6211] offers protection for the algorithm identifiers used in the signed-data and authenticated-data content types. However, no protection is provided for the algorithm identifiers in the enveloped-data, digested-data, or encrypted-data content types. Likewise, the CMSAlgorithmProtection attribute provides no protection for the algorithm identifiers used in the authenticated-enveloped-data content type defined in [RFC5083]. A mechanism for algorithm identifier protection for these content types is work for the future.
CMSalgorithmProtection属性[RFC6211]は、署名付きデータおよび認証データコンテンツタイプで使用されるアルゴリズム識別子の保護を提供します。ただし、エンベロープデータ、消化データ、または暗号化データコンテンツタイプのアルゴリズム識別子には保護はありません。同様に、CMSalgorithmProtection属性は、[RFC5083]で定義されている認証済みエンベロープデータコンテンツタイプで使用されるアルゴリズム識別子を保護しません。これらのコンテンツタイプに対するアルゴリズム識別子保護のためのメカニズムは将来のために機能します。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, <https://www.rfc-editor.org/info/rfc3161>.
[RFC3161] ADAMS、C、Cain、P.、Pinkas、D.、およびR. Zuccherato、「インターネットX.509公開鍵インフラストラクチャタイムスタンププロトコル（TSP）」、RFC 3161、DOI 10.17487 / RFC3161、2001年8月<https://www.rfc-editor.org/info/rfc3161>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R.、 "Cryptographic Message Syntax（CMS）"、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<https：//www.rfc-editor.org/info/rfc5652>。
[RFC6211] Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute", RFC 6211, DOI 10.17487/RFC6211, April 2011, <https://www.rfc-editor.org/info/rfc6211>.
[RFC6211] Schaad、J.、 "Cryptographic Message Syntax（CMS）アルゴリズム識別子保護属性"、RFC 6211、DOI 10.17487 / RFC6211、2011年4月、<https：//www.rfc-editor.org/info/rfc6211>。
[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>。
[DSS] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", FIPS 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <https://doi.org/10.6028/NIST.FIPS.186-4>.
[DSS]国立標準技術総合研究所（NIST）、「デジタル署名標準（DSS）」、FIPS 186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月、<https：//doi.org/10.6028 / NIST.FIPS.186-4>。
[HASHID] Kaliski, B., "On Hash Function Firewalls in Signature Schemes", DOI 10.1007/3-540-45760-7_1, Lecture Notes in Computer Science, Volume 2271, February 2002, <https://doi.org/10.1007/3-540-45760-7_1>.
[Hashid] Kaliski、B.、「署名スキームのハッシュ関数ファイアウォールのオン」、DOI 10.1007 / 3-540-45760-7_1、コンピュータサイエンス、第2271巻、2002年2月、<https://doi.org/10.1007 / 3-540-45760-7_1>。
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, DOI 10.17487/RFC5083, November 2007, <https://www.rfc-editor.org/info/rfc5083>.
[RFC5083] Housley、R.、 "Cryptographic Message Syntax（CMS）認証済み - データコンテンツの種類"、RFC 5083、DOI 10.17487 / RFC5083、2007年11月、<https://www.rfc-editor.org/info/RFC5083>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC6210] Schaad, J., "Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME", RFC 6210, DOI 10.17487/RFC6210, April 2011, <https://www.rfc-editor.org/info/rfc6210>.
[RFC6210] Schaad、J.、「実験：暗号メッセージ構文（CMS）とS / MIMEのパラメータを持つハッシュ関数」、RFC 6210、DOI 10.17487 / RFC6210、2011年4月、<https：//www.rfc-編集者.ORG / INFO / RFC6210>。
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017] MoriArty、K。、ED。、Kaliski、B.、Jonsson、J.、A. RUSCH、「PKCS＃1：RSA暗号化仕様バージョン2.2」、RFC 8017、DOI 10.17487 / RFC8017、2016年11月、<https://www.rfc-editor.org/info/rfc8017>。
[SHS] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://doi.org/10.6028/NIST.FIPS.180-4>.
[SHS]国立標準技術研究所（NIST）、「セキュアハッシュスタンダード（SHS）」、FIPS 180-4、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<https：//doi.org/10.6028 / NIST.FIPS.180-4>。
Acknowledgements
謝辞
Many thanks to Jim Schaad and Peter Gutmann; without knowing it, they motivated me to write this document. Thanks to Roman Danyliw, Ben Kaduk, and Peter Yee for their careful review and editorial suggestions.
Jim SchaadとPeter Gutmannに感謝します。それを知らずに、彼らは私にこの文書を書くように動機付けられました。Roman Danyliw、Ben Kaduk、そしてPeter Yeeのおかげで、慎重なレビューと編集上の提案のために。
Author's Address
著者の住所
Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 United States of America
Russ Housley Vigil Security、LLC 516 Dranesville Road Herndon、VA 20170アメリカ合衆国
Email: housley@vigilsec.com