[POSH] POSH and EST

Peter Saint-Andre <stpeter@stpeter.im> Thu, 15 August 2013 19:40 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: posh@ietfa.amsl.com
Delivered-To: posh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBAF21F9D2E for <posh@ietfa.amsl.com>; Thu, 15 Aug 2013 12:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.234
X-Spam-Level:
X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ih3kvgKmLuUE for <posh@ietfa.amsl.com>; Thu, 15 Aug 2013 12:40:14 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE2021F9AA3 for <posh@ietf.org>; Thu, 15 Aug 2013 12:40:14 -0700 (PDT)
Received: from ergon.local (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 485EAE834E; Thu, 15 Aug 2013 13:43:17 -0600 (MDT)
Message-ID: <520D2E9C.9010001@stpeter.im>
Date: Thu, 15 Aug 2013 13:40:12 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: "<posh@ietf.org>" <posh@ietf.org>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [POSH] POSH and EST
X-BeenThere: posh@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion about PKIX Over Secure HTTP <posh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/posh>, <mailto:posh-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/posh>
List-Post: <mailto:posh@ietf.org>
List-Help: <mailto:posh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/posh>, <mailto:posh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Aug 2013 19:40:19 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At the POSH BoF in Berlin, Dan Harkins asked why we couldn't just use EST:

https://datatracker.ietf.org/doc/draft-ietf-pkix-est/

This puzzled me, since Matt Miller and I both reviewed EST and
concluded that it wouldn't solve the secure delegation problem. But
Dan was pretty adamant about it so I've taken another look. :-)

The fundamental stumbling block for me is that (as far as I can see)
EST provides a way for a PKIX client to obtain a certificate for
itself (i.e., "certificate enrollment"), whereas in POSH we need a way
for a TLS client to receive a hint about the PKIX certificate that
will be presented by the TLS server during TLS negotiation within an
application protocol such as IMAP or XMPP.

Here is what I see as the goal and "happy path" process in each
approach. (Note: Examples might be simplified.)

First, let's consider EST...

Goal: As the owner of example.com, obtain an end-entity certificate
for, say, the domain im.example.com.

Process (followed by EST client)

1. Discover the EST server for the relevant CA (say, "ca.example")

2. Send GET to https://ca.example/.well-known/est/cacerts to learn the
trust anchor for the EST server

3. Receive a response from the EST server containing the root cert and
any additional certs

4. Send request to https://ca.example/simpleenroll (including a
PKCS#10 Certification Request) to obtain an end-entity certificate for
im.example.com

5. Receive a response from the EST server containing an
"application/pkcs7-mime" object

6. Happily install the end-entity certificate at my XMPP server

Now let's consider POSH...

Goal: As an end user of the im.example.com service, determine what
end-entity certicate will be presented by the TLS server at that domain

Process (followed by XMPP/TLS client)

1. Send GET to
https://im.example.com/.well-known/posh._xmpp-client._tcp.json

2(a). Receive JSON Web Key set specifying the certificate to be
presented by the im.example.com domain

- -or-

2(b). Get redirected to a hosting provider for im.example.com, say
https://hosting.example.net/.well-known/posh._xmpp-client._tcp.json
(and repeat step 1 for this domain, eventually receiving a JWK set)

3. Connect to im.example.com over XMPP, initiate TLS negotiation via
STARTTLS, check the PKIX certificate presented by the TLS server
against the information in the JWK set, and if all is OK then proceed
to do various IM things through the XMPP server at im.example.com

As far as I can see, these scenarios are very different in terms of
goals and process. I freely admit that I might be missing something
that is specified in or implied by the EST spec, but right now I don't
see what that might be. Enlightenment would be welcome. :-)

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSDS6cAAoJEOoGpJErxa2p6EUP/3WbW84D8sXDgrIFg6/puJDq
H3G7fBm3LhDSxklP9R4ac0r3PfFRwD52kAjApwXSG/+35rvRbP9fUVbT/IIu+LuQ
m165CBQbKXgWAZtXzpvHNHLLw2Snk9gpSudlyHzvuYC6widWq2D6NSa/MDgsm7Ge
NBegQqIOGSiM9TOlhMw5tJtppkMZ7D3ehb12YEcqpCT1J7JxzudG1XaDU5o78YDl
CRXCYcFP73g7Tijj1WonQFfn5NPTRbUSHkVmkDqQAtUG7ZNWamGK2RqNJHfULpAl
uy60LZIjinalxbSa0vBB4cYw2G5lw4eh7J/kqJvQXG16ko0dfbv3lXCL5vPB07ge
YF3QXiwiqORTkb/cfuutktakc4PbroTsHr5n8/yOBfBe9HXTCfWylllbBnVHjisQ
DvalAcxRzggdMV3La4J3ISflfwfdEPDRXZhs0dZBOEICol1M2VHgvVc18HQ1R+NS
gjRPR/JJIn48V79Dneff02w3Px6yZD+YXW7S9tWzUR4CKOHCY0icqRspbq6kYcPi
gJ6C+mR7iXsdEH8ZzTVomlQPpocIHGNd0CBNXay5FnphTt6f9UOpXwWSLl4GHrUe
6XdgZ82tqlG0mdHWG6pHw4mnGc2xNrQxdt7vW02lV5A2EMHVcpEbxs3jJgiVACsF
+KSVDLK8BCt8mIuWSdQF
=srFd
-----END PGP SIGNATURE-----