On Thu, Dec 19, 2024 at 11:00 AM Watson Ladd <watsonbl...@gmail.com> wrote:
> Any solution will have to involve the device doing something, and > something validating the device. If we can get the user ISP (I know, I > know), to produce a residential domain setup like > fijinb23.users.example.com, then the router ((I know I know)can somehow > gather that a new printer has been added, give the printer > printer.fijnb23.users.example.com via communication to the ISP, and set > the DNS challenge entries to respond to a request for DCV validation that > results in a cert being sent back to the printer with a CSR the printer > generates. > > There's lots of problems here, but I think this strawman shows the problem > can be solved, and it's just a matter of improvements. > A service provider is essential but it doesn't have to be the user's ISP. The only requirement for being a Mesh Service Provider, is to have a DNS name and a public static IP address. We can discuss different protocol options but I am pretty sure those will be required. I am currently hosting my own MSP on a Digital Ocean Droplet for $5/mo. I would expect the first group of providers stepping up to provide an MSP like service are the VPN companies. Eventually ISPs would likely offer the service. My original goal here was to provide users with an open service where they choose their service provider and can change their choice at. any time with ZERO switching costs. So I am not a big fan of the DNS names at $10/yr for this application. However, another big change happening right now is that Blue Sky has made some extensions to OAUTH2 which together make it what OpenID connect was supposed to be, an actually open identity system where you can use an account you personally control at any Web site (not use an account at Facebook or Google or possibly Apple) as your Web handle. I have implemented this for my Palimpsest document annotation system, I can log in as @phill.hallambaker.com: https://bsky.app/profile/phill.hallambaker.com/post/3ldjuhc7b4d2w This is something I think we should ride hard. OpenID failed the users. All it takes to turn this login approach into what OpenID promised is branding and a name (and a way to make sure the incumbents can't sabotage). I am currently proposing @nything because you can log into anything. So lets say I am offering a free MSP service at example.com and Alice creates an account, I probably issue her @alice.example.com as her @nything handle and can assign coffee.alice.example.com to her coffee pot. Such an MSP might monetize by attempting to upsell to a paid account with VPN service or selling a domain name if it was only doing IoT. Adding @nything means that they can be providing open service, end to end secure messaging, mail, file sharing, voice and video. In this model, all we need to issue the certificates is to relay certificate requests from devices inside a private network to the external network and to return the certificates. I am assuming here that we will be using the new 6 day certs with a 24 hour renewal cycle. I can do that for EC certs with minimal protocol overhead at the device and without the need for a local hub: * Device onboarding - device specifies the base threshold share for the TLS certificates it will use. * Cert renewal: Every 24 hours, device HTTP GETs a package containing its new (encrypted) threshold share and cert Ideally, the base threshold share is bound to the device such that it cannot be extracted. But in any case, the device public key is rolling every 24 hours without the device ever having to be involved with the cert issue. The device doesn't do ACME, it just downloads the certs and threshold shares and uses them to assemble the private key. The MSP end does all the ACME protocol. The device doesn't have to be involved in that AT ALL. The MSP has control of alice.example.com and will provision all the records needed for DNS Challenge, CAA etc. Can even do TLSA and DKIM. This approach does not require callsigns but at the cost of requiring the user to subscribe to a $10/yr name or be captive to the MSP. Another possibility is to get rid of the MSP entirely and the CA does the same function. But then the CA has to be running the DNS for the end user as well. I have code implementing about 80% of this scheme today.
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
