secure HTTPS redirect - encoding a new trust anchor?

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:

                      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?


Received on Wednesday, 12 August 2015 15:33:31 UTC