One document matched: draft-ietf-pkix-cmp-http-00.txt

                  Using HTTP as a Transport Protocol for CMP
                      <draft-ietf-pkix-cmp-http-00.txt>


Status of this Memo

  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC2026.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that
  other groups may also distribute working documents as
  Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six
  months and may be updated, replaced, or obsoleted by other documents
  at any time.  It is inappropriate to use Internet- Drafts as
  reference material or to cite them other than as "work in progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.

  This Internet-Draft will expire on February 5, 2000


Copyright Notice

  Copyright (C)The Internet Society (1999). All Rights Reserved.


Abstract

  This document describes how to layer [CMP] over [HTTP]. A simple method
  for doing so is described in section 5.4 of [CMP], but that method does 
  not accommodate a polling mechanism, which may be required in some 
  environments. This document specifies an alternative method which uses 
  the polling protocol defined in section 5.2 of [CMP]. A new Content-Type 
  for messages is also defined.

  The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
  "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
  as shown) are to be interpreted as described in [RFC2119].


1. Motivation

  Section 5.4 of the CMP spec specifies sending the DER-encoded CMP
  message directly over HTTP. However, because the method described there 
  does not define a polling mechanism, the server is required to send a 
  final response immediately.  This may be impossible for environments in 
  which manual intervention is needed in the registration/certification 
  process (and, for practical reasons, a connection cannot be left open 
  indefinitely until the manual activity is complete). On the other hand, 
  section 5.2 of [CMP] defines a simple protocol over TCP that allows 
  polling. This protocol can be used over HTTP in a straightforward way, 
  solving the above problem and simplifying implementations that support 
  multiple protocols.


2. Specification

  A client creates a "direct TCP-based PKI message", henceforth referred
  to simply as "message", as specified in section 5.2 of [CMP]. The
  message is then sent as the entity-body of an HTTP POST request. If the
  HTTP request is successful then the server returns a similar message
  in the body of the response. The response status code in this case
  MUST be 200; other 2xx codes MUST NOT be used. The content type of the
  request and response MUST be "application/pkixcmp-poll". Content
  codings may be applied.

  Note that a server may return any 1xx, 3xx, 4xx, or 5xx code if the
  HTTP request needs further handling or is otherwise not acceptable.


3. Discussion

  The protocol defined in section 5.2 of [CMP] provides a means for
  letting the client poll for the response. It also defines a response
  for every request, which maps well onto HTTP's request-response
  nature. By using the exact same messages as section 5.2, client and
  server implementations that handle CMP messages over both TCP and HTTP
  are simplified.

  A new content type is introduced so as to avoid confusion with the
  protocol defined in section 5.4 of [CMP]. It is recommended that the 
  section 5.4 specification be phased out in favour of the one described in 
  this document.

  Because in general CMP message are not cacheable, requests and
  responses should include a "Cache-Control: no-cache" (and, if either
  side uses HTTP/1.0, a "Pragma: no-cache") to prevent the client from
  getting cached responses. This is especially important for polling
  requests and responses.


4. Security Considerations

  No new security considerations with respect to [CMP] are introduced.


References

  [CMP]     Adams, C., Farrell, S., "Internet X.509 Public Key 
            Infrastructure, Certificate Management Protocols", RFC 2510, 
            March 1999.

  [HTTP]    Fielding, R.T., et. al, "Hypertext Transfer Protocol --
            HTTP/1.1", RFC 2616, June 1999.

  [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
            Requirement Levels", RFC 2119, March 1997.


Authors' Addresses

  Amit Kapoor
  Trustpoint
  429 Castro Street, Suite B
  Mountain View, CA 94041
  US

  E-Mail: amit@trustpoint.com

  Ronald Tschal„r
  Trustpoint
  429 Castro Street, Suite B
  Mountain View, CA 94041
  US

  E-Mail: ronald@trustpoint.com

  Carlisle Adams
  Entrust Technologies
  750 Heron Road, Suite E08,
  Ottawa, Ontario
  Canada K1V 1A7

  E-Mail: cadams@entrust.com


Appendix A: Registration of MIME Type for Section 2

   To: ietf-types@iana.org
   Subject: Registration of MIME media type application/pkixcmp-poll

   MIME media type name: application

   MIME subtype name: pkixcmp-poll

   Required parameters: none

   Optional parameters: none

   Encoding considerations:
   Content may contain arbitrary octet values (the ASN.1 DER encoding of
   a PKI message, as defined in the IETF PKIX Working Group
   specifications).  base64 encoding is required for MIME e-mail; no
   encoding is necessary for HTTP.

   Security considerations:
   This MIME type may be used to transport Public-Key Infrastructure
   (PKI) messages between PKI entities.  These messages are defined by
   the IETF PKIX Working Group and are used to establish and maintain an
   Internet X.509 PKI.  There is no requirement for specific security
   mechanisms to be applied at this level if the PKI messages themselves
   are protected as defined in the PKIX specifications.

   Interoperability considerations: -

   Published specification: this document

   Applications which use this media type:
   Applications using certificate management, operational, or ancillary
   protocols (as defined by the IETF PKIX Working Group) to send PKI
   messages via e-mail or HTTP.

   Additional information:

     Magic number (s): -
     File extension (s): ".PKI"
     Macintosh File Type Code (s): -

   Person and email address to contact for further information:
   Carlisle Adams, cadams@entrust.com

   Intended usage: COMMON

   Author/Change controller: Carlisle Adams



Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.