I have been thinking about this problem for a very, very long time. I don't see ACME as the solution to the IoT certificate problem because it is designed to support the WebPKI which is predicated on DNS names.
Let's forget about mDNS for a while. mDNS was a hack designed to allow people to set up printers in small networks where splattering multicast messages made sense and telling people to deploy some sort of hub service did not. My FiOS home router has a full DNS server on it and I am pretty certain every other home router does as well. So the problem here is how to push the data we need for resolution into the DNS tables on that device or to move DNS resolution to a different device. Does multicast make sense in a home network with 100 IoT devices? I don't think so. Lets not start off with a commitment to some 20 year tech because it is there. What I propose is a two phase process: Phase One: To provision 'PHB-connect' devices, first deploy an 'always on' PHB-connect hub, which is merely an RaPi ZeroW class device. Phase Two: All the functions of the hub are absorbed into the home network router interface or some other device in the network that has the 'always on' property. Let's start from the beginning as the user sees it. A box arrives on their port. They want to unbox the gadget, power it up and use it with the absolute least fuss possible: * Scan a QR code on the box or the device * Use the camera on the device to scan a QR code presented by some existing device * During the online purchase, click a box to pre-connect it to my network, on delivery, confirm the join request on existing trusted device. This is one of those problems where it is MUCH EASIER to solve the whole of the user's problem than just one little bit. If I am doing the whole onboarding process, I am already talking to the DHCP service, the DNS service and the 802.11x/RADIUS service. If we are going to provision a TLS cert to the device, we can step up and provision a better way to connect to the WiFi networks (ALL OF THEM), than a global password. Home users need enterprise grade security MORE than enterprises do. There is also the question of naming, there are many variations, but the ones I have seen all boil down to three underlying approaches: A) Use a DNS name, costs the user $10/yr for all their devices B) Use a fingerprint of a public signature key as a personal root of trust, cost $0 but horrible usability C) Introduce a new universally unique identifier as a friendly name for B. Case A is pretty much solved already. Just a case of joining up the dots and letting a device inside a private NATed network get an ACME accredited cert. Result works with an unmodified standard browser. Case B is flexible but ugly. We have no problem with .onion addresses or PGP fingerprints but almost everyone else does. Case C does have a cost but it can be very, very low. I believe a wafer-thin registry can be run for a $0.10 one time fee. And the main reason to charge is that domainers would slam the service otherwise. That is low enough that an IoT vendor can provide a coupon redeemable for a name registration if the user needs it in every box. Or we can get clever and elide the need for a paper coupon. Furthermore, we want Alice to be able to connect to the device using one of the following ranked in order of least to most hassle for Alice: 1) A standard Web browser (Chrome, Edge, Firefox, Safari, etc.) 2.1) A new Web browser (or device configurator) shipping with an additional global root. 2.2) Installing the additional global root into a standard browser. 3) A standard Web browser that has a personal root installed that certifies Alice's devices alone. Using a separate browser for IoT devices might sound funky but that is exactly what people are doing today. Most of those IoT apps are merely Chrome or Safari in kiosk mode. [I am describing the system I am building and expect to demo in Bangkok here, so it is based on the Mesh, there are other assertion formats we could use but nobody likes ASN.1 except the NSA, XML has serious problems as I discovered on SAML and JSON is flavor of the month. Mesh is just SAML in JSON.] So Alice buys her first PHB-connect device, plugs it in, picks the name 'alice1234' and that registers an assertion binding the callsign alice1234 and the domain alice1234.mesh to the fingerprint of Alice's Mesh profile. It also assigns an IPv6 ULA which being registered, is guaranteed to be globally unique. At the same time, Alice's PHB-connect hub generates a root certificate for Alice and requests cross certification from a non-WebPKI CA I will describe later. This means we achieve the level 2 user experience. Device is registered using the existing Mesh device connection protocol which causes it to be provisioned with a set of public/private keypairs for authentication, signature and encryption. It is also assigned a unique IPv4 address in the space 10.x.x.x and a globally unique IPv6 address in the ULA that won't change even if Alice takes the device to one of her other homes. [While DHCP means that devices can in theory change their IP address if they are offline and come back, this only makes network management harder and more confused. Giving the device a unique address that will never change for as long as Alice owns it allows us to automate VPN management later on.] If the device has a CPU that is designed to support it, we can bind the Ed448 and X448 private keys the device is going to use to the device itself using threshold cryptography. This makes leak of the private key very, very unlikely unless the device itself is physically compromised. This in turn means we can worry a lot less about key compromise and certificate expiry. So when the device connects, if it has secure storage, can just issue it a 10 year cert under Alice's personal root. This is one of the two systems I hope to demo in Bangkok. The other being 'anything' which is the reason this isn't running already. The operation of the Callsign CA is entirely deterministic. Unlike in the WebCA where the CA has to validate the ownership of the DNS Domain, callsigns are assigned by the act of binding them to a domain creating the axiom of trust for that name. What this means is that we can split the operation of the Callsign cross certification CA across multiple operators using FROST threshold signatures. So instead of a single rogue CA being able to create a bogus certificate for alice1234.mesh, it takes a quorum to go rogue. While we could try to jam this scheme into ACME, there is really no point because ACME is designed to provide validation necessary for issue of end point certificates and the Callsign CA is issuing path constrained cross-certificates that don't require additional data to verify and can be issued without waiting for any sort of user request. Same thing happens with issue of certs under Alice's personal CA, different problem entirely. I own the domain LetsAuthenticate.com which I plan to use for the testbed and have done since before anyone thought to apply for a trademark. It seems like a fitting use for a complimentary service. This post is already far too long and won't go into more details. Suffice to say, anyone already replying 'but you didn't think of...' while reading through the above should probably rethink before hitting send.
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
