Hi
The primary remaining blocker for me is what trust policy to include in the release notes. I'm beginning to feel that whatever goes into the announcement, users are best advised to make their own additional considerations that depends on current knowledge over time.
Still, it would be nice to include a minimal trust policy that is likely to continue to work and at least provide some security advantage for the user. What is the best trade-off right now? Having 25+ lines of policy hashes in the announcements breaks my readability standards, although I would be okay with a 3/5 policy.
Or would you rather not include any trust policy at all, and simply deferring this to your instructions? That would leave the release notes rather inconclusive though.
Another alternative is to add an indirection like:
wget -Oinetutils-sigsum-trust-policy.txt https://sigsum.org/FOO
or
wget https://ftp.gnu.org/gnu/inetutils/inetutils-sigsum-trust-policy.txt
Do you have any objection to the following text snippet? What could you suggest as improvement? I picked 5 AW witnesses from your list.
--- You may use the following Sigsum verification policy as a starting point. You are advised to follow Sigsum operational best practices and revise this going forward, see: https://www.sigsum.org/services/
cat <<EOF > inetutils-sigsum-trust-policy.txt log 0ec7e16843119b120377a73913ac6acbc2d03d82432e2c36b841b09a95841f25 https://seasalp.glasklar.is witness AW-1 54c4862caba4ef942fe1abc6afb65d63cba0a55d3e6313ff59154b8586d882e2 witness AW-2 7ba003654674398b62dd70ab369a3f750a48670354d66f79125827514a0b9fbd witness AW-3 ea31934afb8632958de2fb37dd9bfabb8dc7961dea67a6ae4c57f1a1ca26eef7 witness AW-4 03f38be7ab7f1081be393a9e69dd594d9a184a0eef36b0a1ab6f7a7f05beffc3 witness AW-5 e90299398a4d39d030da888a0923ecf16786881ac12243db73c9f0cf2a2d80e6 group GTF 3 AW-1 AW-2 AW-3 AW-4 AW-5 quorum GTF EOF ---
Wouldn't it be more reliable to include two different logs, possibly with 2/3 witnesses each? Having a single point of control on the 'seasalp.glasklar.is' domain name seems like a serious problem to me. Hard-coding IP addresses? Tor onion name?
Can I specify a quorum group requiring inclusion into two different logs with one witness each? Is there an example of a trust policy with multiple logs, and multiple witness from each, and some quorum setting? Can one witness validate multiple logs? Maybe a nice idea is to require 2/3 witness from two different logs where one of the witnesses is the same for both logs, to allow some cross-log witnessing.
/Simon
Rasmus Dahlberg via Sigsum-general sigsum-general@lists.sigsum.org writes:
You may use the following Sigsum verification policy:
cat <<EOF > inetutils-sigsum-trust-policy.txt log 154f49976b59ff09a123675f58cb3e346e0455753c3c3b15d465dcb4f6512b0b https://poc.sigsum.org/jellyfish
Jellyfish is a prototype log -- I'd recommend that you use seasalp, Glasklar's production log. See https://www.sigsum.org/services/.
witness poc.sigsum.org/nisse 1c25f8a44c635457e2e391d1efbca7d4c2951a0aef06225a881e46b98962ac6c witness rgdd.se/poc-witness 28c92a5a3a054d317c86fc2eeb6a7ab2054d6217100d0be67ded5b74323c5806
These test/prototype witnesses are not available for seasalp. Glasklar isn't running a stable witness yet (ln5 is working on fixing that the coming weeks; I'm also told a few other organizations are looking to start running witnesses). The witness cosignatures that you see on
https://seasalp.glasklar.is/get-tree-headare all from Google TrustFabric's witness which runs from 15 different vantage points. I'd suggest using a majority policy (8/15 cosignatures). Such a policy for seasalp would look like this:
log 0ec7e16843119b120377a73913ac6acbc2d03d82432e2c36b841b09a95841f25 https://seasalp.glasklar.is witness ArmoredWitness-falling-pond 54c4862caba4ef942fe1abc6afb65d63cba0a55d3e6313ff59154b8586d882e2 witness ArmoredWitness-weathered-rain 62db94aa7926e8b2ae0461e9ebf69cd2795c077eb1cfe63360f61d6fdbe1de52 witness ArmoredWitness-wispy-wood 456f659e0b0efa658e3a2895e2775a7c6754ae09d5842241bb603d649517068f witness ArmoredWitness-small-breeze 00166295237c618f42258e82deac2d66a9d0ff6b54e7be39fbb6b8d65b3b8143 witness ArmoredWitness-quiet-wood 9b71799be731b15fe9b54f37cd6f22f9499d3e3309dabcb588bf82e234844913 witness ArmoredWitness-morning-darkness 7ba003654674398b62dd70ab369a3f750a48670354d66f79125827514a0b9fbd witness ArmoredWitness-shy-wind 198bed2687bcf60fc246eae3583f2a9764287ece65aa1aa9f2b6b04a1628be1d witness ArmoredWitness-hidden-river dae934c7cc1f45ba898a3dfe1265d492a6c58405ddec143fc16f84a0f588e3a5 witness ArmoredWitness-autumn-wood eb085426da77b81b534ec99c0e987d90f4aa0e01d5cf31178212767b7dbe38a9 witness ArmoredWitness-snowy-sound 0b85b9d46ccbd1cfa78a19b04f8fc4359538390c9d82675e89d2433217aaad50 witness ArmoredWitness-throbbing-bird 98149a5d739b3baa777128f617531ce8b654d24502a7e151244cc5b7597667bc witness ArmoredWitness-rough-wind ea31934afb8632958de2fb37dd9bfabb8dc7961dea67a6ae4c57f1a1ca26eef7 witness ArmoredWitness-dry-sunset 03f38be7ab7f1081be393a9e69dd594d9a184a0eef36b0a1ab6f7a7f05beffc3 witness ArmoredWitness-nameless-firefly 075189980cc1388fa8686c7432028812de3182e257e219463f7cf28d49d573dd witness ArmoredWitness-floral-sky e90299398a4d39d030da888a0923ecf16786881ac12243db73c9f0cf2a2d80e6 group GoogleTrustFabric 8 ArmoredWitness-falling-pondArmoredWitness-weathered-rain ArmoredWitness-wispy-wood ArmoredWitness-small-breeze ArmoredWitness-quiet-wood ArmoredWitness-morning-darkness ArmoredWitness-shy-wind ArmoredWitness-hidden-river ArmoredWitness-autumn-wood ArmoredWitness-snowy-sound ArmoredWitness-throbbing-bird ArmoredWitness-rough-wind ArmoredWitness-dry-sunset ArmoredWitness-nameless-firefly ArmoredWitness-floral-sky
quorum GoogleTrustFabricThis is not listed on www.sigsum.org yet. For the script I ran and did a bit of cut-and-paste from to extract the appropriate public keys, see:
https://www.rgdd.se/volatile/aw-config