Feature Request: Federated access

[FruityWelsh]

Reasons for doing so:

1. In order to prevent a single point of organizational failure some form of federated services would be useful.
2. Allows for network sharding to deal with temporary or permanent network sharding, to match the real world conditions more accurately.

Some options:
Either allowing for a store to point to another (i.e. RedHat could host a keystore that points to the KDE store). Some issues become people having to figure out which servers to use, much like DNS, likely leading to the use of defaults.

The other option is to use something like ActivityPub (or other gossip protocol) like Mastadon, where a signature could include which server it is posted to (so if a server is known to be untrusted everyone could choose to blacklist it) and know it would need to regather need signatures for software packages hosted from there.

If this already is in use, then maybe more adding documentation on what solution was chosen and how to use it.

[dlorenc]

Can you clarify what you mean by federated access? There are a few different approaches I can imagine so I want to understand the use-case a bit more.

Do you mean federated access to the transparency log itself? Or some kind of multi-log gossip system with quorum?

[lukehinds]

I am not sure if I am following correctly, there is a gossip protocol that was defined and played with to distribute tree(s) in certificate transparency.

[dlorenc]

After rereading - I think you might be suggesting that we would want signatures to be present in multiple transparency logs. CT works this way - CAs must publish certs to two separate logs. Multiple logs for redundancy is something we'd eventually like to support.

I'd really rather avoid federating the data itself though - all public data should be in as many public logs as possible. Users should be able to look up public metadata for any public artifact in any public log.

The logs can gossip and follow and mirror entries amongst themselves.

[FruityWelsh]

Ok, yeah that seems what I would want/expect.

How would a private rekor server work in this scenario? Could it pick and choose what to publish publically?

The quorum question would probably be more on the client software right or this provided/proven somehow from the server as well?

[dlorenc]

Yes - the quorum one could be enforced in a few ways. Publishers could write signatures to a few logs and get inclusion proofs before distributing signatures/artifacts. Clients could check this. Auditors/monitors should also check that publishers are actually doing this.

For private instances, I honestly haven't thought a ton about how they would interact. I could imagine organizations running a private mirror of only public data, so they have a single API they can refer to behind their firewall. Requesting data on hashes from the public log would in some ways leak information on what artifacts an entity is using, so they could bypass this by mirroring the ENTIRE log and consulting that. Relying on the public log also introduces a point of failure - Apple ran into both of these issues last year here: https://developer.apple.com/forums/thread/124773. Their notary server had some trouble, resulting in most laptops hanging as they consulted the server for signatures.

Something like #102 could help with availability, performance and the "leaking usage information" issue. It's conceptually similar to OCSP-stapling (or pre-certificates) in the web PKI world. Publishers can sign an artifact, upload that signature to the log, get a signed proof that the signature is in the log, and bundle all of that up and "staple" it onto the artifact itself. Then clients can verify everything locally with no outside dependencies.

Some artifact formats might allow for this bundling - RPMs, JARs have unsigned metadata portions where we could stick this stuff. We can make up something for containers (similar to how cosign works today). Others like standard tar archives or binaries don't have any way to do this.

[dlorenc]

At the same time, I think a lot of "internal mirror" setups don't need to be transparent. They're behind a firewall and operating on a trusted compute base for most organizations. There's nothing wrong with using one internally, but you could just dump entries into an plain old database with more indexes and flexible querying.

[FruityWelsh]

I know a some organizations are moving towards a "trustless" model, to be more flexible in how they get their services, while trying to preserve a good security posture.

[haydentherapper]

Closing this since it's been awhile - #1067 tracks the technical blocker for quorum with witnesses, and private instances can always be spun up to host entries in addition to the public instance