Sigsum-general

Download

sigsum-general@lists.sigsum.org

June 2026

2 participants
2 discussions

Transparency.dev Summit 2026 -- CFP just opened
by Rasmus Dahlberg 24 Jun '26

24 Jun '26

Hi everyone, We're well under way planning this year's Transparency.Dev Summit, which is taking place 29 Sep - 1 Oct at Google Montreal. * Summit website: https://transparency.dev/summit2026/ The call for presentations just opened, and we're looking for submissions on a wide variety of transparency topics. * CFP link: https://docs.google.com/forms/d/e/1FAIpQLSds5HdEVXDssOKYETEEMoTbveqJe8i2QyP… Please consider if you or someone from your organization should submit a talk, and help us share the CFP with those that should be aware of it. Best, Martin and Rasmus

1 0

Follow up from weekly meet -- examples of incidents in CA/CT space
by Rasmus Dahlberg 05 Jun '26

05 Jun '26

Hi Justin, @CC sigsum-general. As requested on the last weekly meet, here are a few incidents that help motivate CT. - DigiNotar (you're probably familiar already, but including it in case it's interesting for others on this mailing list). One of the seminal incidents that was used as motivation for inventing CT. CT could in particular have reduced the time the attacks were ongoing. And I always emphasize: what if the attacker had been more stealthy? - https://www.enisa.europa.eu/sites/default/files/all_files/Operation_Black_T… - Few more incidents, I was in particular looking for the facebook "user story" but I couldn't find a working link (I have no login). - https://certificate.transparency.dev/community/#successes-grid - You will also find some more CA incidents in Andrew Ayer's enumeration (which haven't been populated since ~2018 or so). - https://sslmate.com/resources/certificate_authority_failures - MitM in datacenter, CT monitoring would have discovered much sooner (Or: had forced the provider to attack inside the VM). - https://notes.valdikss.org.ru/jabber.ru-mitm/ - Unexpected certificate for Cloudflare's 1.1.1.1 - oops. I like this one in particular because it showcases that it is not always easy to have a working monitor configuration, and that is a fundemental assumption. Making CT monitoring easy and non-noisy is, e.g., why we put together silentct (https://git.glasklar.is/rgdd/silentct) - https://blog.cloudflare.com/unauthorized-issuance-of-certificates-for-1-1-1… - ...there's more, but the above is what I usually use as examples. FWIW: you'll also find several issues with CT log operations, but I think you were rather looking for incidents that transparency logs detected, could have detected, or even prevented (which as discussed during the weekly is a bit harder to provide clear pointers to). If you're anyway looking for some log incidents, see: "Several log incidents have already happened in the past, ranging from split-views [ 6, 92, 93 ] to broken promises of timely logging [ 29, 37, 5, 91 ] and potential key compromise [ 84 ]." for links in my PhD thesis (2023). Another incident I like to remember: the San Bernardino case between Apple-FBI. Having a strong transparency log story for rolling out updates to this iPhone would have made it possible to monitor this case, and if anything similar happens behind the scenes it could similarly be detected with a transparency log. This is one of the earlier cases (from when I got involved in the space) that made be understand that binary transparency (and its long umbrella @ supply chain security) is pretty awesome. Also note the thread model here - gossip would not be good enough, because this iPhone is isolated. The witness cosigning stuff we're pushing for modern transparency logs defends against this. This threat modelling aspect is mainly why I'm including this example. https://en.wikipedia.org/wiki/Apple%E2%80%93FBI_encryption_dispute -Rasmus

2 1