The fact that the internet != traffic going to your laptop/PC/phone.
There are a lot of non-consumer use-cases (think, processing of corporate data in the cloud, or deployment of industrial IoT devices) where you want very strong guarantees about the state of the entity you're talking to, stronger than a static x509 gives you.
> over using client certificates
The use-cases are also not restricted to client authentication (and "client" doesn't always mean outside of the cloud).
>The fact that the internet != traffic going to your laptop/PC/phone.
>There are a lot of non-consumer use-cases (think, processing of corporate data in the cloud, or deployment of industrial IoT devices) where you want very strong guarantees about the state of the entity you're talking to, stronger than a static x509 gives you.
I am aware that the Internet is not limited to websites and personal devices. In fact, I have implemented/secured/managed corporate networks with multiple secured data channels (both within the organization and its employees and in B2B and B2C contexts) many times.
Securing such data (whether within a cloud infrastructure or across the open internet) streams doesn't require such remote "attestation." In fact, it adds an additional layer of complexity that, at least AFAICT, primarily adds the ability to track personal devices and usage across the wider internet.
>> over using client certificates
>The use-cases are also not restricted to client authentication (and "client" doesn't always mean outside of the cloud).
Fair enough. call such certificates whatever you like. However in the corporate context, I'd much prefer to be able to verify authorized connections via a process within my control (e.g., issuing my own certificates to network-based devices, servers/VMs/containers/whatever) rather than relying upon some third-party (whether that's an SGX store or a remote "attestation" authority) for such authentication/authorization processes.
I'll add that this (and by me, repeatedly, as well as many thousands of others) has been successfully accomplished without building a mechanism to uniquely identify arbitrary (as opposed to specific devices involved in sharing data streams) devices on the 'net. Which is, AFAICT, what this Internet Draft appears to be advocating.
The fact that the internet != traffic going to your laptop/PC/phone.
There are a lot of non-consumer use-cases (think, processing of corporate data in the cloud, or deployment of industrial IoT devices) where you want very strong guarantees about the state of the entity you're talking to, stronger than a static x509 gives you.
> over using client certificates
The use-cases are also not restricted to client authentication (and "client" doesn't always mean outside of the cloud).