Hi Matt. I completely understand your strong preference for the freshest data to be used, but I'm not convinced that it's wise to make the perfect the enemy of the good.
We're talking about situations where Pwnedkeys is currently not being used at all, due to the requirement to call an API over the internet. Yes, I am suggesting pre-bundling a point-in-time snapshot of the Pwnedkeys dataset with pkimetal, which would become progressively out-of-date. Are you suggesting that checking against an out-of-date list is no better than doing no checks at all? ________________________________ From: [email protected] <[email protected]> on behalf of Matt Palmer <[email protected]> Sent: 25 October 2024 22:47 To: [email protected] <[email protected]> Subject: Re: Standard PKC Test Keys CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2Fa8f4d04e-4470-4c7c-8b8a-23847394aa54%2540mtasv.net&data=05%7C02%7Crob%40sectigo.com%7C10e21b4322794d2cb81f08dcf53ea091%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638654896548317137%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=v6z48Mra9%2BciOssM%2FRbNTmVhhdxivrLvrdtwBDDDUX4%3D&reserved=0<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/a8f4d04e-4470-4c7c-8b8a-23847394aa54%40mtasv.net>. -- 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/MW4PR17MB472908CEC1787DF06E8ABC21AA542%40MW4PR17MB4729.namprd17.prod.outlook.com.
