pkimetal v1.0.0

[Rob Stradling]

Following on from my presentation at the SCWG F2F meeting in Bergamo, I'm delighted to announce that the first stable release of pkimetal is now available.

pkimetal is a PKI meta-linter.  It integrates multiple linters behind a simple REST API, making linting more performant, scalable, and easier for CAs to deploy.

Please see README.md in the open-source repository for more detailed information and documentation: https://github.com/pkimetal/pkimetal

Prebuilt Docker containers are available via the GitHub Container Registry.

Public instances are available at https://pkimet.al/ (stable release) and https://dev.pkimet.al/ (development release), although it is not recommended to use these instances in a production CA system.

--

Rob Stradling

Distinguished Engineer

Sectigo Limited

[Matthew McPherrin]

Congrats on the release, Rob. I look forward to trying this out!

--
You received this message because you are subscribed to the Google Groups "Public (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@groups.cabforum.org.
To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/MW4PR17MB47297C12D7369DB3E76B7FF6AAB42%40MW4PR17MB4729.namprd17.prod.outlook.com.

[Tim Hollebeek]

Happy to see everyone working together on all the great recent improvements in automated compliance enforcement!

 

-Tim

--

[Sina Keshvadi]

Congratulations, Rob! This is a significant step forward for the PKI community.

I'm particularly interested in the performance improvements and how pkimetal handles the integration of diverse linting tools.
Would you be able to share some insights into the architectural decisions that made this possible? (if you have time of course)

Thanks,

Sina

[Rob Stradling]

> Congratulations, Rob! This is a significant step forward for the PKI community.

Thanks Sina.

> I'm particularly interested in the performance improvements

Quoting https://github.com/pkimetal/pkimetal?tab=readme-ov-file#why-use-pkimetal:

• Performance: Most of the available linters are designed to be run from the command line, linting one input file each time. With some linters, repeating this process for multiple files can incur some pretty severe performance penalties: the overhead of starting up the programming language interpreter each time, and the overhead of initiating the linter functionality each time. These overheads mean that, for example, it can take half a second to lint just one certificate, which would be a bottleneck for many CAs' certificate issuance rates. pkimetal incurs these performance penalties only once, making the linting of multiple PKI artifacts up to 20x faster!
• Scalability: Even 20x faster might not be enough for some high-volume certificate issuers. pkimetal can run multiple instances of most linters, taking advantage of multiple CPU cores.

> and how pkimetal handles the integration of diverse linting tools.

pkimetal is written in Go, so integrating Go linters (zlint and dwklint) was simple.  Integrating x509lint (written in C) was achieved via CGO.

The Python (pkilint and ftfy) and Ruby (certlint) linters are executed in child processes that are forked by pkimetal when it starts up.  Communication between pkimetal and these child processes is via STDIN/STDOUT.

If you're interested in further detail, please take a look at the linter integration code at https://github.com/pkimetal/pkimetal/tree/main/linter.

The Dockerfile also plays a significant role.

> Would you be able to share some insights into the architectural decisions that made this possible? (if you have time of course)

One decision I made was to adopt a plugin architecture for the linter integrations, to make it as simple as possible to add further linters in the future.

---

From: Sina Keshvadi <webi...@gmail.com>
Sent: 30 July 2024 16:41
To: Public (CA/B Forum) <pub...@groups.cabforum.org>
Cc: Rob Stradling <r...@sectigo.com>
Subject: [public] Re: pkimetal v1.0.0

 

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.

--
You received this message because you are subscribed to the Google Groups "Public (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@groups.cabforum.org.

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/b9e4bb59-d966-4525-bd54-3c490a8cdae3n%40groups.cabforum.org.

[Sina Keshvadi]

Thank you. I am going to try it and see how it can be used in a research project.

Best,

Sina

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/MW4PR17MB4729C2D751A8EF8BBA3802CCAAB22%40MW4PR17MB4729.namprd17.prod.outlook.com.

[Bineesh]

Thank you for sharing. Any plans to include weak key validations to PkiMetal ?

Thanks

Bineesh

[Rob Stradling]

Hi Bineesh.  (Sorry for the slow reply; this got stuck in my post-holiday backlog).

One of the linters integrated by pkimetal is dwklint, which is (currently) dedicated to checking for Debian Weak Keys as described by SC-73.  (Example, via crt.sh: https://crt.sh/?id=7799145606&opt=pkimetal).

Another of the linters integrated by pkimetal is Zlint, which checks for Close Primes.  (Example, via crt.sh: https://crt.sh/?id=4498686774&opt=pkimetal).

However, it looks like none of the linters integrated by pkimetal check for the ROCA vulnerability.  To address this, I'll implement a ROCA check in dwklint.

---

From: Bineesh <bin...@gmail.com>
Sent: 29 August 2024 16:37

To: Public (CA/B Forum) <pub...@groups.cabforum.org>

Cc: Sina Keshvadi <webi...@gmail.com>
Subject: Re: [public] Re: pkimetal v1.0.0

 

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/1bf2f563-21c1-47ef-80dc-c6dea5c14ee6n%40groups.cabforum.org.

[Antonis Eleftheriadis]

Integrating with badkeys might be a good idea because it contains checks for a lot of issues.

Regards,
Antonis

Στις 17/9/24 19:26, ο/η 'Rob Stradling' via Public (CA/B Forum) έγραψε:

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/MW4PR17MB47290D5725349915013389FAAA612%40MW4PR17MB4729.namprd17.prod.outlook.com.

[Rob Stradling]

> However, it looks like none of the linters integrated by pkimetal check for the ROCA vulnerability.  To address this, I'll implement a ROCA check in dwklint.

I (re)discovered Jonathan Rudenberg's Go implementation (https://github.com/titanous/rocacheck), which I've integrated as an additional linter in pkimetal v1.6.0.  (dwklint remains focused solely only checking for Debian Weak Keys).

---

From: Rob Stradling <r...@sectigo.com>
Sent: 17 September 2024 17:26

[Rob Stradling]

Hi Antonis.  Thanks for the suggestion.  I've implemented this in https://github.com/pkimetal/pkimetal/pull/125.  Already available at https://dev.pkimet.al, and I'm intending to do a Stable release later this week.

---

From: 'Antonis Eleftheriadis' via Public (CA/B Forum) <pub...@groups.cabforum.org>
Sent: 19 September 2024 14:21
To: pub...@groups.cabforum.org <pub...@groups.cabforum.org>

To view this discussion on the web visit https://groups.google.com/a/groups.cabforum.org/d/msgid/public/cd3d7f50-a07b-4f18-a009-504c7cd81f4b%40harica.gr.

[Bineesh]

Thank you for looking into it Rob !