Chris recently observed: One of the more significant things about CurrentOS is that every connected item of equipment has to adhere to a specific CurrentOS set of rules. It is forbidden to connect anything to the installation that doesn’t have a CurrentOS compliance certificate, and to do so will either shut the non-compliant device or its branch circuit down if possible, or shut the whole system down (either way, through detecting more power consumed than CurrentOS expects). Do we want to create the same kind of regime? It gives us much more freedom in design, but increases the barriers to entry.
I suggest an approach to this issue that separates mechanism from policy. We don't have a commercial interest in ensuring compatibility to ODG but installers of ODG grids might want this kind of restriction for two reasons. To reduce maintenance, they might want to ensure that all attached devices were known to be compatible with a version of ODG. For business reasons, they might choose to require that all attached devices were products that they sold.
It's pretty clear that the grid manager needs to be able to enumerate all manageable attached devices. As part of that enumeration the device should at least offer a unique identifier and some description of its requirements and capabilities including what protocol versions it supports.
The challenge is how to guarantee compatibility. In other contexts we have considered that possibility of offering a trademark license to vendors that passed a compatibility test. Part of the information provided by a device could include an X.509 certificate tied to the device's unique identifier and issued by ODG to vendors that passed the compatibility test. This would complicate the manufacturing process slightly but would not add significant cost to the device.
Simply remembering the certificate in non-volatile storage would not prevent nefarious manufacturers from building devices that claimed to be compatible but were not in fact by cloning an existing certificate / UUID combination. The cloner's job is complicated by the fact that the grid could detect multiple devices with the same UUID and report a problem. This makes the task of cloning more complicated but doesn't eliminate the possibility of a single cloned device being added to a grid.
I don't see a way of completely eliminating this problem short of requiring some kind of TPM chip on devices. I don't think requiring TPM functionality makes sense but it might make sense to define how using a TPM chip would work in ODG so that resellers could choose to require it on their grids provided that OEMs were willing to build such products.
To address the business requirement of resellers who want to limit attachment of devices they sold, it might make sense for the standard to require devices to include the capability of programming devices in the field with a second non-erasable certificate that could be programmed by the reseller before a device was delivered to the customer. A similar mechanism is required by PAYG anyway and could be implemented with modest cost by including some kind of one-time programmable device. ODG reference software could include the programming technique and mechanisms to verify certificates on an operating grid.
Chris recently observed: One of the more significant things about CurrentOS is that every connected item of equipment has to adhere to a specific CurrentOS set of rules. It is forbidden to connect anything to the installation that doesn’t have a CurrentOS compliance certificate, and to do so will either shut the non-compliant device or its branch circuit down if possible, or shut the whole system down (either way, through detecting more power consumed than CurrentOS expects). Do we want to create the same kind of regime? It gives us much more freedom in design, but increases the barriers to entry.
I suggest an approach to this issue that separates mechanism from policy. We don't have a commercial interest in ensuring compatibility to ODG but installers of ODG grids might want this kind of restriction for two reasons. To reduce maintenance, they might want to ensure that all attached devices were known to be compatible with a version of ODG. For business reasons, they might choose to require that all attached devices were products that they sold.
It's pretty clear that the grid manager needs to be able to enumerate all manageable attached devices. As part of that enumeration the device should at least offer a unique identifier and some description of its requirements and capabilities including what protocol versions it supports.
The challenge is how to guarantee compatibility. In other contexts we have considered that possibility of offering a trademark license to vendors that passed a compatibility test. Part of the information provided by a device could include an X.509 certificate tied to the device's unique identifier and issued by ODG to vendors that passed the compatibility test. This would complicate the manufacturing process slightly but would not add significant cost to the device.
Simply remembering the certificate in non-volatile storage would not prevent nefarious manufacturers from building devices that claimed to be compatible but were not in fact by cloning an existing certificate / UUID combination. The cloner's job is complicated by the fact that the grid could detect multiple devices with the same UUID and report a problem. This makes the task of cloning more complicated but doesn't eliminate the possibility of a single cloned device being added to a grid.
I don't see a way of completely eliminating this problem short of requiring some kind of TPM chip on devices. I don't think requiring TPM functionality makes sense but it might make sense to define how using a TPM chip would work in ODG so that resellers could choose to require it on their grids provided that OEMs were willing to build such products.
To address the business requirement of resellers who want to limit attachment of devices they sold, it might make sense for the standard to require devices to include the capability of programming devices in the field with a second non-erasable certificate that could be programmed by the reseller before a device was delivered to the customer. A similar mechanism is required by PAYG anyway and could be implemented with modest cost by including some kind of one-time programmable device. ODG reference software could include the programming technique and mechanisms to verify certificates on an operating grid.