[要約] RFC 2585は、FTPとHTTPを使用したインターネットX.509公開鍵基盤の運用プロトコルに関する要約と目的を提供しています。

Network Working Group                                        R. Housley
Request for Comments: 2585                                       SPYRUS
Category: Standards Track                                    P. Hoffman
                                                                    IMC
                                                               May 1999
        

Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP

インターネットX.509公開キーインフラストラクチャ運用プロトコル:FTPおよびHTTP

Status of this Memo

本文書の位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の現在のエディションを参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (1999). All Rights Reserved.

Copyright(c)The Internet Society(1999)。無断転載を禁じます。

Abstract

概要

The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents.

このドキュメントで説明されているプロトコル規則は、インターネット公開インフラストラクチャ(PKI)の運用要件の一部を満たしています。このドキュメントは、PKIリポジトリから証明書と証明書の取り消しリスト(CRL)を取得するために、ファイル転送プロトコル(FTP)とハイパーテキスト転送プロトコル(HTTP)を使用するための規則を指定します。PKIXの運用要件に対処する追加のメカニズムは、個別のドキュメントで指定されています。

1 Introduction

1はじめに

This specification is part of a multi-part standard for the Internet Public Key Infrastructure (PKI) using X.509 certificates and certificate revocation lists (CRLs). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and CRLs from PKI repositories. Additional mechanisms addressing PKI repository access are specified in separate documents.

この仕様は、X.509証明書と証明書の取り消しリスト(CRL)を使用して、インターネット公開キーインフラストラクチャ(PKI)のマルチパート標準の一部です。このドキュメントは、ファイル転送プロトコル(FTP)とハイパーテキスト転送プロトコル(HTTP)を使用するための規則を指定して、PKIリポジトリから証明書とCRLを取得します。PKIリポジトリアクセスに対処する追加のメカニズムは、個別のドキュメントで指定されています。

1.1. Model
1.1. モデル

The following is a simplified view of the architectural model assumed by the Internet PKI specifications.

以下は、インターネットPKI仕様で想定される建築モデルの簡略化されたビューです。

      +---+
      | C |                       +------------+
      | e | <-------------------->| End entity |
      | r |       Operational     +------------+
      | t |       transactions          ^
      |   |      and management         |  Management
      | / |       transactions          |  transactions
      |   |                             |                PKI users
      | C |                             v
      | R |       -------------------+--+-----------+-----------------
      | L |                          ^              ^
      |   |                          |              |   PKI management
      |   |                          v              |       entities
      | R |                       +------+          |
      | e | <---------------------| RA   | <---+    |
      | p |  Publish certificate  +------+     |    |
      | o |                                    |    |
      | s |                                    |    |
      | I |                                    v    v
      | t |                                +------------+
      | o | <------------------------------|     CA     |
      | r |   Publish certificate          +------------+
      | y |   Publish CRL                         ^
      |   |                                       |
      +---+                        Management     |
                                   transactions   |
                                                  v
                                              +------+
                                              |  CA  |
                                              +------+
        

The components in this model are:

このモデルのコンポーネントは次のとおりです。

End Entity: user of PKI certificates and/or end user system that is the subject of a certificate;

End Entity:PKI証明書および/または証明書の主題であるエンドユーザーシステムのユーザー。

CA: certification authority;

CA:認定機関。

RA: registration authority, i.e., an optional system to which a CA delegates certain management functions;

RA:登録機関、つまり、CAが特定の管理機能を委任するオプションのシステム。

Repository: a system or collection of distributed systems that store certificates and CRLs and serves as a means of distributing these certificates and CRLs to end entities.

リポジトリ:証明書とCRLSを保存し、これらの証明書とCRLをエンティティを終了するために配布する手段として機能する分散システムのシステムまたはコレクション。

1.2. Certificate and CRL Repository
1.2. 証明書とCRLリポジトリ

Some CAs mandate the use of on-line validation services, while others distribute CRLs to allow certificate users to perform certificate validation themselves. In general, CAs make CRLs available to certificate users by publishing them in the Directory. The Directory is also the normal distribution mechanism for certificates. However, Directory Services are not available in many parts of the Internet today. The File Transfer Protocol (FTP) defined in RFC 959 and the Hypertext Transfer Protocol (HTTP) defined in RFC 2068 offer alternate methods for certificate and CRL distribution.

一部のCASはオンライン検証サービスの使用を義務付けていますが、他のCAはCRLを配布して証明書ユーザーが証明書検証を自分で実行できるようにします。一般に、CASは、ユーザーをディレクトリに公開することにより、ユーザーを証明するCRLを利用できるようにします。ディレクトリは、証明書の正規分布メカニズムでもあります。ただし、今日のインターネットの多くの部分ではディレクトリサービスは利用できません。RFC 959で定義されたファイル転送プロトコル(FTP)とRFC 2068で定義されたハイパーテキスト転送プロトコル(HTTP)は、証明書とCRL分布の代替方法を提供します。

End entities and CAs may retrieve certificates and CRLs from the repository using FTP or HTTP. End entities may publish their own certificate in the repository using FTP or HTTP, and RAs and CAs may publish certificates and CRLs in the repository using FTP or HTTP.

END ENTITIESおよびCASは、FTPまたはHTTPを使用してリポジトリから証明書とCRLを取得できます。ENDエンティティは、FTPまたはHTTPを使用してリポジトリに独自の証明書を公開し、RASとCASはFTPまたはHTTPを使用してリポジトリに証明書とCRLを公開できます。

2 FTP Conventions

2 FTP規則

Within certificate extensions and CRL extensions, the URI form of GeneralName is used to specify the location where issuer certificates and CRLs may be obtained. For instance, a URI identifying the subject of a certificate may be carried in subjectAltName certificate extension. An IA5String describes the use of anonymous FTP to fetch certificate or CRL information. For example:

証明書拡張およびCRL拡張機能内で、generalNameのURI形式を使用して、発行者証明書とCRLが取得できる場所を指定します。たとえば、証明書の主題を識別するURIは、subjectaltname証明書延長で携帯される場合があります。IA5STRINGは、証明書またはCRL情報を取得するために匿名FTPの使用について説明しています。例えば:

ftp://ftp.netcom.com/sp/spyrus/housley.cer ftp://ftp.your.org/pki/id48.cer ftp://ftp.your.org/pki/id48.no42.crl

ftp://ftp.netcom.com/sp/spyrus/housley.cer ftp://ftp.your.org/pki/id48.cer ftp://ftp.your.org/pki/id48.no42.crl

Internet users may publish the URI reference to a file that contains their certificate on their business card. This practice is useful when there is no Directory entry for that user. FTP is widely deployed, and anonymous FTP are accommodated by many firewalls. Thus, FTP is an attractive alternative to Directory access protocols for certificate and CRL distribution. While this service satisfies the requirement to retrieve information related to a certificate which is already identified by a URI, it is not intended to satisfy the more general problem of finding a certificate for a user about whom some other information, such as their electronic mail address or corporate affiliation, is known.

インターネットユーザーは、名刺に証明書を含むファイルへのURI参照を公開する場合があります。このプラクティスは、そのユーザーにディレクトリエントリがない場合に役立ちます。FTPは広く展開されており、匿名のFTPは多くのファイアウォールに対応しています。したがって、FTPは、証明書とCRLディストリビューションのディレクトリアクセスプロトコルの魅力的な代替品です。このサービスは、URIによって既に特定されている証明書に関連する情報を取得するための要件を満たしていますが、電子メールアドレスなどの他の情報についてユーザーの証明書を見つけるというより一般的な問題を満たすことを意図したものではありませんまたは企業所属が知られています。

For convenience, the names of files that contain certificates should have a suffix of ".cer". Each ".cer" file contains exactly one certificate, encoded in DER format. Likewise, the names of files that contain CRLs should have a suffix of ".crl". Each ".crl" file contains exactly one CRL, encoded in DER format.

便宜上、証明書を含むファイルの名前には「.cer」の接尾辞が必要です。各「.cer」ファイルには、der形式でエンコードされた正確な1つの証明書が含まれています。同様に、CRLを含むファイルの名前には、「.crl」の接尾辞が必要です。各 ".crl"ファイルには、der形式でエンコードされた1つのCRLが含まれています。

3 HTTP Conventions

3 HTTP規則

Within certificate extensions and CRL extensions, the URI form of GeneralName is used to specify the location where issuer certificates and CRLs may be obtained. For instance, a URI identifying the subject of a certificate may be carried in subjectAltName certificate extension. An IA5String describes the use of HTTP to fetch certificate or CRL information. For example:

証明書拡張およびCRL拡張機能内で、generalNameのURI形式を使用して、発行者証明書とCRLが取得できる場所を指定します。たとえば、証明書の主題を識別するURIは、subjectaltname証明書延長で携帯される場合があります。IA5Stringは、証明書またはCRL情報を取得するためにHTTPの使用について説明しています。例えば:

http://www.netcom.com/sp/spyrus/housley.cer http://www.your.org/pki/id48.cer http://www.your.org/pki/id48.no42.crl

http://www.netcom.com/sp/spyrus/housley.cer http://www.your.org/pki/id48.cer http://www.your.org/pki/id48.no42.crl

Internet users may publish the URI reference to a file that contains their certificate on their business card. This practice is useful when there is no Directory entry for that user. HTTP is widely deployed, and HTTP is accommodated by many firewalls. Thus, HTTP is an attractive alternative to Directory access protocols for certificate and CRL distribution. While this service satisfies the requirement to retrieve information related to a certificate which is already identified by a URI, it is not intended to satisfy the more general problem of finding a certificate for a user about whom some other information, such as their electronic mail address or corporate affiliation, is known.

インターネットユーザーは、名刺に証明書を含むファイルへのURI参照を公開する場合があります。このプラクティスは、そのユーザーにディレクトリエントリがない場合に役立ちます。HTTPは広く展開されており、HTTPは多くのファイアウォールに対応しています。したがって、HTTPは、証明書とCRL分布のディレクトリアクセスプロトコルの魅力的な代替品です。このサービスは、URIによって既に特定されている証明書に関連する情報を取得するための要件を満たしていますが、電子メールアドレスなどの他の情報についてユーザーの証明書を見つけるというより一般的な問題を満たすことを意図したものではありませんまたは企業所属が知られています。

For convenience, the names of files that contain certificates should have a suffix of ".cer". Each ".cer" file contains exactly one certificate, encoded in DER format. Likewise, the names of files that contain CRLs should have a suffix of ".crl". Each ".crl" file contains exactly one CRL, encoded in DER format.

便宜上、証明書を含むファイルの名前には「.cer」の接尾辞が必要です。各「.cer」ファイルには、der形式でエンコードされた正確な1つの証明書が含まれています。同様に、CRLを含むファイルの名前には、「.crl」の接尾辞が必要です。各 ".crl"ファイルには、der形式でエンコードされた1つのCRLが含まれています。

4 MIME registrations

4つのMIME登録

Two MIME types are defined to support the transfer of certificates and CRLs. They are:

証明書とCRLの転送をサポートするために、2つのMIMEタイプが定義されています。彼らです:

application/pkix-cert application/pkix-crl

アプリケーション/PKIX-CERTアプリケーション/PKIX-CRL

4.1. application/pkix-cert
4.1. アプリケーション/PKIX-CERT
   To: ietf-types@iana.org
   Subject: Registration of MIME media type application/pkix-cert
        

MIME media type name: application

MIMEメディアタイプ名:アプリケーション

MIME subtype name: pkix-cert

MIMEサブタイプ名:pkix-cert

Required parameters: None

必要なパラメーター:なし

Optional parameters: version (default value is "1")

オプションのパラメーター:バージョン(デフォルト値は「1」です)

Encoding considerations: will be none for 8-bit transports and most likely Base64 for SMTP or other 7-bit transports

考慮事項のエンコーディング:8ビット輸送ではありません。SMTPまたはその他の7ビットトランスポートの場合、おそらくBase64

Security considerations: Carries a cryptographic certificate

セキュリティ上の考慮事項:暗号化証明書を搭載しています

Interoperability considerations: None

相互運用性の考慮事項:なし

Published specification: draft-ietf-pkix-ipki-part1

公開された仕様:draft-yietf-pkix-ipki-part1

Applications which use this media type: Any MIME-complaint transport

このメディアタイプを使用するアプリケーション:MIME-Comprant Transport

   Additional information:
     Magic number(s): None
     File extension(s): .CER
     Macintosh File Type Code(s): none
        
   Person & email address to contact for further information:
   Russ Housley <housley@spyrus.com>
        

Intended usage: COMMON

意図された使用法:共通

   Author/Change controller:
   Russ Housley <housley@spyrus.com>
        
4.2. application/pkix-crl
4.2. アプリケーション/PKIX-CRL
   To: ietf-types@iana.org
   Subject: Registration of MIME media type application/pkix-crl
        

MIME media type name: application

MIMEメディアタイプ名:アプリケーション

MIME subtype name: pkix-crl

mimeサブタイプ名:pkix-crl

Required parameters: None Optional parameters: version (default value is "1")

必要なパラメーター:なしオプションのパラメーター:バージョン(デフォルト値は「1」です)

Encoding considerations: will be none for 8-bit transports and most likely Base64 for SMTP or other 7-bit transports

考慮事項のエンコーディング:8ビット輸送ではありません。SMTPまたはその他の7ビットトランスポートの場合、おそらくBase64

Security considerations: Carries a cryptographic certificate revocation list

セキュリティ上の考慮事項:暗号化された証明書の取り消しリストを搭載しています

Interoperability considerations: None

相互運用性の考慮事項:なし

Published specification: draft-ietf-pkix-ipki-part1

公開された仕様:draft-yietf-pkix-ipki-part1

Applications which use this media type: Any MIME-complaint transport

このメディアタイプを使用するアプリケーション:MIME-Comprant Transport

   Additional information:
     Magic number(s): None
     File extension(s): .CRL
     Macintosh File Type Code(s): none
        
   Person & email address to contact for further information:
   Russ Housley <housley@spyrus.com>
        

Intended usage: COMMON

意図された使用法:共通

   Author/Change controller:
   Russ Housley <housley@spyrus.com>
        

References

参考文献

[RFC 959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 5, RFC 959, October 1985.

[RFC 959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル(FTP)」、STD 5、RFC 959、1985年10月。

[RFC 1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.

[RFC 1738] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators(URL)」、RFC 1738、1994年12月。

[RFC 2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee; "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.

[RFC 2068] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。、およびT. Berners-Lee;「ハイパーテキスト転送プロトコル-HTTP/1.1」、RFC 2068、1997年1月。

Security Considerations

セキュリティに関する考慮事項

Since certificates and CRLs are digitally signed, no additional integrity service is necessary. Neither certificates nor CRLs need be kept secret, and anonymous access to certificates and CRLs is generally acceptable. Thus, no privacy service is necessary.

証明書とCRLがデジタル署名されているため、追加の整合性サービスは必要ありません。証明書もCRLも秘密にする必要はなく、証明書とCRLSへの匿名のアクセスは一般的に受け入れられます。したがって、プライバシーサービスは必要ありません。

HTTP caching proxies are common on the Internet, and some proxies do not check for the latest version of an object correctly. If an HTTP request for a certificate or CRL goes through a misconfigured or otherwise broken proxy, the proxy may return an out-of-date response.

HTTPキャッシングプロキシはインターネット上で一般的であり、一部のプロキシはオブジェクトの最新バージョンを正しくチェックしません。証明書またはCRLのHTTP要求が誤って構成されている、または壊れたプロキシを通過する場合、プロキシは時代遅れの応答を返す場合があります。

Operators of FTP sites and World Wide Web servers should authenticate end entities who publish certificates as well as CAs and RAs who publish certificates and CRLs. However, authentication is not necessary to retrieve certificates and CRLs.

FTPサイトおよびWorld Wide Webサーバーのオペレーターは、証明書を公開するエンティティと、証明書とCRLSを公開するCAとRAを認証する必要があります。ただし、証明書とCRLを取得するために認証は必要ありません。

Authors' Addresses

著者のアドレス

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
        

Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA

ポールホフマンインターネットメールコンソーシアム127セグレプレイスサンタクルス、カリフォルニア州95060 USA

   EMail: phoffman@imc.org
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (1999). All Rights Reserved.

Copyright(c)The Internet Society(1999)。無断転載を禁じます。

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エディター機能の資金は現在、インターネット協会によって提供されています。