Network Working Group P. Gutmann, Ed.
Request for Comments: 4387 University of Auckland
Category: Standards Track February 2006
Internet X.509 Public Key Infrastructure
Operational Protocols: Certificate Store Access via 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 (2006).
著作権（C）インターネット協会（2006）。
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 Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism 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）を得るためにインターフェース機構として、ハイパーテキスト転送プロトコル（HTTP / HTTPS）を使用するための規則を指定します。 PKIX運用要件に対処追加のメカニズムは別の文書で指定されています。
Table of Contents
目次
1. Introduction ....................................................2
2. HTTP Certificate Store Interface ................................3
2.1. Converting Binary Blobs into Search Keys ...................4
2.2. Attribute Types: X.509 .....................................5
2.3. Attribute Types: PGP .......................................6
2.4. Attribute Types: XML .......................................6
2.5. Implementation Notes and Rationale .........................6
2.5.1. Identification ......................................7
2.5.2. Checking of Input Values ............................9
2.5.3. URI Notes ..........................................10
2.5.4. Responses ..........................................11
2.5.5. Performance Issues .................................12
2.5.6. Miscellaneous ......................................13
2.6. Examples ..................................................14
3. Locating HTTP Certificate Stores ...............................15
3.1. Information in the Certificate ............................15
3.2. Use of DNS SRV ............................................16
3.2.1. Example ............................................16
3.3. Use of a "well-known" Location ............................16
3.3.1. Examples ...........................................17
3.4. Manual Configuration of the Client Software ...............18
3.5. Implementation Notes and Rationale ........................18
3.5.1. DNS SRV ............................................18
3.5.2. "well-known" Locations .............................19
3.5.3. Information in the Certificate .....................19
3.5.4. Miscellaneous ......................................20
4. Security Considerations ........................................20
5. IANA Considerations ............................................22
6. Acknowledgements ...............................................22
7. References .....................................................22
7.1. Normative References ......................................22
7.2. Informative References ....................................23
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 Hypertext Transfer Protocol (HTTP), or optionally, HTTPS as an interface mechanism to obtain certificates or public keys, and certificate revocation lists (CRLs), from PKI repositories. Throughout the remainder of this document the generic term HTTP will be used to cover either option.
この仕様はX.509証明書と証明書失効リスト（CRL）を使用して、インターネット公開鍵インフラストラクチャ（PKI）のためのマルチパート規格の一部です。この文書では、PKIリポジトリから証明書または公開鍵、及び証明書失効リスト（CRL）を取得するためのインターフェース機構としてハイパーテキスト転送プロトコル（HTTP）を使用するための規則を指定し、または必要に応じて、HTTPS。このマニュアルでは一般的な用語のHTTPのいずれかのオプションをカバーするために使用されます。
Although RFC 2585 [RFC2585] covers fetching certificates via HTTP, this merely mentions that certificates may be fetched from a static URL, which doesn't provide any general-purpose interface capabilities to a certificate store. The conventions described in this document allow HTTP to be used as a general-purpose, transparent interface to any type of certificate or key store including flat files, standard databases such as Berkeley DB and relational databases, and traditional X.500/LDAP directories. Typical applications would include use with web-enabled relational databases (which most databases are) or simple {key,value} lookup mechanisms such as Berkeley DB and its various descendants.
RFC 2585 [RFC2585]はHTTPを介してフェッチ証明書をカバーするが、これは単に証明書が証明書ストアに任意の汎用のインタフェース機能を提供しない静的なURLからフェッチすることができることを言及しています。この文書で説明する規則は、HTTPは、フラットファイル、などのBerkeley DBやリレーショナルデータベースなどの標準的なデータベース、および伝統的なX.500 / LDAPディレクトリを含む証明書またはキーストアのいずれかのタイプに汎用、透明インタフェースとして使用することができます。典型的な用途は、（ほとんどのデータベースである）は、ウェブ対応のリレーショナルデータベースまたはそのようなバークレイDB及びその種々の子孫のような単純な{キー、値}のルックアップメカニズムと使用が含まれます。
Additional mechanisms addressing PKIX operational requirements are specified in separate documents.
PKIX運用要件に対処追加のメカニズムは別の文書で指定されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード "MUST"、 "NOT MUST"、 "必須"、 "SHOULD"、この文書では、 "推奨"、 "べきでない" "MAY"、及び "OPTIONAL" は[RFC2119]に記載されているように解釈されるべきです。
The GET method is used in combination with an HTTP query URI [RFC2616] to retrieve certificates from the underlying certificate store:
GETメソッドは、基礎となる証明書ストアから証明書を取得するためのHTTPクエリURI [RFC2616]と組み合わせて使用されます。
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
HTTP_URL = "HTTP：" "//" ホスト[ "：" ポート] [腹筋_経路の[ ""？クエリ]]
The parameters for the query portion of the URI are a certificate or key identifier consisting of an attribute type and a value that specifies one or more certificates or public keys to be returned from the query:
URIのクエリ部分のパラメータは、証明書または属性タイプとクエリから返される1つ以上の証明書または公開鍵を指定する値からなるキー識別子です。
query = attribute '=' value
クエリ=属性「=」値
Certificates and public keys are retrieved from one URI (the certificate URI) and CRLs from another URI (the revocation URI). These may or may not correspond to the same certificate store and/or server (the exact interpretation is a local configuration issue). The query value MUST be encoded using the form-urlencoded media type [RFC2854]. Further details of URI construction, size limits, and other factors are given in [RFC2616].
証明書と公開鍵は1つのURI別のURIから（証明書URI）およびCRL（失効URI）から取り出されます。これらは、または（正確な解釈はローカル設定の問題である）同じ証明書ストアおよび/またはサーバに対応してもしなくてもよいです。クエリ値はform-urlencodedでメディアタイプ[RFC2854]を使用して符号化されなければなりません。 URI構造、サイズ制限、およびその他の要因のさらなる詳細は、[RFC2616]に記載されています。
Responses to unsuccessful queries (for example, to indicate a non-match or an error condition) are handled in the standard manner as per [RFC2616]. Clients should in particular be aware that in some instances servers may return HTTP type 3xx redirection requests to explicitly redirect queries to another server. Obviously, implicit DNS-based redirection is also possible.
（例えば、不一致またはエラー状態を示すために）失敗したクエリに対する応答は、[RFC2616]に従って標準的な方法で処理されます。クライアントは、特に、いくつかの例では、サーバは、明示的に別のサーバにクエリをリダイレクトするHTTPタイプの3xxリダイレクト要求を返す可能性があることに注意する必要があります。明らかに、暗黙のDNSベースのリダイレクションも可能です。
If more than one certificate matches a query, it MUST be returned as a multipart/mixed response. The returned data MUST be returned verbatim; it MUST NOT use any additional content- or transfer-encoding at the HTTP level (for example, it can't be compressed or encoded as base64 or quoted-printable text). Implementations SHOULD NOT use chunked encoding in responses.
複数の証明書がクエリに一致した場合、それはマルチパート/混合応答として返されなければなりません。返されたデータは、そのまま返さなければなりません。それは（例えば、それがBASE64または引用された、印刷可能なテキストとして圧縮又は符号化することができない）HTTPレベルで任意の追加のContentまたは転送符号化を使用してはいけません。実装は応答でチャンクエンコーディングを使用しないでください。
The query component of the URI MAY optionally contain additional attribute/value pairs separated by the standard ampersand delimiter '&' that specify further actions to be taken by the certificate store. Certificate stores SHOULD ignore any additional unrecognised attribute/value pairs present in the URI.
URIのクエリコンポーネントは、必要に応じて証明書ストアによって取られるべき更なるアクションを指定する標準のアンパサンド区切り文字「＆」で区切られた追加属性/値のペアを含むかもしれません。証明書ストアは、URI中に存在する任意の追加の認識できない属性/値のペアを無視する必要があります。
Other information, such as naming conventions and MIME types, is specified in [RFC2585] (with additional MIME types for non-X.509 content in [RFC3156] and [RFC3275]).
そのような命名規則とMIMEタイプ、のような他の情報は、[RFC2585]で指定されている（[RFC3156]及び[RFC3275]における非X.509コンテンツの追加のMIMEタイプを持ちます）。
Some fields (indicated by the "Process" column in the tables below) are of arbitrary length and/or contain non-textual data. Both of these properties make them unsuited for direct use in HTTP queries. In order to make them usable, fields for which the processing option is "Hash" are first hashed down to a fixed-length 160-bit value. Fields for which the processing option is "Hash" or "Base64" are base64-encoded to transform the binary data into textual forms:
（以下の表中の「プロセス」欄で示される）いくつかのフィールドは、任意の長さのものであり、および/または非テキストデータを含みます。これらのプロパティの両方がHTTPクエリで直接使用するのに不向きにします。それらを使用可能にするために、処理オプションは「ハッシュ」されているフィールドは、第1の固定長160ビットの値までハッシュされます。処理オプションは、「ハッシュ」または「Base64で」されたフィールドは、テキスト形式にバイナリデータを変換するbase64でエンコードされます。
Processing Processing step option
処理処理ステップオプション
"Hash" Hash the key value using SHA-1 [FIPS180] to produce a 160-bit value, then continue with the base64 encoding step that follows.
以下BASE64符号化ステップに進み、その後、160ビット値を生成するSHA-1 [FIPS180]を使用してキー値をハッシュ「ハッシュ」。
"Hash" Encode the binary value using base64 encoding to produce "Base64" a 27-byte text-only value. Base64 encoding of the 20 byte value will produce 28 bytes, and the last byte will always be a '=' padding character. The 27-byte value is created by dropping the trailing '=' character.
「ハッシュ」は、「Base64で」27バイトのテキストのみの値を生成するためにbase64エンコーディングを使用してバイナリ値をエンコード。 20バイト値をBase64エンコードは28のバイトが生成されます、そして最後のバイトは常に「=」パディング文字になります。 27バイトの値は、末尾の「=」文字をドロップすることによって作成されます。
For cases where the binary value is smaller or larger than the 20- byte SHA-1 output (for example, with 64-bit/8 byte PGP key IDs), the final value is created by removing any trailing '=' padding from the encoding of the binary value (this is a generalisation of the above case).
バイナリ値（64ビット/ 8バイトPGP鍵IDを持つ例えば、）20-バイトのSHA-1の出力よりも小さいまたは大きい場合のために、最終的な値は、以下から任意の末尾「=」パディングを除去することによって作成されますバイナリ値の符号化（これは、上記の場合の一般化です）。
Implementations MUST verify that the base64-encoded values submitted in requests contain only characters in the ranges 'a'-'z', 'A'-'Z', '0'-'9', '+', and '/'. Queries containing any other character MUST be rejected. (See the implementation notes in Section 2.5 and the security considerations in Section 4 for more details on this requirement.)
実装は、リクエストで送信base64エンコード値が範囲「A」にのみ文字が含まれていることを確かめなければなりません - 「Z」、「A」 - 「Z」、「0」 - 「9」、「+」および「/」 。他の文字を含むクエリは拒絶しなければなりません。 （この要件の詳細については、第4節では2.5節での実装ノートとセキュリティの考慮事項を参照してください。）
Permitted attribute types and associated values for use with X.509 certificates and CRLs are described below. Arbitrary-length binary values (as indicated in the table below) are converted into a search key by the process described in Section 2.1. Note that the values are checked for an exact match (after decoding of any form-urlencoded [RFC2854] portions if this is necessary) and are therefore case sensitive.
X.509証明書とCRLで使用するために許可された属性タイプと関連する値を以下に記載されています。任意の長さのバイナリ値は、（以下の表に示されるように）セクション2.1に記載の方法で検索キーに変換されます。値は（これは必要であれば任意form-urlencodedで[RFC2854]の部分の復号後）完全一致がチェックされ、したがって、大文字と小文字が区別されることに留意されたいです。
Attribute Process Value
--------- ------- -----
certHash Hash Search key derived from the SHA-1 hash of the
certificate (sometimes called the certificate
fingerprint or thumbprint).
uri None Subject URI associated with the certificate, without the (optional) scheme specifier. The URI type depends on the certificate. For S/MIME certificates, it would be an email address; for SSL/TLS certificates, it would be the server's DNS name (this is usually also specified as the CommonName); for IPsec certificates, it would be the DNS name/IP address; and so on.
URIなしサブジェクトURI（オプション）方式指定せずに、証明書に関連付けられています。 URIタイプは、証明書によって異なります。 S / MIME証明書の場合は、電子メールアドレスになります。 SSL / TLS証明書のために、それはサーバのDNS名を（これは通常ものCommonNameとして指定されている）になります。 IPsecの証明書のために、それはDNS名/ IPアドレスになります。等々。
iHash Hash Search key derived from the DER-encoded issuer DN as it appears in the certificate, CRL, or other object.
それは、証明書、CRL、またはその他のオブジェクトに表示されるDERでエンコードされた発行者DN由来iHashハッシュ検索キー。
iAndSHash Hash Search key derived from the certificate's DER-encoded issuerAndSerialNumber [RFC3852].
証明書のDERでエンコードされたissuerAndSerialNumber [RFC3852]由来iAndSHashハッシュ検索キー。
name None Subject CommonName contained in the certificate.
証明書に含まれているなし件名のCommonNameに名前を付けます。
sHash Hash Search key derived from the DER-encoded subject DN as it appears in the certificate or other object.
それは、証明書またはその他のオブジェクトに表示されるDER符号化された被験者に由来するDN sHashハッシュ検索キー。
sKIDHash Hash Search key derived from the certificate's subjectKeyIdentifier (specifically the contents octets of the KeyIdentifier OCTET STRING).
証明書のsubjectKeyIdentifier由来sKIDHashハッシュ検索キー（KeyIdentifierオクテット文字列の、具体的内容オクテット）。
Certificate URIs MUST support retrieval by all the above attribute types.
証明書のURIは、上記のすべての属性タイプで検索をサポートしなければなりません。
CRL URIs MUST support retrieval by the iHash and sKIDHash attribute types, which identify the issuer of the CRL. In addition, CRL URIs MAY support retrieval by certHash and iAndSHash attribute types, for cases where this is required by the use of the issuingDistributionPoint extension. A CRL query MUST return the matching CRL with the greatest thisUpdate value (in other words, the most recent CRL).
CRL URIはCRLの発行者を識別するタイプ、属性iHashとsKIDHashによる検索をサポートしなければなりません。また、CRLのURIは、これはissuingDistributionPoint拡張子を使用して必要な場合のために、属性タイプCERTHASHとiAndSHashにより取得をサポートするかもしれません。 CRLのクエリは（つまり、最新のCRL）最大thisUpdateの値と一致するCRLを返さなければなりません。
Permitted attribute types and associated values for use with PGP public keys and key revocation information are described below. Binary values (as indicated in the table below) are converted into a search key by the process described in Section 2.1.
PGP公開鍵および鍵失効情報で使用するために許可された属性タイプと関連する値を以下に記載されています。バイナリ値は、（以下の表に示されるように）セクション2.1に記載の方法で検索キーに変換されます。
Attribute Process Value
--------- ------- -----
email None email address associated with the key.
fingerprint Base64 160-bit PGP key fingerprint [RFC2440].
指紋Base64で160ビットのPGP鍵の指紋[RFC2440]。
keyID Base64 64-bit PGP key ID [RFC2440].
鍵ID Base64で64ビットのPGP鍵ID [RFC2440]。
name None User name associated with the key.
キーに関連付けられたなしユーザーの名前です。
Key URIs MUST support retrieval by all of the above attribute types.
主なURIは、上記の属性タイプのすべてで検索をサポートしなければなりません。
Revocation URIs MUST support retrieval by the fingerprint and keyID attribute types, which identify the issuer of the key revocation.
失効URIは指紋による検索をサポートしなければならないと鍵IDは、鍵無効の発行者を識別するタイプ、属性。
Permitted attribute types and associated values for use with XML are as specified in sections 2.2 and 2.3. Since XML allows arbitrary attributes to be associated with the <RetrievalMethod> child element of <KeyInfo> [RFC3275], there are no additional special requirements for use with XML.
許可属性タイプとXMLとの使用に関連する値のセクション2.2および2.3に指定されています。 XMLは、任意の属性は、<のKeyInfo> [RFC3275]の<RetrievalMethod>子要素に関連付けることを可能にするため、XMLで使用するための追加の特別な要件はありません。
This informative section documents the rationale behind the design in Section 2 and provides guidance for implementors.
この有益なセクションでは、第2節で設計の理論的根拠を文書化し、実装するためのガイダンスを提供します。
The identifiers are taken from PKCS #15 [PKCS15], a standard that covers (among other things) a transparent interface to a certificate/public key store. These identifiers have been field proven, as they have been in common use for a number of years, typically via PKCS #11 [PKCS11]. Certificate stores and the identifiers that are required for typical certificate lookup operations are analysed in some detail in [Gutmann].
識別子は、PKCS＃15の[PKCS15]、証明書/公開鍵ストアに（とりわけ）透明なインターフェースを覆う規格から取られます。彼らは通常、PKCS＃11 [PKCS11]を経て、数年のために一般的に使用されてきたように、これらの識別子は、フィールド実証されています。証明書ストアおよび一般的な証明書の検索操作のために必要とされる識別子は、[Gutmann氏]にいくつかの詳細に分析されています。
The URI identifier type specifies the identifier associated with the certificate's intended usage with a given Internet security protocol. For example, an SSL/TLS server certificate would contain the server's DNS name (this is traditionally also specified as the CommonName or CN) an S/MIME certificate would contain the subject's email address; an IPsec certificate would contain a DNS name or IP address; and a SIP certificate would contain a SIP URI. A modicum of common sense is assumed when deciding upon an appropriate URI field value.
URIの識別子タイプは、指定したインターネットセキュリティプロトコルと証明書の使用目的に関連する識別子を指定します。例えば、SSL / TLSサーバ証明書は、サーバのDNS名（これは伝統的にものCommonNameまたはCNとして指定されている）S / MIME証明書が対象者の電子メールアドレスが含まれます含まれています。 IPsecの証明書は、DNS名またはIPアドレスが含まれます。そして、SIP証明書は、SIP URIが含まれます。適切なURIフィールドの値に決定する際に常識のささやかが想定されます。
For historical reasons going back to its primary use as a means of looking up users' S/MIME email certificates, some clients may specify the URI attribute name as "email" rather than "uri". Although not required by this specification, servers may choose to allow the use of "email" as an alias for "uri".
バックユーザーのS / MIMEメールの証明書を検索する手段として、その主な用途へ行くの歴史的な理由により、一部のクライアントは、URIは、 『電子メール』ではなく 『URI』として属性名を指定することもできます。この仕様で必須ではありませんが、サーバーは、「URI」の別名として「電子メール」の使用を許可することもできます。
In addition, it is common practice to use the Internet identifier associated with the certificate's intended field of application as the CN for the certificate when this is the most sensible name for the certificate subject. For example, an SSL/TLS server certificate will contain the server's DNS name in the CN field. In web-enabled devices, this may indeed be the only name that exists for the device. It is therefore quite possible that the URI will duplicate the CN, and that it may be the only identifier present (that is, there's no full DN but only a single CN field).
また、証明書のサブジェクトのための最も賢明な名前である証明書のCNなど、アプリケーションの証明書の意図したフィールドに関連付けられているインターネットの識別子を使用するのが一般的です。例えば、SSL / TLSサーバ証明書は、CNフィールドに、サーバのDNS名が含まれています。 Web対応のデバイスでは、これは確かに、デバイスのために存在する唯一の名前かもしれません。それはURIがCNを複製するであろうことが十分に可能であり、それが唯一の識別子に存在してもよいこと（すなわち、全く完全なDNだけ単一CNフィールドがありません）。
By long-standing convention, URIs in certificates are given without a scheme specifier. For example, an SSL/TLS server certificate would contain www.example.com rather than https://www.example.com, and an S/MIME certificate would contain user@example.com rather than mailto:user@example.com. This convention is extended to other URI types as well, so that a certificate containing the (effective) URIs im:user@example.com and xmpp:user@example.com would be queried using the single URI user@example.com. The certificate store would then return all certificates containing this URI, leaving it to the client to determine which one is most appropriate for its use. This approach is taken both because for the most common URI types there's no schema specifier (see the paragraphs above) and no easy way to determine what the intended use is (an SSL/TLS server certificate is simply one presented by an SSL/TLS server), and because the relying party/client is in a better position to judge the certificate's most appropriate use than the certificate store server.
長年の慣例では、証明書内のURIスキームを指定せずに与えられています。例えば、SSL / TLSサーバー証明書は、www.example.comというよりhttps://www.example.comを含んでいるでしょうし、S / MIME証明書がuser@example.comではなく、mailtoの含まれます：user@example.comを。 user@example.comとXMPP：user@example.com照会される単一のURI user@example.com使用（有効）を含む証明書のURIイムように、この規則は、同様に他のURIタイプに拡張されます。証明書ストアは、その使用のために最も適切であるかを判断するために、クライアントにそれを残して、このURIを含むすべての証明書を返します。このアプローチには、スキーマの指定（上記の段落を参照）と、使用目的が何であるかを判断する簡単な方法は、（SSL / TLSサーバー証明書は、単にSSLによって提示された1つであるがないので、最も一般的なURIタイプ用/ TLSサーバの両方を取られます）、および証明書利用者/クライアントが証明書ストアサーバーよりも証明書の最も適切な使用を判断するためのより良い位置にあるため。
Another possible identifier that has been suggested is an IP address or DNS name, which will be required for web-enabled embedded devices. This is necessary to allow for example a home automation controller to be queried for certificates for the devices that it controls. Since this value is regarded as the CN for the device, common practice is to use this value for the CN in the same way that web server certificates set the CN to the server's DNS name, so this option is already covered in a widely-accepted manner.
示唆されているもう一つの可能な識別子は、Web対応の組込み機器に必要とされるIPアドレスまたはDNS名です。これは、例えば、制御する機器の証明書を照会するホームオートメーションコントローラを許可する必要があります。この値は、デバイスのためのCNとみなされているので、一般的な方法は、Webサーバ証明書は、サーバのDNS名にCNを設定するのと同じようにCNのために、この値を使用することですので、このオプションは、すでに広く受け入れられているに覆われています。方法。
The name and email address are an exact copy of what is present in the certificate, without any canonicalisation or rewriting (other than the transport encoding required by HTTP). This follows standard implementation practice, which transfers an exact copy of these data items in order to avoid problems due to character set translation, handling of whitespace, and other issues.
名前とメールアドレスは、（HTTPによって必要とされるトランスポート・エンコーディング以外）canonicalisation又は書き換えることなく、証明書内に存在するものの正確なコピーです。これは、文字セットの変換、空白の取り扱い、およびその他の問題のために問題を回避するために、これらのデータ項目の正確なコピーを転送標準実装の練習を、次の。
Hashes are used for arbitrary-length fields such as ones containing DNs in place of the full field to keep the length manageable. In addition, the use of the hashed form emphasizes that searching for structured name data isn't a supported feature, since this is a simple interface to a {key,value} certificate store rather than an HTTP interface to an X.500 directory. Users specifically requiring an HTTP interface to X.500 may use technology such as HTTP LDAP gateways for this purpose.
ハッシュは、このような扱いの長さを保つために、フルフィールドの代わりにDNを含むものとして任意の長さのフィールドに使用されています。また、ハッシュ化された形の使用は、これは{キー、値}の証明書ストアではなく、X.500ディレクトリへのHTTPインターフェースへの単純なインタフェースであるため、構造名データを検索することは、サポートされた機能ではないことを強調しています。特にX.500へのHTTPインタフェースを必要とするユーザーは、この目的のためにHTTPのLDAPゲートウェイなどの技術を使用することができます。
Although clients will always submit a fixed 160-bit value, servers are free to use as many bits of this value as they require. For example, a server may choose to use only the first 40, 64, 80, or 128 bits for efficiency in searching and maintaining indices.
クライアントは常に固定された160ビットの値を提出しますが、サーバーでは、彼らが必要として、この値の多くのビットを自由に使用できます。例えば、サーバは、最初の40、64、80、またはインデックスを検索し、維持するのに効率のために128ビットを使用することを選択することができます。
PGP has traditionally encoded IDs using a C-style 0xABCDEF notation based on the display format used for IDs in PGP 2.0. Unfortunately, strings in this format are also valid strings in the base64 format, complicated further by the fact that near-misses such as 0xABCDRF could be either a mistyped attempt at a hex ID or a valid base64 ID. For this reason, and to ensure consistency, base64 IDs are used throughout this specification. The search keys used internally will be binary values, so whether these are converted from ASCII-hex or base64 is immaterial in the long run.
PGPは、伝統的にPGP 2.0のIDに使用される表示形式に基づいてCスタイル0xABCDEF表記を使用してIDを符号化されています。残念ながら、この形式の文字列はまた、0xABCDRFなどニアミスは六角IDまたは有効なbase64でIDの入力ミスの試みのいずれかであるという事実によってさらに複雑base64形式で有効な文字列です。このような理由から、と一貫性を確保するため、BASE64 IDは本明細書を通して使用されています。これらは長期的には重要ではないASCIIヘックスまたはBASE64から変換されているかどうかように、内部的に使用された検索キーは、バイナリ値になります。
The attributes are given shortened name forms (for example, iAndSHash in place of issuerAndSerialNumberHash) in order to keep the lengths reasonable, or common name forms (for example, email in place of rfc822Name, rfc822Mailbox, emailAddress, mail, or email) where multiple name forms exist.
どこ複数の属性は、合理的な長さを維持するために、または共通の名前形式（たとえば、rfc822Nameで、rfc822Mailboxの代わりに、電子メール、EMAILADDRESS、メール、または電子メール）で短縮名形式（issuerAndSerialNumberHashの代わりに、例えば、iAndSHash）が与えられています名前の形態が存在します。
In some cases, users may require additional, application-specific attribute types. For example, a healthcare application that uses a healthcare ID as the primary key for its databases may require the ability to perform certificate lookups based on this healthcare ID. The formatting and use of such application-specific identifiers is beyond the scope of this document. However, they should begin with 'x-' to ensure that they don't conflict with identifiers that may be defined in future versions of this specification.
いくつかのケースでは、ユーザーが追加、アプリケーション固有の属性タイプが必要な場合があります。例えば、そのデータベースの主キーとして医療IDを使用する医療アプリケーションは、この医療IDに基づいて証明書のルックアップを実行する機能が必要な場合があります。そのようなアプリケーション固有の識別子のフォーマット及び使用は、この文書の範囲外です。しかし、彼らはこの仕様の将来のバージョンで定義される識別子と競合しないことを確実にするために「X-」で始める必要があります。
The attribute value portion of the identifier should be carefully checked for invalid characters since allowing raw data presents a security risk. Consider, for example, a certificate/public key store implemented using an RDBMS in which the SQL query is built up as "SELECT certificate FROM certificates WHERE iHash = " + <search key>. If <search key> is set to "ABCD;DELETE FROM certificates", the results of the query will be quite different from what was expected by the certificate store administrators. Even a read-only query can be problematic; for example, setting <search key> to "UNION SELECT password FROM master.sysxlogins" will list all passwords in an SQL Server database (in an easily-decrypted format) if the user is running under the sa (DBA) account. For this reason, only valid base64 encodings should be allowed. The same checking applies to queries by name or email address.
識別子の属性値の部分は慎重に生データ、セキュリティ上のリスクが伴う可能ので、無効な文字をチェックする必要があります。考えてみましょう、例えば、証明書/公開鍵ストアは、SQLクエリが+ <検索キー>「iHash =証明書から証明書を選択」として構築されているRDBMSを使用して実装しました。 <キーの検索>に設定されている場合は、「ABCD;証明書。DELETE FROM」、クエリの結果は、証明書ストアの管理者によって予想されたものとは全く異なるものになります。でも、読み取り専用のクエリが問題となる可能性があります。例えば、設定<検索キー>は「master.sysxlogins FROM UNION SELECTパスワード」は、ユーザがSA（DBA）アカウントで実行されている場合（簡単に復号化された形式で）SQL Serverデータベース内のすべてのパスワードの一覧が表示されますします。このため、唯一の有効なbase64でエンコードを許可する必要があります。同じチェックは名前や電子メールアドレスでクエリに適用されます。
Straightforward sanitisation of queries may not be sufficient to prevent all attacks; for example, a filter that removes the SQL query string "DELETE" can be bypassed by submitting the string embedded in another instance of the string. Removing "DELETE" from "DELDELETEETE" leaves the outer "DELETE" in place. Abusing the truncation of over-long strings by filters can also be used as a means of attack, with the attacker ensuring that the truncation occurs in the middle of an escape sequence, bypassing the filtering. Although in theory recursive filtering may help here, the use of parameterised queries (often called placeholders) that aren't vulnerable to SQL injection should be used to avoid these attacks. More information on securing database back-ends may be found in [Birkholz], and more comments on sanitisation and safety concerns may be found in the security considerations section.
クエリの簡単な消毒は、すべての攻撃を防ぐのに十分ではないかもしれません。例えば、SQLクエリ文字列を除去するフィルタは、文字列の別のインスタンスに埋め込まれた文字列を提出することによってバイパスすることができ、「削除します」。 「DELDELETEETE」から「削除」削除すると、外側に「DELETE」の場所を離れます。フィルタによってオーバー長い文字列の切り捨てを乱用も、攻撃者が切り捨てがフィルタをバイパスして、エスケープシーケンスの途中で発生することを確実にして、攻撃の手段として使用することができます。理論的には再帰的なフィルタリングがここに役立つかもしれないが、SQLインジェクションに対して脆弱ではありません（多くの場合、プレースホルダと呼ばれる）パラメータ化クエリを使用すると、これらの攻撃を回避するために使用する必要があります。データベースのバックエンドを確保する上でより多くの情報が[Birkholz]に見出すことができ、消毒及び安全性の懸念についてのコメントは、セキュリティ問題のセクションに見出すことができます。
Pre-constructed URIs that fetch a certificate/public key matching a fixed search criterion may be useful for items such as web pages or business cards, or even for technical support/helpdesk staff who want to mail to users but can't find the certificate themselves. These URIs may also be used to enforce privacy measures when distributing certificates by perturbing the search key in a manner known only to the certificate/public key store, or to the certificate store and users (in other words, by converting the URI into a capability). For example, a user with a newly-issued certificate could be instructed to fetch it with a key of "x-encrCertHash=...", which is decrypted by the certificate store to fetch the appropriate certificate, ensuring that only the certificate owner can fetch their certificate immediately after issue. Similarly, an organisation that doesn't want to make its certificates available for public query might require a MAC on search keys (e.g., "x-macCertHash=...") to ensure that only authorised users can search for certificates (although a more logical place for access control, if a true web server is being used to access the store, would obviously be at the HTTP level).
ユーザーにメールしたい、そのようなWebページや名刺、あるいは技術サポート/ヘルプデスクスタッフなどのアイテムのために有用である可能性が固定された検索基準に一致する証明書/公開鍵を取得しますが、証明書を見つけることができないURIを事前に構築自分自身。これらのURIは、証明書/公開鍵ストアにのみ知られている方法で検索キーを摂動することによって証明書を配布するとき、プライバシー対策を適用するために使用することができる、すなわち証明書ストアとユーザー（に、能力にURIを変換し）。例えば、新たに発行された証明書を持つユーザーは、その証明書のみの所有者を確保し、適切な証明書を取得するために証明書ストアで復号化された「X-encrCertHash = ...」のキー、でそれを取得するように指示することができ問題の直後にその証明書を取得することができます。同様に、公共のクエリのためにその証明書を利用できるように望んでいない組織ではあるが（許可されたユーザーのみが証明書を検索することができることを保証するために（例えば、「X-macCertHash = ...」）は、検索キーにMACが必要な場合がありますアクセス制御のためのより多くの論理的な場所、真のWebサーバはストアにアクセスするために使用されている場合、明らかに）HTTPレベルだろう。
The query types have been specifically chosen to be not just an HTTP interface to LDAP but a general-purpose retrieval mechanism that allows arbitrary certificate/public key storage mechanisms (with a bias towards simple {key,value} stores, which are deployed almost universally, whether as ISAM, Berkeley DB, or an RDBMS) to be employed as back-ends. This specification has been deliberately written to be technology neutral, allowing any {key,value} lookup mechanism to be used. It doesn't matter if you choose to have trained chimpanzees look up certificates in books of tables, as long as your method can provide the correct response with reasonable efficiency.
クエリの種類は、特にLDAPへのHTTPインタフェースはほとんど普遍的に展開されている単純{キー、値}店舗に向かってバイアスを用いて任意の証明書/公開鍵格納メカニズムを（可能な汎用検索メカニズムだけでなくなるように選択されています、ISAM、バークレイDB、またはRDBMS）などのかどうかは、バックエンドとして使用することができます。この仕様は意図的に任意{キー、値}ルックアップメカニズムを使用できるように、中性技術であると書かれています。あなたは訓練を受けたチンパンジーがいる限り、あなたの方法は、合理的な効率で正しい応答を提供できるよう、テーブルの本で証明書を検索することを選択した場合、それは問題ではありません。
Certificate/public key and CRL stores are allocated separate URIs because they may be implemented using different mechanisms. A certificate store typically contains large numbers of small items, while a CRL store contains a very small number of potentially large items. By providing independent URIs, it's possible to implement the two stores using mechanisms tailored to the data they contain.
それらは異なるメカニズムを使用して実装することができるので、証明書/公開鍵とCRLストアは別のURIを割り当てられています。 CRLストアが潜在的に大きなアイテムの非常に小さい数を含むが証明書ストアは、典型的には、小項目の多数を含んでいます。独立したURIを提供することにより、それはそこに含まれるデータに合わせたメカニズムを使用して2つの店舗を実装することが可能です。
PGP combines key and revocation information into a single data object so that it's possible to return both public keys and revocation information from the same URI. If distinct key and revocation servers are available, these can provide a slight performance gain since fetching revocation information doesn't require fetching the key that it applies to. If no separate servers are available, a single server can be used to satisfy both types of queries with a slight performance loss, since fetching revocation information will also fetch the public key data associated with the revocation data.
それが可能だと同じURIから公開鍵と失効情報の両方を返すようにしてPGPは、単一のデータ・オブジェクトにキーと失効情報を組み合わせています。個別のキーと失効サーバーが利用できる場合、これらは、それが適用されるキーを取得する必要はありません失効情報を取得以来、わずかなパフォーマンスの向上を提供することができます。別個のサーバが利用できない場合は、単一のサーバは、無効化データに関連付けられた公開鍵データをフェッチする失効情報を取得するため、わずかな性能損失とクエリの両方の種類を満たすために使用することができます。
The disallowance of exotic encoding forms reflects the fact that most clients (and many servers, particularly for embedded devices) are not general-purpose web browsers or servers capable of handling an arbitrary range of encoding forms and types, but simply basic HTTP engines attached to key management applications. In other words, the HTTP interface is a rudimentary add-on to a key management application, rather than key-management being an add-on to a general-purpose web client or server. Eliminating unnecessary choices simplifies the implementation task and reduces code size and complexity, with an accompanying decrease in the probability of security issues arising from the added complexity.
エキゾチックなエンコード形式の否認は、（特に組込み機器向けや多くのサーバ、）ほとんどのクライアントは、エンコード形式や種類の任意の範囲を扱うことが可能な汎用のWebブラウザまたはサーバーではありませんが、それに取り付けただけで、基本的なHTTPエンジンという事実を反映しています鍵管理アプリケーション。つまり、HTTPインタフェースは、鍵管理はアドオンの汎用Webクライアントまたはサーバにされるのではなく、初歩的なアドオン鍵管理アプリケーションにあります。不要な選択肢を排除することは、実装作業を簡素化し、追加の複雑さに起因するセキュリティ問題の確率で添付減少と、コードサイズと複雑さを低減します。
The use of an "Accept-encoding: identity" header would achieve the same effect as disallowing any additional encodings and may indeed be useful since section 14.3 of [RFC2616] indicates that the absence of this header may be taken to mean that any encoding is permitted. However, this unnecessarily bloats the HTTP header in a potentially performance-affecting manner (see Section 2.5.5), whereas establishing a requirement that the response be returned without any additional decoration avoids the need to specify this in each request. Implementations should therefore omit the Accept-encoding header entirely or if it has to be included, include "identity" or the wildcard "*" as an accepted content-encoding type.
使用は、「受け入れエンコード：同一性」ヘッダが追加のエンコーディングを許可しないのと同じ効果を達成するであろうし、[RFC2616]のセクション14.3は、このヘッダが存在しない場合は、任意の符号化であることを意味すると解釈することができることを示しているので、実際に有用であるかもしれません許可。しかし、これは不必要に潜在的に性能に影響する方法（セクション2.5.5を参照）のHTTPヘッダがbloats、応答は、任意の追加の装飾なしに返される要件を確立する一方、各リクエストでこれを指定する必要性を回避します。実装は、従って、完全に受け入れコードヘッダを省略するか、それが含まれなければならない場合、受け付けられたコンテンツ符号化タイプとして「同一性」またはワイルドカード「*」を含むべきです。
Use of chunked encoding is given as a SHOULD NOT rather than a MUST NOT because support for it is required by [RFC2616]. Nevertheless, this form of encoding is strongly discouraged, as the data quantities being transferred (1-2kB) make it entirely unnecessary, and support for this encoding form is vulnerable to various implementation bugs, some of which may affect security. However, implementors should be aware that many versions of the Apache web server will unnecessarily use chunked encoding when returning responses. Although it would be better to make this a MUST NOT, this would render clients that rejected it incompatible with the world's most widely used web server. For this reason, support for chunked encoding is strongly discouraged but is nevertheless permitted. Clients that choose not to support it should be aware that they may run into problems when communicating with Apache-based HTTP certificate stores.
SHOULD NOTではなく、それに対するサポートは、[RFC2616]によって必要とされてはいけませんのでようチャンクエンコーディングの使用が与えられます。データ量は、それが完全に不要とする（1-2kB）転送され、この符号化形式のサポートがセキュリティに影響を与える可能性があるいくつかの様々な実装のバグに対して脆弱であり、それにもかかわらず、符号化のこの形態は強く推奨されます。しかし、実装者は、応答を返すときApache Webサーバの多くのバージョンが不必要にチャンクエンコーディングを使用することを認識する必要があります。それは、このaは、NOT MUSTにする方が良いだろうが、これは世界で最も広く使用されているWebサーバとの互換性がないことを拒否したクライアントをレンダリングします。このため、チャンクエンコーディングのサポートは強くお勧めしますが、それにもかかわらず、許可されています。 ApacheベースのHTTP証明書ストアと通信するときに、彼らが問題に実行可能性があることに注意する必要がありますサポートしないことを選択したクライアント。
Multiple responses are returned as multipart/mixed rather than an ASN.1 SEQUENCE OF Certificate or PKCS #7/CMS certificate chain (degenerate signed data containing only certificates) because this is more straightforward to implement with standard web-enabled tools. An additional advantage is that it doesn't restrict this access mechanism to DER-based data, allowing it to be extended to other certificate types, such as XML, PGP, and SPKI.
複数回答はマルチパート/混合ではなく、証明書のASN.1配列またはPKCS＃7 / CMSの証明書チェーン（縮退が唯一の証明書を含むデータに署名した）これは、標準的なWeb対応のツールで実装するのがより簡単ですのでとして返されます。さらなる利点は、それがこのようなXML、PGP、およびSPKIのような他の証明書のタイプに拡張することを可能にする、DERベースのデータへのこのアクセスメカニズムを制限しないことです。
Where high throughput/performance under load is a critical issue, a main-memory database that acts as a form of content cache may be interposed between the on-disk database and the HTTP interface [Garcia-Molina]. A main-memory database provides the same functionality as an on-disk database and is fully transparent to the HTTP front-end, but offers buffer management and retrieval facilities optimised for memory-resident data. Where further scalability is required, the content-caching system could be implemented as a cluster of main-memory databases [Ji].
ここで、荷重下で高いスループット/性能は重大な問題、コンテンツ・キャッシュの形態は、ディスク上のデータベースとHTTPインタフェース[ガルシア・モリーナ]との間に介在することができるように作用するメインメモリデータベースです。メインメモリデータベースは、ディスク上のデータベースと同じ機能を提供し、HTTPフロントエンドに対して完全に透明であるが、メモリ常駐データのために最適化バッファ管理および検索機能を提供しています。さらにスケーラビリティが必要とされる場合、コンテンツ・キャッシング・システムは、メインメモリデータベースのクラスタ[チ]として実現することができます。
Various network efficiency considerations need to be taken into account when implementing this certificate/public key distribution mechanism. For example, a simplistic implementation that performs two writes (the HTTP header and the certificate, written separately) followed by a read will interact badly with TCP delayed-ACK and slow-start. This occurs because the TCP MSS is typically 1460 bytes on a LAN (Ethernet) or 512/536 bytes on a WAN, while HTTP headers are ~200-300 bytes, far less than the MSS. When an HTTP message is first sent, the TCP congestion window begins at one segment, with the TCP slow-start then doubling its size for each ACK. Sending the headers separately will send one short segment and a second MSS-size segment, whereupon the TCP stack will wait for the responder's ACK before continuing. The responder gets both segments, then delays its ACK for 200ms in the hopes of piggybacking it on responder data, which is never sent, since it's still waiting for the rest of the HTTP body from the initiator. As a result, there is a 200ms (+assorted RTT) delay in each message sent.
様々なネットワーク効率の考慮事項は、この証明書/公開鍵配布メカニズムを実装する際に考慮される必要があります。例えば、読取り、続いて2個の書き込み行う単純な実装（HTTPヘッダおよび証明書を、別々に書かれた）は、TCP遅延ACKおよびスロースタートとひどく相互作用します。 TCP MSSは、通常、LAN（イーサネット）上の1460バイトまたはWAN上の536分の512バイトであるため、HTTPヘッダはMSSよりもはるかに少ない〜200-300バイト、ありながらこれは、発生します。 HTTPメッセージが最初に送信されるとき、TCPは、各ACKのためにそのサイズを倍増スロースタートで、TCP輻輳ウィンドウは、一つのセグメントで始まります。 TCPスタックは続行する前に応答者のACKを待ちます、そこで個別のヘッダを送信すると、1つの短いセグメントと第二MSSサイズのセグメントを送信します。応答者が両方のセグメントを取得し、それはまだ、イニシエータからのHTTP本体の残りの部分を待っていますから、送信されることはありません応答データ、上に便乗を期待して200msの間にそのACKを遅らせます。結果として、送信される各メッセージには200ms（+アソートRTT）遅延があります。
There are various other considerations that need to be taken into account to provide maximum efficiency. These are covered in depth elsewhere [Spero] [Heidemann] [Nielsen]. In addition, modifications to TCP's behaviour, such as the use of 4K initial windows [RFC3390] (designed to reduce small HTTP transfer times to a single RTT), should also ameliorate some of these issues.
最大効率を提供するために、考慮に入れる必要がある他のさまざまな考慮事項があります。これらは、深さ別の場所で[スペロ] [Heidemann] [ニールセン]で覆われています。また、このような4K初期ウィンドウの使用などのTCPの挙動への変更は、[RFC3390]は（単一RTTに小さなHTTP転送時間を短縮するために設計された）、また、これらの問題のいくつかを改善する必要があります。
A rule of thumb for optimal performance is to combine the HTTP header and data payload into a single write (any reasonable HTTP implementation will do this anyway, thanks to the considerable body of experience that exists for HTTP server performance tuning), and to keep the HTTP headers to a minimum to try to fit data within the TCP MSS. For example, since this protocol doesn't involve a web browser, there's no need to include various common browser-related headers such as ones detailing software versions or acceptable languages.
最適なパフォーマンスのための経験則は、（任意の合理的なHTTP実装は、とにかくHTTPサーバのパフォーマンス・チューニングのために存在する経験のかなりのボディのおかげでこれを行います）、および維持するために単一の書き込みにHTTPヘッダとデータペイロードを組み合わせることですTCP MSS内のデータに合うようにしようとする最小のHTTPヘッダ。例えば、このプロトコルは、Webブラウザを必要としないので、そのようなソフトウェアのバージョンまたは許容可能な言語を詳述するものなど、さまざまな一般的なブラウザ関連のヘッダをインクルードする必要はありません。
The interface specified in this document is a basic read-only type that will be used by the majority of clients. The handling of updates (both insertion and deletion) is a complex issue involving both technological issues (a variety of fields used for indexing and information retrieval need to be specified in a technology-neutral manner, or the certificate store needs to perform its own parsing of the item being added, moving it from a near-universal key=value lookup mechanism to a full public-key/certificate processing system) and political ones (who can perform updates to the certificate store, and under what conditions?). Because of this complexity, the details of any potential update mechanism are left as a local configuration issue, although they may at some point be covered in a future document if there is sufficient demand.
この文書で指定されたインターフェイスは、クライアントの大多数が使用する基本的な読み取り専用タイプです。アップデートの取り扱い（挿入や削除の両方）は、両方の技術的な問題を含む複雑な問題（インデックスや情報検索のために使用されるフィールドの様々な技術中立的に指定する必要がある、または証明書ストアは、独自の解析を実行する必要があります証明書ストアに、そしてどのような条件の下で更新を行うことができ、完全な公開鍵/証明書処理システムに近いユニバーサルキー=値のルックアップメカニズムからそれを移動、追加された項目）と政治的なもの（？）の。十分な需要がある場合、彼らはいくつかの時点で将来の文書でカバーすることができるが、この複雑さのため、任意の潜在的な更新メカニズムの詳細は、ローカル設定の問題として残されています。
Concerns have been raised over the use of HTTP as a substrate [RFC3205]. The mechanism described here, which implements a straightforward request/response protocol with the same semantics as traditional HTTP requests, is unaffected by these issues. Specifically, it does not implement any form of complex RPC mechanism, does not require HTTP security measures, is not affected by firewalls (since it uses only a basic HTTP GET rather than layering a new protocol on top of HTTP), and has well-defined MIME media types specified in standards documents. As such, the concerns expressed in [RFC3205] do not apply here. In addition, although a number of servers still don't fully support some of the more advanced features of HTTP 1.1 [Krishnamurthy], the minimal subset used here is well supported by the majority of servers and HTTP implementations.
懸念は、基板[RFC3205]としてHTTPを使用する上で提起されています。従来のHTTPリクエストと同じ意味を持つ単純な要求/応答プロトコルを実装して、ここで説明したメカニズムは、これらの問題の影響を受けません。具体的には、複雑なRPCメカニズムの任意の形式を実装していないHTTPのセキュリティ対策を必要としない、（それだけで、基本的なHTTPはHTTPの上に新しいプロトコルを積層するのではなく、GETを使用するため）ファイアウォールによって影響を受け、そして有していない十分に標準の文書で指定されたMIMEメディアタイプを定義しました。このようにして、[RFC3205]で表明した懸念は、ここでは適用されません。また、サーバーの数がまだ完全にHTTP 1.1のより高度な機能の一部をサポートしていませんが、[Krishnamurthy]、ここで使用される最小限のサブセットはよくサーバやHTTP実装の過半数によってサポートされています。
This access mechanism is similar to the PGP HKP protocol [HKP]; however, the latter is almost entirely undocumented and requires that implementors reverse-engineer other implementations. Because of this lack of standardisation, no attempt has been made to ensure interoperability or compatibility with HKP-based servers, although PGP developers provided much valuable input for this document. One benefit that HKP does bring is extensive implementation experience, which indicates that this is a very workable solution to the problem of a simple certificate/public key retrieval mechanism. HKP servers have been implemented using flat files, Berkeley DB, and various databases, such as Postgres and MySQL.
このアクセス機構は、PGP HKPプロトコル[HKP]と同様です。しかし、後者は、ほぼ完全に非公開であり、実装は、他の実装、リバースエンジニアリングすることを必要とします。 PGPの開発者は、このドキュメントのための多くの貴重な入力を提供するが、そのための標準化の欠如のため、何の試みは、HKPベースのサーバーとの相互運用性や互換性を確保するために行われていません。 HKPがもたらすないことを1つの利点は、これは単純な証明書/公開鍵検索機構の問題に非常に実行可能なソリューションであることを示しており、豊富な実装経験です。 HKPサーバは、PostgresのとMySQLなどのフラットファイル、バークレーDB、および各種データベースを使用して実装されています。
To convert the subject DN C=NZ, O=... CN=Fred Dagg into a search key:
検索キーに対象DN C = NZ、O = ... CN =フレッドDaggを変換するには：
Hash the DN, in the DER-encoded form it appears in the certificate, to obtain
得るために、それが証明書に表示されDER符号化された形態で、DNをハッシュ
96 4C 70 C4 1E C9 08 E5 CA 45 25 10 D6 C8 28 3A 1A C1 DF E2
96 4C 70 C4 1E C9 08 E5 CA 45 25 10 D6 C8 28 3A 1A C1 DF E2
Base-64 encode this to obtain:
これは、取得するベース64エンコード。
lkxwxB7JCOXKRSUQ1sgoOhrB3+I
lkxwxB7JCOXKRSUQ1sgoOhrB3 + I
(Note the absence of trailing '=' padding.) This is the search key to use in the query URI.
（「=」パディング末尾の不在に注意してください。）これは、クエリURIで使用する検索キーです。
To fetch all certificates useful for sending encrypted email to foo@example.com:
foo@example.comに暗号化された電子メールを送信するための便利なすべての証明書を取得するには：
GET /search.cgi?email=foo%40example.com HTTP/1.1
GET /search.cgi?email=foo%40example.com HTTP / 1.1
(For simplicity, the additional Host: header required by [RFC2616] is omitted here and in the following examples.) In this case, "/search.cgi" is the abs_path portion of the query URI, and the request is submitted to the server located at the net_loc portion of the query URI. Note the encoding of the '@' symbol as per [RFC2854]. Remaining required headers, such as the "Host" header required by HTTP 1.1, have been omitted for the sake of clarity.
（簡単にするために、追加のホスト：ヘッダは省略し、以下の実施例であり、[RFC2616]によって必要とされる）、この場合には、「/search.cgi」は、クエリURIの腹筋_経路部分であり、要求がに提出されクエリURIのnet_loc部に位置するサーバー。 [RFC2854]の通りの「@」記号の符号化に注意してください。そのようなHTTP 1.1で必要とされる「ホスト」ヘッダとして残りの必要なヘッダは、明確化のために省略されています。
To fetch the CA certificate that issued the email certificate:
電子メールの証明書を発行したCA証明書を取得するには：
<Convert the issuer DN to a search key> GET /search.cgi?sHash=<search key> HTTP/1.1
/search.cgi?sHash=<searchキー> HTTP / 1.1をGET <発行者DNは、検索キーに変換>
Alternatively, if chaining is by key identifier:
また、チェーンは、キー識別子である場合：
<Extract the keyIdentifier from the authorityKeyIdentifier> GET /search.cgi?sKIDHash=<search key> HTTP/1.1
GET /search.cgi?sKIDHash=<searchキー> HTTP / 1.1 <authorityKeyIdentifierからkeyIdentifierを抽出>
To fetch other certificates belonging to the same user as the email certificate:
電子メールの証明書と同じユーザーに属する他の証明書を取得するには：
<Convert the subject DN to a search key> GET /search.cgi?sHash=<search key> HTTP/1.1
/search.cgi?sHash=<searchキー> HTTP / 1.1をGET <検索キーにサブジェクトDNを変換します>
To fetch the CRL for the certificate:
証明書のCRLを取得するには：
<Convert the issuer DN to a search key> GET /search.cgi?iHash=<search key> HTTP/1.1
/search.cgi?iHash=<searchキー> HTTP / 1.1をGET <発行者DNは、検索キーに変換>
Note that since the differentiator is the URI base, the above two queries appear identical (since the URI base isn't shown) but are in fact distinct.
微分は、URIベースであるため、上記2つのクエリは、（URIベースが図示されていないので）同じように見えるが、実際には異なることに留意されたいです。
To retrieve a key using XML methods, the <KeyName> (which contains the string identifier for the key), used with the subject DN hash above, would be:
（キーの文字列識別子を含む）、XMLの方法を使用してキーを取得<キー名>には、上記被写体DNハッシュと共に使用であろう。
<KeyName KeyID="sHash">lkxwxB7JCOXKRSUQ1sgoOhrB3+I</KeyName>.
<キー名鍵ID = "sHash"> lkxwxB7JCOXKRSUQ1sgoOhrB3 + I </キー名>。
In order to locate servers from which certificates may be retrieved, relying parties can employ one or more of the following strategies:
証明書は、依拠当事者は、以下の戦略の一つ以上を利用することができ、検索することができる、そこからサーバーを検索するために：
- Information contained in the certificate - Use of DNS SRV - Use of a "well-known" location - Manual configuration of the client software
- DNSのSRVの利用 - - 「既知の」場所の使用 - 証明書に含まれている情報のクライアントソフトウェアの手動設定
The intent of the various options provided here is to make the certificate store access as transparent as possible, only requiring manual user configuration as a last resort.
ここで提供される様々なオプションの意図は、最後の手段としてのみ、手動ユーザ設定を必要とし、可能な限り透明証明書ストアへのアクセスをすることです。
In order to convey a well-known point of information access to relying parties, CAs SHOULD use the SubjectInfoAccess (SIA) and AuthorityInfoAccess (AIA) extension [RFC3280] in certificates. The OID value for the accessMethod is one of:
依拠当事者への情報アクセスのよく知られたポイントを伝えるために、CAは証明書にSubjectInfoAccess（SIA）およびAuthorityInfoAccess（AIA）拡張[RFC3280]を使用すべきです。たaccessMethodのためのOID値は、のいずれかです。
id-ad-http-certs OBJECT IDENTIFIER ::= { id-ad 6 }
id-ad-http-crls OBJECT IDENTIFIER ::= { id-ad 7 }
where:
どこ：
id-ad OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
pkix(7) 48 }
The corresponding accessLocation is the query URI. The use of this facility provides a CA with a convenient, standard location to indicate where further certificates may be found, for example, for certification path construction purposes. Note that it doesn't mean that the provision of certificate store access services is limited to CAs only.
対応のaccessLocationは、クエリのURIです。この機能の使用は、証明書が認証パス構築のために、例えば、見つけることができる場所を示すための便利な、標準位置CAを提供します。それが証明書ストア・アクセス・サービスの提供を唯一のCAに制限されていることを意味しないことに注意してください。
DNS SRV is a facility for specifying the location of the server(s) for a specific protocol and domain [RFC2782]. For the certificate store interface, the DNS SRV symbolic name for the certificate store interface SHALL be "certificates". The name for the CRL store interface SHALL be "crls". The name for the PGP public key store SHALL be "pgpkeys". The name for the PGP revocation store SHALL be "pgprevocations". Handling of additional DNS SRV facilities, such as the priority and weight fields, is as per [RFC2782].
DNSのSRVは、特定のプロトコルおよびドメイン[RFC2782]のためのサーバ（複数可）の位置を特定するための設備です。証明書ストア・インタフェースについては、証明書ストア・インタフェースのDNS SRVシンボリック名は、「証明書」ものでなければなりません。 CRL店インタフェースの名前は、「CRL」をされなければなりません。 PGP公開鍵ストアの名前は「pgpkeys」ものでなければなりません。 PGP失効店の名前は「pgprevocations」ものでなければなりません。このような優先度と重みフィールドとして追加のDNS SRV設備の取扱い、[RFC2782]の通りです。
If a CA with the domain example.com were to make its certificates available via an HTTP certificate store interface, the server details could be obtained by a lookup on:
ドメインexample.comとCAがHTTP証明書ストアインタフェースを介して、その証明書を利用できるようにした場合、サーバーの詳細は、上の検索によって得られることができます：
_certificates._tcp.example.com
＿せｒちふぃかてｓ。＿ｔｃｐ。えぁｍｐぇ。こｍ
and
そして
_crls._tcp.example.com
＿ｃｒｌｓ。＿ｔｃｐ。えぁｍｐぇ。こｍ
This would return the server(s) and port(s) for the service as specified in [RFC2782].
[RFC2782]で指定されたように、これはサービスのためのサーバ（群）とポート（複数可）を返します。
If no other location information is available, the certificate store interface may be located at a "well-known" location constructed from the service provider's domain name. In the usual case, the URI is constructed by prepending the type of information to be retrieved ("certificates.", "crls.", "pgpkeys.", or "pgprevocations.") to the domain name to obtain the net_loc portion of the URI, and by appending a fixed abs_path portion "search.cgi". The URI form of the "well-known" location is therefore:
他の位置情報が利用できない場合、証明書ストア・インターフェースは、サービスプロバイダーのドメイン名から作成「既知の」位置に配置することができます。通常の場合、URIはのnet_loc部分を取得するためにドメイン名に（「証明書」、「CRLの」、「pgpkeys。」、又は「pgprevocations。」）検索されるべき情報の種類を付加することにより構成されていますURI、および固定腹筋_経路部分「search.cgi」を付加することによって。 「周知の」場所のURIの形式は、従ってあります。
certificates.<domain_name>/search.cgi crls.<domain_name>/search.cgi pgpkeys.<domain_name>/search.cgi pgprevocations.<domain_name>/search.cgi
証明書を発行します。<ドメイン名> /search.cgiのCRL。<ドメイン名> /search.cgi pgpkeys。<ドメイン名> /search.cgi pgprevocations。<ドメイン名> /search.cgi
Certificate store service providers SHOULD use these URIs in preference to other alternatives. Note that the use of "search.cgi" does not imply the use of CGI scripts [RFC3875]. This would be the exception rather than the rule, since it would lead to a rather inefficient implementation; it merely provides one possible (and relatively simple to set up) implementation alternative (see the rationale for more on this).
証明書ストア・サービス・プロバイダは、他の選択肢に優先してこれらのURIを使用すべきです。 「search.cgi」の使用は、CGIスクリプト[RFC3875]を使用することを意味するものではないことに注意してください。それはむしろ非効率的な実施につながるので、これはむしろ例外になります。それは単に一つの可能な（とセットアップが比較的単純な）実装の選択肢（この詳細について根拠を参照）を提供します。
A second case occurs when the certificate access service is being provided by web-enabled embedded devices, such as Universal Plug and Play devices [UPNP]. These devices have a single, fixed net_loc (either an IP address or a DNS name) and make services available via an HTTP interface. In this case, the URI is constructed by appending a fixed abs_path portion "certificates/search.cgi" for certificates, "crls/search.cgi" for CRLs, "pgpkeys/search.cgi" for PGP public keys, and "pgprevocations/search.cgi" for PGP revocation information to the net_loc. The URI form of the "well-known" location is therefore:
証明書アクセスサービスは、ユニバーサルプラグアンドプレイデバイスなどのウェブ対応組み込みデバイス、[UPNP]によって提供されているときに、第2のケースが発生します。これらのデバイスは、単一の固定net_loc（IPアドレスまたはDNS名のいずれか）を持っており、HTTPインタフェースを介してサービスを利用できるようにします。 /この場合、URIは、証明書の固定腹筋_経路部分「証明書/ search.cgi」を付加することにより構成され、PGP公開鍵のためのCRL、「pgpkeys / search.cgi」の「CRLの/ search.cgi」、および「pgprevocations net_locにPGP失効情報についてsearch.cgi」。 「周知の」場所のURIの形式は、従ってあります。
<net_loc>/certificates/search.cgi <net_loc>/crls/search.cgi <net_loc>/pgpkeys/search.cgi <net_loc>/pgprevocations/search.cgi
<net_loc> /certificates/search.cgi <net_loc> /crls/search.cgi <net_loc> /pgpkeys/search.cgi <net_loc> /pgprevocations/search.cgi
If certificate access as described in this document is implemented by the device, then it SHOULD use these URIs in preference to other alternatives (see the rationale for more on this requirement).
この文書に記載されているように、証明書へのアクセスがデバイスによって実装されている場合、それは他の選択肢（この要件についての理論的根拠を参照）に優先して、これらのURIを使用すべきです。
If a CA with the domain example.com were to make its certificates available via an HTTP certificate store interface, the "well-known" query URIs for certificates and CRLs would be:
ドメインexample.comとCAがHTTP証明書ストアインタフェースを介して、その証明書を利用できるようにした場合、証明書とCRLの「既知の」クエリのURIは次のようになります。
http://certificates.example.com/search.cgi http://crls.example.com/search.cgi
ｈっｔｐ：／／せｒちふぃかてｓ。えぁｍｐぇ。こｍ／せあｒｃｈ。ｃぎ ｈっｔｐ：／／ｃｒｌｓ。えぁｍｐぇ。こｍ／せあｒｃｈ。ｃぎ
A home automation controller with the IP address 192.0.2.1 (a control point in UPnP terminology) would make certificates for devices such as HVAC controllers, lighting and appliance controllers, and fire and physical intrusion detection devices available as:
IPアドレス192.0.2.1（UPnPの用語でコントロールポイント）とホームオートメーションコントローラは、HVACコントローラ、照明や家電のコントローラ、および火災やとして使用可能な物理侵入検知素子等のデバイスの証明書を作成します：
http://192.0.2.1/certificates/search.cgi http://192.0.2.1/crls/search.cgi
ｈっｔｐ：／／１９２。０。２。１／せｒちふぃかてｓ／せあｒｃｈ。ｃぎ ｈっｔｐ：／／１９２。０。２。１／ｃｒｌｓ／せあｒｃｈ。ｃぎ
A print server with DNS name "printspooler" would make certificates for web-enabled printers that it communicates with available as:
DNS名「printspooler」とプリントサーバーは、それが利用できるように通信し、Web対応のプリンタ用の証明書を作成します：
http://printspooler/certificates/search.cgi http://printspooler/crls/search.cgi
http：//printspooler/certificates/search.cgiます。http：//printspooler/crls/search.cgi
The accessLocation for the HTTP certificate/public key/CRL store MAY be configured locally at the client. This can be used if no other information is available, or if it is necessary to override other information.
HTTP証明書のaccessLocation /公開鍵/ CRLストアは、クライアントでローカルに構成されるかもしれません。他の情報が利用できない場合に使用することができ、または他の情報を上書きする必要がある場合。
This informative section documents the rationale behind the design in Section 3 and provides guidance for implementors.
この有益なセクションでは、第3節では、設計の根拠を文書化し、実装するためのガイダンスを提供します。
The optimal solution for the problem of service location would be DNS SRV. Unfortunately, the operating system used by the user group most desperately in need of this type of handholding has no support for anything beyond the most basic DNS address lookups, making it impossible to use DNS SRV with anything but very recent Win2K and XP systems. To make things even more entertaining, several of the function names and some of the function parameters changed at various times during the Win2K phase of development, and the behaviour of portions of the Windows sockets API changed in undocumented ways to match. This leads to an unfortunate situation in which a Unix sysadmin can make use of DNS SRV to avoid having to deal with technical configuration issues, but a Windows'95 user can't. Because of these problems, an alternative to DNS SRV is provided for situations where it's not possible to use this.
サービスの場所の問題のための最適解は、DNS SRVだろう。残念ながら、手持ちのこのタイプを必要としているほとんどの必死のユーザグループが使用するオペレーティングシステムは、それが不可能なものが、非常に最近のWin2KとXPのシステムとのDNS SRVを使用するようになって、最も基本的なDNSアドレス検索を超えたものをサポートしていません。物事はもっと面白いようにするには、関数名や関数のパラメータのいくつかのいくつかは、開発のWin2Kではフェーズの間に様々な時間に変え、およびWindowsの部分の挙動は、APIが一致するように文書化されていない方法で変更ソケット。これは、UNIXのシステム管理者は、技術的な構成の問題に対処することを避けるためにDNSのSRVを利用することが可能な不幸な事態につながるが、Windows'95のユーザーがすることはできません。これらの問題のため、DNSのSRVの代わりに、それがこれを使用することはできません状況のために用意されています。
The SRV or "well-known" location option can frequently be automatically derived by user software from currently-known parameters. For example, if the recipient's email address is @example.com, the user software would query _certificates._tcp.example.com or go to certificates.example.com and request the certificate. In addition, user software may maintain a list of known certificate sources in the way that known CA lists are maintained by web browsers. The specific mention of support for redirection in Section 2 emphasises that many sites will outsource the certificate-storage task. At worst, all that will be required is the addition of a single static web page pointing to the real server. Alternatives such as DNS CNAME RRs are also possible but may not be as easy to set up as HTTP redirects (corporate policies tend to be more flexible in regard to web page contents than modifying DNS configurations would be).
SRVまたは「よく知られている」locationオプションは、頻繁に自動的に現在知られているパラメータからユーザソフトウェアによって導出することができます。受信者のメールアドレスが@ example.comであれば、例えば、ユーザソフトウェアは_certificates._tcp.example.comを照会でしょうかcertificates.example.comに移動し、証明書を要求します。また、ユーザー・ソフトウェアは、既知のCAリストは、Webブラウザによって維持されている方法で知られている証明書ソースのリストを維持することができます。第2節でのリダイレクションのためのサポートの具体的な言及は、多くのサイトは、証明書のストレージタスクを外部委託することを強調しています。最悪の場合、必要とされるものすべては、実サーバへの単一の静的なWebページのポインティングを追加することです。このようDNS CNAME RRのなどの代替も可能であるが、（企業ポリシーは、DNSの設定を変更するよりも、Webページの内容に関して、より柔軟になりがちだろう）HTTPリダイレクトとして設定するように簡単ではないかもしれません。
The "well-known" location URI is designed to make hosting options as flexible as possible. Locating the service at www.<domain name> would generally require that it be handled by the provider's main web server, while using a distinct server URI allows for it be handled as desired by the provider. Although there will no doubt be servers that implement the interface using Apache and Perl scripts, a more logical implementation would consist of a simple network interface to a key-and-value lookup mechanism, such as Berkeley DB. The URI form presented in Section 3.3 allows for maximum flexibility, since it will work with both web servers/CGI scripts and non-web-server-based network front-ends for certificate stores.
「よく知られた」ロケーションURIは、可能な限り柔軟なホスティングオプションをするように設計されています。プロバイダが望むようにそれを処理するためにURIが可能に個別のサーバーを使用しながら、WWWでのサービスの場所。<ドメイン名>一般的に、それはプロバイダのメインのWebサーバによって処理されることを必要とするであろう。間違いなくApacheとPerlのスクリプトを使用して、インターフェイスを実装するサーバは存在しませんが、より論理的な実装は、バークレーDBなど、キーと値のルックアップメカニズムへの単純なネットワークインタフェース、で構成されます。それは、証明書ストアのWebサーバ/ CGIスクリプトと非Webサーバベースのネットワークのフロントエンドの両方で動作しますので、3.3節で提示URIの形式は、最大の柔軟性を可能にします。
Implementations that require the use of nonstandard locations, ports, or HTTPS rather than HTTP in combination with "well-known" locations should use an HTTP redirect at the "well-known" location to point to the nonstandard location. For example, if the print spooler in Section 3.3 used an SSL-protected server named printspooler-server with an abs_path portion of cert_access, it would use an HTTP 302 redirect to https://printspooler-server/cert_access. This combines the plug-and-play capability of "well-known" locations with the ability to use nonstandard locations and ports.
「周知の」場所は、HTTPを使用すべきと組み合わせて、非標準の場所、ポート、またはHTTPSではなく、HTTPを使用する必要が実装が非標準の場所を指すように、「既知の」位置にリダイレクトします。セクション3.3で印刷スプーラがcert_accessの腹筋_経路部分とprintspoolerサーバ命名SSLで保護されたサーバーを使用した場合、例えば、それはHTTP 302を使用するHTTPSにリダイレクト：// printspoolerサーバ/ cert_access。これは、非標準の場所とポートを使用する能力を持つ「既知の」場所のプラグアンドプレイ機能を兼ね備えています。
The SIA and AIA extensions are used to indicate the location for the CRL store interface rather than the CRLDistributionPoint (CRLDP) extension, since the two perform entirely different functions. A CRLDP contains "a pointer to the current CRL", a fixed location containing a CRL for the current certificate, while the SIA/AIA extension indicates "how to access CA information and services for the subject/issuer of the certificate in which the extension appears", in this case, the CRL store interface that provides CRLs for any certificates issued by the CA. In addition, CRLDP associates other attribute information with a query that is incompatible with the simple query mechanisms presented in this document.
SIAおよびAIA拡張は、二つの全く異なる機能を実行するため、むしろCRLDistributionPoint（CRLDP）拡張よりCRLストアインターフェイスの位置を示すために使用されます。 SIA / AIA拡張は、拡張内の証明書のサブジェクト/発行者のCA情報とサービスにアクセスする方法」を示しながらCRLDPは、「現在のCRLへのポインタ」、現在の証明書のCRLを含む固定された位置を含みますCAによって発行された証明書のCRLを提供し、この場合には、」表示され、CRL店インタフェースまた、CRLDPは、この文書の単純なクエリメカニズムと互換性がないクエリと他の属性情報を関連付けます。
A single server can be used to handle both CRLDP and AIA/SIA queries provided that the CRLDP form uses an HTTP URI. Since CRLDP points to a single static location for a CRL, a query can be pre-constructed and stored in the CRLDP extension. Software that uses the CRLDP will retrieve the single CRL that applies to the certificate from the server, and software that uses the AIA/SIA can retrieve any CRL from the server. Similar pre-constructed URIs may also be useful in other circumstances (for example, for links on web pages) to place in appropriate locations like the issuerAltName, or even for technical support/helpdesk staff to email to users who can't find the certificate themselves, as described in Section 2.5. The resulting certstore URL, when clicked on by the user, will directly access the certificate when used in conjunction with any certificate-aware application, such as a browser or mail program.
単一のサーバはCRLDPとCRLDP形態がHTTP URIを使用することを提供AIA / SIAクエリの両方を処理するために使用することができます。 CRLのための単一の静的位置にCRLDPポイントは、クエリが事前に構築しCRLDP拡張に格納することができるからです。 CRLDPを使用するソフトウェアは、サーバからの証明書に適用され、AIA / SIAを使用するソフトウェアは、サーバからすべてのCRLを取得することができ、単一のCRLを取得します。同様の事前構築されたURIには、証明書を見つけることができないユーザーに電子メールで送信するissuerAltNameのような適切な場所で、あるいは技術サポート/ヘルプデスクのスタッフを配置する（例えば、Webページ上のリンクのための）他の状況で有用である可能性があります自分自身、2.5節で説明したように。すべての証明書対応のアプリケーションと組み合わせて使用する場合、ユーザーがクリックした結果としてのCertStore URLは、直接的なブラウザやメールプログラムとして、証明書にアクセスします。
Web-enabled (or, more strictly, HTTP-enabled) devices are intended to be plug-and-play, with minimal (or no) user configuration necessary. The "well-known" URI allows any known device (for example, one discovered via UPNP's Simple Service Discovery Protocol, SSDP) to be queried for certificates without requiring further user configuration. Note that in practice no embedded device would ever use the address given in the example (the de facto standard address for web-enabled embedded devices is 192.168.1.x and not 192.0.2.x); however, IETF policy requires the use of this non-address for examples.
（厳密または、HTTP対応）Web対応のデバイスが必要な最小限の（または全く）ユーザ設定で、プラグアンドプレイであることを意図しています。 「既知の」URIは、（例えば、UPNPの簡易サービス発見プロトコル、SSDPを介して発見されたもの）、任意の既知の装置は、さらに、ユーザ設定を必要とせずに証明書を照会することを可能にします。 （Web対応組み込み機器の事実上の標準アドレスは192.168.1.xのではなく192.0.2.xです）練習なし組み込みデバイスで、これまでの例で与えられたアドレスを使用することに注意してください。しかし、IETF方針は、例のために、この非アドレスを使用する必要があります。
Protocols such as UPnP have their own means of disseminating device and protocol information. For example, UPnP uses SOAP, which provides a GetPublicKeys action for pulling device keys and a PresentKeys action for pushing control point keys. The text in Section 3.3 is not meant to imply that this document overrides the existing UPnP mechanism, but merely that, if a device implements the mechanism described here, it should use the naming scheme in Section 3.3 rather than use arbitrary names.
UPnPなどのプロトコルは、デバイスとプロトコル情報を広める独自の手段を持っています。例えば、UPnPはデバイス鍵と制御ポイントキーを押すためPresentKeys作用を引っ張るGetPublicKeys作用を提供するSOAPを使用します。 3.3節のテキストは、この文書は、既存のUPnPメカニズムをオーバーライドすることを意味するものではないが、デバイスは、ここで説明するメカニズムを実装している場合、単にそれは、それは、3.3節で命名規則を使用してではなく、任意の名前を使用する必要があります。
HTTP caching proxies are common on the Internet, and some proxies may not check for the latest version of an object correctly. [RFC2616] specifies that responses to query URLs should not be cached, and most proxies and servers correctly implement the "Cache-Control: no-cache" mechanism, which can be used to override caching ("Pragma: no-cache" for HTTP 1.0). However, in the rare instance in which 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キャッシングプロキシは、インターネット上で共通しており、いくつかのプロキシは正しくオブジェクトの最新バージョンをチェックしない場合があります。 HTTPのために：（「キャッシュなしプラグマを」キャッシュオーバーライドするために使用することができますメカニズム、：[RFC2616]は、URLを照会するための応答がキャッシュされるべきではない、とほとんどのプロキシとサーバが正しく「キャッシュなしのCache-Control」を実装することを指定します1.0）。しかし、証明書やCRLのHTTPリクエストが誤って設定または他の方法で破損プロキシを経由した稀な例では、プロキシは、期限切れの応答を返すことができます。
Care should be taken to ensure that only valid queries are fed through to the back-end used to retrieve certificates. Allowing attackers to submit arbitrary queries may allow them to manipulate the certificate store in unexpected ways if the back-end tries to interpret the query contents. For example, if a certificate store is implemented using an RDBMS for which the calling application assembles a complete SQL string to perform the query, and the SQL query is built up as "SELECT certificate FROM certificates WHERE iHash = " + <search key>, and <search key> is set to "X;DELETE FROM certificates", the results of the query will be quite different from what was expected by the certificate store administrator. The same applies to queries by name and email address. Even a read-only query can be problematic; for example, setting <search key> to "UNION SELECT password FROM master.sysxlogins" will list all passwords in an SQL Server database (in an easily decrypted format) if the user is running under the sa (DBA) account. Straightforward sanitisation of queries may not be sufficient to prevent all attacks; for example, a filter that removes the SQL query string "DELETE" can be bypassed by submitting the string embedded in another instance of the string. Removing "DELETE" from "DELDELETEETE" leaves the outer "DELETE" in place. Abusing the truncation of over-long strings by filters can also be used as a means of attack, in which the attacker ensures that the truncation occurs in the middle of an escape sequence, bypassing the filtering. The use of parameterised queries (often called placeholders) that aren't vulnerable to SQL injection should be used to avoid these attacks.
ケアは、唯一の有効なクエリが証明書を取得するために使用されるバックエンドに介して供給されることを保証するために取られるべきです。攻撃者が任意のクエリを送信できるようにすると、バックエンドが問い合わせ内容を解釈しようとすると、彼らが予期しない方法で証明書ストアを操作することを可能にします。たとえば、証明書ストアは、呼び出し元のアプリケーションがクエリを実行するために、完全なSQL文字列を組み立てているためRDBMSを使用して実装され、そしてSQLクエリは+ <検索キー>「iHash =証明書から証明書を選択」として構築されている場合、そして、<検索キー>に設定されている「X;証明書。DELETE FROM」、クエリの結果は、証明書ストアの管理者によって予想されたものとは全く異なるものになります。同じ名前とメールアドレスでクエリに適用されます。でも、読み取り専用のクエリが問題となる可能性があります。例えば、設定<検索キー>は「master.sysxlogins FROM UNION SELECTパスワード」は、ユーザがSA（DBA）アカウントで実行されている場合（簡単に復号化された形式で）SQL Serverデータベース内のすべてのパスワードの一覧が表示されますします。クエリの簡単な消毒は、すべての攻撃を防ぐのに十分ではないかもしれません。例えば、SQLクエリ文字列を除去するフィルタは、文字列の別のインスタンスに埋め込まれた文字列を提出することによってバイパスすることができ、「削除します」。 「DELDELETEETE」から「削除」削除すると、外側に「DELETE」の場所を離れます。フィルタによるオーバー長い文字列の切り捨てを悪用する攻撃者は切り捨てがフィルタリングをバイパスして、エスケープシーケンスの途中で発生することを確実にした、攻撃の手段としても使用することができます。 SQLインジェクションの脆弱性ではありません（多くの場合、プレースホルダと呼ばれる）パラメータ化クエリを使用すると、これらの攻撃を回避するために使用する必要があります。
In addition, since some query data may be encoded/decoded before being sent to the back-end, applications should check both the encoded and decoded form for valid data. A simple means of avoiding these problems is to use parameterised commands rather than hand-assembling SQL strings for use in queries (this is also more efficient for most database interfaces). The use of parameterised commands means that the query value is never present in any position where it could be interpreted as a portion of the query command.
いくつかのクエリデータがバックエンドに送られる前に/復号化符号化することができるので、また、アプリケーションは、有効なデータのための符号化及び復号化形態の両方を確認しなければなりません。これらの問題を回避するための簡単な手段（これはまた、ほとんどのデータベース・インターフェースのためのより効率的である）クエリで使用するためのパラメータ化コマンドではなく、手組立SQL文字列を使用することです。パラメータ化コマンドを使用すると、クエリの値は、クエリコマンドの一部として解釈することができる任意の位置に存在することはないことを意味します。
Alongside filtering of queries, the back-end should be configured to disable any form of update access via the web interface. For Berkeley DB, this restriction can be imposed by opening the certificate store in read-only mode from the web interface. For relational databases, it can be imposed through the SQL GRANT/REVOKE mechanism, for example, "REVOKE ALL ON certificates FROM webuser. GRANT SELECT ON certificates TO webuser" will allow read-only access of the appropriate kind for the web interface. Server-specific security measures may also be employed; for example, the SQL Server provides the built-in db_datareader account that only allows read access to tables (but see the note above about what can be done even with read-only access) and the ability to run the server under a dedicated low-privilege account (a standard feature of Unix systems).
クエリのフィルタリングと一緒に、バックエンドは、ウェブインタフェースを介して更新アクセスの任意の形式を無効にするように構成されるべきです。バークレイDBのために、この制限は、Webインターフェイスから読み取り専用モードで証明書ストアを開くことによって課すことができます。リレーショナルデータベースでは、それはメカニズムをREVOKE / SQLのGRANTを通じて課すことができる、例えば、「のWebUserからの証明書のすべてを取り消します。GRANT SELECTいるwebuser TO証明書には、」読み取り専用ウェブインターフェースに対する適切な種類のアクセスを許可します。サーバ固有のセキュリティ対策を採用することもできます。たとえば、SQL Serverが提供する唯一のテーブルへの読み取りアクセスを許可するのdb_datareaderアカウントビルトイン（ただし、読み取り専用アクセスでも、何ができるかについて上記の注を参照）と、専用の低下のサーバーを実行する機能を特権アカウント（Unixシステムの標準機能）。
The mechanism described in this document is not intended to function as a trusted directory/database. In particular, users should not assume that just because they fetched a public key or certificate from an entity claiming to be X, that X has made any statement about the veracity of the public key or certificate. The use of a signed representation of the items stored removes the need to depend on the certificate store for any security service other than availability. Although it's possible to implement a trusted directory/database using HTTPS or some other form of secured/trusted link, this is a local policy/configuration issue, and in the absence of such additional security measures users should apply appropriate levels of verification to any keys or certificates fetched before they take them into use.
この文書で説明するメカニズムは、信頼できるディレクトリ/データベースとして機能するように意図されていません。具体的には、ユーザーは、Xは、公開鍵や証明書の真実性についての声明を発表したことを、Xであると主張するエンティティからの公開鍵や証明書をフェッチからといっていることを仮定するべきではありません。格納されているアイテムの署名表現の使用は、可用性以外の任意のセキュリティサービスの証明書ストアに依存する必要がなくなります。それがHTTPSを使用して、信頼できるディレクトリ/データベースまたはセキュリティで保護された/信頼されたリンクの他のいくつかのフォームを実装することは可能ですが、これはローカルポリシー/構成の問題であり、そのような追加のセキュリティ対策のユーザーが存在しない場合に任意のキーに検証の適切なレベルを適用すべきです彼らは使用にそれらを取る前に、または証明書が取り出されました。
No action by IANA is needed. The AIA/SIA accessMethod types are identified by object identifiers (OIDs) from an arc managed by the PKIX working group. Should additional accessMethods be introduced (for example, for attribute certificates or non-X.509 certificate types), the advocates for such accessMethods are expected to assign the necessary OIDs from their own arcs.
IANAによって必要なアクションはありません。 AIA / SIAたaccessMethodタイプはPKIXワーキンググループによって管理されるアークからのオブジェクト識別子（OID）によって識別されます。追加accessMethodsが導入されるべきである（例えば、属性証明書または非X.509証明書タイプのため）、などaccessMethodsのための支持者は、独自のアークから必要なOIDを割り当てることが期待されています。
Anders Rundgren, Blake Ramsdell, Jeff Jacoby, David Shaw, and members of the ietf-pkix working group provided useful input and feedback on this document.
アンダース・ラングレン、ブレイクRamsdell、ジェフ・ジャコビー、デビッド・ショー、そして、IETF PKIXワーキンググループのメンバーは、この文書に便利な入力とフィードバックを提供します。
[FIPS180] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
[FIPS180]連邦情報処理規格出版（FIPS PUBの）180-1、セキュアハッシュ標準、1995年4月17日。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440]カラス、J.、Donnerhacke、L.、フィニー、H.、およびR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、1998年11月。
[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"、RFC 2585、1999年5月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[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）"、RFC 2782、2000年2月。
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[RFC2854]コノリー、D.およびL. Masinter、 " 'text / htmlの' メディアの種類"、RFC 2854、2000年6月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156]エルキンズ、M.、デルTorto、D.、Levien、R.、およびT.レスラー、 "OpenPGPの持つMIMEセキュリティ"、RFC 3156、2001年8月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275]イーストレーク3、D.、Reagle、J.、およびD.ソロ "（拡張マークアップ言語）、XML署名の構文および処理"、RFC 3275、2002年3月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley氏、R.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley氏、R.、 "暗号メッセージ構文（CMS）"、RFC 3852、2004年7月。
[Birkholz] "Special Ops: Host and Network Security for Microsoft, Unix, and Oracle", Erik Birkholz et al, Syngress Publishing, November 2002.
[Birkholz] "特別オプス：ホストとマイクロソフト、Unixの、およびOracleのネットワークセキュリティ"、エリックBirkholzら、Syngress出版、2002年11月。
[Garcia-Molina] "Main Memory Database Systems", Hector Garcia-Molina and Kenneth Salem, IEEE Transactions on Knowledge and Data Engineering, Vol.4, No.6 (December 1992), p.509.
[ガルシア・モリーナ]「メインメモリデータベースシステム」、ヘクターガルシア - モリーナとケネス・セーラム、知識上のIEEEトランザクションとデータ工学、第4巻、第6号（1992年12月）、p.509。
[Gutmann] "A Reliable, Scalable General-purpose Certificate Store", P. Gutmann, Proceedings of the 16th Annual Computer Security Applications Conference, December 2000.
[Gutmann氏]「信頼性の高い、スケーラブルな汎用証明書ストア」、第16回コンピュータセキュリティアプリケーションのP. Gutmann氏、議事録会議、2000年12月。
[Heidemann] "Performance Interactions Between P-HTTP and TCP Implementations", J. Heidemann, ACM Computer Communications Review, April 1997.
[Heidemann] "P-HTTPおよびTCP実装間のパフォーマンスの相互作用"、J. Heidemann、ACMコンピュータコミュニケーションレビュー、1997年4月。
[HKP] "A PGP Public Key Server", Marc Horowitz, 2000, http://www.mit.edu/afs/net.mit.edu/project/pks/ thesis/paper/thesis.html. A more complete and up-to-date overview of HKP may be obtained from the source code of an open-source OpenPGP implementation such as GPG.
[HKP] "PGP公開鍵サーバ"、マーク・ホロウィッツ、2000、http://www.mit.edu/afs/net.mit.edu/project/pks/論文/紙/ thesis.html。 HKPのより完全で最新の概要は、GPGのようなオープンソースのOpenPGP実装のソースコードから得ることができます。
[Ji] "Affinity-based Management of Main Memory Database Clusters", Minwen Ji, ACM Transactions on Internet Technology, Vol.2, No.4 (November 2002), p.307.
[智]「主記憶データベースクラスタの親和性に基づく管理」、Minwen智、インターネット技術、第2巻、第4号（2002年11月）のACM取引、p.307。
[Krishnamurthy] "PRO-COW: Protocol Compliance on the Web - A Longitudinal Survey", Balachander Krishnamurthy and Martin Arlitt, Proceedings of the 3rd Usenix Symposium on Internet Technologies and Systems (USITS'01), March 2001, p.109.
[Krishnamurthy] "PRO-COW：Web上のプロトコル準拠 - 縦断調査"、Balachander Krishnamurthyとインターネット技術・システム上のマーティンArlitt、第三のUsenixシンポジウム（USITS'01）、2001年3月、P.109。
[Nielsen] "Network Performance Effects of HTTP/1.1, CSS1, and PNG", H.Nielsen, J.Gettys, A.Baird-Smith, E.Prud'hommeaux, H.Wium Lie, and C.Lilley, 24 June 1997, http://www.w3.org/Protocols/HTTP/ Performance/Pipeline.html
[ニールセン]、H.Nielsen、J.Gettys、A.Baird・スミス、E.Prud'hommeaux、H.Wium嘘、そしてC.Lilley、6月24日、 "HTTP / 1.1、CSS1、およびPNGのネットワークパフォーマンスの影響" 1997年、http://www.w3.org/Protocols/HTTP/パフォーマンス/ Pipeline.html
[PKCS11] PKCS #11 Cryptographic Token Interface Standard, RSA Laboratories, December 1999.
[PKCS11] PKCS＃11暗号トークンインターフェイス規格、RSA Laboratories社、1999年12月。
[PKCS15] PKCS #15 Cryptographic Token Information Syntax Standard, RSA Laboratories, June 2000.
[PKCS15] PKCS＃15暗号トークン情報構文規格、RSA Laboratories社、2000年6月。
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
"基板としてのHTTPの使用について" [RFC3205]ムーア、K.、BCP 56、RFC 3205、2002年2月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390]オールマン、M.、フロイド、S.、およびC.ヤマウズラ、 "増加するTCPの初期ウィンドウ"、RFC 3390、2002年10月。
[RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface (CGI) Version 1.1", RFC 3875, October 2004.
[RFC3875]ロビンソン、D.及びK. COAR、 "のCommon Gateway Interface（CGI）バージョン1.1"、RFC 3875、2004年10月。
[Spero] "Analysis of HTTP Performance Problems", S.Spero, July 1994, http://www.w3.org/Protocols/HTTP/1.0/ HTTPPerformance.html.
[スペロ] "HTTPパフォーマンスの問題の分析"、S.Spero、1994年7月、http://www.w3.org/Protocols/HTTP/1.0/ HTTPPerformance.html。
[UPNP] "Universal Plug and Play Device Architecture, Version 1.0", UPnP Forum, 8 June 2000.
[UPNP] "ユニバーサルプラグアンドプレイデバイスアーキテクチャ、バージョン1.0"、UPnPフォーラム、2000年6月8日。
Author's Address
著者のアドレス
Peter Gutmann University of Auckland Private Bag 92019 Auckland, New Zealand
オークランドプライベートバッグのピーター・ガットマン大学92019オークランド、ニュージーランド
EMail: pgut001@cs.auckland.ac.nz
メールアドレス：pgut001@cs.auckland.ac.nz
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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エディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。