June 2025 meeting minutes (Foundation BAC)

Foundation BAC meeting (June 24, 2025)

Attendees:

• Using ML-KEM with old (pre-3.5) FIPS providers (Dmitry)

  • See: https://github.com/openssl/openssl/pull/27728

  • fips=yes is a hack. Encoders and decoders are outside of the FIPS boundary, but cryptographic algorithms are not. (Paul)

  • This is not FIPS validation and could be confusing for users who don't know that. (Tomas)

  • Is it a desirable feature to support at all? (Matt)

  • Paul concerns about this particular implementation, but thinks it’s a good idea to support.

  • Foundation focus on non-commercial communities (Matt)

    • FIPS might give non-commercial a good feeling, but provide no value. (Randall)

    • Red Hat wants to make sure that FIPS can work on Fedora. (Dmitry)

    • May change our mandate/scope if we consider precursor projects. (Randall)

  • Let Corporation take the lead (Matt)

  • TAC should decide how it should be done (Paul)

  • No objections to implementing it, but it might not be a Foundation priority

• OpenSSL Conference (Jon)

  • The BAC will be on the program committee and will be able to vet submitted talks. More details to come. (Jon)

  • Face-to-face meetings? (Matt)

  • Not all of the BAC will be able to make the conference, but Matt will find a time for those who can.

• Communities platform best practices (Jon)

  • See the OpenSSL community site walkthrough (Jon)

  • Feel free to ask follow up questions

• OpenSSL Open hours (Matt and/or Jon)

  • Proposal: submit a form so that we don’t need to sit around waiting for someone to show up. (Jon)

  • Fixed time, but cancel if there is no agenda (Dmitry)

• Formally verified crypto implementations/Memory-safe language rewrite (Rust, Zig, etc) (Nicola)

  • Academic community is interested in potential plans for verified crypto and/or memory-safe rewrite

  • Dmitry also gets questions about these items

  • The Foundation has no plans, but we aren’t categorically against these ideas. The BAC should consider them in the list of priorities. (Matt)

  • “Competitors” are moving in that direction. Is there a risk to the project in not pursuing these goals? (Nicola)

  • Maybe a hybrid approach that rewrites parts of OpenSSL in Rust or whatnot. (Matt)

  • Project starts a fork that implements a subset of the functionality that is written in Rust. (Tomas)

  • OpenSSL will build and run on virtually any platform that’s around. Is there an LTS commitment? It’s a very big question. (Randall)

  • Is there a risk that memory-safe could be mandated in the future? (Nicola)

  • Staff developers might allow this to be possible. (Randall)

  • Formally verified stuff can be done incrementally and by anyone (Matt)

  • Example: GitHub - ericmercer/sha3-verification: SAW Verification of OpenSSL's SHA3 Implementation (Tim)

  • Can we just provide the framework (Matt)

  • Memory-safe languages also have potential problems (Dmitry)

  • Can we achieve memory-safe using C? (Randall)

  • There is memory-safe C, but it's slow. (Tomas)

• AOB

  • Reconsider LMS verify. Oracle and Cisco are interested. Signing is unsafe, however. (Paul)

    • This is also an interest to the academic community too. (Nicola)

    • Light weight and avoids new PQC mathematics (Paul)

    • Implementation just needs a final review (Paul)

    • Tim wanted LMS from the get go.

    • All in favor so Paul should raise the PR

  • Should the BAC have a panel or other presence at the conference (Nicola) 

  • We are hiring a C engineer
    

Action items

• Submit a PR about LMS verify (Paul)

• Set up a form and possible time slots for open hours (Jon)

• Add memory-safe and formally verified to the priority list (Jon)

• Open a thread on the communities about BAC involvement at the conference (Nicola)

• Find a time for a face-to-face meeting around the time of the conference (Matt)