GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc6712

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6712.txt · Last modified: 2012/09/11 00:01 (external edit)