summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6712.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6712.txt')
-rw-r--r--doc/rfc/rfc6712.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc6712.txt b/doc/rfc/rfc6712.txt
new file mode 100644
index 0000000..f787a08
--- /dev/null
+++ b/doc/rfc/rfc6712.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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)
+
+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.
+
+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.
+
+ 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.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ 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.
+
+
+
+
+
+
+Kause & Peylo Standards Track [Page 1]
+
+RFC 6712 CMPtrans September 2012
+
+
+ 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.
+
+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
+
+ 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.
+
+ 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.
+
+
+
+
+
+Kause & Peylo Standards Track [Page 2]
+
+RFC 6712 CMPtrans September 2012
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+2. Conventions Used in This Document
+
+ 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].
+
+3. HTTP-Based Protocol
+
+ For direct interaction between two entities, where a reliable
+ transport protocol like TCP is available, HTTP SHOULD be utilized for
+ conveying CMP messages.
+
+
+
+Kause & Peylo Standards Track [Page 3]
+
+RFC 6712 CMPtrans September 2012
+
+
+3.1. HTTP Versions
+
+ Implementations MUST support HTTP/1.0 [RFC1945] and SHOULD support
+ HTTP/1.1 [RFC2616].
+
+3.2. Persistent Connections
+
+ 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.
+
+3.3. General Form
+
+ 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.
+
+ 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.
+
+ All applicable "Client Error 4xx" or "Server Error 5xx" status codes
+ MAY be used to inform the client about errors.
+
+3.4. Media Type
+
+ The Internet Media Type "application/pkixcmp" MUST be set in the HTTP
+ Content-Type header field when conveying a PKIMessage.
+
+
+
+
+
+Kause & Peylo Standards Track [Page 4]
+
+RFC 6712 CMPtrans September 2012
+
+
+3.5. Communication Workflow
+
+ In CMP, most communication is initiated by the EEs where every CMP
+ request triggers a CMP response message from the CA or RA.
+
+ 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.
+
+ 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.
+
+3.6. HTTP Request-URI
+
+ The Request-URI is formed as specified in [RFC3986].
+
+ A server implementation MUST handle Request-URI paths, with or
+ without a trailing slash, as identical.
+
+ 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
+
+ POST /cmp HTTP/1.1
+ Host: example.com
+
+ or in the absoluteURI form
+
+ POST http://example.com/cmp/ HTTP/1.1
+ Host: example.com
+
+3.7. Pushing of Announcements
+
+ 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.
+
+ 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.
+
+
+
+
+
+Kause & Peylo Standards Track [Page 5]
+
+RFC 6712 CMPtrans September 2012
+
+
+ When pushing Announcement messages, PKIMessage structures are sent as
+ the entity-body of an HTTP POST request.
+
+ 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.
+
+ The following PKIMessages are announcements that may be pushed by a
+ CA. The prefixed numbers reflect ASN.1 numbering of the respective
+ element.
+
+ [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.
+
+ 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.
+
+ 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.
+
+ A receiver MUST answer with a suitable 4xx or 5xx HTTP error code
+ when a problem occurs.
+
+3.8. HTTP Considerations
+
+ 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.
+
+
+
+
+
+Kause & Peylo Standards Track [Page 6]
+
+RFC 6712 CMPtrans September 2012
+
+
+ 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.
+
+4. Implementation Considerations
+
+ 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.
+
+5. Security Considerations
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Kause & Peylo Standards Track [Page 7]
+
+RFC 6712 CMPtrans September 2012
+
+
+ 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.
+
+6. IANA Considerations
+
+ The IANA has already registered the MIME media type "application/
+ pkixcmp" for identifying CMP sequences due to an request made in
+ connection with [RFC2510].
+
+ No further action by the IANA is necessary for this document or any
+ anticipated updates.
+
+7. Acknowledgments
+
+ 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
+ Certicom
+ 25801 Industrial Blvd
+ Hayward, CA
+ US
+ Email: amit@trustpoint.com
+
+ Ronald Tschalaer
+ Certicom
+ 25801 Industrial Blvd
+ Hayward, CA
+ US
+ Email: 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).
+
+
+
+
+Kause & Peylo Standards Track [Page 8]
+
+RFC 6712 CMPtrans September 2012
+
+
+ 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
+
+8. References
+
+8.1. Normative References
+
+ [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.
+
+ [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
+ Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key
+ Infrastructure Certificate Management Protocols", RFC
+ 2510, March 1999.
+
+ [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.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC
+ 3986, January 2005.
+
+ [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
+ "Internet X.509 Public Key Infrastructure Certificate
+ Management Protocol (CMP)", RFC 4210, September 2005.
+
+8.2. Informative References
+
+ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+
+
+
+Kause & Peylo Standards Track [Page 9]
+
+RFC 6712 CMPtrans September 2012
+
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+Authors' Addresses
+
+ Tomi Kause
+ SSH Communications Security
+ Takomotie 8
+ Helsinki 00380
+ Finland
+
+ EMail: toka@ssh.com
+
+
+ Martin Peylo
+ Nokia Siemens Networks
+ Linnoitustie 6
+ Espoo 02600
+ Finland
+
+ EMail: martin.peylo@nsn.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kause & Peylo Standards Track [Page 10]
+