On Fri, Oct 25, 2024 at 11:00:29AM +0000, Rob Stradling wrote: > Thanks Matt. > > > I'm not averse to providing the pwnedkeys dataset in other forms, if the > > live-query-over-HTTP model is the only barrier to adoption by someone > > who will make use of the data. > > You have my attention. 🙂 > > I'd like to ship the pwnedkeys dataset with pkimetal. I think it would be > uncontroversial for pkimetal to enable local pwnedkeys checks by default. > > I think bundling the actual keys and signed evidence of compromise with > pkimetal would be overkill and that that full dataset would be prohibitively > large, so I would be looking to create a system that downloads all of that > information, verifies all the signatures, and produces a compact list of > pwned SPKI hashes that would be bundled with pkimetal. For transparency, I > would want to make the download-and-verify process open-source so that anyone > can reproduce it if they want to.
The important requirement I have for use of the Pwnedkeys dataset is that it *must* be kept fresh. New keys are constantly being discovered, and I don't believe it's unreasonable for anyone that says "I am checking for compromised keys using Pwnedkeys" to always be checking against something that closely approximates the then-current set of known-compromised keys. That is why the current HTTP query approach is what I've initially rolled out: I can be confident that everyone doing a query is checking the current dataset as of the time of that query (or my monitoring will tell me there's a problem and I can fix it ASAP). Your proposed approach of pre-bundling, as I understand it, doesn't appear to meet that requirement, as it would seem to capture a point-in-time snapshot of the Pwnedkeys dataset. This would become progressively out-of-date, and only come back towards currency when the bundling process was re-run *and* the operator's local pkimetal installation was updated. I have my doubts that operators would be updating their pkimetal installations, say, hourly, and even that is a much larger discovery -> disclosure delay than is currently provided by the HTTP query mechanism. - Matt -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a8f4d04e-4470-4c7c-8b8a-23847394aa54%40mtasv.net.
