[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-----
- [POSH] POSH and EST Peter Saint-Andre