Skip to main content

Solution Overview

This section describes the building blocks for potential solutions. The purpose is to describe current practices and spark ideas on how they can be applied in a different context.

Some solutions may prove impractical, while other solutions involve working with standardisation bodies to amend or extend existing standards. Unfortunately, there is no easy fix.

The solutions are layered, and partially interconnected. Part of the solution is understanding what technically needs to change in the browser implementation; the other part is understanding the different mechanisms to put these augmented browsers in people's hands.

Other considerations include looking at the mechanism of assigning a name to a device, the mechanism of resolving the name, and lastly the mechanism (security negotiation) of bootstrapping the secure TLS connection between browser and device.

Browser Changes​

  • Ask browser vendors to treat certificates for local IP addresses differently and at least change the warning message.

  • Ask the CA/Browser Forum to adapt the rules for signing certificates.

    Currently a local domain for IoT, similar to .local used in mDNS, but for which certificates are allowed to be signed (like .onion).

  • Create a dedicated IoT browser or mobile app to manage IoT devices through a generic interface.

Provisioning Names and Certificates​

  • Create a public domain infrastructure to give local devices a globally unique domain name.

  • Let local gateways and routers sign certificates and let browsers trust this as an alternative root of trust.

  • Create a dedicated special purpose ROOT CA for IoT devices (learning from ISRG 'Let's Encrypt' and cacert.org)

  • Set up a dedicated IoT domain name for which different certificate rules can apply

  • Create an infrastructure for onboarding devices using 802.11AR Device ID's and the BRSKI bootstrapping (the Registrar would live in the home gateway, router and/or NAS, with a smartphone interface).

  • Use special purpose TLS certificates by introducing a new extended key-usage field for IoT.

Apart from patching a browser to generate a softer warning message, all the other solutions require interworking with other standardisation organisations, or creating an elaborate infrastructure.