datatracker.ietf.org
Sign in
Version 5.6.2.p2, 2014-07-24
Report a bug

PKIX over Secure HTTP (POSH)
draft-miller-posh-03

Document type: Replaced Internet-Draft (individual)
Document stream: No stream defined
Last updated: 2014-02-14 (latest revision 2013-11-12)
Intended RFC status: Unknown
Other versions: (expired, archived): plain text, pdf, html

Stream State:No stream defined
Document shepherd: No shepherd assigned

IESG State: Replaced by draft-ietf-xmpp-posh
Responsible AD: (None)
Send notices to: No addresses provided

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found here:
http://www.ietf.org/archive/id/draft-miller-posh-03.txt

Abstract

Experience has shown that it is extremely difficult to deploy proper PKIX certificates for TLS in multi-tenanted environments, since certification authorities will not issue certificates for hosted domains to hosting services, hosted domains do not want hosting services to hold their private keys, and hosting services wish to avoid liability for holding those keys. As a result, domains hosted in multi-tenanted environments often deploy non-HTTP applications such as email and instant messaging using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in obvious security implications. This document defines two methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. The first method enables the TLS client associated with a user agent or peer application server to obtain the end-entity certificate of a hosted domain over secure HTTP as an alternative to standard PKIX techniques. The second method enables a hosted domain to securely delegate a non-HTTP application to a hosting service using redirects provided by HTTPS itself or by a pointer in a file served over HTTPS at the hosted domain. While this approach is developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association prooftype, it can be applied to any non-HTTP application protocol.

Authors

Matthew Miller <mamille2@cisco.com>
Peter Saint-Andre <psaintan@cisco.com>

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid)