- 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