Clarity needed in relation to Snapshot role and online vs offline

[udf2457]

At the moment, the website can't seem to make its mind up as to whether Snapshot role keys should be online or offline.

Really someone needs to decide once and for all and stick to it, instead of all this conflicting wording.

If we consider the Specification as the ultimate source of truth, then we are told:

All keys, except those for the timestamp and mirrors roles, should be stored securely offline

content/metadata.md seems to agree:

so that the Snapshot role's keys can be kept offline, and thus more secure

So far so good. But the FAQ content/faq.md is where you have the bouncing around. On one page we are told two different things...

Three places state online:

even sharing online keys (e.g., between the Timestamp and Snapshot roles)

In contrast, the Snapshot role is updated often, signed with an online key

The Timestamp and Snapshot roles can use online keys

And then we have a suggestion of offline for Snapshot:

separate keys should be used so that the Snapshot role’s keys can be kept offline, and thus in a more secure manner.

If we assume the Specification reflects the TUF design decision, then the rest of the website should be consistent.

[joshuagl]

Thanks for pointing out this inconsistency @udf2457 ! I think the website could do with a general overhaul to improve accessibility and understanding of the project. One way we might do that is by describing some use-cases that the project supports and an associated TUF "profile", somewhat like our sibling Uptane project's Deployment Considerations documentation.

For the specific issue of snapshot keys, it really does depend. We are seeing increasing use of an online snapshot key. For example, while working on PEP 458: – Secure PyPI downloads with signed repository metadata the authors concluded that snapshot must be online in order to support the continuous delivery model of PyPI. See the section Number and type of keys recommended.

Similarly, Sigstore's root-signing system opted for an online snapshot key (see https://github.com/sigstore/root-signing#tuf-repository-structure).

[udf2457]

I suppose equally in today's world, where how do you categorise cloud keys ? Cloud services are clearly online, but something like AWS CloudHSM ?

Thanks for the pointer links, will have a read.

I agree use-cases, or if you wanted to go one step further reference architecture and/or best practices could be great additions. The TUF site is certainly very theory heavy at the moment, and practical real-world examples could certainly be a welcome addition.

[joshuagl]

I agree use-cases, or if you wanted to go one step further reference architecture and/or best practices could be great additions. The TUF site is certainly very theory heavy at the moment, and practical real-world examples could certainly be a welcome addition.

Completely agree. Members of the TUF community are working on generalised implementations of PEP 458 in Repository Service for TUF (RSTUF) and of Sigstore's root-signing in tuf-on-ci. I would like us to be able to articulate those architectures and point to these implementations on a future update to the website.

[JustinCappos]

I will also add my acknowledgment of the problem and agreement that this depends on the use case. For something like a Linux distro which does a release every month or so, then snapshot should absolutely be offline. For something like PyPI, which releases a new version of a package on the order of a few seconds, then the snapshot key should absolutely be online. We originally were thinking about the first case back in 2010 so the first TUF paper talks about this and it is in the oldest documentation. Most newer adopters fall into the second case, so most practical use today is the latter.

…

On Thu, Aug 17, 2023 at 9:52 AM Joshua Lock ***@***.***> wrote: I agree use-cases, or if you wanted to go one step further reference architecture and/or best practices could be great additions. The TUF site is certainly very theory heavy at the moment, and practical real-world examples could certainly be a welcome addition. Completely agree. Members of the TUF community are working on generalised implementations of PEP 458 in Repository Service for TUF (RSTUF) <https://repository-service-tuf.readthedocs.io/en/stable/> and of Sigstore's root-signing in tuf-on-ci <https://github.com/theupdateframework/tuf-on-ci>. I would like us to be able to articulate those architectures and point to these implementations on a future update to the website. — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRODZWBQKHA7EGZMCQRFTXVYO23ANCNFSM6AAAAAA3T4OB3Y> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[udf2457]

Maybe (long-term) there is scope for adding a type metadata item to keys which could be ['online','offline']. Then you would have two optional extensions to the basic threshold: threshold-online and threshold-offline.

So therefore in addition to today's M of N threshold, you could optionally enforce key type. So you could have, say:

threshold: 3
threhold-offline: 1

Which would mandate 3 of N keys, of which minimum 1 must be offline type.

[joshuagl]

That's an interesting suggestion. My initial thought is one of reservation: as threshold computation is a frequent source of implementation issues. see theupdateframework/specification#154, I'm wary of making it more complicated. The idea merits deeper (non-visceral) evaluation, thanks for sharing it.