doc: Add RFC documents

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]
+