[要約] RFC 2951は、KEAとSKIPJACKを使用したTELNET認証に関する仕様です。このRFCの目的は、TELNETセッションのセキュリティを向上させるために、強力な認証メカニズムを提供することです。
Network Working Group R. Housley
Request for Comments: 2951 T. Horting
Category: Informational P. Yee
SPYRUS
September 2000
TELNET Authentication Using KEA and SKIPJACK
KeaとSkipjackを使用したTelnet認証
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK. Two encryption modes are specified; one provides data integrity and the other does not. The method relies on the TELNET Authentication Option.
このドキュメントでは、キーエクスチェンジアルゴリズム（KEA）を使用してTelnetを認証する方法を定義し、SkipJackを使用してTelnetストリームの暗号化を定義します。2つの暗号化モードが指定されています。1つはデータの整合性を提供し、もう1つはそうではありません。この方法は、Telnet認証オプションに依存しています。
AUTHENTICATION 37
認証37
Authentication Commands:
認証コマンド：
IS 0
SEND 1
REPLY 2
NAME 3
Authentication Types:
認証タイプ：
KEA_SJ 12
KEA_SJ_INTEG 13
Modifiers:
修飾子：
AUTH_WHO_MASK 1
AUTH_CLIENT_TO_SERVER 0
AUTH_SERVER_TO CLIENT 1
AUTH_HOW_MASK 2
AUTH_HOW_ONE_WAY 0
AUTH_HOW_MUTUAL 2
ENCRYPT_MASK 20
ENCRYPT_OFF 0
ENCRYPT_USING_TELOPT 4
ENCRYPT_AFTER_EXCHANGE 16
ENCRYPT_RESERVED 20
INI_CRED_FWD_MASK 8 INI_CRED_FWD_OFF 0 INI_CRED_FWD_ON 8
ini_cred_fwd_mask 8 ini_cred_fwd_off 0 ini_cred_fwd_on 8
Sub-option Commands:
サブオプションコマンド：
KEA_CERTA_RA 1
KEA_CERTB_RB_IVB_NONCEB 2
KEA_IVA_RESPONSEB_NONCEA 3
KEA_RESPONSEA 4
TELNET, as a protocol, has no concept of security. Without negotiated options, it merely passes characters back and forth between the NVTs represented by the two TELNET processes. In its most common usage as a protocol for remote terminal access (TCP port 23), TELNET normally connects to a server that requires user-level authentication through a user name and password in the clear. The server does not authenticate itself to the user.
プロトコルとしてのTelnetには、セキュリティの概念はありません。交渉されたオプションがなければ、2つのTelnetプロセスで表されるNVTの間でキャラクターを前後に渡すだけです。リモート端子アクセスのプロトコルとしての最も一般的な使用（TCPポート23）で、Telnetは通常、ユーザー名とパスワードを介してユーザーレベルの認証を必要とするサーバーに接続します。サーバーはユーザーに認証されません。
The TELNET Authentication Option provides for:
Telnet認証オプションは次のことを提供します。
* User authentication -- replacing or augmenting the normal host password mechanism;
* Server authentication -- normally done in conjunction with user authentication;
* Session parameter negotiation -- in particular, encryption key and attributes;
* Session protection -- primarily encryption of the data and embedded command stream, but the encryption algorithm may also provide data integrity.
*ユーザー認証 - 通常のホストパスワードメカニズムの交換または拡張。
*サーバー認証 - 通常、ユーザー認証と組み合わせて行われます。
*セッションパラメーターネゴシエーション - 特に、暗号化キーと属性。
*セッション保護 - 主にデータの暗号化と埋め込みコマンドストリームですが、暗号化アルゴリズムはデータの整合性も提供する場合があります。
In order to support these security services, the two TELNET entities must first negotiate their willingness to support the TELNET Authentication Option. Upon agreeing to support this option, the parties are then able to perform sub-option negotiations to determine the authentication protocol to be used, and possibly the remote user name to be used for authorization checking. Encryption is negotiated along with the type of the authentication.
これらのセキュリティサービスをサポートするために、2つのTelnetエンティティは、最初にTelnet認証オプションをサポートする意欲を交渉する必要があります。このオプションをサポートすることに同意すると、当事者はサブオプション交渉を実行して使用する認証プロトコルを決定することができ、場合によっては認可チェックに使用されるリモートユーザー名が決定されます。暗号化は、認証のタイプとともに交渉されます。
Authentication and parameter negotiation occur within an unbounded series of exchanges. The server proposes a preference-ordered list of authentication types (mechanisms) that it supports. In addition to listing the mechanisms it supports, the server qualifies each mechanism with a modifier that specifies whether encryption of data is desired. The client selects one mechanism from the list and responds to the server indicating its choice and the first set of authentication data needed for the selected authentication type. The client may ignore a request to encrypt data and so indicate, but the server may also terminate the connection if the client refuses encryption. The server and the client then proceed through whatever number of iterations is required to arrive at the requested authentication.
認証とパラメーターの交渉は、無制限の一連の交換内で発生します。サーバーは、サポートする認証タイプ（メカニズム）の優先順序付きリストを提案します。サポートするメカニズムのリストに加えて、サーバーは、データの暗号化が必要かどうかを指定する修飾子を使用して各メカニズムを修飾します。クライアントはリストから1つのメカニズムを選択し、選択した認証タイプに必要な認証データの選択を示すサーバーに応答します。クライアントは、データを暗号化するリクエストを無視するため、そのように示す場合がありますが、クライアントが暗号化を拒否した場合、サーバーは接続を終了する場合もあります。サーバーとクライアントは、要求された認証に到達するために必要な反復数の数を進めます。
Encryption is started immediately after the Authentication Option is completed.
暗号化は、認証オプションが完了した直後に開始されます。
This paper specifies the method in which KEA is used to achieve TELNET Authentication. KEA (in conjunction with SKIPJACK) [4] provides authentication and confidentiality. Integrity may also be provided.
このペーパーでは、KEAを使用してTelnet認証を実現する方法を指定します。KEA（SkipJackと併せて）[4]は、認証と機密性を提供します。整合性も提供される場合があります。
TELNET entities may use KEA to provide mutual authentication and support for the setup of data encryption keys. A simple token format and set of exchanges delivers these services.
Telnetエンティティは、KEAを使用して、データ暗号化キーのセットアップに相互認証とサポートを提供する場合があります。簡単なトークン形式と交換セットは、これらのサービスを提供します。
NonceA and NonceB used in this exchange are 64-bit bit strings. The client generates NonceA, and the server generates NonceB. The nonce value is selected randomly. The nonce is sent in a big endian form. The encryption of the nonce will be done with the same mechanism that the session will use, detailed in the next section.
この交換で使用される非CEAおよび非CEBは、64ビットの文字列です。クライアントは非CEAを生成し、サーバーは非CEBを生成します。NonCe値はランダムに選択されます。Nonceは大きなエンディアンの形で送信されます。ノンセの暗号化は、次のセクションで詳述されているセッションが使用するのと同じメカニズムで行われます。
Ra and Rb used in this exchange are 1024 bit strings and are defined by the KEA Algorithm [4].
この交換で使用されるRAとRBは1024ビット文字列であり、KEAアルゴリズム[4]によって定義されています。
The IVa and IVb are 24 byte Initialization Vectors. They are composed of "THIS IS NOT LEAF" followed by 8 random bytes.
IVAとIVBは24バイト初期化ベクトルです。それらは、「これは葉ではない」で構成され、その後に8つのランダムバイトが続きます。
CertA is the client's certificate. CertB is the server's certificate. Both certificates are X.509 certificates [6] that contain KEA public keys [7]. The client must validate the server's certificate before using the KEA public key it contains. Likewise, the server must validate the client's certificate before using the KEA public key it contains.
CERTAはクライアントの証明書です。CERTBはサーバーの証明書です。両方の証明書は、KEAパブリックキー[7]を含むX.509証明書[6]です。クライアントは、含まれているKEAの公開キーを使用する前に、サーバーの証明書を検証する必要があります。同様に、サーバーに含まれるKEAの公開キーを使用する前に、サーバーはクライアントの証明書を検証する必要があります。
On completing these exchanges, the parties have a common SKIPJACK key. Mutual authentication is provided by verification of the certificates used to establish the SKIPJACK encryption key and successful use of the derived SKIPJACK session key. To protect against active attacks, encryption will take place after successful authentication. There will be no way to turn off encryption and safely turn it back on; repeating the entire authentication is the only safe way to restart it. If the user does not want to use encryption, he may disable encryption after the session is established.
これらの交換を完了すると、当事者は共通のSkipjackキーを持っています。相互認証は、SkipJack暗号化キーを確立するために使用される証明書の検証と、派生したSkipJackセッションキーの使用の成功によって提供されます。アクティブな攻撃から保護するために、認証が成功した後、暗号化が行われます。暗号化をオフにして安全に戻す方法はありません。認証全体を繰り返すことは、それを再起動する唯一の安全な方法です。ユーザーが暗号化を使用したくない場合、セッションの確立後に暗号化を無効にする場合があります。
There are two distinct modes for encrypting TELNET streams; one provides integrity and the other does not. Because TELNET is normally operated in a character-by-character mode, the SKIPJACK with stream integrity mechanism requires the transmission of 4 bytes for every TELNET data byte. However, a simplified mode SKIPJACK without integrity mechanism will only require the transmission of one byte for every TELNET data byte.
Telnetストリームを暗号化するための2つの異なるモードがあります。1つは完全性を提供し、もう1つはそうではありません。Telnetは通常、文字ごとに動作するため、ストリーム整合性メカニズムを備えたSkipJackには、すべてのTelnetデータバイトに4バイトの伝送が必要です。ただし、整合性メカニズムのない単純化されたモードSkipJackでは、すべてのTelnetデータバイトに対して1バイトの送信のみが必要です。
The cryptographic mode for SKIPJACK with stream integrity is Cipher Feedback on 32 bits of data (CFB-32) and the mode of SKIPJACK is Cipher Feedback on 8 bits of data (CFB-8).
ストリームの整合性を備えたSkipJackの暗号化モードは、32ビットのデータ（CFB-32）に対する暗号フィードバックであり、Skipjackのモードは8ビットのデータ（CFB-8）に対する暗号フィードバックです。
The first and least complicated mode uses SKIPJACK CFB-8. This mode provides no stream integrity.
最初と最も複雑なモードでは、SkipJack CFB-8を使用します。このモードは、ストリームの完全性を提供しません。
For SKIPJACK without stream integrity, the two-octet authentication type pair is KEA_SJ AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF. This indicates that the SKIPJACK without integrity mechanism will be used for mutual authentication and TELNET stream encryption. Figure 1 illustrates the authentication mechanism of KEA followed by SKIPJACK without stream integrity.
Skipjackの整合性のない場合、2オクテット認証タイプのペアはKEA_SJ auth_client_to_serverです|auth_how_mutual |encrypt_after_exchange |ini_cred_fwd_off。これは、整合性メカニズムのないSkipJackが相互認証とTelnetストリーム暗号化に使用されることを示しています。図1は、KEAの認証メカニズムと、ストリームの完全性のないSkipJackが続くことを示しています。
---------------------------------------------------------------------
Client (Party A) Server (Party B)
<-- IAC DO AUTHENTICATION
<-IACは認証を行います
IAC WILL AUTHENTICATION -->
<-- IAC SB AUTHENTICATION SEND <list of authentication options> IAC SE
<-IACSB認証送信<認証オプションのリスト> IAC SE
IAC SB AUTHENTICATION
NAME <user name> -->
IAC SB AUTHENTICATION IS
KEA_SJ
AUTH_CLIENT_TO_SERVER |
AUTH_HOW_MUTUAL |
ENCRYPT_AFTER_EXCHANGE |
INI_CRED_FWD_OFF
KEA_CERTA_RA
CertA||Ra IAC SE -->
<-- IAC SB AUTHENTICATION REPLY KEA_SJ AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF IVA_RESPONSEB_NONCEA KEA_CERTB_RB_IVB_NONCEB CertB||Rb||IVb|| Encrypt( NonceB ) IAC SE
<-IAC SB認証応答kea_sj auth_client_to_server |auth_how_mutual |encrypt_after_exchange |ini_cred_fwd_off iva_responseb_noncea kea_certb_rb_ivb_nonceb certb || rb || ivb ||暗号化（非CEB）IAC SE
IAC SB AUTHENTICATION IS
KEA_SJ
AUTH_CLIENT_TO_SERVER |
AUTH_HOW_MUTUAL |
ENCRYPT_AFTER_EXCHANGE |
INI_CRED_FWD_OFF
KEA_IVA_RESPONSEB_NONCEA
IVa||Encrypt( (NonceB XOR 0x0C12)||NonceA )
IAC SE -->
Client (Party A) Server (Party B)
<client begins encryption> <-- IAC SB AUTHENTICATION REPLY KEA_SJ AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_RESPONSEA Encrypt( NonceA XOR 0x0C12 ) IAC SE
<クライアントはencryption> <-iac sb認証返信kea_sj auth_client_to_server |auth_how_mutual |encrypt_after_exchange |INI_CRED_FWD_OFF KEA_RESPONSEA ENCRYPT（NONCEA XOR 0x0C12）IAC SE
<server begins encryption>
---------------------------------------------------------------------
Figure 1.
SKIPJACK with stream integrity is more complicated. It uses the SHA-1 [3] one-way hash function to provide integrity of the encryption stream as follows:
ストリームの完全性を備えたSkipJackはより複雑です。SHA-1 [3]一方向ハッシュ関数を使用して、次のように暗号化ストリームの完全性を提供します。
Set H0 to be the SHA-1 hash of a zero-length string. Cn is the nth character in the TELNET stream. Hn = SHA-1( Hn-1||Cn ), where Hn is the hash value associated with the nth character in the stream. ICVn is set to the three most significant bytes of Hn. Transmit Encrypt( Cn||ICVn ).
h0をゼロ長さの文字列のsha-1ハッシュに設定します。CNは、Telnetストリームのn番目の文字です。hn = sha-1（hn-1 || cn）。ここで、hnはストリーム内のn番目の文字に関連付けられたハッシュ値です。ICVNは、HNの3つの最も重要なバイトに設定されています。暗号化（CN || ICVN）を送信します。
The ciphertext that is transmitted is the SKIPJACK CFB-32 encryption of ( Cn||ICVn ). The receiving end of the TELNET link reverses the process, first decrypting the ciphertext, separating Cn and ICVn, recalculating Hn, recalculating ICVn, and then comparing the received ICVn with the recalculated ICVn. Integrity is indicated if the comparison succeeds, and Cn can then be processed normally as part of the TELNET stream. Failure of the comparison indicates some loss of integrity, whether due to active manipulation or loss of cryptographic synchronization. In either case, the only recourse is to drop the TELNET connection and start over.
送信される暗号文は、（CN || ICVN）のSkipJack CFB-32暗号化です。Telnetリンクの受信側は、プロセスを逆転させ、最初に暗号文を復号化し、CNとICVNを分離し、HNを再計算し、ICVNを再計算し、受信したICVNと再計算されたICVNを比較します。比較が成功した場合、整合性が示され、その後、CNをTelnetストリームの一部として通常処理できます。比較の障害は、積極的な操作または暗号化の同期の喪失によるものであろうと、ある程度の完全性の喪失を示します。どちらの場合でも、唯一の手段はTelnet接続をドロップしてやり直すことです。
For SKIPJACK with stream integrity, the two-octet authentication type pair is KEA_SJ_INTEG AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF. This indicates that the KEA SKIPJACK with integrity mechanism will be used for mutual authentication and TELNET stream encryption. Figure 2 illustrates the authentication mechanism of KEA SKIPJACK with stream integrity.
SkipJackの整合性の場合、2オクテット認証タイプのペアはKEA_SJ_INTEG AUTH_CLIENT_TO_SERVERです|auth_how_mutual |encrypt_after_exchange |ini_cred_fwd_off。これは、整合性メカニズムを備えたKea Skipjackが相互認証とTelnetストリーム暗号化に使用されることを示しています。図2は、Kea Skipjackの認証メカニズムを、ストリームの完全性を示しています。
---------------------------------------------------------------------
Client (Party A) Server (Party B)
<-- IAC DO AUTHENTICATION
<-IACは認証を行います
IAC WILL AUTHENTICATION -->
<-- IAC SB AUTHENTICATION SEND <list of authentication options> IAC SE
<-IACSB認証送信<認証オプションのリスト> IAC SE
IAC SB AUTHENTICATION
NAME <user name> -->
IAC SB AUTHENTICATION IS
KEA_SJ_INTEG
AUTH_CLIENT_TO_SERVER |
AUTH_HOW_MUTUAL |
ENCRYPT_AFTER_EXCHANGE |
INI_CRED_FWD_OFF
KEA_CERTA_RA
CertA||Ra IAC SE -->
<-- IAC SB AUTHENTICATION REPLY KEA_SJ_INTEG AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF IVA_RESPONSEB_NONCEA KEA_CERTB_RB_IVB_NONCEB CertB||Rb||IVb|| Encrypt( NonceB ) IAC SE
<-IAC SB認証返信KEA_SJ_INTEG AUTH_CLIENT_TO_SERVER |auth_how_mutual |encrypt_after_exchange |ini_cred_fwd_off iva_responseb_noncea kea_certb_rb_ivb_nonceb certb || rb || ivb ||暗号化（非CEB）IAC SE
IAC SB AUTHENTICATION IS
KEA_SJ_INTEG
AUTH_CLIENT_TO_SERVER |
AUTH_HOW_MUTUAL |
ENCRYPT_AFTER_EXCHANGE |
INI_CRED_FWD_OFF
KEA_IVA_RESPONSEB_NONCEA
IVa||Encrypt( (NonceB XOR 0x0D12)||NonceA )
IAC SE -->
Client (Party A) Server (Party B)
<client begins encryption> <-- IAC SB AUTHENTICATION REPLY KEA_SJ_INTEG AUTH_CLIENT_TO_SERVER | AUTH_HOW_MUTUAL | ENCRYPT_AFTER_EXCHANGE | INI_CRED_FWD_OFF KEA_RESPONSEA Encrypt( NonceA XOR 0x0D12 ) IAC SE
<クライアントはencryption> <-iac sb認証返信kea_sj_integ auth_client_to_server |auth_how_mutual |encrypt_after_exchange |INI_CRED_FWD_OFF KEA_RESPONSEA ENCRYPT（NONCEA XOR 0x0D12）IAC SE
<server begins encryption>
---------------------------------------------------------------------
Figure 2
This entire memo is about security mechanisms. For KEA to provide the authentication discussed, the implementation must protect the private key from disclosure. Likewise, the SKIPJACK keys must be protected from disclosure.
このメモ全体は、セキュリティメカニズムに関するものです。KEAが議論された認証を提供するには、実装は秘密鍵を開示から保護する必要があります。同様に、Skipjackキーは開示から保護する必要があります。
Implementations must randomly generate KEA private keys, initialization vectors (IVs), and nonces. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult. RFC 1750 [8] offers important guidance in this area, and Appendix 3 of FIPS Pub 186 [9] provides one quality PRNG technique.
実装では、KEAプライベートキー、初期化ベクトル（IV）、およびNoncesをランダムに生成する必要があります。不十分な擬似ランダム数ジェネレーター（PRNGS）を使用して暗号化キーを生成すると、セキュリティがほとんどまたはまったくなりません。攻撃者は、キーを生成するキーを生成するPRNG環境を再現する方がはるかに簡単になる可能性があります。品質の乱数の生成は困難です。RFC 1750 [8]はこの分野で重要なガイダンスを提供し、FIPS Pub 186 [9]の付録3は1つの品質のPRNG手法を提供します。
By linking the enabling of encryption as a side effect of successful authentication, protection is provided against an active attacker. If encryption were enabled as a separate negotiation, it would provide a window of vulnerability from when the authentication completes, up to and including the negotiation to turn on encryption. The only safe way to restart encryption, if it is turned off, is to repeat the entire authentication process.
暗号化の有効化を成功した認証の副作用としてリンクすることにより、アクティブな攻撃者に対して保護が提供されます。暗号化が別の交渉として有効になった場合、認証が完了したときから脆弱性のウィンドウを提供し、暗号化をオンにする交渉まで、そして含めます。暗号化がオフになっている場合、暗号化を再起動する唯一の安全な方法は、認証プロセス全体を繰り返すことです。
The authentication types KEA_SJ and KEA_SJ_INTEG and their associated suboption values are registered with IANA. Any suboption values used to extend the protocol as described in this document must be registered with IANA before use. IANA is instructed not to issue new suboption values without submission of documentation of their use.
認証タイプのKEA_SJとKEA_SJ_INTEGおよびそれに関連するサブオプション値は、IANAに登録されています。このドキュメントで説明されているプロトコルを拡張するために使用されるサブオプション値は、使用前にIANAに登録する必要があります。IANAは、使用の文書を提出せずに新しいサブオプション値を発行しないように指示されています。
We would like to thank William Nace for support during implementation of this specification.
この仕様の実装中にサポートをしてくれたWilliam Naceに感謝します。
[1] Postel, J. and J. Reynolds, "TELNET Protocol Specification", ASTD 8, RFC 854, May 1983.
[1] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、ASTD 8、RFC 854、1983年5月。
[2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941, September 2000.
[2] Ts'o、T。およびJ. Altman、「Telnet認証オプション」、RFC 2941、2000年9月。
[3] Secure Hash Standard. FIPS Pub 180-1. April 17, 1995.
[3] 安全なハッシュ標準。FIPS Pub 180-1。1995年4月17日。
[4] "SKIPJACK and KEA Algorithm Specification", Version 2.0, May 29, 1998. Available from http://csrc.nist.gov/encryption/skipjack-kea.htm
[4] 「Skipjack and Keaアルゴリズムの仕様」、バージョン2.0、1998年5月29日。http：//csrc.nist.gov/encryption/skipjack-kea.htmから入手可能
[5] Postel, J. and J. Reynolds, "TELNET Option Specifications", STD 8, RFC 855, May 1983.
[5] Postel、J。およびJ. Reynolds、「Telnetオプション仕様」、STD 8、RFC 855、1983年5月。
[6] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure: X.509 Certificate and CRL Profile", RFC 2459, January 1999.
[6] Housley、R.、Ford、W.、Polk、W。and D. Solo、「Internet X.509公開キーインフラストラクチャ：X.509証明書とCRLプロファイル」、RFC 2459、1999年1月。
[7] Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure - Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates", RFC 2528, March 1999.
[7] Housley、R。and W. Polk、「インターネットX.509公開キーインフラストラクチャ - インターネットX.509公開キーインフラストラクチャ証明書のキー交換アルゴリズム（KEA）キーの表現」、RFC 2528、1999年3月。
[8] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[8] Eastlake、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性の推奨」、RFC 1750、1994年12月。
[9) National Institute of Standards and Technology. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
[9）国立標準技術研究所。FIPS Pub 186：デジタル署名標準。1994年5月19日。
Russell Housley SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20170 USA
Russell Housley Spyrus 381 Elden Street、Suite 1120 Herndon、VA 20170 USA
EMail: housley@spyrus.com
Todd Horting SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20170 USA
トッド・ホートスピルス381エルデンストリート、スイート1120ハーンドン、バージニア州20170 USA
EMail: thorting@spyrus.com
Peter Yee SPYRUS 5303 Betsy Ross Drive Santa Clara, CA 95054 USA
Peter Yee Spyrus 5303 Betsy Ross Drive Santa Clara、CA 95054 USA
EMail: yee@spyrus.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。