On Thu, Dec 19, 2024 at 11:29 AM Michael Sweet <msw...@msweet.org> wrote:
> This also has huge privacy issues - it is one thing to require local > services to be published/registered/validated locally, but quite another to > make them globally visible (if not globally accessible). > You have three choices: 1) Issue a cert with a public facing DNS name, this will leak the existence of the device. 2) Issue a wildcard certificate to the IoT device (baad!). 3) The homeowner has a private root, cross certified to a trusted root with path constraints. Given how we have set up transparency expectations in the WebPKI, I am thinking the third would run into real heavy compliance issues in CABForum. I can do that with callsigns and .mesh because its my playground and I can make up my own rules and build the thing and run it for a time before going to the browser providers and asking for their approval. And then they are looking at a thing that is built and running and can understand the risks a lot better than if I am coming to them asking for what could be a blank check. Keeping device names private was a huge concern in the design of trans and I was involved in the ongoing discussions back in the day but I have been out of that loop for almost a decade at this point and cannot remember how they turned out, if they ever did. At any rate, I am pretty sure that the enterprise privacy concerns raised then are no less serious than those of the homeowner. I am not too keen on homeowners running completely unconstrained private CAs either. I would use threshold cryptography to split the private CA capabilities across a device in the homeowner's network and an external service so we get some separation of duties going on. > Finally, this also depends on having Internet connectivity which IMHO > makes this a non-starter, even for homes that have a dedicated Internet > service. For example, my Starlink service drops out regularly as > satellites transit overhead, and cellular similarly comes and goes for a > variety of reasons. We need a *local* trusted authority for *local* > services. > The proposal I just made only requires intermittent connectivity. Each device has two modes of engagement: * Onboarding / Reconfiguration, about 5 HTTP POST methods. Usually just when the device is initially deployed and when it is disposed of. * Certificate/key Refresh: One HTTP GET, usually every 24 hours but certificates are valid for 6 days. So even if you have a power outage, your system will work just fine so long as it is less than 120 hours. And when you get power back, everything can recover automatically. I am all for everyone having their own private CA. In fact, that is the model I have coded. But going through these interactions today, I can see that I don't need it for the 1.0 version of the system which can be dramatically less complicated with a very small reduction in functionality and the infrastructure deployed in 1.0 enables the step up to 2.0. We don't need to build such a scheme on the Mesh, but there are some technical requirements that I think we would end up agreeing on: * Use a SAML-like assertion architecture. * Use JSON syntax for the assertions so people can read 'em. * Use JOSE cryptographic packaging * Use threshold cryptography for key distribution because it greatly simplifies everything. If you sign off on those, you are going to end up with something that looks pretty close to the Mesh.
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
