On Mon, Jan 20, 2020 at 12:22 PM Michael Richardson <[email protected]> wrote:
> > Alan DeKok <[email protected]> wrote: > > While, there are commercial supplicant products, these products are > > overwhelmingly used by the enterprise, on computers owned by the > > enterprise, and managed by the enterprise systems. They have zero > > impact on the average user. > > Today. > But, since a goal here was for IoT devices, this changes things: > > 1) Enterprises want to manage IoT device onboarding, and they > overwhelmingly > want to use EAP/1x. > > 2) IoT devices don't have users and can't even load a non-standard XML > configuration. > I think it best that we focus on meeting the needs of customers rather than engaging in the spec lawyer-ing seen earlier in the thread. We already have the EU and the US House and Senate looking at the PKI world as one example of what they believe to be a 'Big Tech' agenda set against the little guy. And not just on the left. Most of the people I have been talking to are Republicans or staffers thereof. So no, let us not suggest that we can find some wording in some CA's CPS that enables us to force them to revoke certificates that are clearly not being abused. And certainly not on the basis of some arbitrary interpretation of a CPS. Such would likely prove a career-limiting move. Let us instead focus on the onboarding problem Michael poses, because that goes to the heart of the matter in my view. Enterprises want to onboard devices with as little manual intervention as is possible. They are currently using the WebPKI roots of trust because that is expedient. This exposes them to real risks which is precisely the reason why the product that was the focus of much of my early VeriSign work was OnSite which is designed to provide enterprises with their own separate PKI for their exclusive use. The reason I have been delving into threshold cryptography and writing the Mathematical Mesh is precisely to support that set of use cases for both personal and enterprise use. What I call connecting a device to a personal Mesh is essentially a PKI driven onboarding process in which the device may be connected by means of one of the following types of identifier * Unique device ID passed to the customer during procurement (most enterprise suppliers provide MAC addresses of the devices that are shipped.) * QR Code printed on the device during manufacture, scanned by customer. * Ad hoc credentials generated by customer-installed application. The device that is onboarded acquires: 1) The ultimate root of trust for that connection context 2) A set of device keys for Encryption, Authentication and Signature to use within that connection context 3) A connection statement credentialing the device keys under the connection context The use of threshold techniques allows the usual concerns about use of manufacturer provided vs centrally generated key pairs to be finessed by providing all the advantages of both. The disadvantages only appear if both the admin device and the device being connected are compromised by the same party. The reason I have moved to a new syntax for this PKI (JSON) is that in my trust model, every user, every enterprise is their own root of trust. It is much easier to design a completely new PKI than to attempt to impose that restriction on PKIX or SAML. I can easily spit out X.509 certs as needed but these are products of the enterprise PKI, they are not the primary accreditation trust path. The traditional approach used to engineer this in OnSite is about as well as can be achieved using 1990s technology when the machines were severely limited in their CPU capabilities and processing RSA path math took seconds. Automating the device and service management processes is a necessary precondition for using client side PKI, and security policy and thus making effective use of DNSSEC. The key difference in my new approach is that under the OnSite approach, enterprises that outsourced their PKI to VRSN were handing over the keys to their kingdom. Using threshold, that is no longer necessary.
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
