Network Working Group P. Gutmann, Ed.
Request for Comments: 4387 University of Auckland
Category: Standards Track February 2006
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
Internet 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).
版权所有（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.
本文档中描述的协议约定满足Internet公钥基础设施（PKI）的一些操作要求。本文档指定了使用超文本传输协议（HTTP/HTTPS）作为从PKI存储库获取证书和证书吊销列表（CRL）的接口机制的约定。解决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
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）多部分标准的一部分。本文档指定了使用超文本传输协议（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获取证书，而静态URL不提供任何证书存储的通用接口功能。本文档中描述的约定允许HTTP用作任何类型证书或密钥存储的通用透明接口，包括平面文件、标准数据库（如Berkeley DB和关系数据库）以及传统的X.500/LDAP目录。典型的应用程序包括使用支持web的关系数据库（大多数数据库都是这样）或简单的{key，value}查找机制，如Berkeley 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].
本文件中的关键词“必须”、“不得”、“必需”、“应该”、“不应该”、“建议”、“可能”和“可选”应按照[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:" "//" 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查询部分的参数是一个证书或密钥标识符，由属性类型和一个值组成，该值指定从查询返回的一个或多个证书或公钥：
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].
从一个URI（证书URI）检索证书和公钥，从另一个URI（吊销URI）检索CRL。这些可能与同一证书存储和/或服务器对应，也可能与之不对应（确切的解释是本地配置问题）。查询值必须使用URL编码媒体类型[RFC2854]的格式进行编码。[RFC2616]中给出了URI构造、大小限制和其他因素的更多详细信息。
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查询中直接使用。为了使它们可用，处理选项为“Hash”的字段首先散列到固定长度的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字节的值是通过删除尾随的“=”字符创建的。
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编码值是否仅包含范围为“a'-'z”、“a'-'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节所述的过程转换为搜索键。注意，检查值是否精确匹配（在解码任何形式的URLC2554编码的[RFC2854]部分后，如果有必要），因此区分大小写。
Attribute Process Value
--------- ------- -----
certHash Hash Search key derived from the SHA-1 hash of the
certificate (sometimes called the certificate
fingerprint or thumbprint).
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哈希搜索键，从证书、CRL或其他对象中显示的DER编码的颁发者DN派生。
iAndSHash Hash Search key derived from the certificate's DER-encoded issuerAndSerialNumber [RFC3852].
从证书的DER编码颁发者序列号[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).
sKIDHash哈希搜索键派生自证书的subjectKeyIdentifier（特别是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必须支持iHash和sKIDHash属性类型的检索，它们标识CRL的颁发者。此外，CRL URI可能支持通过certHash和iAndHash属性类型进行检索，这是使用issuingDistributionPoint扩展所必需的。CRL查询必须返回具有最大thisUpdate值的匹配CRL（换句话说，最近的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.
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位PGP密钥ID[RFC2440]。
name None User name associated with the key.
name None与密钥关联的用户名。
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必须支持通过指纹和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>子元素相关联，因此使用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标识符类型指定与给定Internet安全协议的证书预期用途相关联的标识符。例如，SSL/TLS服务器证书将包含服务器的DNS名称（传统上也指定为CommonName或CN），s/MIME证书将包含主题的电子邮件地址；IPsec证书将包含DNS名称或IP地址；SIP证书将包含一个SIPURI。在决定一个合适的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".
出于历史原因，可以追溯到它作为查找用户/MIME电子邮件证书的主要用途，一些客户端可能会将URI属性名称指定为“email”而不是“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
根据长期的约定，证书中的URI是在没有方案说明符的情况下给出的。例如，SSL/TLS服务器证书将包含www.example.com而不是https://www.example.com，并且S/MIME证书将包含user@example.com而不是邮寄：user@example.com. 此约定也扩展到其他URI类型，因此包含（有效）URI im的证书：user@example.com和xmpp：user@example.com将使用单个URI进行查询user@example.com. 然后，证书存储将返回包含此URI的所有证书，将其留给客户端以确定哪个证书最适合其使用。之所以采用这种方法，是因为对于最常见的URI类型，没有模式说明符（请参见上面的段落），也没有简单的方法来确定预期用途（SSL/TLS服务器证书）
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.
仅由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.
另一个可能的标识符是IP地址或DNS名称，这对于支持web的嵌入式设备是必需的。这是必要的，以允许例如家庭自动化控制器查询其控制的设备的证书。由于此值被视为设备的CN，通常的做法是将此值用于CN的方式与web服务器证书将CN设置为服务器的DNS名称的方式相同，因此此选项已被广泛接受。
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的字段，以代替完整字段，以保持长度可管理。此外，使用哈希形式强调搜索结构化名称数据不是受支持的功能，因为这是{key，value}证书存储的简单接口，而不是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传统上使用C样式0xABCDEF表示法对ID进行编码，该表示法基于PGP2.0中用于ID的显示格式。不幸的是，此格式的字符串也是base64格式的有效字符串，由于0xABCDRF等未遂事件可能是在十六进制ID或有效base64 ID上输入错误，因此更加复杂。因此，为了确保一致性，在整个规范中都使用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
这些属性使用缩写名称形式（例如，用iAndSHash代替issuerAndSerialNumberHash）以保持长度合理，或使用通用名称形式（例如，用电子邮件代替issuerAndSerialNumberHash）
rfc822Name, rfc822Mailbox, emailAddress, mail, or email) where multiple name forms exist.
RFC822名称、RFC822邮箱、电子邮件地址、邮件或电子邮件），其中存在多个姓名表单。
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.
应仔细检查标识符的属性值部分是否存在无效字符，因为允许原始数据存在安全风险。例如，考虑使用RDBMS实现的证书/公钥存储，其中SQL查询被构建为“从证书中选择证书，其中IHASH= = ++Simulink KEY”。如果将<search key>设置为“ABCD；从证书中删除”，则查询结果将与证书存储管理员预期的结果大不相同。即使是只读查询也可能有问题；例如，如果用户在sa（DBA）帐户下运行，将<search key>设置为“UNION SELECT password FROM master.sysxlogins”将列出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查询字符串“DELETE”的筛选器可以通过提交嵌入该字符串的另一个实例中的字符串来绕过。从“DELDELETEETE”中删除“DELETE”将保留外部的“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).
获取与固定搜索条件匹配的证书/公钥的预构造URI可能对网页或名片等项目有用，甚至对希望向用户发送邮件但自己找不到证书的技术支持/帮助台人员也有用。这些URI还可用于在分发证书时强制实施隐私措施，方法是以仅证书/公钥存储或证书存储和用户知道的方式（换句话说，通过将URI转换为功能）干扰搜索密钥。例如，可以指示具有新颁发证书的用户使用密钥“x-encrCertHash=…”获取证书，该密钥由证书存储解密以获取适当的证书，从而确保只有证书所有者可以在证书颁发后立即获取其证书。类似地，不想公开查询其证书的组织可能需要MAC on搜索密钥（例如，“x-macCertHash=…”），以确保只有授权用户才能搜索证书（如果使用真正的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接口，而且是允许任意证书/公钥存储机制的通用检索机制（偏向于简单的{key，value}存储，无论是作为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，可以使用根据其包含的数据定制的机制来实现这两个存储。
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
PGP将密钥和吊销信息合并到一个数据对象中，这样就可以从同一URI返回公钥和吊销信息。如果可以使用不同的密钥和吊销服务器，那么它们可以提供轻微的性能提升，因为获取吊销信息不需要获取它所应用的密钥。如果没有单独的服务器可用，则
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.
由于获取撤销信息也将获取与撤销数据相关联的公钥数据，因此可以使用单个服务器来满足这两种类型的查询，但性能会略有损失。
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.
使用“Accept encoding:identity”（接受编码：标识）标头将达到与禁止任何额外编码相同的效果，并且可能确实有用，因为[RFC2616]第14.3节指出，缺少此标头可能意味着允许任何编码。但是，这会以可能影响性能的方式（参见第2.5.5节）不必要地膨胀HTTP头，而建立响应返回而无需任何额外修饰的要求可以避免在每个请求中指定这一点。因此，实现应该完全省略Accept encoding标头，或者如果必须包含它，则将“identity”或通配符“*”作为可接受的内容编码类型。
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）使其完全不必要，并且对这种编码形式的支持容易受到各种实现错误的影响，其中一些可能会影响安全性。但是，实现者应该知道，许多版本的ApacheWeb服务器在返回响应时将不必要地使用分块编码。尽管最好将此设置为“不得”，但这会使拒绝它的客户端与世界上使用最广泛的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
多个响应以多部分/混合而不是ASN.1证书序列或PKCS#7/CMS证书链（仅包含证书的退化签名数据）的形式返回，因为这是
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.
使用支持web的标准工具实现更简单。另一个优点是，它不会将这种访问机制限制为基于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.
在实现此证书/公钥分发机制时，需要考虑各种网络效率因素。例如，执行两次写入（HTTP头和证书，分别写入）然后执行读取的过于简单的实现将与TCP延迟ACK和缓慢启动严重交互。这是因为TCP MSS在LAN（以太网）上通常为1460字节，或在WAN上为512/536字节，而HTTP头约为200-300字节，远小于MSS。第一次发送HTTP消息时，TCP拥塞窗口从一个段开始，TCP慢速开始，然后每个ACK的大小加倍。单独发送报头将发送一个短段和第二个MSS大小段，因此TCP堆栈将在继续之前等待响应者的确认。响应程序获取这两个段，然后将其ACK延迟200ms，希望将其装载在响应程序数据上，而响应程序数据永远不会发送，因为它仍在等待来自启动器的HTTP正文的其余部分。因此，发送的每条消息都有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.
为了提供最大效率，还需要考虑其他各种因素。其他地方[Spero][Heidemann][Nielsen]对此进行了深入讨论。此外，对TCP行为的修改，如使用4K初始窗口[RFC3390]（旨在将较小的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,
最佳性能的经验法则是将HTTP头和数据有效负载组合成一次写入（任何合理的HTTP实现都会这样做，这要归功于HTTP服务器性能调优方面的大量经验），并将HTTP头保持在最小值，以尝试将数据放入TCP MSS中。例如，由于该协议不涉及web浏览器，
there's no need to include various common browser-related headers such as ones detailing software versions or acceptable languages.
不需要包括各种与浏览器相关的常见标题，例如详细说明软件版本或可接受语言的标题。
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.
本文档中指定的接口是一种基本的只读类型，大多数客户端都将使用它。更新（插入和删除）的处理是一个涉及两个技术问题的复杂问题（用于索引和信息检索的各种字段需要以技术中立的方式指定，或者证书存储需要对添加的项执行自己的解析，将其从接近通用的key=值查找机制移动到完整的公钥/证书处理系统）和政治性字段（谁可以执行证书存储的更新，以及在什么条件下？）。由于这一复杂性，任何潜在更新机制的详细信息都将作为本地配置问题保留，但如果有足够的需求，可能在将来的文档中会涉及这些细节。
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 GET，而不是在HTTP之上分层新协议），并且在标准文档中指定了定义良好的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带来的一个好处是广泛的实施经验，这表明这是一个非常可行的解决方案，可以解决简单的证书/公钥检索机制的问题。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将匕首插入搜索键：
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:
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_路径部分，请求被提交到位于查询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
<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
<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
<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
<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基，因此上述两个查询看起来相同（因为未显示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>.
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:
为了定位可从中检索证书的服务器，依赖方可以采用以下一种或多种策略：
- 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应在证书中使用SubjectInfo access（SIA）和AuthorityInfoAccess（AIA）扩展[RFC3280]。accessMethod的OID值为以下值之一：
id-ad-http-certs OBJECT IDENTIFIER ::= { id-ad 6 }
id-ad-http-crls OBJECT IDENTIFIER ::= { id-ad 7 }
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 }
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存储接口的名称应为“crls”。PGP公钥存储的名称应为“pgpkeys”。PGP撤销存储的名称应为“pgprevocations”。按照[RFC2782]处理额外的DNS SRV设施，如优先级和权重字段。
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
_证书。_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是通过在域名前面加上要检索的信息类型（“certificates.”、“crls.”、“pgpkeys.”或“PgpPreocations.”）来构造的，以获取URI的net_loc部分，并通过附加固定的abs_路径部分“search.cgi”来构造的。因此，“已知”位置的URI形式为：
certificates.<domain_name>/search.cgi
crls.<domain_name>/search.cgi
pgpkeys.<domain_name>/search.cgi
pgprevocations.<domain_name>/search.cgi
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]。这将是一个例外，而不是规则，因为它将导致相当低效的执行；它只提供了一种可能的（而且设置起来相对简单）实现备选方案（请参阅关于这方面的更多信息的基本原理）。
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:
第二种情况发生在证书访问服务由支持web的嵌入式设备（如通用即插即用设备[UPNP]）提供时。这些设备有一个固定的网络地址（IP地址或DNS名称），并通过HTTP接口提供服务。在这种情况下，URI是通过将证书的固定abs_路径部分“certificates/search.cgi”、crls的固定abs_路径部分“crls/search.cgi”、PGP公钥的固定abs_路径部分“pgpkeys/search.cgi”以及PGP撤销信息的固定abs_路径部分“pgpreocations/search.cgi”附加到net_loc来构建的。因此，“已知”位置的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
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存储的accessLocation可以在客户端本地配置。如果没有其他可用信息，或者需要覆盖其他信息，则可以使用此选项。
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系统管理员可以使用DNS SRV来避免处理技术配置问题，但Windows的95用户却不能。由于这些问题，在无法使用DNS SRV的情况下，提供了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
SRV或“已知”位置选项通常可由用户软件根据当前已知参数自动导出。例如，如果收件人的电子邮件地址为@example.com，则用户软件将查询\u certificates.\u tcp.example.com或转到certificates.example.com并请求证书。此外，用户软件可以以web浏览器维护已知CA列表的方式维护已知证书源的列表。第2节中特别提到了对重定向的支持，强调许多站点将证书存储任务外包。最糟糕的情况是，只需要添加一个指向真实服务器的静态网页。DNS CNAME RRs等替代方案也是可能的，但可能不像HTTP重定向那样容易设置（公司策略通常是
more flexible in regard to web page contents than modifying DNS configurations would be).
在网页内容方面比修改DNS配置更灵活）。
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则允许提供商根据需要处理服务。虽然使用Perl和Berkeley这样的简单网络接口来实现查找，但毫无疑问，使用Perl和Berkeley这样的逻辑接口会有一个更简单的实现。第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.
需要使用非标准位置、端口或HTTPS而不是HTTP与“已知”位置结合使用的实现应该在“已知”位置使用HTTP重定向来指向非标准位置。例如，如果第3.3节中的打印后台处理程序使用名为printspooler server的SSL保护服务器，该服务器具有证书访问的abs_路径部分，则它将使用HTTP 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扩展用于指示CRL存储接口的位置，而不是CRLDistributionPoint（CRLDP）扩展，因为两者执行完全不同的功能。CRLDP包含“指向当前CRL的指针”，一个包含当前证书CRL的固定位置，而SIA/AIA扩展指示“如何访问扩展出现在其中的证书主体/颁发者的CA信息和服务”，CRL存储接口，为CA颁发的任何证书提供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
如果CRLDP表单使用HTTP URI，则可以使用单个服务器处理CRLDP和AIA/SIA查询。由于CRLDP指向CRL的单个静态位置，因此可以预先构造查询并将其存储在CRLDP扩展中。使用CRLDP的软件将从服务器检索应用于证书的单个CRL，而使用AIA/SIA的软件可以从服务器检索任何CRL。类似的预构造URI在其他应用程序中也可能有用
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.
如第2.5节所述，在适当的位置（例如，网页上的链接）放置诸如ISSUERATNAME，甚至技术支持/帮助热线工作人员向自己找不到证书的用户发送电子邮件。当用户单击生成的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的简单服务发现协议（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操作来拉取设备键，以及一个PresentKeys操作来推送控制点键。第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缓存代理在Internet上很常见，有些代理可能无法正确检查对象的最新版本。[RFC2616]指定不应缓存对查询URL的响应，并且大多数代理和服务器正确地实现了“缓存控制：无缓存”机制，该机制可用于覆盖缓存（“HTTP 1.0的Pragma:no Cache”）。但是，在极少的情况下，证书或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
应注意确保只有有效的查询被反馈到用于检索证书的后端。如果后端试图解释查询内容，允许攻击者提交任意查询可能会使他们以意外的方式操纵证书存储。例如，如果证书存储是使用RDBMS实现的，则调用应用程序将为其组装一个完整的SQL字符串以执行查询，并且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.
查询建立为“从证书中选择证书，其中iHash=“+<search key>”，并且<search key>设置为“X；从证书中删除”，查询结果将与证书存储管理员预期的结果大不相同。这同样适用于按姓名和电子邮件地址进行的查询。即使是只读查询也可能有问题；例如，如果用户在sa（DBA）帐户下运行，将<search key>设置为“UNION SELECT password FROM master.sysxlogins”将列出SQL Server数据库中的所有密码（以易于解密的格式）。直接清除查询可能不足以防止所有攻击；例如，删除SQL查询字符串“DELETE”的筛选器可以通过提交嵌入该字符串的另一个实例中的字符串来绕过。从“DELDELETEETE”中删除“DELETE”将保留外部的“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).
除了过滤查询外，还应将后端配置为通过web界面禁用任何形式的更新访问。对于Berkeley DB，可以通过从web界面以只读模式打开证书存储来施加此限制。对于关系数据库，它可以通过SQL GRANT/REVOKE机制强制执行，例如，“从webuser吊销所有证书。将SELECT ON证书授予webuser”将允许对web界面进行适当类型的只读访问。还可以采用服务器特定的安全措施；例如，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
本文档中描述的机制不打算用作受信任的目录/数据库。特别是，用户不应该仅仅因为从声称是X的实体获取了公钥或证书，就认为X对公钥或证书的真实性做出了任何声明。符号的使用
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.
存储项的表示消除了除可用性之外的任何安全服务都依赖于证书存储的需要。虽然可以使用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访问方法类型由PKIX工作组管理的arc中的对象标识符（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.
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，安全哈希标准，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 24401998年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，“Internet X.509公钥基础设施操作协议：FTP和HTTP”，RFC 25851999年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.，弗莱斯蒂克，H.，马斯特，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 SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[RFC2854]Connolly，D.和L.Masinter，“文本/html”媒体类型”，RFC 28542000年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安全性”，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签名语法和处理”，RFC 32752002年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 32802002年4月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852]Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[Birkholz] "Special Ops: Host and Network Security for Microsoft, Unix, and Oracle", Erik Birkholz et al, Syngress Publishing, November 2002.
[Birkholz]“特别行动：Microsoft、Unix和Oracle的主机和网络安全”，Erik 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.
[Garcia Molina]“内存数据库系统”，Hector Garcia Molina和Kenneth Salem，《IEEE知识与数据工程学报》，第4卷，第6期（1992年12月），第509页。
[Gutmann] "A Reliable, Scalable General-purpose Certificate Store", P. Gutmann, Proceedings of the 16th Annual Computer Security Applications Conference, December 2000.
[Gutmann]“一个可靠、可扩展的通用证书存储”，P.Gutmann，第16届计算机安全应用年会论文集，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公钥服务器”，Marc Horowitz，2000年，http://www.mit.edu/afs/net.mit.edu/project/pks/ 论文/paper/thesis.html。可以从开源OpenPGP实现（如GPG）的源代码中获得对HKP更完整和最新的概述。
[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]“基于亲和力的主存数据库集群管理”，季民文，互联网技术ACM交易，第2卷，第4期（2002年11月），第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：网络协议合规性——纵向调查”，Balachander Krishnamurthy和Martin Arlitt，第三届Usenix互联网技术和系统研讨会论文集（USITS'01），2001年3月，第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] "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
[PKCS11] PKCS #11 Cryptographic Token Interface Standard, RSA Laboratories, December 1999.
[PKCS11]PKCS#11加密令牌接口标准，RSA实验室，1999年12月。
[PKCS15] PKCS #15 Cryptographic Token Information Syntax Standard, RSA Laboratories, June 2000.
[PKCS15]PKCS#15加密令牌信息语法标准，RSA实验室，2000年6月。
[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[RFC3205]Moore，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]奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC3390，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，“公共网关接口（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/ 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
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。