Subject: [POSH] BoF Charter Proposal -00

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 5 Jun 2013 21:01:31 +0000

Here is the charter proposal Peter and I submitted.  Any feedback would be greatly appreciated!

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

-----BEGIN CHARTER PROPOSAL-----

Charter Proposal: PKIX Over Secure HTTP (POSH)

Problem Statement

Channel encryption with TLS depends on proper checking of the server's
identity, as specified in RFC 2818 or RFC 6125 for PKIX certificates. 
However, in multi-tenanted environments it is effectively impossible for
a hosting service to offer the correct certificates on behalf of a 
hosted domain, since neither party wants the hosting service to hold the 
hosted domain's private keys. As a result, typically the hosting service 
offers its own certificate (say, for hosting.example.net), which means 
that TLS clients and peer servers need to "just know" that the hosted 
domain (say, foo.example.com) is hosted at the service. 

This situation is clearly insecure. The use of DNSSEC and DANE has the
potential to solve the problem, but that potential is most likely many
years from being fully realized. Hosting services and hosted domains
need a method that can be deployed more quickly to overcome the lack of
secure delegation on the Internet today.

For a more detailed description of the problem from the perspective of a
particular application protocol (XMPP), see draft-ietf-xmpp-dna.

Proposed Solution

POSH (PKIX Over Secure HTTP) provides a way to solve the problem,
involving two interconnected aspects:

1. TLS clients and peer servers retrieve the material to be used in
checking the TLS server's identity by requesting it from a well-known
HTTPS URI, where the response contains one or more certificates
formatted as a JSON Web Key set defined within the JOSE WG.

2. If a hosted domain securely delegates an application to a hosting
service, it redirects requests for the well-known HTTPS URI to an HTTPS
URI at the hosting service.

For a more detailed description of the proposed solution (at least for 
XMPP), see draft-miller-xmpp-posh-prooftype.

Deliverables

The group would produce a specification for POSH, and might informally
provide advice about how to use the POSH technique for particular 
application protocols.

Any additional work would require a recharter.

Milestones

To be determined.

-----END CHARTER PROPOSAL-----