RFC3163 日本語訳
3163 ISO/IEC 9798-3 Authentication SASL Mechanism. R. Zuccherato, M.Nystrom. August 2001. (Format: TXT=32498 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Zuccherato
Request for Comments: 3163 Entrust Technologies
Category: Experimental M. Nystrom
RSA Security
August 2001
Zuccheratoがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3163は技術カテゴリをゆだねます: 実験的なM.ニストロムRSAセキュリティ2001年8月
ISO/IEC 9798-3 Authentication SASL Mechanism
ISO/IEC9798-3認証SASLメカニズム
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
IESG Note
IESG注意
It is the opinion of the Security Area Directors that this document defines a mechanism to use a complex system (namely PKI certificates) for authentication, but then intentionally discards the key benefits (namely integrity on each transmission). Put another way, it has all of the pain of implementing a PKI and none of the benefits. We should not support it in use in Internet protocols.
このドキュメントが認証の複合システム(すなわち、PKI証明書)を使用するためにメカニズムを定義しますが、故意に、主要な利益(すなわち、各トランスミッションでの保全)を捨てるのは、Security Areaディレクターの意見です。 別の方法を置いてください、そして、それはPKIを実装する痛みと利益のどれかのすべてを持っているというわけではありません。 私たちはインターネットプロトコルでそれを使用中にサポートするべきではありません。
The same effect, with the benefits of PKI, can be had by using TLS/SSL, an existing already standards track protocol.
PKIの利益で、TLS/SSLを使用することによって、同じ効果を持つことができて、存在は既に標準化過程プロトコルです。
Abstract
要約
This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB 196 entity authentication.
このドキュメントはISO/IEC9798-3とFIPS PUB196実体認証に基づくSASL(簡単なAuthenticationとSecurity Layer)認証機構を定義します。
Zuccherato & Nystrom Experimental [Page 1] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[1ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
1. Introduction
1. 序論
1.1. Overview
1.1. 概要
This document defines a SASL [RFC2222] authentication mechanism based on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS] entity authentication.
このドキュメントはISO/IEC9798-3[ISO3]とFIPS PUB196[FIPS]実体認証に基づくSASL[RFC2222]認証機構を定義します。
This mechanism only provides authentication using X.509 certificates [X509]. It has no effect on the protocol encodings and does not provide integrity or confidentiality services.
このメカニズムは、X.509証明書[X509]を使用することで認証を提供するだけです。 それは、プロトコルencodingsで効き目がなくて、また保全か秘密性にサービスを提供しません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
The key benefit of asymmetric (public key) security, is that the secret (private key) only needs to be placed with the entity that is being authenticated. Thus, a private key can be issued to a client, which can then be authenticated by ANY server based on a token generated by the client and the generally available public key. Symmetric authentication mechanisms (password mechanisms such as CRAM-MD5 [RFC2195]) require a shared secret, and the need to maintain it at both endpoints. This means that a secret key for the client needs to be maintained at every server that may need to authenticate the client.
非対称の(公開鍵)セキュリティの主要な利益は秘密(秘密鍵)が、認証されている実体に置かれる必要があるだけであるということです。 したがって、クライアントに秘密鍵を発行できます。(次に、クライアントと一般に利用可能な公開鍵によって生成されたトークンに基づくどんなサーバもそのクライアントを認証できます)。 左右対称の認証機構(CRAM-MD5[RFC2195]などのパスワードメカニズム)は共有秘密キー、および両方の終点でそれを維持する必要性を必要とします。 これは、クライアントのための秘密鍵が、クライアントを認証する必要があるかもしれないあらゆるサーバで維持される必要を意味します。
The service described in this memo provides authentication only. There are a number of places where an authentication only service is useful, e.g., where confidentiality and integrity are provided by lower layers, or where confidentiality or integrity services are provided by the application.
このメモで説明されたサービスは認証だけを提供します。 多くの場所がそこでは、どこであるか、認証、サービスだけが役に立ちます、例えば、下層で秘密性と保全を提供するか、またはアプリケーションで秘密性か保全サービスを提供するところで。
1.2. Relationship to TLS
1.2. TLSとの関係
The functionality defined here can be provided by TLS, and it is important to consider why it is useful to have it in both places. There are several reasons for this, e.g.:
TLSはここで定義された機能性を提供できます、そして、それがなぜ両方の場所で主張するために役に立つかを考えるのは重要です。 このいくつかの理由が例えばあります:
- Simplicity. This mechanism is simpler than TLS. If there is
only a requirement for this functionality (as distinct from all
of TLS), this simplicity will facilitate deployment.
- 簡単さ。 このメカニズムはTLSより簡単です。 この機能性(TLSのすべてと異なるとしての)のための要件しかないと、この簡単さは展開を容易にするでしょう。
- Layering. The SASL mechanism to establish authentication works
cleanly with most protocols. This mechanism can fit more
cleanly than TLS for some protocols.
- レイヤリング。 認証を確立するSASLメカニズムはほとんどのプロトコルで清潔に動作します。 このメカニズムはいくつかのプロトコルのためのTLSより清潔に合うことができます。
Zuccherato & Nystrom Experimental [Page 2] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[2ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
- Proxies. In some architectures the endpoint of the TLS session
may not be the application endpoint. In these situations, this
mechanism can be used to obtain end-to-end authentication.
- プロキシ。 いくつかのアーキテクチャでは、TLSセッションの終点はアプリケーション終点でないかもしれません。 これらの状況で、終わりから終わりへの認証を得るのにこのメカニズムを使用できます。
- Upgrade of authentication. In some applications it may not be
clear at the time of TLS session negotiation what type of
authentication may be required (e.g., anonymous, server,
client-server). This mechanism allows the negotiation of an
anonymous or server authenticated TLS session which can, at a
later time, be upgraded to provide the desired level of
authentication.
- 認証のアップグレード。 いくつかのアプリケーションでは、どんなタイプの認証が必要であるかが、TLSセッション交渉時点で明確でないかもしれない、(例えば、匿名である、サーバ、クライアント/サーバ) このメカニズムで、後でアップグレードできる匿名かサーバの認証されたTLSセッションの交渉は必要なレベルの認証を提供できます。
2. Description of Mechanism
2. メカニズムの記述
2.1. Scope
2.1. 範囲
The mechanism described in this memo provides either mutual or unilateral entity authentication as defined in ISO/IEC 9798-1 [ISO1] using an asymmetric (public-key) digital signature mechanism.
このメモで説明されたメカニズムはISO/IEC9798-1[ISO1]で非対称の(公開鍵)デジタル署名メカニズムを使用することで定義されるように互いの、または、一方的な実体認証を提供します。
2.2. Authentication modes
2.2. 認証モード
This SASL mechanism contains two authentication modes:
このSASLメカニズムは2つの認証モードを含んでいます:
- Unilateral client authentication: The client digitally signs a
challenge from the server, thus authenticating itself to the
server.
- 一方的なクライアント認証: クライアントはサーバから挑戦にデジタルに署名して、その結果、サーバにそれ自体を認証します。
- Mutual authentication: The client digitally signs a challenge
from the server and the server digitally signs a challenge from
the client. Thus both the client and server authenticate each
other.
- 互いの認証: クライアントはサーバから挑戦にデジタルに署名します、そして、サーバはクライアントから挑戦にデジタルに署名します。 したがって、クライアントとサーバの両方が互いを認証します。
2.3. SASL key
2.3. SASLキー
This mechanism has two SASL keys corresponding to the two different modes:
このメカニズムで、2個のSASLキーが2つの異なったモードに対応するようになります:
- "9798-U-<algorithm>" for unilateral client authentication.
- 「9798-U、-、<アルゴリズム>、」 一方的なクライアント認証のために。
- "9798-M-<algorithm>" for mutual authentication.
- 互いの認証のための「9798M-<のアルゴリズム>。」
Each SASL key may be used with a list of algorithms. A list of supported algorithms is given in Section 4.
アルゴリズムのリストと共にそれぞれのSASLキーを使用するかもしれません。セクション4でサポートしているアルゴリズムのリストを与えます。
Zuccherato & Nystrom Experimental [Page 3] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[3ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
2.4. Unilateral Client Authentication
2.4. 一方的なクライアント認証
This section gives a brief description of the steps that are performed for unilateral client authentication. The actual data structures are described fully in Section 3.
このセクションは一方的なクライアント認証のために実行されるステップの簡単な説明を与えます。 実際のデータ構造はセクション3で完全に説明されます。
a) The server generates a random challenge value R_B and sends it
to the client.
a) サーバは、無作為の挑戦が値R_Bであると生成して、それをクライアントに送ります。
b) The client generates a random value R_A and creates a token
TokenAB. The token contains R_A, the client's certificate and
also a digital signature created by the client over both R_A
and R_B. Optionally, it also contains an identifier for the
server.
b) クライアントは、無作為の値がRであると生成して、トークンTokenABを作成します。 トークンはR、クライアントの証明書、およびクライアントによってRとR_Bの両方の上に作成されたデジタル署名も含んでいます。 また、任意に、それはサーバのための識別子を含んでいます。
c) The client sends the token to the server.
c) クライアントはトークンをサーバに送ります。
d) The server verifies the token by:
d) サーバは以下でトークンについて確かめます。
- verifying the client's signature in TokenAB (this includes
full certificate path processing as described in [RFC2459]),
- TokenAB(これは[RFC2459]で説明されるように完全な証明書経路処理を含んでいる)でクライアントの署名について確かめます。
- verifying that the random number R_B, sent to the client in
Step 1, agrees with the random number contained in the
signed data of TokenAB, and
- そしてStep1のクライアントに送られた乱数R_BがTokenABの署名しているデータに含まれた乱数に同意することを確かめる。
- verifying that the identifier for the server, if present,
matches the server's distinguishing identifier.
- 存在しているならサーバのための識別子がサーバの区別識別子に合っていることを確かめます。
2.5. Mutual Authentication
2.5. 互いの認証
This section gives a brief description of the steps that are performed for mutual authentication. The actual data structures are described fully in Section 3.
このセクションは互いの認証のために実行されるステップの簡単な説明を与えます。 実際のデータ構造はセクション3で完全に説明されます。
a) The server generates a random challenge value R_B and sends it
to the client.
a) サーバは、無作為の挑戦が値R_Bであると生成して、それをクライアントに送ります。
b) The client generates a random value R_A and creates a token
TokenAB. The token contains R_A, the client's certificate and
also a digital signature created by the client over both R_A
and R_B. Optionally, it also contains an identifier for the
server.
b) クライアントは、無作為の値がRであると生成して、トークンTokenABを作成します。 トークンはR、クライアントの証明書、およびクライアントによってRとR_Bの両方の上に作成されたデジタル署名も含んでいます。 また、任意に、それはサーバのための識別子を含んでいます。
c) The client sends the token to the server.
c) クライアントはトークンをサーバに送ります。
d) The server verifies the token by:
d) サーバは以下でトークンについて確かめます。
Zuccherato & Nystrom Experimental [Page 4] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[4ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
- verifying the client's signature in TokenAB (this includes
full certificate path processing as described in [RFC2459]),
- TokenAB(これは[RFC2459]で説明されるように完全な証明書経路処理を含んでいる)でクライアントの署名について確かめます。
- verifying that the random number R_B, sent to the client in
Step 1, agrees with the random number contained in the
signed data of TokenAB, and
- そしてStep1のクライアントに送られた乱数R_BがTokenABの署名しているデータに含まれた乱数に同意することを確かめる。
- verifying that the identifier for the server, if present,
matches the server's distinguishing identifier.
- 存在しているならサーバのための識別子がサーバの区別識別子に合っていることを確かめます。
e) The server creates a token TokenBA. The token contains a third
random value R_C, the server's certificate and a digital
signature created by the server over R_A, R_B and R_C.
Optionally, it also contains an identifier for the client.
e) サーバはトークンTokenBAを作成します。 トークンはR、R_B、およびR_Cの上にサーバによって作成された3番目の無作為の値R_C、サーバの証明書、およびデジタル署名を含んでいます。 また、任意に、それはクライアントへの識別子を含んでいます。
f) The server sends the token to the client.
f) サーバはトークンをクライアントに送ります。
g) The client verifies the token by:
g) クライアントは以下でトークンについて確かめます。
- verifying the server's signature in TokenBA (this includes
full certificate path processing as described in [RFC2459]),
- TokenBA(これは[RFC2459]で説明されるように完全な証明書経路処理を含んでいる)でサーバの署名について確かめます。
- verifying that the random number R_B, received by the client
in Step 1, agrees with the random number contained in the
signed data of TokenBA,
- Step1にクライアントによって受け取られた乱数R_BがTokenBAの署名しているデータに含まれた乱数に同意することを確かめます。
- verifying that the random number R_A, sent to the server in
Step 2, agrees with the random number contained in the
signed data of Token BA and
- そしてStep2のサーバに送られた乱数RがToken BAの署名しているデータに含まれた乱数に同意することを確かめる。
- verifying that the identifier for the client, if present,
matches the client's distinguishing identifier.
- 存在しているならクライアントへの識別子がクライアントの区別識別子に合っていることを確かめます。
3. Token and Message Definition
3. トークンとメッセージ定義
Note - Protocol data units (PDUs) SHALL be DER-encoded [X690]
before transmitted.
注意--伝えられる前にプロトコルデータ単位(PDUs)SHALLはDERによってコード化されています[X690]。
3.1. The "TokenBA1" PDU
3.1. "TokenBA1" PDU"
TokenBA1 is used in both the unilateral client authentication and mutual authentication modes and is sent by the server to the client.
TokenBA1を一方的なクライアント認証と互いの認証モードの両方で使用して、サーバはクライアントに送ります。
TokenBA1 contains a random value, and, optionally, the servers name and certificate information.
TokenBA1は任意に無作為の値、サーバ名、および証明書情報を含んでいます。
Zuccherato & Nystrom Experimental [Page 5] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[5ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
TokenBA1 ::= SEQUENCE {
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
}
TokenBA1:、:= 系列randomB RandomNumber、TrustedAuth任意の任意のentityB[0]GeneralNames certPref[1]系列サイズ(1..MAX)
3.2. The "TokenAB" PDU
3.2. "TokenAB"PDU
TokenAB is used in the unilateral client authentication and mutual authentication modes and is sent by the client to the server. TokenAB contains a random number, entity B's name (optionally), entity certification information, an (optional) authorization identity, and a signature of a DER-encoded value of type TBSDataAB. The certA field is used to send the client's X.509 certificate (or a URL to it) and a related certificate chain to the server.
TokenABは一方的なクライアント認証と互いの認証モードで使用されて、クライアントによってサーバに送られます。TokenABはタイプTBSDataABのDERによってコード化された価値の乱数、実体ビーズ名(任意に)、実体証明情報、(任意)の承認のアイデンティティ、および署名を含んでいます。 certA分野は、クライアントのX.509証明書(または、それへのURL)と関連する証明書チェーンをサーバに送るのに使用されます。
The authID field is to be used when the identity to be used for access control is different than the identity contained in the certificate of the signer. If this field is not present, then the identity from the client's X.509 certificate shall be used.
authID分野はアクセスコントロールに使用されるべきアイデンティティが署名者の証明書に含まれたアイデンティティと異なっているとき、使用されていることです。 この分野が存在していないなら、クライアントのX.509証明書からのアイデンティティは使用されるものとします。
TokenAB ::= SEQUENCE {
randomA RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certA [1] CertData,
authID [2] GeneralNames OPTIONAL,
signature SIGNATURE { TBSDataAB }
TokenAB:、:= SEQUENCE、randomA RandomNumber、entityB[0]GeneralNames OPTIONAL、certA[1]CertData、authID[2]GeneralNames OPTIONAL、署名SIGNATURETBSDataAB
}(CONSTRAINED BY {-- The entityB and authID fields shall be included
-- in TokenAB if and only if they are also included in TBSDataAB.
-- The entityB field SHOULD be present in TokenAB whenever the
-- client believes it knows the identity of the server.--})
}(強制的{-- そして、TokenABの含まれていて、分野がそうするものとするentityBとauthID、また、それらがTBSDataABに含まれている場合にだけ。 -- entityBが現在のコネがTokenABであったならSHOULDをさばく、いつ、--クライアントが、サーバのアイデンティティを知っていると信じているか、--、)
TBSDataAB ::= SEQUENCE {
randomA RandomNumber,
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
authID [1] GeneralNames OPTIONAL
}
TBSDataAB:、:= 系列randomA RandomNumber、entityB[0]GeneralNames任意の、そして、authID[1]GeneralNames任意のrandomB RandomNumber
3.3. The "TokenBA2" PDU
3.3. "TokenBA2" PDU"
TokenBA2 is used in the mutual authentication mode and is sent by the server to the client. TokenBA2 contains a random number, entity A's name (optionally), certification information, and a signature of a DER-encoded value of type TBSDataBA. The certB field is to be used to send the server's X.509 certificate and a related certificate chain to the client.
TokenBA2を互いの認証モードで使用して、サーバはクライアントに送ります。 TokenBA2はタイプTBSDataBAのDERによってコード化された価値の乱数、実体Aの名前(任意に)、証明情報、および署名を含んでいます。 certB分野はサーバのX.509証明書と関連する証明書チェーンをクライアントに送るのに使用されることです。
Zuccherato & Nystrom Experimental [Page 6] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[6ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
TokenBA2 ::= SEQUENCE {
randomC RandomNumber,
entityA [0] GeneralNames OPTIONAL,
certB [1] CertData,
signature SIGNATURE { TBSDataBA }
}(CONSTRAINED BY {-- The entityA field shall be included in TokenBA2
-- if and only if it is also included in TBSDataBA. The entityA
-- field SHOULD be present and MUST contain the client's name
-- from their X.509 certificate.--})
TokenBA2:、:= SEQUENCE、randomC RandomNumber、entityA[0]GeneralNames OPTIONAL、certB[1]CertData、署名SIGNATURE TBSDataBA(強制的{-- そして、entityA分野はTokenBA2に含まれているものとします--、また、それがTBSDataBAに含まれている場合にだけ。 entityA--分野SHOULDは存在していて、クライアントの名前を含まなければなりません--それらのX.509証明書から--})
TBSDataBA ::= SEQUENCE {
randomB RandomNumber,
randomA RandomNumber,
randomC RandomNumber,
entityA GeneralNames OPTIONAL
}
TBSDataBA:、:= 系列randomB RandomNumber、randomC RandomNumberの、そして、entityA GeneralNames任意のrandomA RandomNumber
3.4. The "TrustedAuth" type
3.4. "TrustedAuth"はタイプします。
TrustedAuth ::= CHOICE {
authorityName [0] Name,
-- SubjectName from CA certificate
issuerNameHash [1] OCTET STRING,
-- SHA-1 hash of Authority's DN
issuerKeyHash [2] OCTET STRING,
-- SHA-1 hash of Authority's public key
authorityCertificate [3] Certificate,
-- CA certificate
pkcs15KeyHash [4] OCTET STRING
-- PKCS #15 key hash
}
TrustedAuth:、:= 選択{authorityName[0]は--OCTET STRING--AuthorityのDN issuerKeyHash[2]OCTET STRINGのSHA-1ハッシュ--SHA-1が論じ尽くすAuthorityの公開鍵authorityCertificate[3]証明書のカリフォルニア証明書issuerNameHash[1]からのSubjectName--カリフォルニアを証明書pkcs15KeyHash[4]OCTET STRINGと命名します--PKCS#15の主要なハッシュ}
The TrustedAuth type can be used by a server in its initial message
("TokenBA1") to indicate to a client preferred certificates/public
key pairs to use in the authentication.
サーバは初期のメッセージで使用できますTrustedAuthが、タイプする。(「TokenBA1") 都合のよい証明書/公開鍵をクライアントに示すのは認証における使用と対にします」。
A trusted authority is identified by its name, hash of its name, hash of its public key, its certificate, or PKCS #15 key hash. If identified by its name, then the authorityName field in TrustedAuth contains the SubjectName of its CA certificate. If it is identified by the hash of its name then the issuerNameHash field contains the SHA-1 hash of the DER encoding of SubjectName from its CA certificate. If it is identified by the hash of its public key then the issuerKeyHash field contains the SHA-1 hash of the authority's public key. The hash shall be calculated over the value (excluding tag and length) of the subject public key field in the issuer's certificate. If it is identified by its certificate then the authorityCertificate field contains its CA certificate. If it is
信じられた権威は名前、名前のハッシュ、公開鍵のハッシュ、証明書、またはPKCS#15の主要なハッシュによって特定されます。 名前によって特定されるなら、TrustedAuthのauthorityName分野はカリフォルニア証明書のSubjectNameを含んでいます。 それが名前のハッシュによって特定されるなら、issuerNameHash分野はカリフォルニア証明書からのSubjectNameのDERコード化のSHA-1ハッシュを含んでいます。 それが公開鍵のハッシュによって特定されるなら、issuerKeyHash分野は権威の公開鍵のSHA-1ハッシュを含んでいます。 ハッシュは発行人の証明書の対象の公開鍵分野の値(タグと長さを除いた)に関して計算されるものとします。 それが証明書によって特定されるなら、authorityCertificate分野はカリフォルニア証明書を含んでいます。 それがそうなら
Zuccherato & Nystrom Experimental [Page 7] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[7ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
identified by the PKCS #15 key hash then the pkcs15KeyHash field contains the hash of the CA's public key as defined in PKCS #15 [PKCS15] Section 6.1.4.
その時PKCS#15の主要なハッシュによって特定されて、pkcs15KeyHash分野はPKCS#15[PKCS15]部6.1の.4で定義されるようにCAの公開鍵のハッシュを含んでいます。
3.5. The "CertData" type
3.5. "CertData"はタイプします。
The certification data is a choice between a set of certificates and a certificate URL.
証明データは1セットの証明書と証明書URLの選択です。
The certificate set alternative is as in [RFC2630], meaning it is intended that the set be sufficient to contain chains from a recognized "root" or "top-level certification authority" to all of the sender certificates with which the set is associated. However, there may be more certificates than necessary, or there may be fewer than necessary.
セットが十分であることを意図することを含む意味するのが[RFC2630]で認識された「根」か「トップレベル証明権威」からセットが関連している送付者証明書のすべてまで鎖を作るように証明書セット代替手段があります。 しかしながら、必要とするより多くの証明書があるかもしれないか、またはそこでは、必要とするより少ないかもしれません。
Note - The precise meaning of a "chain" is outside the scope of
this document. Some applications may impose upper limits on
the length of a chain; others may enforce certain
relationships between the subjects and issuers of
certificates within a chain.
注意--このドキュメントの範囲の外に「チェーン」の正確な意味があります。 いくつかのアプリケーションが最大の限界をチェーンの長さに課すかもしれません。 他のものはチェーンの中で証明書の対象と発行人とのある関係を実施するかもしれません。
When the certURL type is used to specify the location at which the user's certificate can be found, it MUST be a non-relative URL, and MUST follow the URL syntax and encoding rules specified in [RFC1738]. The URL must include both a scheme (e.g., "http" or "ldap") and a scheme-specific part. The scheme-specific part must include a fully qualified domain name or IP address as the host.
certURLタイプがユーザの証明書を見つけることができる位置を指定するのに使用されるとき、URL構文と符号化規則が[RFC1738]で指定したと非親類URLでなければならなく、いうことにならなければなりません。 URLは体系(例えば、"http"か"ldap")と体系特有の部分の両方を含まなければなりません。 体系特有の部分はホストとして完全修飾ドメイン名かIPアドレスを含まなければなりません。
CertData ::= CHOICE {
certificateSet SET SIZE (1..MAX) OF Certificate,
certURL IA5String,
... -- For future extensions
}
CertData:、:= 選択certificateSet SET SIZE(1..MAX)OF Certificate、certURL IA5String、今後の拡大のための…
3.6. The "RandomNumber" type
3.6. "RandomNumber"はタイプします。
A random number is simply defined as an octet string, at least 8 bytes long.
乱数は単に八重奏ストリング、少なくとも8バイト長と定義されます。
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
RandomNumber:、:= 八重奏ストリング(サイズ(8..MAX))
3.7. The "SIGNATURE" type
3.7. 「署名」タイプ
This is similar to the "SIGNED" parameterized type defined in [RFC2459], the difference being that the "SIGNATURE" type does not include the data to be signed.
これは[RFC2459](「署名」タイプが署名されるためにデータを入れないということである違い)で定義されたparameterized「署名している」タイプと同様です。
Zuccherato & Nystrom Experimental [Page 8] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[8ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
SIGNATURE { ToBeSigned } ::= SEQUENCE {
algorithm AlgorithmIdentifier,
signature BIT STRING
}(CONSTRAINED BY {-- Must be the result of applying the signing
-- operation indicated in "algorithm" to the DER-encoded octets of
-- a value of type -- ToBeSigned })
署名ToBeSigned:、:= SEQUENCE、アルゴリズムAlgorithmIdentifier、署名BIT STRING(CONSTRAINED BY、--、署名を適用するという結果になってください--操作が中に--タイプの値--ToBeSignedのDERによってコード化された八重奏に「アルゴリズム」を示した、)でなければならない
3.8. Other types
3.8. 他のタイプ
The "GeneralNames" type is defined in [RFC2459].
「GeneralNames」タイプは[RFC2459]で定義されます。
4. Supported Algorithms
4. アルゴリズムであるとサポートされます。
The following signature algorithms are recognized for use with this mechanism, and identified by a key. Each key would be combined to make two possible SASL mechanisms. For example the DSA-SHA1 algorithm would give 9798-U-DSA-SHA1, and 9798-M-DSA-SHA1. All algorithm names are constrained to 13 characters, to keep within the total SASL limit of 20 characters.
以下の署名アルゴリズムは、使用としてこのメカニズムで認識されて、キーによって特定されます。 各キーは、2つの可能なSASLメカニズムを作るために結合されるでしょう。例えば、DSA-SHA1アルゴリズムは9798-U-DSA-SHA1、および9798MのDSA-SHA1に与えるでしょう。 すべてのアルゴリズム名が20のキャラクタの総SASL限界を制限するのが13のキャラクタに抑制されます。
The following table gives a list of algorithm keys, noting the object identifier and the body that assigned the identifier.
オブジェクト識別子と識別子を割り当てたボディーに注意して、以下のテーブルはアルゴリズムキーのリストを与えます。
Key Object Id Body
RSA-SHA1-ENC 1.2.840.113549.1.1.5 RSA
DSA-SHA1 1.2.840.10040.4.3 ANSI
ECDSA-SHA1 1.2.840.10045.4.1 ANSI
主要なオブジェクトイドボディーRSA-SHA1-ENC1.2.840.113549.1.1.5RSA DSA-SHA1 1.2.840.10040.4.3ANSI ECDSA-SHA1 1.2.840、.10045、.4、.1ANSI
Support of the RSA-SHA1-ENC algorithm is RECOMMENDED for use with this mechanism.
RSA-SHA1-ENCアルゴリズムのサポートはこのメカニズムによる使用のためのRECOMMENDEDです。
5. Examples
5. 例
5.1. IMAP4 example
5.1. IMAP4の例
The following example shows the use of the ISO/IEC 9798-3 Authentication SASL mechanism with IMAP4 [RFC2060].
以下の例はIMAP4[RFC2060]とのISO/IEC9798-3Authentication SASLメカニズムの使用を示しています。
The base64 encoding of challenges and responses, as well as the "+ " preceding the responses are part of the IMAP4 profile, not part of this specification itself (note that the line breaks in the sample authenticators are for editorial clarity and are not in real authenticators).
挑戦と応答のbase64コード化、および応答に先行する「+」はこの仕様の一部ではなく、IMAP4プロフィールの一部(サンプル固有識別文字のラインブレイクは編集の明快ためにあって、本当の固有識別文字にはないことに注意する)自体です。
Zuccherato & Nystrom Experimental [Page 9] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[9ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
S: * OK IMAP4 server ready
C: A001 AUTHENTICATE 9798-U-RSA-SHA1
S: + MAoECBI4l1h5h0eY
C: MIIBAgQIIxh5I0h5RYegD4INc2FzbC1yLXVzLmNvbaFPFk1odHRwOi8vY2VydHMt
ci11cy5jb20vY2VydD9paD1odmNOQVFFRkJRQURnWUVBZ2hBR2hZVFJna0ZqJnNu
PUVQOXVFbFkzS0RlZ2pscjCBkzANBgkqhkiG9w0BAQUFAAOBgQCkuC2GgtYcxGG1
NEzLA4bh5lqJGOZySACMmc+mDrV7A7KAgbpO2OuZpMCl7zvNt/L3OjQZatiX8d1X
buQ40l+g2TJzJt06o7ogomxdDwqlA/3zp2WMohlI0MotHmfDSWEDZmEYDEA3/eGg
kWyi1v1lEVdFuYmrTr8E4wE9hxdQrA==
S: A001 OK Welcome, 9798-U-RSA-SHA1 authenticated user: Magnus
S: * OK IMAP4のサーバ持ち合わせのC: A001は9798-U-RSA-SHA1 Sを認証します: + MAoECBI4l1h5h0eY C: MIIBAgQIIxh5I0h5RYegD4INc2FzbC1yLXVzLmNvbaFPFk1odHRwOi8vY2VydHMt ci11cy5jb20vY2VydD9paD1odmNOQVFFRkJRQURnWUVBZ2hBR2hZVFJna0ZqJnNu PUVQOXVFbFkzS0RlZ2pscjCBkzANBgkqhkiG9w0BAQUFAAOBgQCkuC2GgtYcxGG1 NEzLA4bh5lqJGOZySACMmc+mDrV7A7KAgbpO2OuZpMCl7zvNt/L3OjQZatiX8d1X buQ40l+g2TJzJt06o7ogomxdDwqlA/3zp2WMohlI0MotHmfDSWEDZmEYDEA3/卵のkWyi1v1lEVdFuYmrTr8E4wE9hxdQrA== S: A001 OK Welcome、9798-U-RSA-SHA1はユーザを認証しました: マグヌス
6. IANA Considerations
6. IANA問題
By registering the 9798-<U/M>-<algorithm> protocols as SASL mechanisms, implementers will have a well-defined way of adding this authentication mechanism to their product. Here is the registration template for the SASL mechanisms defined in this memo:
SASLメカニズム、implementersとしてのアルゴリズム>プロトコルが登録する9798<U/M>-<を登録することによって、彼らの製品にこの認証機構を加える明確な方法を持ってください。 ここに、このメモで定義されたSASLメカニズムのための登録テンプレートがあります:
SASL mechanism names: 9798-U-RSA-SHA1-ENC
9798-M-RSA-SHA1-ENC
9798-U-DSA-SHA1
9798-M-DSA-SHA1
9798-U-ECDSA-SHA1
9798-M-ECDSA-SHA1
; For a definition of the algorithms
see Section 4 of this memo.
SASLメカニズム名: 9798-U-RSA-SHA1-ENCの9798MのRSA-SHA1-ENC 9798-U-DSA-SHA1の9798MのDSA-SHA1 9798-U-ECDSA-SHA1の9798MのECDSA-SHA1。 アルゴリズムの定義に関しては、このメモのセクション4を見てください。
Security Considerations: See Section 7 of this memo
Published specification: This memo
Person & email address to
contact for further
information: See Section 9 of this memo.
Intended usage: COMMON
Author/Change controller: See Section 9 of this memo.
セキュリティ問題: このメモPublished仕様のセクション7を見てください: 詳細のために連絡するこのメモPersonとEメールアドレス: このメモのセクション9を見てください。 意図している用法: COMMON Author/変化コントローラ: このメモのセクション9を見てください。
7. Security Considerations
7. セキュリティ問題
The mechanisms described in this memo only provides protection against passive eavesdropping attacks. They do not provide session privacy or protection from active attacks. In particular, man-in- the-middle attacks aimed at session "hi-jacking" are possible.
このメモで説明されたメカニズムは受け身の盗聴攻撃に対する保護を提供するだけです。 彼らは活発な攻撃からセッションプライバシーか保護を提供しません。 特に中の男性、-、-、中央、セッション「ハイジャック」が目的とされた攻撃は可能です。
The random numbers used in this protocol MUST be generated by a cryptographically strong random number generator. If the number is chosen from a small set or is otherwise predictable by a third party, then this mechanism can be attacked.
aで暗号でこのプロトコルに使用される乱数を生成しなければなりません。強い乱数発生器。 数が小さいセットから選ばれているか、またはそうでなければ、第三者が予測できるなら、このメカニズムを攻撃できます。
Zuccherato & Nystrom Experimental [Page 10] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[10ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
The inclusion of the random number R_A in the signed part of TokenAB prevents the server from obtaining the signature of the client on data chosen by the server prior to the start of the authentication mechanism. This measure may be required, for example, when the same key is used by the client for purposes other than entity authentication. However, the inclusion of R_B in TokenBA2, whilst necessary for security reasons which dictate that the client should check that it is the same as the value sent in the first message, may not offer the same protection to the server, since R_B is known to the client before R_A is chosen. For this reason a third random number, R_C, is included in the TokenBA2 PDU.
TokenABの署名している部分での乱数Rの包含は、サーバが認証機構の始まりの前にサーバによって選ばれたデータにおけるクライアントの署名を得るのを防ぎます。 同じキーが実体認証以外の目的にクライアントによって使用されるとき、例えば、この測定が必要であるかもしれません。 しかしながら、TokenBA2でのR_Bの包含は値が最初のメッセージを送ったのでクライアントが、それが同じであることをチェックするべきであると決めるセキュリティ理由に必要である間、同じ保護をサーバに提供しないかもしれません、Rが選ばれる前にR_Bがクライアントにとって知られているので。 この理由で、3番目の乱数(R_C)はTokenBA2 PDUに含まれています。
8. Bibliography
8. 図書目録
[FIPS] FIPS 196, "Entity authentication using public key
cryptography," Federal Information Processing Standards
Publication 196, U.S. Department of Commerce/N.I.S.T.,
National Technical Information Service, Springfield,
Virginia, 1997.
[FIPS]FIPS196、「公開鍵暗号を使用する実体認証」、連邦政府の情報Processing Standards Publication196、米国商務省/N.I.S.T.、技術情報サービス、スプリングフィールド(ヴァージニア)1997。
[ISO1] ISO/IEC 9798-1: 1997, Information technology - Security
techniques - Entity authentication - Part 1: General.
[ISO1]ISO/IEC9798-1: 1997、情報技術--セキュリティのテクニック--実体認証--第1部: 一般。
[ISO3] ISO/IEC 9798-3: 1997, Information technology - Security
techniques - Entity authentication - Part 3: Mechanisms
using digital signature techniques.
[ISO3]ISO/IEC9798-3: 1997、情報技術--セキュリティのテクニック--実体認証--パート3: デジタル署名のテクニックを使用するメカニズム。
[PKCS15] RSA Laboratories, "The Public-Key Cryptography Standards
- PKCS #15 v1.1: Cryptographic token information syntax
standard", June 6, 2000.
[PKCS15]RSA研究所、「公開鍵暗号化標準--PKCS#15v1.1:、」 2000年6月6日の「暗号のトークン情報構文規格。」
[RFC1738] Berners-Lee, T., Masinter L. and M. McCahill "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] バーナーズ・リーとT.とMasinter L.とM.McCahill「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2060] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[RFC2060] クリスピン、M.、「バージョン4rev1"、RFC2060、1996年インターネットメッセージアクセス・プロトコル--12月。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2195] Klensin, J., Catoe, R. and P. Krumviede "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2195, September 1997.
[RFC2195]Klensin、J.、Catoe、R.、およびP.Krumviede、「IMAP/POPは簡単な挑戦/応答のための拡大を認可する」RFC2195、9月1997日
Zuccherato & Nystrom Experimental [Page 11] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[11ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
[RFC2222] J. Meyers, "Simple Authentication and Security Layer",
RFC 2222, October 1997.
[RFC2222]J.メイヤーズ、「簡易認証とセキュリティは層にする」RFC2222、1997年10月。
[RFC2459] 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.
[RFC2459]Housley、R.、フォード、W.、ポーク、W.、およびD.が独奏される、「インターネットX.509公開鍵基盤:」 「X.509証明書とCRLプロフィール」、RFC2459、1月1999日
[RFC2630] R. Housley, "Cryptographic Message Syntax", RFC 2630,
June 1999.
[RFC2630]R.Housley、「暗号のメッセージ構文」、RFC2630、1999年6月。
[X509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
Information Technology - Open Systems Interconnection -
The Directory: Authentication Framework.
[X509]ITU-T推薦X.509(1997)| 情報技術--オープン・システム・インターコネクション--ISO/IEC9594-8:1998、ディレクトリ: 認証フレームワーク。
[X690] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
Information Technology - ASN.1 Encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
[X690]ITU-T推薦X.690(1997)| ISO/IEC8825-1: 1998、情報技術--ASN.1符号化規則: 基本的なコード化の仕様は(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)を統治します。
9. Authors' Addresses
9. 作者のアドレス
Robert Zuccherato Entrust Technologies 1000 Innovation Drive Ottawa, Ontario Canada K2K 3E7
ロバートZuccheratoは技術1000革新Driveオンタリオオタワ(カナダ)K2K3を7Eゆだねます。
Phone: +1 613 247 2598 EMail: robert.zuccherato@entrust.com
以下に電話をしてください。 +1 2598年の613 247メール: robert.zuccherato@entrust.com
Magnus Nystrom RSA Security Box 10704 121 29 Stockholm Sweden
マグヌスニストロムRSAセキュリティ箱10704の121 29ストックホルムスウェーデン
Phone: +46 8 725 0900 EMail: magnus@rsasecurity.com
以下に電話をしてください。 +46 8 725 0900はメールされます: magnus@rsasecurity.com
Zuccherato & Nystrom Experimental [Page 12] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[12ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
APPENDICES
付録
A. ASN.1 modules
A。 ASN.1モジュール
A.1. 1988 ASN.1 module
A.1。 1988ASN.1モジュール
SASL-9798-3-1988
SASL-9798-3-1988
DEFINITIONS IMPLICIT TAGS ::=
定義、内在しているタグ:、:=
BEGIN
始まってください。
-- EXPORTS ALL --
-- すべてをエクスポートします--
IMPORTS
輸入
Name, AlgorithmIdentifier, Certificate
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
PKIX1Explicit88からの名前、AlgorithmIdentifier、証明書iso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の明白な88(1)
GeneralNames
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(2)};
GeneralNames FROM PKIX1Implicit88のiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ風の(0)イドpkix1内在している88(2)。
TokenBA1 ::= SEQUENCE {
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
}
TokenBA1:、:= 系列randomB RandomNumber、TrustedAuth任意の任意のentityB[0]GeneralNames certPref[1]系列サイズ(1..MAX)
TokenAB ::= SEQUENCE {
randomA RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certA [1] CertData,
authID [2] GeneralNames OPTIONAL,
signature SEQUENCE {
algorithm AlgorithmIdentifier,
signature BIT STRING
}
} -- The entityB and authID fields shall be included in TokenAB
-- if and only if they are also included in TBSDataAB. The entityB
-- field SHOULD be present in TokenAB whenever the client
-- believes it knows the identity of the server.
-- The signature operation shall be done on a
-- DER-encoded value of type TBSDataAB.
TokenAB:、:= そして、SEQUENCE、randomA RandomNumber、entityB[0]GeneralNames OPTIONAL、certA[1]CertData、authID[2]GeneralNames OPTIONAL、署名SEQUENCE、アルゴリズムAlgorithmIdentifier、署名BIT STRING、--entityBとauthID分野はTokenABに含まれているものとします--、また、それらがTBSDataABに含まれている場合にだけ。 それはサーバのアイデンティティを知っています。entityB--現在のコネがTokenABであったならSHOULDをさばいてください、いつ、クライアント--、信じているか. --aで署名操作をするものとします--タイプTBSDataABのDERによってコード化された値。
Zuccherato & Nystrom Experimental [Page 13] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[13ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
TBSDataAB ::= SEQUENCE {
randomA RandomNumber,
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
authID [1] GeneralNames OPTIONAL
}
TBSDataAB:、:= 系列randomA RandomNumber、entityB[0]GeneralNames任意の、そして、authID[1]GeneralNames任意のrandomB RandomNumber
TokenBA2 ::= SEQUENCE {
randomC RandomNumber,
entityA [0] GeneralNames OPTIONAL,
certB [1] CertData,
signature SEQUENCE {
algorithm AlgorithmIdentifier,
signature BIT STRING
}
} -- The entityA field shall be included in TokenBA2
-- if and only if it is also included in TBSDataBA. The entityA
-- field SHOULD be present and MUST contain the client's name
-- from their X.509 certificate. The signature shall be done
-- on a DER-encoded value of type TBSDataBA.
TokenBA2:、:= そして、SEQUENCE、randomC RandomNumber、entityA[0]GeneralNames OPTIONAL、certB[1]CertData、署名SEQUENCE、アルゴリズムAlgorithmIdentifier、署名BIT STRING、--entityA分野はTokenBA2に含まれているものとします--、また、それがTBSDataBAに含まれている場合にだけ。 entityA--分野SHOULDは存在していて、それらのX.509証明書からのクライアントの名前を含まなければなりません。 署名は完了しているものとします--タイプTBSDataBAのDERによってコード化された値に関して。
TBSDataBA ::= SEQUENCE {
randomB RandomNumber,
randomA RandomNumber,
randomC RandomNumber,
entityA GeneralNames OPTIONAL
}
TBSDataBA:、:= 系列randomB RandomNumber、randomC RandomNumberの、そして、entityA GeneralNames任意のrandomA RandomNumber
TrustedAuth ::= CHOICE {
authorityName [0] Name,
-- SubjectName from CA certificate
issuerNameHash [1] OCTET STRING,
-- SHA-1 hash of Authority's DN
issuerKeyHash [2] OCTET STRING,
-- SHA-1 hash of Authority's public key
authorityCertificate [3] Certificate,
-- CA certificate
pkcs15KeyHash [4] OCTET STRING
-- PKCS #15 key hash
}
TrustedAuth:、:= 選択{authorityName[0]はAuthorityのDN issuerKeyHash[2]OCTET STRING(Authorityの公開鍵authorityCertificate[3]証明書のSHA-1細切れ肉料理)の--カリフォルニア証明書issuerNameHash[1]OCTET STRINGからのSubjectName--SHA-1細切れ肉料理をカリフォルニア証明書pkcs15KeyHash[4]OCTET STRINGと命名します--PKCS#15の主要な細切れ肉料理}
CertData ::= CHOICE {
certificateSet SET SIZE (1..MAX) OF Certificate,
certURL IA5String
}
CertData:、:= 選択certificateSetは証明書、certURL IA5Stringのサイズ(1..MAX)を設定します。
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
RandomNumber:、:= 八重奏ストリング(サイズ(8..MAX))
Zuccherato & Nystrom Experimental [Page 14] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[14ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
END
終わり
A.2. 1997 ASN.1 module
A.2。 1997ASN.1モジュール
SASL-9798-3-1997
SASL-9798-3-1997
DEFINITIONS IMPLICIT TAGS ::=
定義、内在しているタグ:、:=
BEGIN
始まってください。
-- EXPORTS ALL --
-- すべてを輸出します--
IMPORTS
輸入
AlgorithmIdentifier, Name, Certificate
FROM PKIX1Explicit93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-93(3)}
PKIX1Explicit93からのAlgorithmIdentifier、名前、証明書iso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の明白な93(3)
GeneralNames
FROM PKIX1Implicit93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-93(4)};
GeneralNames FROM PKIX1Implicit93のiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ風の(0)イドpkix1内在している93(4)。
TokenBA1 ::= SEQUENCE {
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
}
TokenBA1:、:= 系列randomB RandomNumber、TrustedAuth任意の任意のentityB[0]GeneralNames certPref[1]系列サイズ(1..MAX)
TokenAB ::= SEQUENCE {
randomA RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certA [1] CertData,
authID [2] GeneralNames OPTIONAL,
signature SIGNATURE { TBSDataAB }
}(CONSTRAINED BY {-- The entityB and authID fields shall be included
-- in TokenAB if and only if they are also included in TBSDataAB.
-- The entityB field SHOULD be present in TokenAB whenever the
-- client believes it knows the identity of the server.--})
TokenAB:、:= SEQUENCE、randomA RandomNumber、entityB[0]GeneralNames OPTIONAL、certA[1]CertData、authID[2]GeneralNames OPTIONAL、署名SIGNATURE TBSDataAB(強制的{-- そして、TokenABの含まれていて、分野がそうするものとするentityBとauthID、また、それらがTBSDataABに含まれている場合にだけ。 -- entityBが現在のコネがTokenABであったならSHOULDをさばく、いつ、--クライアントが、サーバのアイデンティティを知っていると信じているか、--})
TBSDataAB ::= SEQUENCE {
randomA RandomNumber,
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
authID [1] GeneralNames OPTIONAL
}
TBSDataAB:、:= 系列randomA RandomNumber、entityB[0]GeneralNames任意の、そして、authID[1]GeneralNames任意のrandomB RandomNumber
Zuccherato & Nystrom Experimental [Page 15] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[15ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
TokenBA2 ::= SEQUENCE {
randomC RandomNumber,
entityA [0] GeneralNames OPTIONAL,
certB [1] CertData,
signature SIGNATURE { TBSDataBA }
}(CONSTRAINED BY {-- The entityA field shall be included in TokenBA2
-- if and only if it is also included in TBSDataBA. The entityA
-- field SHOULD be present and MUST contain the client's name
-- from their X.509 certificate.--})
TokenBA2:、:= SEQUENCE、randomC RandomNumber、entityA[0]GeneralNames OPTIONAL、certB[1]CertData、署名SIGNATURE TBSDataBA(強制的{-- そして、entityA分野はTokenBA2に含まれているものとします--、また、それがTBSDataBAに含まれている場合にだけ。 entityA--分野SHOULDは存在していて、クライアントの名前を含まなければなりません--それらのX.509証明書から--})
TBSDataBA ::= SEQUENCE {
randomB RandomNumber,
randomA RandomNumber,
randomC RandomNumber,
entityA GeneralNames OPTIONAL
}
TBSDataBA:、:= 系列randomB RandomNumber、randomC RandomNumberの、そして、entityA GeneralNames任意のrandomA RandomNumber
TrustedAuth ::= CHOICE {
authorityName [0] Name,
-- SubjectName from CA certificate
issuerNameHash [1] OCTET STRING,
-- SHA-1 hash of Authority's DN
issuerKeyHash [2] OCTET STRING,
-- SHA-1 hash of Authority's public key
authorityCertificate [3] Certificate,
-- CA certificate
pkcs15KeyHash [4] OCTET STRING
-- PKCS #15 key hash
}
TrustedAuth:、:= 選択{authorityName[0]はAuthorityのDN issuerKeyHash[2]OCTET STRING(Authorityの公開鍵authorityCertificate[3]証明書のSHA-1細切れ肉料理)の--カリフォルニア証明書issuerNameHash[1]OCTET STRINGからのSubjectName--SHA-1細切れ肉料理をカリフォルニア証明書pkcs15KeyHash[4]OCTET STRINGと命名します--PKCS#15の主要な細切れ肉料理}
CertData ::= CHOICE {
certificateSet SET SIZE (1..MAX) OF Certificate,
certURL IA5String,
... -- For future extensions
}
CertData:、:= 選択certificateSet SET SIZE(1..MAX)OF Certificate、certURL IA5String、今後の拡大のための…
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
RandomNumber:、:= 八重奏ストリング(サイズ(8..MAX))
SIGNATURE { ToBeSigned } ::= SEQUENCE {
algorithm AlgorithmIdentifier,
signature BIT STRING
}(CONSTRAINED BY {-- Must be the result of applying the signing
-- operation indicated in "algorithm" to the DER-encoded octets of
-- a value of type -- ToBeSigned })
署名ToBeSigned:、:= SEQUENCE、アルゴリズムAlgorithmIdentifier、署名BIT STRING(CONSTRAINED BY、--、調印を適用するという結果になってください--操作が中に--タイプの値--ToBeSignedのDERによってコード化された八重奏に「アルゴリズム」を示した、)でなければならない
END
終わり
Zuccherato & Nystrom Experimental [Page 16] RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism August 2001
2001年のZuccheratoとニストロム実験的な[16ページ]RFC3163ISO/IEC認証SASLメカニズム8月9798-3日
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Zuccherato & Nystrom Experimental [Page 17]
ZuccheratoとニストロムExperimentalです。[17ページ]
一覧
スポンサーリンク
