Scenario for unreliable network connectivity

[sudo-bmitch]

This is likely a 5.1 scenario. In v2 I'm looking for support when network connectivity may be intermittent. For images, that would likely involve some kind of pull through caching registry. For notary signatures I'm looking for a way to make them valid even if stale for some users, which I realize breaks the TUF timestamp keys in v1.

The use case I'm looking at is a utility provider that wants to run signed images on their field equipment, and this equipment needs to continue to operate during a natural disaster that may sever connectivity to the central image registry for a month, possibly longer. Connectivity to this field equipment is provided over cellular networks that may become saturated or unavailable during a disaster. All images would be signed by the company, so they control all of the keys and can manage distribution of the certificates.

[SteveLasker]

Would this be considered as part of the air-gap environment requirements, combined with the ability to copy content (with its signatures) into that environment?
The Key Revocation scenarios, including air-gap requirements, should also account for this.

[sudo-bmitch]

The scenarios are close enough, and I'm involved enough with the rest of the spec process, that I'm fine if this gets closed.

The difference to me is in implementations. In a restricted network, there's a full registry and controlled copy of the artifact and its signatures, and likely a controlled update of those signatures if we do something with short lifetimes on the signatures. In the scenario I'm proposing, it would only have a pull through cache rather than a constantly updated registry, and that cache would only get updated when a pull is run. A later pull for the same artifacts could occur during a network outage, and in those cases, I'd like the client to be configurable to allow any expired data rather than failing.

More than likely, I'll abandon the attempt to use a pull through cache, and instead run a minimal registry with a process to constantly pull updates, turning it into the air-gaped scenario 5. But if we can support the cache with intermittent connectivity, I suspect others may appreciate that functionality.