Re: [DNSOP] On trust anchors, roots of trust, humans and indirection

[Phillip Hallam-Baker <[e-mail]>]

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.