RFC2585 日本語訳
2585 Internet X.509 Public Key Infrastructure Operational Protocols:FTP and HTTP. R. Housley, P. Hoffman. May 1999. (Format: TXT=14813 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley
Request for Comments: 2585 SPYRUS
Category: Standards Track P. Hoffman
IMC
May 1999
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2585年のSPYRUSカテゴリ: 標準化過程P.ホフマンIMC1999年5月
Internet X.509 Public Key Infrastructure
Operational Protocols: FTP and HTTP
インターネットのX.509の公開鍵暗号基盤の操作上のプロトコル: FTPとHTTP
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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)の操作上の要件のいくつかを満たします。 File Transferプロトコル(FTP)を使用して、ハイパーテキストTransferプロトコル(HTTP)がPKI倉庫から証明書と証明書失効リスト(CRLs)を入手するように、このドキュメントはコンベンションを指定します。 操作上の要件を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証明書と証明書失効リスト(CRLs)を使用するインターネット公開鍵暗号基盤(PKI)の複合規格の一部です。 File Transferプロトコル(FTP)を使用して、ハイパーテキストTransferプロトコル(HTTP)がPKI倉庫から証明書とCRLsを入手するように、このドキュメントはコンベンションを指定します。 PKIが倉庫アクセスであると扱う追加メカニズムが別々のドキュメントで指定されます。
Housley & Hoffman Standards Track [Page 1] RFC 2585 PKIX Operational Protocols: FTP and HTTP May 1999
HousleyとホフマンStandardsはRFC2585のPKIXの操作上のプロトコルを追跡します[1ページ]: FTPとHTTP1999年5月
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 |
+------+
+---+ | C| +------------+ | e| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 終わりの実体| | r| 操作上の+------------+ | t| トランザクション^| | そして、管理| 管理| / | トランザクション| トランザクション| | | PKIユーザ| C| v| R| -------------------+--+-----------+----------------- | L| ^ ^ | | | | PKI管理| | v| 実体| R| +------+ | | e| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| RA| <--+ | | p| 証明書+を発表してください。------+ | | | o | | | | s| | | | I| vに対して| t| +------------+ | o | <------------------------------| カリフォルニア| | r| 証明書+を発表してください。------------+ | y| CRL^を発行してください。| | | +---+ 管理| トランザクション| +に対して------+ | カリフォルニア| +------+
The components in this model are:
このモデルのコンポーネントは以下の通りです。
End Entity: user of PKI certificates and/or end user system that is
the subject of a certificate;
実体を終わらせてください: 証明書の対象であるPKI証明書、そして/または、エンドユーザシステムのユーザ。
CA: certification authority;
カリフォルニア: 証明権威。
RA: registration authority, i.e., an optional system to
which a CA delegates certain management functions;
RA: すなわち、登録局、カリフォルニアが、ある管理機能を代表として派遣する任意のシステム。
Housley & Hoffman Standards Track [Page 2] RFC 2585 PKIX Operational Protocols: FTP and HTTP May 1999
HousleyとホフマンStandardsはRFC2585のPKIXの操作上のプロトコルを追跡します[2ページ]: FTPとHTTP1999年5月
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を配布する手段として証明書、CRLs、およびサーブを保存する分散システムのシステムか収集。
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がオンライン合法化サービスの使用を強制します、他のものは証明書ユーザが自分たちで証明書合法化を実行するのを許容するためにCRLsを分配しますが。 一般に、CAsで、CRLsはディレクトリで彼らを発行することによってユーザを証明するために利用可能になります。 また、ディレクトリは証明書のための正規分布メカニズムです。 しかしながら、ディレクトリサービスは今日、インターネットの多くの地域で利用可能ではありません。 プロトコル(FTP)がRFC959で定義したFile Transferとプロトコル(HTTP)がRFC2068で定義したハイパーテキストTransferは証明書と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.
終わりの実体とCAsは、倉庫からFTPかHTTPを使用することで証明書とCRLsを検索するかもしれません。 終わりの実体は倉庫でFTPかHTTPを使用することでそれら自身の証明書を発表するかもしれません、そして、RAsとCAsは倉庫でFTPかHTTPを使用することで証明書とCRLsを発表するかもしれません。
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フォームは、発行人証明書とCRLsが入手されるかもしれない位置を指定するのに使用されます。 例えば、証明書の対象を特定する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によって既に特定される証明書に関連する情報を検索するという要件を満たしている間、彼らの電子メールアドレスか法人の提携のある他の情報が知られているユーザのために証明書を見つけるというより一般的な問題を満たすことを意図しません。
Housley & Hoffman Standards Track [Page 3] RFC 2585 PKIX Operational Protocols: FTP and HTTP May 1999
HousleyとホフマンStandardsはRFC2585のPKIXの操作上のプロトコルを追跡します[3ページ]: FTPとHTTP1999年5月
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通の証明書を入れてあます。 同様に、CRLsを入れてあるファイルの名前には、".crl"の接尾語があるべきです。 それぞれの".crl"ファイルはちょうどDER形式でコード化された1CRLを入れてあます。
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フォームは、発行人証明書とCRLsが入手されるかもしれない位置を指定するのに使用されます。 例えば、証明書の対象を特定する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通の証明書を入れてあます。 同様に、CRLsを入れてあるファイルの名前には、".crl"の接尾語があるべきです。 それぞれの".crl"ファイルはちょうどDER形式でコード化された1CRLを入れてあます。
4 MIME registrations
4 MIME登録証明書
Two MIME types are defined to support the transfer of certificates and CRLs. They are:
2つのMIMEの種類が、証明書とCRLsの転送をサポートするために定義されます。 それらは以下の通りです。
application/pkix-cert
application/pkix-crl
pkixアプリケーション/本命アプリケーション/pkix-crl
Housley & Hoffman Standards Track [Page 4] RFC 2585 PKIX Operational Protocols: FTP and HTTP May 1999
HousleyとホフマンStandardsはRFC2585のPKIXの操作上のプロトコルを追跡します[4ページ]: FTPとHTTP1999年5月
4.1. application/pkix-cert
4.1. pkixアプリケーション/本命
To: ietf-types@iana.org Subject: Registration of MIME media type application/pkix-cert
To: ietf-types@iana.org Subject: MIMEメディアの登録はpkixアプリケーション/本命をタイプします。
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: pkix-cert
MIME「副-タイプ」は以下を命名します。 pkix-本命
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
問題をコード化します: SMTPか他の7ビットの輸送のための8ビットの輸送とたぶんBase64のためのなしでしょう。
Security considerations: Carries a cryptographic certificate
セキュリティ問題: 暗号の証明書を運びます。
Interoperability considerations: None
相互運用性問題: なし
Published specification: draft-ietf-pkix-ipki-part1
広められた仕様: 草稿-ietf-pkix-ipki-part1
Applications which use this media type: Any MIME-complaint transport
このメディアタイプを使用するアプリケーション: どんなMIME苦情輸送
Additional information:
Magic number(s): None
File extension(s): .CER
Macintosh File Type Code(s): none
追加情報: マジックナンバー(s): なにも、File拡張子: .CERマッキントッシュファイルタイプは(s)をコード化します: なし
Person & email address to contact for further information: Russ Housley <housley@spyrus.com>
詳細のために連絡する人とEメールアドレス: ラス Housley <housley@spyrus.com 、gt。
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller: Russ Housley <housley@spyrus.com>
コントローラを書くか、または変えてください: ラス Housley <housley@spyrus.com 、gt。
4.2. application/pkix-crl
4.2. アプリケーション/pkix-crl
To: ietf-types@iana.org Subject: Registration of MIME media type application/pkix-crl
To: ietf-types@iana.org Subject: MIMEメディアタイプアプリケーション/pkix-crlの登録
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: pkix-crl
MIME「副-タイプ」は以下を命名します。 pkix-crl
Required parameters: None
必要なパラメタ: なし
Housley & Hoffman Standards Track [Page 5] RFC 2585 PKIX Operational Protocols: FTP and HTTP May 1999
HousleyとホフマンStandardsはRFC2585のPKIXの操作上のプロトコルを追跡します[5ページ]: FTPとHTTP1999年5月
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
問題をコード化します: SMTPか他の7ビットの輸送のための8ビットの輸送とたぶんBase64のためのなしでしょう。
Security considerations: Carries a cryptographic certificate revocation list
セキュリティ問題: 暗号の証明書失効リストを運びます。
Interoperability considerations: None
相互運用性問題: なし
Published specification: draft-ietf-pkix-ipki-part1
広められた仕様: 草稿-ietf-pkix-ipki-part1
Applications which use this media type: Any MIME-complaint transport
このメディアタイプを使用するアプリケーション: どんなMIME苦情輸送
Additional information:
Magic number(s): None
File extension(s): .CRL
Macintosh File Type Code(s): none
追加情報: マジックナンバー(s): なにも、File拡張子: .CRLマッキントッシュファイルタイプは(s)をコード化します: なし
Person & email address to contact for further information: Russ Housley <housley@spyrus.com>
詳細のために連絡する人とEメールアドレス: ラス Housley <housley@spyrus.com 、gt。
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller: Russ Housley <housley@spyrus.com>
コントローラを書くか、または変えてください: ラス Housley <housley@spyrus.com 、gt。
References
参照
[RFC 959] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
STD 5, RFC 959, October 1985.
[RFC959] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD5、RFC959、1985年10月。
[RFC 1738] 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月。
[RFC 2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and
T. Berners-Lee; "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997.
[RFC2068] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、およびT.バーナーズ・リー。 「HTTP/1.1インチ、RFC2068、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.
証明書とCRLsがデジタルに署名されるので、どんな追加保全サービスも必要ではありません。 証明書もCRLsも秘密にされる必要はありません、そして、一般に、証明書とCRLsへの匿名のアクセスは許容できます。 したがって、どんなプライバシーサービスも必要ではありません。
Housley & Hoffman Standards Track [Page 6] RFC 2585 PKIX Operational Protocols: FTP and HTTP May 1999
HousleyとホフマンStandardsはRFC2585のPKIXの操作上のプロトコルを追跡します[6ページ]: FTPとHTTP1999年5月
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要求がmisconfiguredされたかそうでなければ、失意のプロキシを通るなら、プロキシは時代遅れな応答を返すかもしれません。
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サイトとWWWサーバのオペレータは終わりの実体のだれが証明書を発表するCAsとRAsと同様に証明書を発表するか、そして、CRLsを認証するべきです。 しかしながら、認証は、証明書とCRLsを検索するのに必要ではありません。
Authors' Addresses
作者のアドレス
Russell Housley SPYRUS 381 Elden Street, Suite 1120 Herndon, VA 20170 USA
ラッセルHousley SPYRUS381エルデンスイート1120ハーンドン、ヴァージニア20170通り(米国)
EMail: housley@spyrus.com
メール: housley@spyrus.com
Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA
ポールホフマンインターネットメール共同体127セグレ・Placeカリフォルニア95060サンタクルス(米国)
EMail: phoffman@imc.org
メール: phoffman@imc.org
Housley & Hoffman Standards Track [Page 7] RFC 2585 PKIX Operational Protocols: FTP and HTTP May 1999
HousleyとホフマンStandardsはRFC2585のPKIXの操作上のプロトコルを追跡します[7ページ]: FTPとHTTP1999年5月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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機能のための基金は現在、インターネット協会によって提供されます。
Housley & Hoffman Standards Track [Page 8]
Housleyとホフマン標準化過程[8ページ]
一覧
スポンサーリンク
