- From: Kent Watsen <kwatsen@juniper.net>
- Date: Wed, 12 Aug 2015 15:33:00 +0000
- To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
I'm writing to discover if HTTP already supports the use-case described below, or if there is a need to extend HTTP in any way. The use-case regards the automatic bootstrapping of devices, as currently being discussed by the NETCONF and ANIMA working groups. One prevailing idea is for an Internet-based "bootstrap server" (most likely hosted by the vendor of the device) to redirect devices to their deployment-specific bootstrap server. That is, the owner of the device only needs to register the URL (not all the bootstrapping data for a device), thus resolving a privacy concern. The issue regards how to convey the TLS trust-anchor used to verify the redirected HTTPS connection, specifically when the deployment chooses to use their own PKIX infrastructure instead of a global certificate authority (e.g., Verisign). Thus the HTTP Redirect (e.g., 307) needs to return both the Location header and also a TLS certificate. For instance: Trusted Internet-based Deployment-specific Device Bootstrap Server Bootstrap Server | | | | | | | HTTPS using factory | | | default trust anchor | | |------------------------->| | | | | | HTTP redirect, with | | | deployment-specific | | | trust anchor | | |<-------------------------| | | | | | | |HTTPS using learned trust anchor | |----------------------------------------------->| | | FWIW, this is considered secure, as the trust anchor is learned through a trusted connection. Now back to the original question. As far as I can tell, a 307 response may have a message body, so a TLS certificate could be returned in it. Is this accurate? Also, while this specific behavior could be documented in draft-ietf-netconf-zerotouch, it seems generally useful and may be better defined in HTTP instead - what do you think? Thanks, Kent
Received on Wednesday, 12 August 2015 15:33:31 UTC