4 ms·

> Global hosts should be your first point of contact and from there you should be able to leverage global TLS to bootstrap more intimate trust relationships...

> Global hosts should be your first point of contact and from there you should be able to leverage global TLS to bootstrap more intimate trust relationships... to make informed decisions about the trust relationships you want to establish. Explain more how this would work.

dcow 9y ago
Part of setting up an account with a web service or iot device provider or whatever should be acquiring their certificate authority. However, instead of having a single bucket OS level root trust store, browsers empower users to whitelist the sites they trust that authority to well have authority over. You trust googles ca for google.com. Or maybe you don't. At the application level, trust should be managed by the application provider and the user. Their certificate authority can issue whatever certificates it wants for whatever kind of network topology or application use cases or whatever else they need to support. As a user you're either still using a browser or you've at this point switched to their native app or you've got their JS helpers loaded or whatever. Their application logic can manage all the certificate crap so that users are minimally encumbered by it. If you're talking to local network devices their application logic would issue certificates for whatever scope of IPv6 addresses you're using. Maybe your fancy device is running dns, their thing issues certs for your scope's site, etc. You can even do mutual TLS now because their authority can issue installs of their app their own certificates. Browsers should support client certs too. Navigating to foo.com using a scoped IPv6 address? You're prompted to select the identity you wish to use. Your browser remembers your choice for that scope. The CA is only valid for your blessed names, scope aware.
- collinmanderson 9y ago
  > Their certificate authority can issue whatever certificates it wants for whatever kind of network topology or application use cases or whatever else they need to support. But that means that other customers can get a trusted certificate for the exact same ip address, right?

dcow 9y ago

Part of setting up an account with a web service or iot device provider or whatever should be acquiring their certificate authority. However, instead of having a single bucket OS level root trust store, browsers empower users to whitelist the sites they trust that authority to well have authority over. You trust googles ca for google.com. Or maybe you don't. At the application level, trust should be managed by the application provider and the user. Their certificate authority can issue whatever certificates it wants for whatever kind of network topology or application use cases or whatever else they need to support. As a user you're either still using a browser or you've at this point switched to their native app or you've got their JS helpers loaded or whatever. Their application logic can manage all the certificate crap so that users are minimally encumbered by it. If you're talking to local network devices their application logic would issue certificates for whatever scope of IPv6 addresses you're using. Maybe your fancy device is running dns, their thing issues certs for your scope's site, etc. You can even do mutual TLS now because their authority can issue installs of their app their own certificates. Browsers should support client certs too. Navigating to foo.com using a scoped IPv6 address? You're prompted to select the identity you wish to use. Your browser remembers your choice for that scope. The CA is only valid for your blessed names, scope aware.

collinmanderson 9y ago
> Their certificate authority can issue whatever certificates it wants for whatever kind of network topology or application use cases or whatever else they need to support. But that means that other customers can get a trusted certificate for the exact same ip address, right?