Skip to main content

Shepherd writeup
draft-ietf-xmpp-posh

PROTO Shepherd Writeup for draft-ietf-xmpp-posh

Shepherd writeup for draft-ietf-xmpp-posh-04

1. Summary

The document shepherd is Dave Cridland.

The responsible Area Director is Ben Campbell.

This document defines the "PKIX over Secure HTTP (POSH)" prooftype, to
be used as part of the XMPP Domain Name Assertion (DNA) framework. From
the abstract:

"Experience has shown that it is extremely difficult to deploy proper
PKIX certificates for TLS in multi-tenanted environments.  As a result,
domains hosted in such environments often deploy applications 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.  While these methods developed for use in the
Extensible Messaging and Presence Protocol (XMPP) as a Domain Name
Association (DNA) prooftype, they might also be usable in other non-HTTP
application protocols."

The XMPP working group believes that this technology is ready for wider
implementation, and would benefit from interoperability testing.
Therefore we request the document to be published as a "Proposed
Standard".

2. Review and Consensus

The XMPP working group is chartered to provide a solution to allow a
hosting service to share an XMPP server among multiple hosted domains.
That effort produced the Domain Name Assertion (DNA) framework, which is
still a work-in-progress at the time of this writing. POSH was
originally proposed in 2012 as a prooftype for the DNA framework.

During discussion in XMPP, it became apparent that POSH might have more
general applicability. There was a POSH BoF in the Security area at IETF
87. While there was recognition that POSH could be generally useful,
there was no consensus to expand the effort beyond the needs of XMPP.
Therefore POSH was adopted as an XMPP work item, with the idea that we
would make it as general as we reasonable could without bogging down the
work, but that we would not attempt to meet the specific requirements
for applications other than XMPP.

The  chairs believe POSH has reached a broad consensus in XMPP. There
has been considerable review in XMPP, and in the Security area due to
the BoF. POSH does not need targeted reviews beyond the usual Gen-ART,
SecDir, etc reviews.

Reviews have concentrated primarily on clarifying the specification rather
than altering how it works. Some members of the working group (including
an author) have expressed the opinion that this is a stopgap technology rather
than a long-term plan.

At the time of this writing, the shepherd is aware of two experimental
implementations which have not been deployed - however various implementors
of XMPP have expressed some interest, and some are in progress.

3. Intellectual Property

There are no IPR disclosures on this document. The authors have
explicitly indicated that they are not aware of any undisclosed IPR, and
understand their obligations under BCP 78 and BCP 79.

4. Other Points

POSH makes no requests of IANA, but it does require application
protocols that use it to register "Well-known" URIs. POSH does offer
guidance on the structure of those URIs in non-normative language.
Back