[要約] RFC 4387は、HTTP経由で証明書ストアにアクセスするためのプロトコルを定義しています。このRFCの目的は、インターネット上での証明書の取得と管理を容易にすることです。
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
インターネットX.509公開キーインフラストラクチャ運用プロトコル：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).
Copyright（c）The Internet Society（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リポジトリからハイパーテキスト転送プロトコル（HTTP）、またはオプションでHTTPS、またはPKIリポジトリからの証明書取消リスト（CRL）を使用するための規則を指定します。このドキュメントの残りの部分を通して、一般的な用語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は、フラットファイル、バークレーDBやリレーショナルデータベースなどの標準データベース、従来のX.500/LDAPディレクトリなど、あらゆるタイプの証明書またはキーストアへの汎用的な透明なインターフェイスとして使用できます。一般的なアプリケーションには、Web対応のリレーショナルデータベース（ほとんどのデータベースがそうです）またはSimple {key、value} lookupメカニズムなどの使用が含まれます。
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].
「必須」、「「必須」、「必須」、「は」、「はない」、「必要」、「推奨」、「5月」、および「オプション」は、[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 ]]
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
query = attribute '='値
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（失効URI）からCRLから取得されます。これらは、同じ証明書ストアやサーバーに対応する場合と対応する場合と対応する場合があります（正確な解釈はローカル構成の問題です）。クエリ値は、Form-Urlencoded Media Type [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.
複数の証明書がクエリと一致する場合、マルチパート/混合応答として返す必要があります。返されたデータは逐語的に返される必要があります。HTTPレベルで追加のコンテンツまたは転送エンコードを使用してはなりません（たとえば、Base64または引用プリント可能なテキストとして圧縮またはエンコードすることはできません）。実装は、応答でチャンクされたエンコードを使用しないでください。
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クエリで直接使用するのに適していません。それらを使用可能にするために、処理オプションが「ハッシュ」であるフィールドは、最初に固定長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.
「ハッシュ」は、SHA-1 [FIPS180]を使用して160ビット値を生成し、次に続くBase64エンコードステップを続行します。
"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エンコードを使用してバイナリ値をエンコードして、「base64」を27バイトのテキストのみの値を生成します。20バイト値のbase64エンコードは28バイトを生成し、最後のバイトは常に「=」パディング文字になります。27バイト値は、Trailing '='文字を削除することで作成されます。
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).
バイナリ値が20バイトSHA-1出力（たとえば、64ビット/8バイトPGPキーIDの場合）よりも小さいまたは大きい場合、最終値は、後続の「=」パディングを削除することによって作成されます。バイナリ値のエンコード（これは上記のケースの一般化です）。
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エンコード値に、「z」、「 ' - ' z '、' 0」 - '9'、 ''、および '。他の文字を含むクエリは拒否する必要があります。（この要件の詳細については、セクション2.5の実装ノートとセクション4のセキュリティに関する考慮事項を参照してください。）
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で説明したプロセスによって検索キーに変換されます。値は正確な一致のためにチェックされていることに注意してください（これが必要な場合は、任意のフォームウルンコード[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.
IHASH HASH検索キーは、証明書、CRL、またはその他のオブジェクトに表示されるDERエンコード発行者DNから派生しました。
iAndSHash Hash Search key derived from the certificate's DER-encoded issuerAndSerialNumber [RFC3852].
証明書のderエンコードされた発行済みの発行担当者[RFC3852]から派生したiandshash hash検索キー。
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.
Shash Hash検索キーは、証明書または他のオブジェクトに表示されるDer-Encoded DNから派生したものです。
sKIDHash Hash Search key derived from the certificate's subjectKeyIdentifier (specifically the contents octets of the KeyIdentifier OCTET STRING).
Skidhash Hash Searchキーは、証明書の件名KeyDeyIdentifier（特にKeyIdentifier Octet Stringのコンテンツオクテット）から派生しました。
Certificate URIs MUST support retrieval by all the above attribute types.
証明書URISは、上記のすべての属性タイプによる検索をサポートする必要があります。
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 URISは、CRLの発行者を識別するIHASHおよびSkidhash属性タイプによる検索をサポートする必要があります。さらに、CRL URISは、発行済みDistributionPoint拡張の使用によって必要とされる場合に対して、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].
KeyID 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.
Key URIは、上記のすべての属性タイプによって検索をサポートする必要があります。
Revocation URIs MUST support retrieval by the fingerprint and keyID attribute types, which identify the issuer of the key revocation.
取り消しURISは、主要な取り消しの発行者を識別する指紋およびKeyID属性タイプによる検索をサポートする必要があります。
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> child Elementに関連付けることを許可するため、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.
長年の条約により、証明書のurisはスキーム仕様なしで与えられます。たとえば、SSL/TLSサーバー証明書にはhttps://www.example.comではなくwww.example.comが含まれ、S/Mime証明書にはmailto：user@example.comではなくuser@example.comが含まれます。。このコンベンションは他のURIタイプにも拡張されているため、（効果的な）uris im：user@example.comおよびxmpp：user@example.comを含む証明書は、単一のuri user@example.comを使用して照会されます。その後、証明書ストアはこのURIを含むすべての証明書を返し、クライアントに使用して使用するのに最も適しているものを決定します。このアプローチは、最も一般的なURIタイプにはスキーマ仕様（上記の段落を参照）がなく、意図した使用が何であるかを判断する簡単な方法がないためです（SSL/TLSサーバー証明書はSSL/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.
提案されているもう1つの可能な識別子は、IPアドレスまたはDNS名です。これは、Web対応の埋め込みデバイスに必要です。これは、たとえば、ホームオートメーションコントローラーが制御するデバイスの証明書をクエリすることを可能にするために必要です。この値はデバイスのCNと見なされているため、一般的な実践は、Webサーバー証明書がCNをサーバーのDNS名に設定するのと同じように、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が必要とする輸送エンコード以外）。これは、文字セットの翻訳、空白の取り扱い、その他の問題による問題を回避するために、これらのデータ項目の正確なコピーを転送する標準的な実装慣行に従います。
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.
ハッシュは、長さを管理しやすくするために、完全なフィールドの代わりにDNSを含むDNSを含む任意の長さのフィールドに使用されます。さらに、ハッシュされたフォームの使用は、構造化された名前データを検索することはサポートされている機能ではないことを強調しています。これは、x.500ディレクトリへのHTTPインターフェイスではなく、{key、value}証明書ストアへの単純なインターフェイスであるためです。特に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をエンコードしていました。残念ながら、この形式の文字列はBase64形式の有効な文字列でもあり、0XABCDRFなどの近いミスは、160個のIDでの誤った試みまたは有効なBase64 IDのいずれかである可能性があるという事実によってさらに複雑です。このため、一貫性を確保するために、この仕様全体でbase64 IDが使用されます。内部で使用される検索キーはバイナリ値になるため、これらがASCII-HEXまたは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.
属性には、長さを合理的に保つために、短縮名フォーム（たとえば、発行者の代わりに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.
識別子の属性値部分は、RAWデータがセキュリティリスクをもたらすことを許可するため、無効な文字を慎重にチェックする必要があります。たとえば、SQLクエリが「ihash = "<検索キー>」として「証明書から選択された証明書を選択する」として構築されるRDBMSを使用して実装された証明書/公開キーストアを検討してください。<search key>が「ABCD;証明書から削除」に設定されている場合、クエリの結果は、証明書ストア管理者が予想したものとはまったく異なります。読み取り専用クエリでさえ問題がある場合があります。たとえば、<search key>を「master.sysxloginsから[パスワードを選択]に設定します」は、ユーザーが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」から「削除」を削除すると、外側の「削除」が所定の位置にあります。フィルターによる長い文字列の切り捨てを乱用することも攻撃の手段として使用でき、攻撃者は脱出が脱出シーケンスの中央で発生することを保証し、フィルタリングをバイパスします。理論的には再帰的なフィルタリングが役立つ場合がありますが、SQL注入に対して脆弱ではないパラメーター化されたクエリ（多くの場合、プレースホルダーと呼ばれることが多い）の使用は、これらの攻撃を回避するために使用する必要があります。データベースのバックエンドの保護に関する詳細については、[Birkholz]に記載されており、Sanitationと安全性の懸念に関するコメントは、セキュリティ上の考慮事項セクションにあります。
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).
固定された検索基準に一致する証明書/公開キーを取得する事前に構成されたURIは、Webページや名刺などのアイテム、またはユーザーに郵送したいが証明書を見つけることができないテクニカルサポート/ヘルプデスクスタッフに役立つ場合があります彼ら自身。これらの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、Berkeley db、またはrdbmsとして）は、バックエンドとして採用されます。この仕様は、テクノロジーニュートラルであるために意図的に書かれており、{key、value}ルックアップメカニズムを使用できるようにします。メソッドが正しい応答を合理的な効率で提供できる限り、チンパンジーをテーブルの本で検索することを選択することを選択したかどうかは関係ありません。
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.
PGPは、キー情報と取り消し情報を単一のデータオブジェクトに組み合わせて、同じURIからのパブリックキーと取り消し情報の両方を返すことができるようにします。個別のキーと取り消しサーバーが利用可能である場合、取り消し情報を取得する必要がないため、これらはわずかなパフォーマンスゲインを提供できます。別々のサーバーが使用できない場合、単一のサーバーを使用して、失効情報を取得することで失効データに関連付けられている公開キーデータも取得するため、わずかなパフォーマンス損失で両方のタイプのクエリを満たすことができます。
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.
エキゾチックなエンコードフォームの不許可は、ほとんどのクライアント（および多くのサーバー、特に組み込みデバイスの場合）であるという事実を反映しています。主要な管理アプリケーション。言い換えれば、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.
「Accept-Encoding：Identity」ヘッダーの使用は、追加のエンコーディングを許可することと同じ効果を達成し、[RFC2616]のセクション14.3がこのヘッダーの欠如が、エンコードがあることを意味する可能性があることを示しているため、実際に有用である可能性があります。許可されています。ただし、これは潜在的にパフォーマンスに影響を与える方法でHTTPヘッダーを不必要に肥大化します（セクション2.5.5を参照）。一方、追加の装飾なしで返されるという要件を確立すると、各リクエストでこれを指定する必要がなくなります。したがって、実装は、受け入れエンコードヘッダーを完全に省略するか、それを含めなければならない場合は、「アイデンティティ」または容認されたコンテンツエンコードタイプとして「ワイルドカード」*「*」を含める必要があります。
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.
チャンクされたエンコードの使用は、[RFC2616]で必要とされるため、必須ではなく、必須ではないはずではありません。それにもかかわらず、この形式のエンコードは、データ量が転送される（1-2kb）により完全に不要になるため、このエンコードフォームのサポートはさまざまな実装バグに対して脆弱であり、その一部はセキュリティに影響を与える可能性があります。ただし、実装者は、Apache Webサーバーの多くのバージョンが、応答を返すときにチャンクされたエンコードを不必要に使用することに注意する必要があります。これを必須ではないことをお勧めしますが、これにより、世界で最も広く使用されている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証明書チェーン（証明書のみを含む縮退した署名データ）ではなく、マルチパート/混合として返されます。追加の利点は、このアクセスメカニズムをDERベースのデータに制限しないため、XML、PGP、SPKIなどの他の証明書タイプに拡張できることです。
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インターフェイス[Garcia-Molina]の間に挿入される場合があります。メインメモリデータベースは、オンディスクデータベースと同じ機能を提供し、HTTPフロントエンドに完全に透過的ですが、メモリレジデントデータ用に最適化されたバッファ管理および検索施設を提供します。さらにスケーラビリティが必要な場合、コンテンツキャッシングシステムは、メインメモリデータベース[JI]のクラスターとして実装できます。
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 MSSが通常、LAN（イーサネット）で1460バイトまたはWAN上の512/536バイトであるため、HTTPヘッダーはMSSよりもはるかに少ない〜200〜300バイトであるためです。HTTPメッセージが最初に送信されると、TCP輻輳ウィンドウは1つのセグメントで始まり、TCPはスロースタートし、ACKごとにサイズを2倍にします。ヘッダーを個別に送信すると、1つの短いセグメントと2番目のMSSサイズのセグメントが送信されると、TCPスタックは継続する前にレスポンダーのACKを待ちます。レスポンダーは両方のセグメントを取得し、その後、レスポンダーデータでそれをピギーバックすることを期待して200msのACKを遅らせます。その結果、送信された各メッセージに200ms（Assorted 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.
最大の効率を提供するために考慮する必要がある他のさまざまな考慮事項があります。これらは他の場所で深さで覆われています[spero] [heidemann] [nielsen]。さらに、4K初期ウィンドウ[RFC3390]の使用など、TCPの動作の変更（小さなHTTP転送時間を単一のRTTに短縮するように設計）も、これらの問題のいくつかを改善するはずです。
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実装はとにかくこれを行います）、およびHTTPヘッダーは、TCP MSS内にデータを適合しようとするために最小限に抑えます。たとえば、このプロトコルには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.
HTTPの基質としての使用に関する懸念が提起されています[RFC3205]。ここで説明するメカニズムは、従来の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サーバーは、フラットファイル、Berkeley DB、およびPostgresやMySQLなどのさまざまなデータベースを使用して実装されています。
To convert the subject DN C=NZ, O=... CN=Fred Dagg into a search key:
被験者をdn c = nz、o = ... cn = fred daggを検索キーに変換するには：
Hash the DN, in the DER-encoded form it appears in the certificate, to obtain
dnをハッシュして、derエンコードされた形式で証明書に表示され、取得するために
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:
Base-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のABS_PATH部分であり、リクエストはクエリ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
Alternatively, if chaining is by key identifier:
または、チェーンがキー識別子による場合：
<Extract the keyIdentifier from the authorityKeyIdentifier>
GET /search.cgi?sKIDHash=<search key> HTTP/1.1
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
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
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>（キーの文字列識別子が含まれています）は次のとおりです。
<KeyName KeyID="sHash">lkxwxB7JCOXKRSUQ1sgoOhrB3+I</KeyName>.
<keyname keyid = "shash"> lkxwxb7jcoxkrsuq1sgoohrb3 i </keyname>。
In order to locate servers from which certificates may be retrieved, relying parties can employ one or more of the following strategies:
証明書が取得されるサーバーを見つけるために、頼る当事者は次の1つ以上の戦略を採用できます。
- 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:
依存関係者への有名な情報アクセスを伝えるために、CASは証明書でsubjectinfoaccess（sia）とauthoridinfoaccess（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.
対応するアクセスロケーションはクエリURIです。この施設の使用は、たとえば認証パスの建設目的で、さらなる証明書がどこにあるかを示すために、便利な標準的な場所を備えたCAを提供します。証明書ストアアクセスサービスの提供がCASのみに限定されているという意味ではないことに注意してください。
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 Rococationストアの名前は「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:
domain example.comを備えたCAがHTTP証明書ストアインターフェイスを介して証明書を利用可能にする場合、サーバーの詳細は次のように検索することで取得できます。
_certificates._tcp.example.com
_certificates._tcp.example.com
and
と
_crls._tcp.example.com
_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は、取得する情報の種類（「証明書」、「crls」、「pgpkeys」、または "pgprevocations。」）をドメイン名に準備することにより構築され、ドメイン名のnet_loc部分を取得します。URI、および固定されたABS_PATH部分「Search.CGI」を追加することにより。したがって、「よく知られている」場所のURI形式は次のとおりです。
certificates.<domain_name>/search.cgi
crls.<domain_name>/search.cgi
pgpkeys.<domain_name>/search.cgi
pgprevocations.<domain_name>/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]。これは、かなり非効率的な実装につながるため、ルールではなく例外です。実装の代替手段を1つだけ提供するだけです（これについては、詳細については、理論的根拠を参照してください）。
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:
2番目のケースは、ユニバーサルプラグアンドプレイデバイス[UPNP]などのWeb対応の組み込みデバイスによって証明書アクセスサービスが提供されているときに発生します。これらのデバイスには、単一の固定NET_LOC（IPアドレスまたはDNS名のいずれか）があり、HTTPインターフェイスを介してサービスを利用できるようにします。この場合、URIは、PGPパブリックキーのCRLSの「CRLS/SEARCH.CGI」、「CRLS/SEARCH.CGI」の証明書「CRLS/SEARCH.CGI」に固定されたABS_PATH部分「証明書/SEARCH.CGI」を追加することにより構築されます。search.cgi "net_locへのpgp取消情報について。したがって、「よく知られている」場所のURI形式は次のとおりです。
<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:
Domain example.comを備えたCAがHTTP証明書ストアインターフェイスを介して証明書を利用可能にする場合、証明書とCRLの「よく知られている」クエリURIが次のとおりです。
http://certificates.example.com/search.cgi http://crls.example.com/search.cgi
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
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証明書/公開キー/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です。残念ながら、このタイプのハンドホールディングを必死に必要としているユーザーグループが使用するオペレーティングシステムは、最も基本的なDNSアドレスルックアップを超えたものをサポートしていないため、ごく最近のWin2KおよびXPシステム以外のDNS SRVを使用することは不可能です。物事をさらに面白くするために、機能名と関数パラメーターのいくつかは、開発のWin2Kフェーズのさまざまな時期に変更され、Windows Sockets APIの部分の動作は、文書化されていない方法で変更されました。これは、UNIX Sysadminが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または「よく知られている」ロケーションオプションは、現在知られているパラメーターからユーザーソフトウェアによって自動的に導出されることがよくあります。たとえば、受信者のメールアドレスが @example.comの場合、ユーザーソフトウェアは_certificates._tcp.example.comを照会するか、証明書に移動してexample.comに移動して証明書をリクエストします。さらに、ユーザーソフトウェアは、既知のCAリストがWebブラウザーによって維持される方法で、既知の証明書ソースのリストを維持する場合があります。セクション2のリダイレクトのサポートに関する具体的な言及は、多くのサイトが証明書の保存タスクを外部委託することを強調しています。最悪の場合、必要なのは、実際のサーバーを指す単一の静的Webページを追加することだけです。DNS CNAME RRSなどの代替案も可能ですが、HTTPリダイレクトほどセットアップするのは簡単ではない場合があります（企業ポリシーは、DNS構成を変更するよりもWebページのコンテンツに関してより柔軟になる傾向があります）。
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は、ホスティングオプションを可能な限り柔軟にするように設計されています。www。<domain name>でサービスを見つけると、通常、プロバイダーのメインWebサーバーが処理する必要がありますが、異なるサーバーURIを使用すると、プロバイダーが望むように処理できます。ApacheおよびPerlスクリプトを使用してインターフェイスを実装するサーバーは間違いありませんが、より論理的な実装は、Berkeley DBなどのキーと価値のルックアップメカニズムへの単純なネットワークインターフェイスで構成されます。セクション3.3に示されているURIフォームは、証明書ストアのWebサーバー/CGIスクリプトと非Webサーバーベースのネットワークフロントエンドの両方で動作するため、最大限の柔軟性を可能にします。
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ではなく、標準以外の場所、ポート、またはHTTPを使用する必要がある実装では、「よく知られている」場所でHTTPリダイレクトを使用して標準以外の場所を指す必要があります。たとえば、セクション3.3の印刷スプーラーが、CERT_ACCESSのABS_PATH部分を持つPrintSpooler-Serverという名前のSSL保護サーバーを使用した場合、https 302リダイレクトをhttps：// printspooler-server/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拡張機能は、2つがまったく異なる関数を実行するため、CRLDISTRISTPOINT（CRLDP）拡張ではなく、CRLストアインターフェイスの位置を示すために使用されます。CRLDPには「現在のCRLへのポインター」が含まれています。現在の証明書のCRLを含む固定場所、SIA/AIA拡張は「拡張証明書の主題/発行者のCA情報とサービスにアクセスする方法を示しています。この場合、CA。さらに、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フォームがHTTP URIを使用している場合、CRLDPとAIA/SIAの両方のクエリの両方を処理するために単一のサーバーを使用できます。CRLDPはCRLの単一の静的位置を指しているため、クエリを事前に構築してCRLDP拡張機能に保存できます。CRLDPを使用するソフトウェアは、サーバーから証明書に適用される単一のCRLを取得し、AIA/SIAを使用するソフトウェアはサーバーからCRLを取得できます。同様の事前に構築されたURISは、他の状況（たとえば、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.
Web対応（または、より厳密には、HTTP対応）デバイスは、最小限の（またはなし）ユーザー構成が必要なプラグアンドプレイを目的としています。「よく知られている」URIでは、既知のデバイス（たとえば、UPNPのSimple Service Discovery Protocol、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はSOAPを使用します。これは、デバイスキーを引くためのGetPublickeysアクションと、コントロールポイントキーを押すためのプレゼントキーアクションを提供します。セクション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キャッシュプロキシはインターネット上で一般的であり、一部のプロキシは、オブジェクトの最新バージョンを正しくチェックしない場合があります。[RFC2616]クエリURLへの応答をキャッシュしてはならず、ほとんどのプロキシとサーバーは、キャッシュをオーバーライドするために使用できる「キャッシュコントロール：キャッシュなし」メカニズムを正しく実装することを指定します（httpの「プラグマ：ノーキャッシュ」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 = <search key>、および "証明書から証明書を選択し、<検索キー>は「x;証明書から削除」に設定されています。クエリの結果は、証明書ストア管理者が予想したものとはまったく異なります。同じことが、名前とメールアドレスによるクエリにも当てはまります。読み取り専用クエリでさえ問題がある場合があります。たとえば、<search key>を「master.sysxloginsからのユニオン選択パスワード」に設定すると、ユーザーがSA（DBA）アカウントで実行されている場合、SQL Serverデータベース（簡単に復号化された形式）にすべてのパスワードがリストされます。クエリの簡単な消毒は、すべての攻撃を防ぐのに十分ではないかもしれません。たとえば、SQLクエリ文字列「削除」を削除するフィルターは、文字列の別のインスタンスに埋め込まれた文字列を送信することでバイパスできます。「deldeleteete」から「削除」を削除すると、外側の「削除」が所定の位置にあります。フィルターによる長い文字列の切り捨てを乱用することは、攻撃の手段としても使用できます。攻撃者は、フィルタリングをバイパスして、脱出シーケンスの中央で切り捨てが発生することを保証します。これらの攻撃を回避するために、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).
クエリのフィルタリングに加えて、バックエンドは、Webインターフェイスを介して任意の形式の更新アクセスを無効にするように構成する必要があります。Berkeley DBの場合、この制限は、Webインターフェイスから読み取り専用モードで証明書ストアを開くことで課すことができます。リレーショナルデータベースの場合、たとえば「Webuuserからの証明書のすべてを取り消します。Webuserへの証明書の選択」を使用すると、SQL Grant/Recokeメカニズムを介して課すことができます。サーバー固有のセキュリティ対策も採用される場合があります。たとえば、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が公開キーまたは証明書の真実性について声明を出したと想定すべきではありません。保存されているアイテムの署名された表現を使用すると、空室状況以外のセキュリティサービスに対して証明書ストアに依存する必要性が削除されます。HTTPまたは他の形式のセキュリティ/信頼できるリンクを使用して信頼できるディレクトリ/データベースを実装することは可能ですが、これはローカルポリシー/構成の問題であり、そのような追加のセキュリティ対策がない場合、ユーザーは任意のキーに適切なレベルの検証を適用する必要がありますまたは、それらを使用する前にフェッチされた証明書。
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ワーキンググループが管理するARCのオブジェクト識別子（OID）によって識別されます。追加のAccessMethodを導入した場合（たとえば、属性証明書やX.509以外の証明書の種類について）、そのようなAccessMethodの支持者は、独自のアークから必要な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.
Anders Rundgren、Blake Ramsdell、Jeff Jacoby、David Shaw、およびIETF-PKIXワーキンググループのメンバーは、このドキュメントに関する有用な入力とフィードバックを提供しました。
[FIPS180] Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
[FIPS180]連邦情報処理標準出版（FIPS Pub）180-1、Secure Hash Standard、1995年4月17日。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440] Callas、J.、Donnerhacke、L.、Finney、H。、およびR. Thayer、「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. Hoffman、「インターネット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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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] Connolly、D。およびL. Masinter、「The "Text/HTML 'Media Type"、RFC 2854、2000年6月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156] Elkins、M.、Del Torto、D.、Levien、R。、およびT. Roessler、「OpenPGPを使用したMime Security」、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] EastLake 3rd、D.、Reagle、J。、およびD. Solo、 "（拡張可能なマークアップ言語）XML-Signature構文と処理"、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.、Polk、W.、Ford、W.、およびD. Solo、「インターネット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] "Special Ops：Microsoft、Unix、およびOracleのホストとネットワークセキュリティ"、Erik Birkholz et al、Syngress Publishing、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.
[Garcia-Molina]「メインメモリデータベースシステム」、Hector Garcia-MolinaおよびKenneth Salem、IEEE Transactions on Knowledge and Data Engineering、Vol.4、No.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]「信頼できるスケーラブルな汎用証明書ストア」、P。ガットマン、2000年12月、第16回年次コンピューターセキュリティアプリケーション会議の議事録。
[Heidemann] "Performance Interactions Between P-HTTP and TCP Implementations", J. Heidemann, ACM Computer Communications Review, April 1997.
[Heidemann]「P-HTTPとTCP実装の間のパフォーマンスの相互作用」、J。Heidemann、ACM Computer Communications Review、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公開キーサーバー」、Marc Horowitz、2000、http：//www.mit.edu/afs/net.mit.edu/project/pks/ thesis/paper/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.
[JI]「メインメモリデータベースクラスターのアフィニティベースの管理」、Minwen JI、ACM Transactions on Internet Technology、Vol.2、No.4（2002年11月）、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：Protocol Compliance on the Web-縦断的調査」、Balachander Krishnamurthy and Martin Arlitt、2001年3月、インターネット技術とシステムに関する第3回Usenixシンポジウム（USITS'01）の議事録、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
[Nielsen] "HTTP/1.1、CSS1、およびPNGのネットワークパフォーマンス効果"、H.Nielsen、J.Gettys、A.Baird-Smith、E.Prud'Hommeaux、H.Wium Lie、およびC.Lilley、6月24日1997、http：//www.w3.org/protocols/http/ performance/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.
[RFC3205]ムーア、K。、「基質としてのHTTPの使用について」、BCP 56、RFC 3205、2002年2月。
[RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 3390, October 2002.
[RFC3390] Allman、M.、Floyd、S。、およびC. Partridge、「TCPの初期ウィンドウの増加」、RFC 3390、2002年10月。
[RFC3875] Robinson, D. and K. Coar, "The Common Gateway Interface (CGI) Version 1.1", RFC 3875, October 2004.
[RFC3875] Robinson、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.
[Spero]「HTTPパフォーマンスの問題の分析」、S.Spero、1994年7月、http：//www.w3.org/protocols/http/1.0/ httppperformance.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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。