It is a hard problem and it is possible that there is actually no solution.
All these systems consist of a chain or a graph of signed assertions. There is no intrinsic ground truth in PKI. All that you can do is to define a particular key or set of keys as producing the ground truth for your particular application. There is also a psychological angle. People are uncomfortable with the idea of keys with infinite validity intervals. Yet we know that key rollover mechanisms are the most complex and error prone parts of any PKI. Another problem we face is the question of what a device or application should do if it cannot get an acceptable source of ground truth. A lot of people assume that the answer should be to simply halt. Which is kind of the wrong thing if the device is a pacemaker. ICANN has a mechanism for specifying their ground truth that is ultimately embodied in a sequence of root keys that are created over time. One consequence of that approach is that I cannot build a device today for a 20 year service life using the DNSSEC as ground truth for the PKI. No, don't tell me why that is not a requirement because it is. 95% of all the world's SCADA systems run code that was written in the 1990s and has not had one byte modified since. So don't you dare claim that software updates are essential, that is an ideological position learned from a limited set of experience. But even if we accept the need for updates, where does the ground truth for the updates come from? If you want to produce a device that has a 20 year service lifespan, the only way you can do that is to use a PKI that is expressly designed for that. Which is of course what CableLabs etc. do (or try to). And we need to encourage vendors to take that approach rather than assume that they can apply an off the shelf PKI for their purpose. All the problems of the SHA-1 phaseout in the WebPKI came from groups that had applied it to embedded devices assuming that this would be OK. This is of course the approach that browser and O/S vendors have taken. They do not rely on the DNSSEC or WebPKI for validating updates, they rely on their own PKI that is answerable only to their requirements. .... but what about user requirements? I have a perfectly good 36" plotter I paid $50 for that is just as good as a new $2500 machine for my needs. The only problem being getting round the planned obsolescence of ink cartridge manufacturing being shut down. That is why I have developed my SIN proposal which allows devices to be subordinated to a PKI that is managed by the User/Customer and is within their sole control. Let us say that MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ is the fingerprint of the master key for the enterprise PKI for example.net This then cross certifies the ICANN DNSSEC roots as they are published. Thus the interpretation of the following SIN becomes as robust as the management of the enterprise PKI: example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz Don't want to run the PKI yourself? Get a group of lime minded manufactuers together and run one as a co-op (e.g. Cable Labs). Outsource management, etc. etc.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
