RFC4386 日本語訳

Network Working Group                                          S. Boeyen
Request for Comments: 4386                                  Entrust Inc.
Category: Experimental                                   P. Hallam-Baker
                                                           VeriSign Inc.
                                                           February 2006

Boeyenがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4386は株式会社カテゴリをゆだねます: 実験的なP.ハラム-ベイカーベリサイン株式会社2006年2月

               Internet X.509 Public Key Infrastructure
                      Repository Locator Service

インターネットX.509公開鍵暗号基盤倉庫ロケータサービス

Status of This 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 (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   This document defines a Public Key Infrastructure (PKI) repository
   locator service.  The service makes use of DNS SRV records defined in
   accordance with RFC 2782.  The service enables certificate-using
   systems to locate PKI repositories.

このドキュメントは公開鍵暗号基盤(PKI)倉庫ロケータサービスを定義します。 サービスはRFC2782に従って定義されたDNS SRV記録を利用します。 サービスは、証明書を使用するシステムがPKI倉庫の場所を見つけるのを可能にします。

Table of Contents

目次

   1. Overview ........................................................2
      1.1. Conventions Used in This Document ..........................2
   2. SRV RR Definition ...............................................2
      2.1. Assignment of New Protocol Prefixes ........................3
      2.2. Use of Multiple Repositories ...............................3
      2.3. SRV RR Example .............................................3
   3. Security Considerations .........................................4
   4. IANA Considerations .............................................4
   5. Informative References ..........................................4

1. 概要…2 1.1. このドキュメントで中古のコンベンション…2 2. SRV RR定義…2 2.1. 新しいプロトコル接頭語の課題…3 2.2. 複数の倉庫の使用…3 2.3. SRV RRの例…3 3. セキュリティ問題…4 4. IANA問題…4 5. 有益な参照…4

Boeyen & Hallam-Baker         Experimental                      [Page 1]

RFC 4386                        PKIXREP                    February 2006

Boeyenと[1ページ]RFC4386PKIXREP2006年2月に実験的なハラム-ベイカー

1.  Overview

1. 概要

   A number of RFCs (including [RFC2559], [RFC2560], and [RFC2585]) have
   specified operational protocols for retrieval of PKI data, including
   public-key certificates and revocation information, from PKI
   repositories.  These RFCs assume that a certificate-using system has
   the information necessary to identify, locate, and connect to the PKI
   repository with a specific protocol.  Although some tools are
   available in protocol-specific environments for this purpose, such as
   knowledge references in directory systems, these are restricted for
   use with a single protocol and do not share a common means of
   publication.  This document provides a solution to this problem
   through the use of Service Record (SRV) Resource Records (RRs) in
   DNS.  This solution is expected to be particularly useful in
   environments where only a domain name is available.  In other
   situations (e.g., where a certificate is available that contains the
   required information), such a DNS lookup is not needed.

多くのRFCs([RFC2559]、[RFC2560]、および[RFC2585]を含んでいる)がPKIデータの検索に操作上のプロトコルを指定しました、公開鍵証明書と取消し情報を含んでいて、PKI倉庫から。 これらのRFCsは、証明書を使用するシステムには特定のプロトコルでPKI倉庫に特定して、場所を見つけて、接続する必要情報があると仮定します。 いくつかのツールが利用可能ですが、この目的のためのディレクトリシステムにおける知識参照などのプロトコル特有の環境で、これらは、使用のためにただ一つのプロトコルで制限されて、公表の一般的な手段を共有しません。 このドキュメントはDNSにおけるService Record(SRV)リソースRecords(RRs)の使用によるこの問題に解決法を提供します。 このソリューションがドメイン名だけが入手できるところで環境で特に役に立つと予想されます。 他の状況(例えば、証明書が利用可能であるところでは、それは必須情報を含んでいる)で、そのようなDNSルックアップは必要ではありません。

   [RFC2782] defines a DNS RR for specifying the location of services
   (SRV).  This document defines SRV records for a PKI repository
   locator service to enable PKI clients to obtain the necessary
   information to connect to a domain's PKI repository, including
   information about each protocol that is supported by that domain for
   access to its repository.  This document includes the definition of
   an SRV RR format for this service and an example of its potential use
   in an email environment.

[RFC2782]は、サービス(SRV)の位置を指定するためにDNS RRを定義します。 PKI倉庫ロケータサービスが、PKIクライアントがドメインのPKI倉庫に接続するために必要事項を得るのを可能にするように、このドキュメントはSRV記録を定義します、倉庫へのアクセスのためにそのドメインによってサポートされる各プロトコルの情報を含んでいて。 このドキュメントはメール環境とのこのサービスのためのSRV RR形式と潜在的使用に関する例の定義を含んでいます。

1.1.  Conventions Used in This Document

1.1. 本書では使用されるコンベンション

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
   as shown) are to be interpreted as described in [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「「推薦され」て、このドキュメント(中で大文字してください、示されるように)で「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?

   In examples, "C:" and "S:" indicate lines sent by the client and
   server, respectively.

例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。

2.  SRV RR Definition

2. SRV RR定義

   The format of the SRV RR, whose DNS type code is 33, is:

SRV RRの形式は以下の通りです。(SRV RRのDNSタイプコードは33です)。

    _Service._Proto.Name TTL Class SRV Priority Weight Port Target

_サービス_Proto.Name TTLクラスSRV優先権重さのポート目標

   For the PKI repository locator service, this document uses the
   symbolic name "PKIXREP".  Note that when used in an SRV RR, this name
   MUST be prepended with an "_" character.

PKI倉庫ロケータサービスのために、このドキュメントは英字名"PKIXREP"を使用します。 SRV RRで使用されると、"_"キャラクタと共にこの名前をprependedしなければならないことに注意してください。

Boeyen & Hallam-Baker         Experimental                      [Page 2]

RFC 4386                        PKIXREP                    February 2006

Boeyenと[2ページ]RFC4386PKIXREP2006年2月に実験的なハラム-ベイカー

   The protocols that can be included in PKIXREP SRV RRs are:

PKIXREP SRV RRsに含むことができるプロトコルは以下の通りです。

      Protocol     SRV Prefix

プロトコルSRV接頭語

      LDAP         _LDAP
      HTTP         _HTTP
      OCSP         _OCSP

LDAP_LDAP HTTP_HTTP OCSP_OCSP

2.1.  Assignment of New Protocol Prefixes

2.1. 新しいプロトコル接頭語の課題

   Protocol prefix assignments for new PKIX repository protocols SHOULD
   be defined in the document that specifies the protocol.

定義されたコネがプロトコルを指定するドキュメントであったなら新しいPKIX倉庫プロトコルSHOULDに接頭語課題について議定書の中で述べてください。

2.2.  Use of Multiple Repositories

2.2. 複数の倉庫の使用

   The existence of multiple repositories MAY be determined by making
   separate DNS queries for each of the protocols supported by the
   client.

クライアントにそれぞれのプロトコルのための別々のDNS質問をサポートさせることによって、複数の倉庫の存在は決定するかもしれません。

   If this approach is found to be unacceptably inefficient due to a
   proliferation of repository protocols at a future date, the service
   discovery protocol could be extended to allow the repository to
   advertise the protocols supported.

このアプローチが倉庫プロトコルの増殖のために後日に容認できないほど効率が悪いのがわかっているなら、サービス発見プロトコルは、サポートされたプロトコルの広告を出すために倉庫を許容するために広げられるかもしれません。

2.3.  SRV RR Example

2.3. SRV RRの例

   This example uses the fictional domain "example.com" as an aid in
   understanding the use of SRV records by a certificate-using system.

SRVの使用を理解することにおける援助が証明書を使用するシステムで記録するようにこの例は作り事のドメイン"example.com"を使用します。

   Assume that Alice is an email client that needs a certificate for a
   recipient.  Alice's client system supports LDAP for certificate
   retrieval.  Assume the message recipient is Bob and that Bob's email
   address is bob@example.com.  Assume that example.test maintains a
   "border directory" PKI repository and that Bob's certificate is
   available from that directory, "border.example.com", via LDAP.

アリスが受取人に証明書を必要とするメールクライアントであると仮定してください。 アリスのクライアントシステムは証明書検索のためにLDAPをサポートします。 メッセージ受取人がボブであり、そのボブのEメールアドレスが bob@example.com であると仮定してください。 example.testが「境界ディレクトリ」PKI倉庫を維持して、ボブの証明書がそのディレクトリ、"border.example.com"から利用可能であると仮定してください、LDAPを通して。

   Alice's client system retrieves, via DNS, the SRV record for
   _PKIXREP._LDAP.example.com.

アリスのクライアントシステムはDNSを通して_PKIXREP_LDAP.example.comのためのSRV記録を検索します。

      -  The QNAME of the DNS query is _PKIXREP._LDAP.example.com.

- DNS質問のQNAMEはそうです。_PKIXREP_LDAP.example.com。

      - The QCLASS of the DNS query is IN.

- DNS質問のQCLASSはINです。

      -  The QTYPE of the DNS query is SRV.

- DNS質問のQTYPEはSRVです。

   The result SHOULD include the host address for example.com's border
   directory system.

結果SHOULDはホスト・アドレスfor example.comの境界ディレクトリシステムを含んでいます。

Boeyen & Hallam-Baker         Experimental                      [Page 3]

RFC 4386                        PKIXREP                    February 2006

Boeyenと[3ページ]RFC4386PKIXREP2006年2月に実験的なハラム-ベイカー

   Note that if example.com operated its service on a number of hosts,
   more than one SRV RR would be returned.  In this case, RFC 2782
   defines the procedure to be followed in determining which of these
   should be accessed first.

example.comが多くのホストの上でサービスを操作するなら、1SRV RRが返されることに注意してください。 この場合、RFC2782は、これらのどれが最初にアクセスされるべきであるかを決定する際に続かれるように手順を定義します。

3.  Security Considerations

3. セキュリティ問題

   Security issues regarding PKI repositories themselves are outside the
   scope of this document.  For LDAP repositories, for example, specific
   security considerations are addressed in RFC 2559.

このドキュメントの範囲の外にPKI倉庫自体に関する安全保障問題があります。 LDAP倉庫に関しては、例えば、特定のセキュリティ問題はRFC2559で扱われます。

   Security issues with respect to the use of SRV records in general are
   addressed in RFC 2782, and these issues apply to the use of SRV
   records in the context of the PKIXREP service defined here.

一般に、SRV記録の使用に関する安全保障問題はRFC2782で扱われます、そして、これらの問題はここで定義されたPKIXREPサービスの文脈におけるSRV記録の使用に適用されます。

4.  IANA Considerations

4. IANA問題

   This document reserves the use of "_PKIXREP" service label.  Since
   this relates to a service that may pass messages over a number of
   different message transports, each message must be associated with a
   specific transport.

「このドキュメントは」 _PKIXREPの使用を控える」というサービスラベル。 これが多くの異なったメッセージ転送の上にメッセージを通過するかもしれないサービスに関連するので、それぞれのメッセージは特定の輸送に関連しているに違いありません。

   In order to ensure that the association between "_PKIXREP" and their
   respective underlying services is deterministic, the IANA has created
   a new registry: PKIX SRV Protocol Labels.

「」 」 _PKIXREPの間でそれらがそれぞれの基本的さがサービスを提供する協会が確実に決定論的になるようにするために、IANAは新しい登録を作成しました: PKIX SRVはラベルについて議定書の中で述べます。

   For this registry, an entry shall consist of a label name and a
   pointer to a specification describing how the protocol named in the
   label uses SRV.  Specifications should conform to the requirements
   listed in [RFC2434] for "specification required".

この登録に関しては、エントリーはラベルで指定されたプロトコルがどうSRVを使用するかを説明する仕様にラベル名と指針から成るものとします。 仕様は「仕様が必要である」ように[RFC2434]にリストアップされた要件に従うべきです。

5.  Informative References

5. 有益な参照

   [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月。

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.

[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [RFC2559] Boeyen, S., Howes, T., and P. Richard, "Internet X.509
             Public Key Infrastructure Operational Protocols - LDAPv2",
             RFC 2559, April 1999.

[RFC2559] Boeyen、S.、ハウズ、T.、およびP.リチャード、「LDAPv2"、RFC2559、1999年インターネットのX.509の公開鍵暗号基盤の操作上のプロトコル--4月。」

   [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
             Adams, "X.509 Internet Public Key Infrastructure Online
             Certificate Status Protocol - OCSP", RFC 2560, June 1999.

[RFC2560] マイアーズ、M.、Ankney、R.、Malpani、A.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。

Boeyen & Hallam-Baker         Experimental                      [Page 4]

RFC 4386                        PKIXREP                    February 2006

Boeyenと[4ページ]RFC4386PKIXREP2006年2月に実験的なハラム-ベイカー

   [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
             Infrastructure Operational Protocols: FTP and HTTP", RFC
             2585, May 1999.

[RFC2585] Housley、R.、およびP.ホフマン、「インターネットのX.509の公開鍵暗号基盤の操作上のプロトコル:」 「FTPとHTTP」(RFC2585)は1999がそうするかもしれません。

   [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
             specifying the location of services (DNS SRV)", RFC 2782,
             February 2000.

[RFC2782] Gulbrandsen、A.、Vixie、P.、およびL.Esibov、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2782(2000年2月)。

Authors' Addresses

作者のアドレス

   Sharon Boeyen
   Entrust
   1000 Innovation Drive
   Ottawa, Ontario
   Canada K2K 3E7

シャロンBoeyenは1000革新Driveオンタリオオタワ(カナダ)K2K3を7Eゆだねます。

   EMail: sharon.boeyen@entrust.com

メール: sharon.boeyen@entrust.com

   Phillip M. Hallam-Baker
   VeriSign Inc.
   401 Edgewater Place, Suite 280
   Wakefield MA 01880

フィリップM.ハラム-ベイカーベリサイン株式会社401Edgewater場所、スイート280ウェークフィールドMA 01880

   EMail: pbaker@VeriSign.com

メール: pbaker@VeriSign.com

Boeyen & Hallam-Baker         Experimental                      [Page 5]

RFC 4386                        PKIXREP                    February 2006

Boeyenと[5ページ]RFC4386PKIXREP2006年2月に実験的なハラム-ベイカー

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Boeyen & Hallam-Baker         Experimental                      [Page 6]

Boeyenであって、ハラム-ベイカーExperimentalです。[6ページ]