Internet Engineering Task Force (IETF) T. Kause
Request for Comments: 6712 SSH
Updates: 4210 M. Peylo
Category: Standards Track NSN
ISSN: 2070-1721 September 2012
Internet Engineering Task Force (IETF) T. Kause
Request for Comments: 6712 SSH
Updates: 4210 M. Peylo
Category: Standards Track NSN
ISSN: 2070-1721 September 2012
Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)
Internet X.509公钥基础设施--证书管理协议（CMP）的HTTP传输
Abstract
摘要
This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It is the "CMPtrans" document referenced in RFC 4210; therefore, this document updates the reference given therein.
本文档描述如何在HTTP上分层证书管理协议（CMP）。它是RFC 4210中引用的“CMPtrans”文件；因此，本文件更新了其中给出的参考。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6712.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6712.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. HTTP-Based Protocol .............................................3
3.1. HTTP Versions ..............................................4
3.2. Persistent Connections .....................................4
3.3. General Form ...............................................4
3.4. Media Type .................................................4
3.5. Communication Workflow .....................................5
3.6. HTTP Request-URI ...........................................5
3.7. Pushing of Announcements ...................................5
3.8. HTTP Considerations ........................................6
4. Implementation Considerations ...................................7
5. Security Considerations .........................................7
6. IANA Considerations .............................................8
7. Acknowledgments .................................................8
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. HTTP-Based Protocol .............................................3
3.1. HTTP Versions ..............................................4
3.2. Persistent Connections .....................................4
3.3. General Form ...............................................4
3.4. Media Type .................................................4
3.5. Communication Workflow .....................................5
3.6. HTTP Request-URI ...........................................5
3.7. Pushing of Announcements ...................................5
3.8. HTTP Considerations ........................................6
4. Implementation Considerations ...................................7
5. Security Considerations .........................................7
6. IANA Considerations .............................................8
7. Acknowledgments .................................................8
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
The Certificate Management Protocol (CMP) [RFC4210] requires a well-defined transfer mechanism to enable End Entities (EEs), Registration Authorities (RAs), and Certification Authorities (CAs) to pass PKIMessage sequences between them.
证书管理协议（CMP）[RFC4210]需要定义良好的传输机制，以使终端实体（EE）、注册机构（RAs）和证书颁发机构（CA）能够在它们之间传递PKI消息序列。
The first version of the CMP specification [RFC2510] included a brief description of a simple transfer protocol layer on top of TCP. Its features were simple transfer-level error handling and a mechanism to poll for outstanding PKI messages. Additionally, it was mentioned that PKI messages could also be conveyed using file-, E-mail-, and HTTP-based transfer, but those were not specified in detail.
CMP规范的第一个版本[RFC2510]简要描述了TCP之上的简单传输协议层。它的特点是简单的传输级错误处理和轮询未完成PKI消息的机制。此外，有人提到，也可以使用基于文件、电子邮件和HTTP的传输来传输PKI消息，但没有详细说明。
The current version of the CMP specification [RFC4210] incorporated its own polling mechanism, and thus the need for a transfer protocol providing this functionality vanished. The remaining features CMP requires from its transfer protocols are connection and error handling.
CMP规范[RFC4210]的当前版本包含了自己的轮询机制，因此不再需要提供此功能的传输协议。CMP传输协议所要求的其余功能是连接和错误处理。
Before this document was published as an RFC, the draft version underwent drastic changes during the long-lasting work process. The so-called "Direct TCP-Based Management Protocol" specified in [RFC2510] was enhanced, and at some point a version existed where this protocol was again transferred over HTTP. As both approaches proved to be needless and cumbersome, implementers preferred to use plain HTTP transfer following [RFC1945] or [RFC2616]. This document now reflects that by exclusively describing HTTP as the transfer protocol for CMP.
在本文件作为RFC发布之前，草案版本在长期的工作过程中经历了剧烈的变化。[RFC2510]中指定的所谓的“基于TCP的直接管理协议”得到了增强，并且在某个时候存在一个版本，该协议再次通过HTTP传输。由于这两种方法都被证明是不必要和麻烦的，所以实现者倾向于在[RFC1945]或[RFC2616]之后使用普通HTTP传输。本文档现在通过专门将HTTP描述为CMP的传输协议来反映这一点。
The usage of HTTP for transferring CMP messages exclusively uses the POST method for requests, effectively tunneling CMP over HTTP. While this is generally considered bad practice and should not be emulated, there are good reasons to do so for transferring CMP. HTTP is used as it is generally easy to implement and it is able to traverse network borders utilizing ubiquitous proxies. Most importantly, HTTP is already commonly used in existing CMP implementations. Other HTTP request methods, such as GET, are not used because PKI management operations can only be triggered using CMP's PKI messages, which need to be transferred using a POST request.
使用HTTP传输CMP消息专门使用POST方法进行请求，有效地通过HTTP隧道传输CMP。虽然这通常被认为是不好的做法，不应效仿，但有充分的理由这样做来转移CMP。HTTP的使用是因为它通常易于实现，并且能够利用无处不在的代理穿越网络边界。最重要的是，HTTP已经普遍用于现有的CMP实现中。其他HTTP请求方法（如GET）不使用，因为PKI管理操作只能使用CMP的PKI消息触发，需要使用POST请求传输这些消息。
With its status codes, HTTP provides needed error reporting capabilities. General problems on the server side, as well as those directly caused by the respective request, can be reported to the client.
HTTP通过其状态代码提供所需的错误报告功能。服务器端的一般问题以及由相应请求直接引起的问题可以报告给客户端。
As CMP implements a transaction ID, identifying transactions spanning over more than just a single request/response pair, the statelessness of HTTP is not blocking its usage as the transfer protocol for CMP messages.
由于CMP实现了一个事务ID，用于标识跨越多个请求/响应对的事务，因此HTTP的无状态状态不会阻止其作为CMP消息的传输协议的使用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
For direct interaction between two entities, where a reliable transport protocol like TCP is available, HTTP SHOULD be utilized for conveying CMP messages.
对于两个实体之间的直接交互，如果有可靠的传输协议（如TCP），则应使用HTTP来传输CMP消息。
Implementations MUST support HTTP/1.0 [RFC1945] and SHOULD support HTTP/1.1 [RFC2616].
实现必须支持HTTP/1.0[RFC1945]，并且应该支持HTTP/1.1[RFC2616]。
HTTP persistent connections [RFC2616] allow multiple interactions to take place on the same HTTP connection. However, neither HTTP nor the protocol specified in this document are designed to correlate messages on the same connection in any meaningful way; persistent connections are only a performance optimization. In particular, intermediaries can do things like mix connections from different clients into one "upstream" connection, terminate persistent connections, and forward requests as non-persistent requests, etc. As such, implementations MUST NOT infer that requests on the same connection come from the same client (e.g., for correlating PKI messages with ongoing transactions); every message is to be evaluated in isolation.
HTTP持久连接[RFC2616]允许在同一HTTP连接上进行多个交互。然而，无论是HTTP还是本文档中指定的协议，都不能以任何有意义的方式将同一连接上的消息关联起来；持久连接只是一种性能优化。特别是，中介可以将来自不同客户端的连接混合到一个“上游”连接中，终止持久性连接，并将请求作为非持久性请求转发等。因此，实现不能推断同一连接上的请求来自同一客户端（例如，用于将PKI消息与正在进行的交易关联）；每个消息都要单独评估。
A DER-encoded [ITU.X690.1994] PKIMessage [RFC4210] is sent as the entity-body of an HTTP POST request. If this HTTP request is successful, the server returns the CMP response in the body of the HTTP response. The HTTP response status code in this case MUST be 200; other "Successful 2xx" codes MUST NOT be used for this purpose. HTTP responses to pushed CMP Announcement messages (i.e., CA Certificate Announcement, Certificate Announcement, Revocation Announcement, and Certificate Revocation List (CRL) Announcement) utilize the status codes 201 and 202 to identify whether the received information was processed.
DER编码的[ITU.X690.1994]PKI消息[RFC4210]作为HTTP POST请求的实体体发送。如果此HTTP请求成功，服务器将在HTTP响应主体中返回CMP响应。在这种情况下，HTTP响应状态代码必须为200；其他“成功2xx”代码不得用于此目的。对推送的CMP公告消息（即CA证书公告、证书公告、撤销公告和证书撤销列表（CRL）公告）的HTTP响应利用状态代码201和202来识别是否处理了接收到的信息。
While "Redirection 3xx" status codes MAY be supported by implementations, clients should only be enabled to automatically follow them after careful consideration of possible security implications. As described in Section 5, "301 Moved Permanently" could be misused for permanent denial of service.
虽然实现可能支持“重定向3xx”状态代码，但只有在仔细考虑可能的安全影响后，才应启用客户端自动跟踪它们。如第5节所述，“301永久移动”可能被误用为永久拒绝服务。
All applicable "Client Error 4xx" or "Server Error 5xx" status codes MAY be used to inform the client about errors.
所有适用的“客户端错误4xx”或“服务器错误5xx”状态代码可用于通知客户端错误。
The Internet Media Type "application/pkixcmp" MUST be set in the HTTP Content-Type header field when conveying a PKIMessage.
传输PKI消息时，必须在HTTP内容类型标头字段中设置Internet媒体类型“application/pkixcmp”。
In CMP, most communication is initiated by the EEs where every CMP request triggers a CMP response message from the CA or RA.
在CMP中，大多数通信由EEs发起，其中每个CMP请求都会触发来自CA或RA的CMP响应消息。
The CMP Announcement messages described in Section 3.7 are an exception. Their creation may be triggered by certain events or done on a regular basis by a CA. The recipient of the Announcement only replies with an HTTP status code acknowledging the receipt or indicating an error, but not with a CMP response.
第3.7节中描述的CMP公告信息属于例外。它们的创建可能由某些事件触发，或由CA定期完成。公告的接收者仅回复HTTP状态码，以确认接收或指示错误，但不回复CMP响应。
If the receipt of an HTTP request is not confirmed by receiving an HTTP response, it MUST be assumed that the transferred CMP message was not successfully delivered to its destination.
如果未通过接收HTTP响应确认收到HTTP请求，则必须假定传输的CMP消息未成功传递到其目的地。
The Request-URI is formed as specified in [RFC3986].
请求URI的格式如[RFC3986]中所述。
A server implementation MUST handle Request-URI paths, with or without a trailing slash, as identical.
服务器实现必须处理相同的请求URI路径（带或不带尾随斜杠）。
An example of a Request-Line and a Host header field in an HTTP/1.1 header, sending a CMP request to a server, located in the "/cmp" path of the host "example.com", would be
HTTP/1.1报头中的请求行和主机报头字段的示例是，向位于主机“example.com”的“/CMP”路径中的服务器发送CMP请求
POST /cmp HTTP/1.1 Host: example.com
POST/cmp HTTP/1.1主机：example.com
or in the absoluteURI form
或者以绝对的形式
POST http://example.com/cmp/ HTTP/1.1
Host: example.com
POST http://example.com/cmp/ HTTP/1.1
Host: example.com
A CMP server may create event-triggered announcements or generate them on a regular basis. It MAY utilize HTTP transfer to convey them to a suitable recipient. In this use case, the CMP server acts as an HTTP client, and the recipient needs to utilize an HTTP server. As no request messages are specified for those announcements, they can only be pushed to the recipient.
CMP服务器可以创建或定期生成事件触发的公告。它可以利用HTTP传输将它们传送给合适的接收者。在这个用例中，CMP服务器充当HTTP客户机，接收方需要使用HTTP服务器。由于没有为这些公告指定请求消息，因此只能将它们推送到收件人。
If an EE wants to poll for a potential CA Key Update Announcement or the current CRL, a PKI Information Request using a General Message as described in Appendix E.5 of [RFC4210] can be used.
如果EE希望轮询潜在CA密钥更新公告或当前CRL，则可以使用[RFC4210]附录E.5中所述的一般消息的PKI信息请求。
When pushing Announcement messages, PKIMessage structures are sent as the entity-body of an HTTP POST request.
推送公告消息时，PKI消息结构作为HTTP POST请求的实体体发送。
Suitable recipients for CMP announcements might, for example, be repositories storing the announced information, such as directory services. Those services listen for incoming messages, utilizing the same HTTP Request-URI scheme as defined in Section 3.6.
例如，CMP公告的合适接收者可能是存储公告信息的存储库，例如目录服务。这些服务使用第3.6节中定义的相同HTTP请求URI方案侦听传入消息。
The following PKIMessages are announcements that may be pushed by a CA. The prefixed numbers reflect ASN.1 numbering of the respective element.
以下PKI消息是CA可能推送的公告。前缀数字反映了相应元素的ASN.1编号。
[15] CA Key Update Announcement
[16] Certificate Announcement
[17] Revocation Announcement
[18] CRL Announcement
[15] CA Key Update Announcement
[16] Certificate Announcement
[17] Revocation Announcement
[18] CRL Announcement
CMP Announcement messages do not require any CMP response. However, the recipient MUST acknowledge receipt with an HTTP response having an appropriate status code and an empty body. When not receiving such a response, it MUST be assumed that the delivery was not successful. If applicable, the sending side MAY try sending the Announcement again after waiting for an appropriate time span.
CMP公告消息不需要任何CMP响应。但是，收件人必须使用具有适当状态代码和空正文的HTTP响应确认收到。如果未收到此类回复，则必须假定交付未成功。如果适用，发送方可以在等待适当的时间跨度后再次尝试发送公告。
If the announced issue was successfully stored in a database or was already present, the answer MUST be an HTTP response with a "201 Created" status code and an empty message body.
如果已宣布的问题已成功存储在数据库中或已存在，则答案必须是带有“201已创建”状态代码和空消息正文的HTTP响应。
In case the announced information was only accepted for further processing, the status code of the returned HTTP response MAY also be "202 Accepted". After an appropriate delay, the sender may then try to send the Announcement again and may repeat this until it receives a confirmation that it has been successfully processed. The appropriate duration of the delay and the option to increase it between consecutive attempts should be carefully considered.
如果所宣布的信息仅被接受用于进一步处理，则返回的HTTP响应的状态代码也可以是“202已接受”。经过适当的延迟后，发送方可再次尝试发送公告，并可重复发送，直到收到已成功处理的确认。应仔细考虑延迟的适当持续时间以及在连续尝试之间增加延迟的选项。
A receiver MUST answer with a suitable 4xx or 5xx HTTP error code when a problem occurs.
出现问题时，接收器必须使用合适的4xx或5xx HTTP错误代码进行应答。
While all defined features of the HTTP protocol are available to implementations, they SHOULD keep the protocol utilization as simple as possible. For example, there is no benefit in using chunked Transfer-Encoding, as the length of an ASN.1 sequence is known when starting to send it.
虽然HTTP协议的所有已定义功能都可用于实现，但它们应使协议的使用尽可能简单。例如，使用分块传输编码没有任何好处，因为ASN.1序列的长度在开始发送时是已知的。
There is no need for the clients to send an "Expect" request-header field with the "100-continue" expectation and wait for a "100 Continue" status as described in Section 8.2.3 of [RFC2616]. The CMP payload sent by a client is relatively small, so having extra messages exchanged is inefficient, as the server will only seldom reject a message without evaluating the body.
客户端无需发送带有“100 continue”预期的“Expect”请求头字段，并等待[RFC2616]第8.2.3节所述的“100 continue”状态。客户端发送的CMP负载相对较小，因此交换额外的消息是低效的，因为服务器很少会在不评估消息体的情况下拒绝消息。
Implementors should be aware that implementations might exist that use a different approach for transferring CMP over HTTP, because this document has been under development for more than a decade. Further, implementations based on earlier drafts of this document might use an unregistered "application/pkixcmp-poll" MIME type.
实现者应该知道，可能存在使用不同方法通过HTTP传输CMP的实现，因为本文档已经开发了十多年。此外，基于本文档早期草稿的实现可能使用未注册的“应用程序/pkixcmp轮询”MIME类型。
The following aspects need to be considered by implementers and users:
实施者和用户需要考虑以下方面：
1. There is the risk for denial-of-service attacks through resource consumption by opening many connections to an HTTP server. Therefore, idle connections should be terminated after an appropriate timeout; this may also depend on the available free resources. After sending a CMP Error Message, the server should close the connection, even if the CMP transaction is not yet fully completed.
1. 通过打开与HTTP服务器的多个连接来消耗资源，存在拒绝服务攻击的风险。因此，空闲连接应在适当的超时后终止；这也可能取决于可用的免费资源。发送CMP错误消息后，服务器应关闭连接，即使CMP事务尚未完全完成。
2. Without being encapsulated in effective security protocols, such as Transport Layer Security (TLS) [RFC5246], there is no integrity protection at the HTTP protocol level. Therefore, information from the HTTP protocol should not be used to change state of the transaction.
2. 如果没有封装在有效的安全协议中，例如传输层安全性（TLS）[RFC5246]，HTTP协议级别就没有完整性保护。因此，不应使用来自HTTP协议的信息来更改事务的状态。
3. Client users should be aware that storing the target location of an HTTP response with the "301 Moved Permanently" status code could be exploited by a man-in-the-middle attacker trying to block them permanently from contacting the correct server.
3. 客户机用户应该知道，将HTTP响应的目标位置存储为“301永久移动”状态代码可能会被中间人攻击者利用，试图永久阻止他们联系正确的服务器。
4. If no measures to authenticate and protect the HTTP responses to pushed Announcement messages are in place, their information regarding the Announcement's processing state may not be trusted. In that case, the overall design of the PKI system must not depend on the Announcements being reliably received and processed by their destination.
4. 如果没有对推送公告消息的HTTP响应进行身份验证和保护的措施，则它们关于公告处理状态的信息可能不可信。在这种情况下，PKI系统的总体设计决不能依赖于目的地可靠地接收和处理公告。
5. CMP provides inbuilt integrity protection and authentication. The information communicated unencrypted in CMP messages does not contain sensitive information endangering the security of the PKI when intercepted. However, it might be possible for an eavesdropper to utilize the available information to gather confidential technical or business critical information. Therefore, users of the HTTP transfer for CMP might want to consider using HTTP over TLS according to [RFC2818] or virtual private networks created, for example, by utilizing Internet Protocol Security according to [RFC4301]. Compliant implementations MUST support TLS with the option to authenticate both server and client.
5. CMP提供内置完整性保护和身份验证。CMP消息中未加密的信息在被截获时不包含危及PKI安全的敏感信息。然而，窃听者可能利用现有信息收集机密的技术或业务关键信息。因此，针对CMP的HTTP传输的用户可能想要考虑根据[RCFC1818]或创建的虚拟专用网络使用HTTP在TLS上使用，例如，根据[RCF4301]利用因特网协议安全性。兼容的实现必须支持TLS，并提供对服务器和客户端进行身份验证的选项。
The IANA has already registered the MIME media type "application/ pkixcmp" for identifying CMP sequences due to an request made in connection with [RFC2510].
IANA已注册MIME媒体类型“application/pkixcmp”，用于识别与[RFC2510]相关的CMP序列。
No further action by the IANA is necessary for this document or any anticipated updates.
IANA无需对本文件或任何预期更新采取进一步行动。
Amit Kapoor and Ronald Tschlaer were the original authors of this document, and their version focused on the so-called "TCP-Based Management Protocol", which has been removed from this document. Their contact data, as originally stated by them, is as follows:
Amit Kapoor和Ronald Tschlaer是本文档的原始作者，他们的版本侧重于所谓的“基于TCP的管理协议”，该协议已从本文档中删除。他们最初陈述的联系方式如下：
Amit Kapoor Certicom 25801 Industrial Blvd Hayward, CA US Email: amit@trustpoint.com
美国加利福尼亚州海沃德工业大道25801号Amit Kapoor Certicom电子邮件：amit@trustpoint.com
Ronald Tschalaer Certicom 25801 Industrial Blvd Hayward, CA US Email: ronald@trustpoint.com
美国加利福尼亚州海沃德工业大道25801号Ronald Tschalaer Certicom电子邮件：ronald@trustpoint.com
The authors gratefully acknowledge the contributions of various members of the IETF PKIX working group and the ICSA CA-talk mailing list (a list solely devoted to discussing CMP interoperability efforts).
作者衷心感谢IETF PKIX工作组和ICSA CA talk邮件列表（仅用于讨论CMP互操作性工作的列表）各成员的贡献。
By providing ideas, giving hints, and doing invaluable review work, the following alphabetically listed individuals have significantly contributed to this document:
以下按字母顺序排列的个人通过提供想法、提供提示和进行宝贵的审查工作，为本文件做出了重大贡献：
Tomas Gustavsson, Primekey Peter Gutmann, University of Auckland Wolf-Dietrich Moeller, Nokia Siemens Networks
Tomas Gustavsson，Primekey Peter Gutmann，奥克兰大学沃尔夫迪特里希默勒，诺基亚西门子网络
[ITU.X690.1994] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 1994.
[ITU.X690.1994]国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）的规范”，ITU-T建议X.690，1994。
[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC1945]Berners Lee，T.，Fielding，R.，和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[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月。
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure Certificate Management Protocols", RFC 2510, March 1999.
[RFC2510]Adams，C.和S.Farrell，“互联网X.509公钥基础设施证书管理协议”，RFC25101999年3月。
[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月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4210]Adams，C.，Farrell，S.，Kause，T.，和T.Mononen，“互联网X.509公钥基础设施证书管理协议（CMP）”，RFC 42102005年9月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
Authors' Addresses
作者地址
Tomi Kause SSH Communications Security Takomotie 8 Helsinki 00380 Finland
Tomi Kause SSH通信安全Takomotie 8芬兰赫尔辛基00380
EMail: toka@ssh.com
EMail: toka@ssh.com
Martin Peylo Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Martin Peylo诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
EMail: martin.peylo@nsn.com
EMail: martin.peylo@nsn.com