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. ________________________________ From: [email protected] <[email protected]> on behalf of Matt Palmer <[email protected]> Sent: 22 October 2024 23:54 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 Tue, Oct 22, 2024 at 05:25:17PM +0000, Corey Bonnell wrote: > For better or worse, it is not uncommon to install linting software on > the same host as the CA system itself. I'll vote for "worse", for whatever it's worth. > In fact, that is how one popular CA software suite invokes external > linters: it expects a CLI tool to be installed locally to perform > linting. Given that pkimetal runs as a HTTP service, the "CLI tool" that the CA software runs would need to be a `curl | jq` (or similar) shell script. That would remove the need for pkimetal itself to be running on the same machine even for that CA software suite. > Having a linter running on the CA host dial out to the wider Internet > is not a good idea given the security-sensitive nature of the host and > the software it is running. Having *anything* running on the CA host itself dial out to the wider Internet seems like a recipe for giving your SOC a regular panic attack. > A secondary concern is that external API calls are harder to reason > about in terms of performance impact due to variability in API > response times. 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. Hell, I can provide a replication slot on the PostgreSQL database (that you can feed into a machine in your infrastructure) if that'll work. But nobody has ever actually reached out to discuss how to come up with a design that meets both parties' needs. For example, every time someone says "why not just provide an SPKI dump?", I explain why that won't work without additional engineering to ensure currency of the dataset, and then... crickets. - 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 on the web visit https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2Fbafdf285-5fcd-4fbc-893f-80a88bdf4e59%2540mtasv.net&data=05%7C02%7Crob%40sectigo.com%7C7a6cf63b3ae6407fdda808dcf2ec6fbb%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638652344509991077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=yjerVWPZI9RVe65TlnrDht6qRA9dopSKwR9HALRKmuU%3D&reserved=0<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/bafdf285-5fcd-4fbc-893f-80a88bdf4e59%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/MW4PR17MB4729F8ABB9BAFB2A7877D5FCAA4F2%40MW4PR17MB4729.namprd17.prod.outlook.com.
