- Sigsum-general - Sigsum mailing lists

Multi proofs for multi signing?
by Giulio 23 Oct '25

23 Oct '25

Hi all, In WEBCAT we're adding support for multiple signatures over the same artifact (a manifest). How we log that depends on the monitoring story. One (probably not great) option would be to sign the artifact once with a known key (which one, though?) and log that artifact that includes the N signatures once in Sigsum. The downside is that the Sigsum leaf would then be discoverable only via the submitting key, not by the individual signer keys. If we want per-key transparency, we should instead submit each signature over the artifact to Sigsum and get a proof for each. That seems best for monitoring and seems to be the least hacky design. Assuming all signatures (and proofs) need to adhere to the same trust policy, there's a lot of duplication when gathering individual proofs. My understanding is that we can wait until all leaves are included in the same tree, collect a single cosigned tree head (STH), and verify the log signature and cosignatures once. Each leaf will have its own inclusion path, but many hashes will overlap. This reduces verification work (one STH validation instead of N) and total size on the wire. Does this usage make sense? For a first step, I'd like to just fetch per-leaf proofs for the same tree size so I can reuse the same STH, without trying to merge paths yet. If that sounds reasonable, is this a mode of operation Sigsum would be interested in supporting in the client (i.e., worth a PR), or should I implement it on top using the log APIs directly? Thanks! Giulio

2 3

Temporal guarantees of Sigsum proofs
by Giulio 23 Oct '25

23 Oct '25

Hi all, After a conversation with rgdd, I was trying to understand what kind of temporal guarantees a Sigsum entry can provide. For instance, I need something akin (but slightly less strict) to a timestamping authority: something that can attest that a certain signature was included on a specific date, or at least definitely not afterwards. This would allow me to enforce expirations over signed artifacts: if an artifact was included after a certain threshold (e.g., 30 days after signing), I could consider it expired, knowing that the corresponding signature couldn’t have been forward-dated. A naive way to achieve this without Sigsum would be to submit the content to a timestamping authority (TSA), then include the TSA’s signed timestamp within the content to be signed. However, this approach introduces a single point of failure (a trusted third party) and adds unnecessary format complexity. Since inclusion proofs from a Sigsum server already include a cosigned checkpoint with a timestamp, I was wondering whether similar guarantees could be derived from these components. My concern is that if I simply trusted the timestamp in the checkpoint, the logic wouldn’t hold: anyone could request a new inclusion proof at a later time, which would include a newer checkpoint timestamp and an updated tree head. One immutable element between proofs is the leaf index, which correlates monotonically with inclusion order, though not directly with wall-clock time. A possible workaround would be to require proofs where the tree size in the checkpoint is at most N leaves ahead of the included leaf (say < 10), ensuring some temporal proximity between signing and inclusion. However, this approach would prevent me from obtaining new proofs for old signatures, for instance, after witness rotation, unless there was an archive of checkpoints (and the same for witnesses)? Summarizing: is there a way to use the Sigsum log server and the witnesses to attest that an inclusion happened at a specific timestamp? Thank you, Cheers, Giulio

2 3

Sigsum verifier in TypeScript
by Giulio 17 Jun '25

17 Jun '25

Hey there, as part of the work on WEBCAT I've rewritten a Sigsum verifier in browser-native TypeScript, this time that actually checks inclusion proofs ;) https://github.com/freedomofpress/sigsum-ts There's 100% coverage, and I've written many tests, though there likely still some niche case that I'm missing, but overall I'd plan to use it in a less experimental but still beta release in a few months. If no objections, will publish the package on npm in a few days! In many parts Ive just followed line by line the original Go code and translated in TS, in others I've taken a bit more liberty. I'll add support for JSON based formats for proofs and policies as anticipated in a previous thread. Cheers, Giulio

2 3

Policies and web-friendly format
by Giulio 19 May '25

19 May '25

Dear all, I've started looking into building a more complete and stable Sigsum verifier to run in the browser extension I'm prototyping. The model I sent previously changed a bit, we are removing Sigstore, to allow website administrators to specify their own ed25519 signing keys, and bring their own logs. The "bring your own log" model has been suggested in the WAICT proposal[1], and I think it improved decentralization for the better. I think the WAICT proposal refers to a type of log, or in general to log software that does not exists yet, and I think Sigsum fits the job well. I would like thus for website administrators to specify a Sigsum policy, but since that will be shipped in the HTTP headers, I'd need something more serialization friendly, such as JSON. While looking into the policy format, I was wondering why the quorum is global and not per log? In a JSON like format, I was imagining something like this, also to reduce to the minimum key/texts duplication: { "witnesses": { "X1": "base64-key-X1", "X2": "base64-key-X2", "X3": "base64-key-X3", "Y1": "base64-key-Y1", "Y2": "base64-key-Y2", "Y3": "base64-key-Y3", "Z1": "base64-key-Z1" }, "groups": { "X-witnesses": { "2": ["X1", "X2", "X3"] }, "Y-witnesses": { "any": ["Y1", "Y2", "Y3"] }, "Z-witnesses": { "all": ["Z1"] }, "XY-majority": { "all": ["X-witnesses", "Y-witnesses"] }, "Trusted-Bloc": { "any": ["XY-majority", "Z-witnesses"] } }, "logs": [ { "base_url": "https://log-a.example.org", "public_key": "base64-logkey-A", "quorum": "X-witnesses" }, { "base_url": "https://log-b.example.org", "public_key": "base64-logkey-B", "quorum": "Trusted-Bloc" } ] } It's just exploratory, but I'm a bit confused by the multi-log model. For instance, you'd expect the signers to send to two logs and then provide back two proofs bundles, or you'd expect a log with a policy with multiple logs, to propagate to the second log? In this format, I'd support per-log quorum, and probably thus expect multiple proofs. Cheers Giulio [1] https://github.com/rozbb/draft-waict-transparency/blob/main/draft-waict-tra…

2 3

Experimental project using Sigsum and Sigstore to sign and verify web-applications in the browser
by Giulio 05 May '25

05 May '25

Hi all, For my master's thesis, and as a way to showcase a solution to the long-standing problem of using web applications for cryptographic tasks in the browser, without having to rely on server trust, I've developed a system that integrates a few components: - Sigsum is used to transparently build a list of authorized signers for each domain that wants to participate in the system. - Sigstore is used to sign executable web assets (JS, HTML, CSS, WASM) using OIDC identities, with the authorization for a specific domain verified against the Sigsum-powered list. The demo shows the system securing some of the most common self-hostable web apps, such as Jitsi, Element, and CryptPad. There is currently some shared interest from the Tor Project in bringing similar functionality into TBB. For a higher-level description, see [1], and for the project repository, see [2]. I’ll share my thesis at a later date, which will include additional insights and threat modeling for the whole system. Cheers Giulio [1] - https://securedrop.org/news/introducing-webcat-web-based-code-assurance-and… [2] - https://github.com/freedomofpress/webcat

2 3

Sigsum proof specification
by Simon Josefsson 10 Mar '25

10 Mar '25

Hi Your file format document is a great document: https://git.glasklar.is/sigsum/core/sigsum-go/-/blob/main/doc/sigsum-proof.… I have some ideas for how to improve it; I may have mentioned these before but would like to summarize the ideas and ask for your feedback: 1) Suggest a filename extension It seems some people use *.proof although *.sigsum-proof may be more advertizy. Or just *.sigsum? 2) Suggest a filename naming convention It should also suggest that the common way to name a Sigsum proof file is to name it after the file it contains a proof for, and include an example like: hello-2.1.3.tar.gz hello-2.1.3.tar.gz.proof 3) Specify a MIME media subtype. I suggest "text/sigsum-proof". 4) To be a clear MIME media subtype specification it should discuss character set encoding concerns. The document already refer to ASCII and I suggest making this even more explicit: Sigsum proof files MUST be 7-bit clear ASCII files and MUST NOT contain any byte with the high bit set. 5) Add a ABNF grammar describing the format. 6) Discuss how to handle non-compliant data. For example is a "#" comment line allowed? Is adding/removing whitespace allowed? CRLF vs CR vs LF vs NUL etc delimiters? Behaviour if the format doesn't comply with the grammar? "Applications MUST generate compliant data and MUST be able to parse compliant data, and SHOULD NOT use non-compliant data. A valid reasing for accepting non-compliant data is if the applications for some reason is unable to implement a strict parser." 7) Putting the text into an IETF draft would be useful, as a reference for the MIME media subtype registration and a file format reference. I'm sure you know the process, but I'm happy to put this together and submit it if you want. 8) Versioning... the following document makes me a little nervous that the file format is still in flux which is detrimental for deployment: https://git.glasklar.is/sigsum/project/documentation/-/blob/main/proposals/… It may be useful to discuss if all file format versions are using the same filename extension, convention, MIME media sub-type, and if so any discussion how entities should behave when parsing and generating files. I think there are two options: 1) Pretend version 1 never existed and just remove all support for it. 2) Document that applications MUST generate version 2 format, and applications MUST handle both formats and MUST discard the short 'leaf' checksum. /Simon

3 47

sigsum proofs in GNU libtasn1 release
by Simon Josefsson 07 Mar '25

07 Mar '25

Hi Here is a software announcement with pointers to Sigsum proofs https://lists.gnu.org/archive/html/help-libtasn1/2025-02/msg00000.html The artifact can be reproduce by GitLab pipeline or offline by following the same recipe as in .gitlab-ci.yml ('R-guix' job) on the git tag. Ideas for improvements? Are you able to build a "libtasn1 release monitor" out of this information? /Simon

5 15

Feedback on documenting log operations
by Rasmus Dahlberg 30 Jan '25

30 Jan '25

Hi everyone, Glasklar runs its first stable Sigsum log since a few months ago. We finally got around to also writing down what to expect from this log. https://git.glasklar.is/glasklar/services/sigsum-logs/-/blob/main/instances… It's a first draft. We're hoping to gather feedback for at least 90 days, so read this as what we're currently trying out and adjusting based on feedback from you all: what's good, bad, ugly, unclear, unexpected, missing, etc. All kinds of feedback is appreaciated! -Rasmus

1 0

On the naming of Sigsum services
by Linus Nordberg 30 Jan '25

30 Jan '25

Warning: Boring naming scheme discussion ahead. And as if that wasn't enough I'm going to propose that we become more boring, not less. ## What I would like for us to move away from "pet names" for stable Sigsum services, including log instances. Or if we decide to keep them, choose them in a way that provides some context. ## Why Pet names without any context requires everybody to memorise a token and connect it to a Sigsum service. While this might be ok for those who work with them a lot, I find it a bit presumptuous to ask everyone else to do that. Compare Debian release names. ## How One kind of context that would have particular value for all but the few of us who work with Sigsum daily would be a connection to Sigsum. Prefixing names with "sigsum-" would be one way of doing this. Another type of context could be provided by including in the name the type of service provided. "log" and "witness", "wit" or "wtn" come to mind. It could be argued that the cleverly chosen families of animals currently used provide such context but I don't think that is helpful. Yet another, useful in cases where we know that there is an upcoming incompatible protocol change, would be to include a version number. ## Random, minor Non stable services, like current test log "jellyfish", are presumably used by fewer and more involved people and can keep being named like pets. ## Going forward Happy to turn this into a proposal if there's any support for this position.

4 11

Origin line issues
by Niels Möller 11 Oct '24

11 Oct '24

Hi, I said during the witnessing breakout at tdev that I'm afraid that the origin line as id is coming back to bite us. Let me expand a little on the problem I see. For a start, when adding keys for logs or witnesses to the trust policy for log users, it's clear that care and due diligence is required. That's natural, and I don't think origin line or other non-cryptographic ids in the picture is much of a problem. However, I think it's desirable that logs and witnesses are decoupled. When an operator of a log or witness gets an email "please add my new shiny witness/log to your config", I think it's rather important that no subtle or complicated due diligence is required, and that there are no severe or surprising consequences for temporarily adding a malicious entry. Main problem is for witness operators, and in particular if trying to run a witness on a device like the tkey with minimal configuration. For a sigsum log, with origin line based on keyhash, the only irreversible consequence when a witness operator adds a new log to the witness config is a commitment to storing a record (on the order of 100 bytes) for that log for the entire lifetime of the witness. If the log causes other operational problems, it could be rate limited or completely removed from the config, and that's it. The tkey app could happily accept any add-checkpoint request + log pubkey from the host, verify everything, and store the (pubkey, treehead) on success. A compromised host could fill up the tkey storage, preventing the witness from adding new logs later on, but that's about the worst it could do. On the other hand, if the host provides a pubkey and a checkpoint with an arbitrary origin line, that mapping needs to be authenticated. If not, an attacker could make it's own keypair for anyone else origin line, push a tree head with new leaves to the witness, and the witness would then refuse cosiging genuine tree heads for that origin. If we envision that people will start lots of application specific logs, and want them cosigned by public witnesses (e.g., consider a thousand github projects doing "serverless logs" in their github actions (if that makes sense, I'm not that familiar with github)), it's clear that adding logs to a witness config must be easy. The witness needs an authority mapping origin lines to keys. In the tkey case, the simple solution would be to have that authority sign some kind of certs defining this binding, and embed the ca pubkey in the tkey app binary. (For key rotation, one could consider accepting certs signed by previous key rather than the ca, but the ca is still needed for new logs). And then origin line owners should demand transparency for those certs, and we're down the rabbit whole. Finally, on the log side, for a non-sigsum log that publishes cosignatures as checkpoints, we have a related issue with the witness key names. I think that's less severe: if a bad witness is added, the log might publish cosignatures where the pubkey doens't belong to the "proper" owner of a key name, which will look invalid to users that have the right keys for that name, but that is a recoverable problem; once the problem is pointed out, the log can just drop that witness, and it will not appear on later checkpoints. So what would be my take aways, accepting that the "ship has sailed" on radical changes, and this isn't the right time for cosignature/v2? 1. We should define a origin line scheme similar to sigsum.org/v1/tree for use by non-sigsum logs that don't need key rotation. And strongly recommend that logs that don't have an urgent need for key rotation use that scheme. The advantage for logs that follow this scheme is that it's very cheap for witnesses to add their logs, since no due diligence on who's the proper "owner" of that origin line is needed. We will in effect get two classes of logs: Those with self-authenticating origin lines, and those that need require additional data or context to establish an authentic mapping between name and keys. (Again, this is an issue in the context of making witness operation easy; defining a proper trust policy will always require more information about a log than just what its key is). 2. Witness operators need to document what procedures they use to validate origin lines of logs they are asked to witness, and how they validate new public keys to be added for that origin line. 3. It would be nice if those operating logs identified by arbitrary origin lines, like "go.sum database tree", outline what procedures they'd like a witness to take before accepting a new public key for that log. For example, say Debian wants to run a witness for the go checksum database and patch go tooling to require that as an additional witness in the trust policy, how will they get authentic information about key rotation events? (Making a replica of the log and witness that, instead of witnessing the upstream log, as was suggested at the breakout, doesn't seem like an attractive alternative to me. With a new origin line, witness cosignatures on the upstream log won't verify, so they are effectively lost. And one would still need that authentic key for the upstream log, when building the replica. But maybe that alternative could be fleshed out). 4. How should we act when we find that a witness used a "wrong" or unexpected public key to verify a checkpoint for some origin? The witness clearly can't cosign any later tree heads for the proper view of that log, and it should be removed from policies involving that log. But perhaps we should make it very clear that this is possible result of an honest mistake, and not hold that against the witness operator's reputation? 5. We could think of alternative ways to do key rotation, e.g., starting a new log under a fresh key, and adding a special leaf at index 0 including the signed tree head of the old log + needed metadata. And possibly with a corresponding forward link in the tombstone message of the old log. /nisse

1 0

2025

2024

2023

2022

2021

Sigsum-general