[{"url":"https://api.github.com/repos/mozilla/crlite/issues/comments/5998938521","html_url":"https://github.com/mozilla/crlite/issues/392#issuecomment-5998938521","issue_url":"https://api.github.com/repos/mozilla/crlite/issues/392","id":5998938521,"node_id":"IC_kwDOB9GFrc8AAAABZZCJmQ","user":{"login":"jschanck","id":25615540,"node_id":"MDQ6VXNlcjI1NjE1NTQw","avatar_url":"https://avatars.githubusercontent.com/u/25615540?v=4","gravatar_id":"","url":"https://api.github.com/users/jschanck","html_url":"https://github.com/jschanck","followers_url":"https://api.github.com/users/jschanck/followers","following_url":"https://api.github.com/users/jschanck/following{/other_user}","gists_url":"https://api.github.com/users/jschanck/gists{/gist_id}","starred_url":"https://api.github.com/users/jschanck/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jschanck/subscriptions","organizations_url":"https://api.github.com/users/jschanck/orgs","repos_url":"https://api.github.com/users/jschanck/repos","events_url":"https://api.github.com/users/jschanck/events{/privacy}","received_events_url":"https://api.github.com/users/jschanck/received_events","type":"User","user_view_type":"public","site_admin":false},"created_at":"2026-10-05T16:45:57Z","updated_at":"2026-10-05T16:45:57Z","body":"> 1. Is the lag on Xenon2026h2, Wyvern2026h2 and Sphinx2026h2 known, and is it capacity (ct-fetch throughput on the largest RFC 6962 shards) or something else?\n\nThe lag on those logs is known and it is due to rate limiting. We monitor log ingestion rate closely. I have a public dashboard with some of our data [here](https://finiterealities.net/crl_audit.html). The upshot is that the performance of RFC 6962 logs has not kept up with the growth of the WebPKI, and monitors are struggling across the ecosystem. You'll find several threads on this topic on the ct-policy mailing list, e.g. https://groups.google.com/a/chromium.org/g/ct-policy/c/lTqtb4WHsqo/m/38t48RAyAgAJ, and https://groups.google.com/a/chromium.org/g/ct-policy/c/I7xlqUM-5w0/m/9vRPnNnGAgAJ. Fortunately we expect a significant uptick in the use of static CT logs in the coming months, and no log operator is planning on running an RFC 6962 log for 2028.\n \n> 2. TrustAsia log2026a/b are usable and still accepting entries (we got fresh entries included in under 2 minutes), but coverage stopped on 2025-11-25. Dropped on purpose?\n\nWe are still ingesting TrustAsia log2026a/b, but our requests are severely rate limited.\n\n> 3. Is the 5% \"not covered\" figure in the Clubcards paper still what telemetry shows, and does Mozilla track which logs the uncovered certificates come from?\n\nThe current value is closer to 13%, see https://dl.acm.org/doi/abs/10.1145/3789240.3829108. We do not track which logs the uncovered certificates come from, but we do track the age of uncovered certificates. For instance, I can tell you that 75% of uncovered certificates have a notBefore date that is more than 9 days in the past. From this it's obvious that the majority of uncovered certificates are presented with SCTs from RFC 6962 logs exclusively.\n\n> 4. Would the client be safer falling back to OCSP for NotCovered certificates older than one MMD, since the filter's own metadata shows the gap isn't the merge delay?\n\nThis is not really an option. CAs are no longer required to support OCSP, and several major CAs including Let's Encrypt and Google Trust Services turned down their OCSP services last year. \n\n","author_association":"COLLABORATOR","pin":null,"reactions":{"url":"https://api.github.com/repos/mozilla/crlite/issues/comments/5998938521/reactions","total_count":0,"+1":0,"-1":0,"laugh":0,"hooray":0,"confused":0,"heart":0,"rocket":0,"eyes":0},"performed_via_github_app":null,"minimized":null}]