[要約] RFC 2808は、SecurID(r) SASLメカニズムに関する仕様であり、認証プロトコルのセキュリティを向上させるために設計されています。このRFCの目的は、SecurIDトークンを使用してユーザーを認証するための安全な方法を提供することです。
Network Working Group M. Nystrom
Request for Comments: 2808 RSA Laboratories
Category: Informational April 2000
The SecurID(r) SASL Mechanism
Securid（R）SASLメカニズム
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
概要
SecurID is a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication. This document defines a SASL [RFC2222] authentication mechanism using these tokens, thereby providing a means for such tokens to be used in SASL environments. This mechanism is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services.
Securidは、エンドユーザー認証に使用されるRSA Security Inc.が生成するハードウェアトークンカード製品（またはそのソフトウェアエミュレーション）です。このドキュメントは、これらのトークンを使用してSASL [RFC2222]認証メカニズムを定義し、それによりSASL環境で使用する手段を提供します。このメカニズムは認証のみであり、プロトコルエンコーディングに影響を与えず、整合性または機密保持サービスを提供するようには設計されていません。
This memo assumes the reader has basic familiarity with the SecurID token, its associated authentication protocol and SASL.
このメモは、読者がSecuridトークン、関連する認証プロトコル、SASLに基本的な精通度を持っていると仮定しています。
How to read this document
このドキュメントを読む方法
The key words "MUST", "MUST NOT", "SHALL", "SHOULD" and "MAY" in this document are to be interpreted as defined in [RFC2119].
このドキュメントの「しなければならない」、「そうしない」、「そうしない」、「そうする必要はありません」、「そうする」、「可能性」は、[RFC2119]で定義されていると解釈されます。
In examples, "C:" and "S:" indicate messages sent by the client and server respectively.
例では、「C：」と「S：」は、それぞれクライアントとサーバーから送信されたメッセージを示します。
The SECURID SASL mechanism is a good choice for usage scenarios where a client, acting on behalf of a user, is untrusted, as a one-time passcode will only give the client a single opportunity to act maliciously. This mechanism provides authentication only.
Securid SASLメカニズムは、ユーザーに代わって行動するクライアントが1回限りのパスコードが悪意を持って行動する単一の機会を与えるだけであるため、クライアントが信頼されていない場合に適しています。このメカニズムは認証のみを提供します。
The SECURID SASL mechanism provides a formal way to integrate the existing SecurID authentication method into SASL-enabled protocols including IMAP [RFC2060], ACAP [RFC2244], POP3 [RFC1734] and LDAPv3 [RFC2251].
Securid SASLメカニズムは、既存のSecurID認証法をIMAP [RFC2060]、ACAP [RFC2244]、POP3 [RFC1734]、LDAPV3 [RFC2251]を含むSASL対応プロトコルに統合する正式な方法を提供します。
The SECURID SASL mechanism provides two-factor based user authentication as defined below.
Securid SASLメカニズムは、以下に定義する2要素ベースのユーザー認証を提供します。
There are basically three entities in the authentication mechanism described here: A user, possessing a SecurID token, an application server, to which the user wants to connect, and an authentication server, capable of authenticating the user. Even though the application server in practice may function as a client with respect to the authentication server, relaying authentication credentials etc. as needed, both servers are, unless explicitly mentioned, collectively termed "the server" here. The protocol used between the application server and the authentication server is outside the scope of this memo. The application client, acting on behalf of the user, is termed "the client".
ここで説明する認証メカニズムには、基本的に3つのエンティティがあります。ユーザーは、ユーザーが接続したいアプリケーションサーバー、ユーザーを認証できる認証サーバーを所有しています。実際のアプリケーションサーバーは、認証サーバーに関してクライアントとして機能し、認証資格情報などを中継する場合がありますが、両方のサーバーは、明示的に言及されていない限り、ここで「サーバー」と集合的に呼ばれます。アプリケーションサーバーと認証サーバーの間で使用されるプロトコルは、このメモの範囲外です。ユーザーに代わって行動するアプリケーションクライアントは、「クライアント」と呼ばれます。
The mechanism is based on the use of a shared secret key, or "seed", and a personal identification number (PIN), which is known both by the user and the authentication server. The secret seed is stored on a token that the user possesses, as well as on the authentication server. Hence the term "two-factor authentication", a user needs not only physical access to the token but also knowledge about the PIN in order to perform an authentication. Given the seed, current time of day, and the PIN, a "PASSCODE(r)" is generated by the user's token and sent to the server.
メカニズムは、ユーザーと認証サーバーの両方で知られている共有シークレットキーまたは「シード」の使用と、個人識別番号（PIN）の使用に基づいています。シークレットシードは、ユーザーが所有するトークンに、および認証サーバーに保存されます。したがって、「2要素認証」という用語では、ユーザーはトークンへの物理的なアクセスだけでなく、認証を実行するためにPINに関する知識も必要です。シード、現在の時刻、ピン、「パスコード（r）」がユーザーのトークンによって生成され、サーバーに送信されます。
The SECURID SASL mechanism provides one service:
Securid SASLメカニズムは1つのサービスを提供します。
- User authentication where the user provides information to the server, so that the server can authenticate the user.
- ユーザーがユーザーがサーバーに情報を提供し、サーバーがユーザーを認証できるようにするユーザー認証。
This mechanism is identified with the SASL key "SECURID".
このメカニズムは、SASLキー「Securid」で識別されます。
a) The client generates the credentials using local information (seed, current time and user PIN/password).
a) クライアントは、ローカル情報（シード、現在の時間、ユーザーPIN/パスワード）を使用して資格情報を生成します。
b) If the underlying protocol permits, the client sends credentials to the server in an initial response message. Otherwise, the client sends a request to the server to initiate the authentication mechanism, and sends credentials after the server's response (see [RFC2222] section 5.1 for more information regarding the initial response option).
b) 基礎となるプロトコルが許可されている場合、クライアントは最初の応答メッセージでサーバーに資格情報を送信します。それ以外の場合、クライアントは認証メカニズムを開始するためにサーバーにリクエストを送信し、サーバーの応答の後に資格情報を送信します（初期応答オプションに関する詳細については、セクション5.1を参照）。
Unless the server requests a new PIN (see below), the contents of the client's initial response SHALL be as follows:
サーバーが新しいピンを要求しない限り（以下を参照）、クライアントの初期応答の内容は次のとおりです。
(1) An authorization identity. When this field is empty, it defaults to the authentication identity. This field MAY be used by system administrators or proxy servers to login with a different user identity. This field MUST NOT be longer than 255 octets, SHALL be terminated by a NUL (0) octet, and MUST consist of UTF-8-encoded [RFC2279] printable characters only (US-ASCII [X3.4] is a subset of UTF-8).
(1) 認証アイデンティティ。このフィールドが空の場合、デフォルトは認証IDになります。このフィールドは、システム管理者またはプロキシサーバーが異なるユーザーIDでログインするために使用できます。このフィールドは255オクテットを超えてはならず、NUL（0）オクテットによって終了するものとし、UTF-8エンコード[RFC2279]印刷可能な文字のみで構成されている必要があります（US-ASCII [X3.4]はUTFのサブセットです-8）。
(2) An authentication identity. The identity whose passcode will be used. If this field is empty, it is assumed to have been transferred by other means (e.g. if the underlying protocol has support for this, like [RFC2251]). This field MUST NOT be longer than 255 octets, SHALL be terminated by a NUL (0) octet, and MUST consist of UTF-8-encoded printable characters only.
(2) 認証アイデンティティ。パスコードが使用されるアイデンティティ。このフィールドが空である場合、それは他の手段によって転送されたと想定されています（たとえば、基礎となるプロトコルが[RFC2251]のようにこれをサポートしている場合）。このフィールドは255オクテットを超えてはならず、NUL（0）オクテットによって終了するものとし、UTF-8エンコードの印刷可能な文字のみで構成されている必要があります。
(3) A passcode. The one-time password that will be used to grant access. This field MUST NOT be shorter than 4 octets, MUST NOT be longer than 32 octets, SHALL be terminated by a NUL (0) octet, and MUST consist of UTF-8-encoded printable characters only. Passcodes usually consist of 4-8 digits.
(3) パスコード。アクセスを付与するために使用される1回限りのパスワード。このフィールドは4オクテットよりも短くてはならず、32オクテットを超えてはならず、nul（0）オクテットによって終了する必要があり、UTF-8エンコードの印刷可能な文字のみで構成されている必要があります。通常、パスコードは4〜8桁で構成されています。
The ABNF [RFC2234] form of this message is as follows:
このメッセージのABNF [RFC2234]形式は次のとおりです。
credential-pdu = authorization-id authentication-id passcode [pin]
credential-pdu = authorization-id authentication-id passcode [pin]
authorization-id = 0*255VUTF8 %x00
authorization-id = 0*255vutf8％x00
authentication-id = 0*255VUTF8 %x00
Authentication-ID = 0*255VUTF8％X00
passcode = 4*32VUTF8 %x00
PassCode = 4*32VUTF8％X00
pin ::= 4*32VUTF8 %x00
VUTF8 = <Visible (printable) UTF8-encoded characters>
Regarding the <pin> rule, see d) below.
<pin>ルールについては、以下を参照してください。
c) The server verifies these credentials using its own information. If the verification succeeds, the server sends back a response indicating success to the client. After receiving this response, the client is authenticated. Otherwise, the verification either failed or the server needs an additional set of credentials from the client in order to authenticate the user.
c) サーバーは、独自の情報を使用してこれらの資格情報を検証します。検証が成功した場合、サーバーはクライアントに成功を示す応答を送り返します。この応答を受け取った後、クライアントは認証されます。それ以外の場合、検証が失敗したか、サーバーがユーザーを認証するためにクライアントから追加の資格情報を必要とします。
d) If the server needs an additional set of credentials, it requests them now. This request has the following format, described in ABNF notation:
d) サーバーが追加の資格情報を追加する必要がある場合、今すぐリクエストします。このリクエストには、ABNF表記で説明されている次の形式があります。
server-request = passcode | pin
server-request = passcode |ピン
passcode = "passcode" %x00
passCode = "passCode"％x00
pin = "pin" %x00 [suggested-pin]
pin = "pin"％x00 [swansed-pin]
suggested-pin = 4*32VUTF8 %x00 ; Between 4 and 32 UTF-8 characters
The 'passcode' choice will be sent when the server requests another passcode. The 'pin' choice will be sent when the server requests a new user PIN. The server will either send an empty string or suggest a new user PIN in this message.
サーバーが別のパスコードを要求すると、「パスコード」の選択が送信されます。サーバーが新しいユーザーピンを要求すると、「ピン」の選択が送信されます。サーバーは、空の文字列を送信するか、このメッセージに新しいユーザーピンを提案します。
e) The client generates a new set of credentials using local information and depending on the server's request and sends them to the server. Authentication now continues as in c) above.
e) クライアントは、ローカル情報を使用して、サーバーの要求に応じて新しい資格情報のセットを生成し、サーバーに送信します。現在、認証はc）上記のように続きます。
Note 1: Case d) above may occur e.g. when the clocks on which the server and the client relies are not synchronized.
注1：ケースd）上記が発生する可能性があります。サーバーとクライアントが依存する時計が同期されない場合。
Note 2: If the server requests a new user PIN, the client MUST respond with a new user PIN (together with a passcode), encoded as a UTF-8 string. If the server supplies the client with a suggested PIN, the client accepts this by replying with the same PIN, but MAY replace it with another one. The length of the PIN is application-dependent as are any other requirements for the PIN, e.g. allowed characters. If the server for some reason does not accept the received PIN, the client MUST be prepared to receive either a message indicating the failure of the authentication or a repeated request for a new PIN. Mechanisms for transferring knowledge about PIN requirements from the server to the client are outside the scope of this memo. However, some information MAY be provided in error messages transferred from the server to the client when applicable.
注2：サーバーが新しいユーザーピンを要求する場合、クライアントはUTF-8文字列としてエンコードされた新しいユーザーピン（パスコードと一緒に）で応答する必要があります。サーバーがクライアントに提案されたピンを提供する場合、クライアントは同じピンで返信することでこれを受け入れますが、別のピンに置き換えることができます。ピンの長さは、ピンの他の要件と同様に、アプリケーション依存です。許可された文字。何らかの理由でサーバーが受信したピンを受け入れない場合、クライアントは、認証の障害または新しいPINの繰り返しリクエストを示すメッセージのいずれかを受信する必要があります。サーバーからクライアントにPIN要件に関する知識を転送するメカニズムは、このメモの範囲外です。ただし、一部の情報は、該当する場合にサーバーからクライアントに転送されたエラーメッセージで提供される場合があります。
The following example shows the use of the SECURID SASL mechanism with IMAP4. The example is only designed to illustrate the protocol interaction but do provide valid encoding examples.
次の例は、IMAP4を使用したSecurid SASLメカニズムの使用を示しています。この例は、プロトコルの相互作用を説明するようにのみ設計されていますが、有効なエンコーディングの例を提供します。
The base64 encoding of the last client response, as well as the "+ " preceding the response, is part of the IMAP4 profile, and not a part of this specification itself.
最後のクライアント応答のbase64エンコーディングと、「応答の前の」は、IMAP4プロファイルの一部であり、この仕様自体の一部ではありません。
S: * OK IMAP4 server ready
C: A001 CAPABILITY
S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=SECURID
S: A001 OK done
C: A002 AUTHENTICATE SECURID
S: +
C: AG1hZ251cwAxMjM0NTY3OAA=
S: A002 OK Welcome, SECURID authenticated user: magnus
The following examples show the use of the SECURID SASL mechanism with LDAPv3. The examples are only designed to illustrate the protocol interaction, but do provide valid encoding examples. Usernames, passcodes and PINs are of course fictitious. For readability, all messages are shown in the value-notation defined in [X680]. <credential-pdu> values are shown hex-encoded in the 'credentials' field of LDAP's 'BindRequest' and <server-request> values are shown hex-encoded in the 'serverSaslCreds' field of LDAP's 'BindResponse'.
次の例は、LDAPV3を使用したSecurid SASLメカニズムの使用を示しています。例は、プロトコルの相互作用を説明するようにのみ設計されていますが、有効なエンコーディングの例を提供します。もちろん、ユーザー名、パスコード、ピンは架空のものです。読みやすさのために、すべてのメッセージは[x680]で定義されている値通知に表示されます。<資格-PDU>値は、LDAPの「BindRequest」の「資格情報」フィールドでヘックスエンコードされており、<server-Request>値は、LDAPの「bindResponse」の「serversaslcreds」フィールドでヘックスエンコードされています。
Initial response message, successful authentication.
初期応答メッセージ、成功した認証。
C: { messageID 1,
protocolOp bindRequest :
{ version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl :
{ mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
S: { messageID 1,
protocolOp bindResponse :
{ resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
Initial response message, server requires second passcode.
初期応答メッセージ、サーバーには2番目のパスコードが必要です。
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
S: {
messageID 1,
protocolOp bindResponse : {
resultCode saslBindInProgress,
matchedDN ''H,
errorMessage ''H,
serverSaslCreds '70617373636f646500'H
}
}
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300383736353433323100'H
}
}
}
S: {
messageID 1,
protocolOp bindResponse : {
resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
Initial response message, server requires new PIN and passcode, and supplies client with a suggested new PIN (which the client accepts).
最初の応答メッセージ、サーバーには新しいピンとパスコードが必要であり、クライアントに提案された新しいピン（クライアントが受け入れる）を提供します。
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e757300313233343536373800'H
}
}
}
S: {
messageID 1,
protocolOp bindResponse : {
resultCode saslBindInProgress,
matchedDN ''H,
errorMessage ''H,
serverSaslCreds '70696e006b616c6c6500'H
}
}
C: {
messageID 1,
protocolOp bindRequest : {
version 1,
name '434E3D4D41474E5553'H, -- "CN=MAGNUS"
authentication sasl : {
mechanism '53454355524944'H, -- "SECURID"
credentials '006d61676e7573003837343434363734006b616c6c6500'H
}
}
}
S: {
messageID 1,
protocolOp bindResponse : {
resultCode success,
matchedDN ''H,
errorMessage ''H,
}
}
This mechanism only provides protection against passive eavesdropping attacks. It does not provide session privacy, server authentication or protection from active attacks. In particular, man-in-the-middle attacks, were an attacker acts as an application server in order to acquire a valid passcode are possible.
このメカニズムは、受動的な盗聴攻撃に対する保護のみを提供します。セッションのプライバシー、サーバー認証、またはアクティブな攻撃からの保護は提供されません。特に、中間の攻撃は、有効なパスコードを取得するためにアプリケーションサーバーとして行動する攻撃者でした。
In order to protect against such attacks, the client SHOULD make sure that the server is properly authenticated. When user PINs are transmitted, user authentication SHOULD take place on a server-authenticated and confidentiality-protected connection.
そのような攻撃から保護するために、クライアントはサーバーが適切に認証されていることを確認する必要があります。ユーザーピンが送信されると、ユーザー認証がサーバーと保護された接続と保護された接続で行われる必要があります。
Server implementations MUST protect against replay attacks, since an attacker could otherwise gain access by replaying a previous, valid request. Clients MUST also protect against replay of PIN-change messages.
攻撃者は以前の有効な要求を再生することでアクセスを得ることができるため、サーバーの実装はリプレイ攻撃から保護する必要があります。また、クライアントはピンチェンジメッセージのリプレイから保護する必要があります。
It is possible for an attacker to listen to most of a passcode, guess the remainder, and then race the legitimate user to complete the authentication. As for OTP [RFC2289], conforming server implementations MUST protect against this race condition. One defense against this attack is outlined below and borrowed from [RFC2289]; implementations MAY use this approach or MAY select an alternative defense.
攻撃者がパスコードのほとんどを聞き、残りを推測し、正当なユーザーに競争して認証を完了することができます。OTP [RFC2289]に関しては、適合サーバーの実装はこのレース条件から保護する必要があります。この攻撃に対する1つの防御は、[RFC2289]から以下に概説され、借用されています。実装は、このアプローチを使用するか、代替防御を選択する場合があります。
One possible defense is to prevent a user from starting multiple simultaneous authentication sessions. This means that once the legitimate user has initiated authentication, an attacker would be blocked until the first authentication process has completed. In this approach, a timeout is necessary to thwart a denial of service attack.
考えられる防御の1つは、ユーザーが複数の同時認証セッションを開始できないようにすることです。これは、正当なユーザーが認証を開始すると、最初の認証プロセスが完了するまで攻撃者がブロックされることを意味します。このアプローチでは、サービス拒否攻撃を妨害するためのタイムアウトが必要です。
By registering the SecurID protocol as a SASL mechanism, implementers will have a well-defined way of adding this authentication mechanism to their product. Here is the registration template for the SECURID SASL mechanism:
SecuridプロトコルをSASLメカニズムとして登録することにより、実装者はこの認証メカニズムを製品に追加する明確な方法を持っています。Securid SASLメカニズムの登録テンプレートは次のとおりです。
SASL mechanism name: SECURID Security Considerations: See corresponding section of this memo Published specification: This memo Person & email address to contact for further information: See author's address section below Intended usage: COMMON Author/Change controller: See author's address section below
SASLメカニズム名：Securidセキュリティの考慮事項：このメモの対応するセクションを参照してください
RSA Security Inc. does not make any claims on the general constructions described in this memo, although underlying techniques may be covered. Among the underlying techniques, the SecurID technology is covered by a number of US patents (and foreign counterparts), in particular US patent no. 4,885,778, no. 5,097,505, no. 5,168,520, and 5,657,388.
RSA Security Inc.は、このメモに記載されている一般的な構造について主張していませんが、基礎となる手法については説明できます。基礎となる技術の中で、Securidテクノロジーは、多くの米国の特許（および外国の対応者）、特に米国の特許番号によってカバーされています。4,885,778、いいえ。5,097,505、いいえ。5,168,520、および5,657,388。
SecurID is a registered trademark, and PASSCODE is a trademark, of RSA Security Inc.
Securidは登録商標であり、PassCodeはRSA Security Incの商標です。
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[RFC1734] Myers、J。、「POP3認証コマンド」、RFC 1734、1994年12月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC2060] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 2060、1996年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer", RFC 2222, October 1997.
[RFC2222] Myers、J。、「Simple Authentication and Security Layer」、RFC 2222、1997年10月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244] Newman、C。and J. Myers、「ACAP -Application Configuration Access Protocol」、RFC 2244、1997年11月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", RFC 2289, February 1998.
[RFC2289] Haller、N.、N.、Metz、C.、Nesser、P。and M. Straw、「1回限りのパスワードシステム」、RFC 2289、1998年2月。
[X3.4] ANSI, "ANSI X3.4: Information Systems - Coded Character Sets - 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII)," American National Standards Institute.
[X3.4] ANSI、「ANSI X3.4：情報システム - コード化された文字セット-7ビットアメリカ国立標準コードのためのインターチェンジ（7ビットASCII）」、American National Standards Institute。
[X680] ITU-T, "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation," International Telecommunication Union, 1997.
[X680] ITU -T、「情報技術 - 要約構文表記1（ASN.1）：基本表記の仕様」、International Telecommunication Union、1997。
The author gratefully acknowledges the contributions of various reviewers of this memo, in particular the ones from John Myers. They have significantly clarified and improved the utility of this specification.
著者は、このメモのさまざまなレビュアー、特にジョンマイヤーズのレビュアーの貢献に感謝しています。彼らは、この仕様の有用性を大幅に明らかにし、改善しました。
Magnus Nystrom RSA Laboratories Box 10704 121 29 Stockholm Sweden
Magnus Nystrom RSA Laboratories Box 10704 121 29 Stockholm Sweden
Phone: +46 8 725 0900
EMail: magnus@rsasecurity.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エディター機能の資金は現在、インターネット協会によって提供されています。