OpenSSL Blog

Face-to-face Meetings: OTC and Committers, Day 1

Posted by Anton Arapov ,

  • The OTC retrospective highlighted the need for diversity and improved communication.
    • A proposal for a Special Interest Group (SiG) model was made.
    • The necessity for regular communication with communities was identified.
    • A need for reevaluation of membership criteria was highlighted.
  • The team acknowledged the presence of technical debt in OpenSSL. Challenges like code redundancy and inconsistent APIs were noted within OpenSSL. Refactoring was seen as a potential solution to these OpenSSL challenges.
  • Updates and improvements to the Certificate Management Protocol (CMP) were discussed. Focus was placed on interoperability and testing within the CMP.
  • Red Hat engineers shared their journey towards FIPS compliance. Their approach to security vulnerabilities was discussed.
  • Solutions for managing parameters and configurations were examined.
  • The challenge of accessing entropy sources was discussed. A proposition to enhance randomness providers was made.
  • The implementation of Post-Quantum Cryptography was also discussed. Focus was put on compatibility between OQS and OpenSSL in the future.
  • Red Hat presented several significant issues, including confirmed bugs. There was also a discussion on features needing careful consideration by Red Hat.
  • The experience of writing a PKCS#11 provider emphasized the need for better documentation. The need for more supportive resources for writing a PKCS#11 provider was also discussed.

OTC Retrospective (Tim Hudson)

In our OTC retrospective, we identified strengths and weaknesses, recognizing the need for diversity and better outward communication. We proposed a Special Interest Group (SiG) model to target specific areas like OpenSSL providers. The aim is to attract diverse contributors, simplifying their inclusion and facilitating the formation of SiGs. The OTC team is tasked with streamlining new member acceptance and establishing the first SiG. Furthermore, we will ensure consistent, regular communication with our communities.

  • The process and criteria for accepting new members, as well as the criteria to maintain memberships, need to be reevaluated.
  • Opportunities to involve community members who can contribute meaningfully but don’t fit into the OTC or Committers groups should be explored.
  • The first Special Interest Group (SiG) needs to be identified and piloted.
  • News and updates should be consistently and regularly shared with our communities.

What Is Technical Debt with Some Examples (slides) (David von Oheimb)

David led an informative session about this technical debt, providing real-world examples and further emphasising the urgency for improvements. We acknowledged the technical debt in OpenSSL and the challenges it poses, including issues such as code redundancy, inconsistent APIs, and limitations in the build system. Understanding the pressing need for refactoring, we aim to improve consistency and make the API more user-friendly.

  • Identify the areas from which we would benefit the most if improved.
  • Come up with an idea for how the debt can be tackled.
  • Find a way to integrate the identified work into the product roadmap items.

CMP Updates Forward Planning (slides) (David von Oheimb)

David gave a quick introduction to what the Certificate Management Protocol (CMP) is, including its main features, security objectives, and specific benefits. Then he presented an overview of the new features of CMPv3 as defined in the upcoming CMP Updates and Lightweight CMP Profile RFCs and what the size of the respective contributions to OpenSSL will be. These new features were already implemented in an intermediate library, which was crucial for the standardisation process. In the conversation, we delved into various aspects of CMP, including the importance of interoperability and rigorous testing with other implementations, and discussed the extent and timeline of the new CMP features and extensions being added to OpenSSL.

  • Review the remaining PRs implementing the various new CMP features.

Performance Measurement (slides) (Ales Marecek)

Ales initiated a discussion on performance measurements, focusing on proof-of-concept tests and the need for baselines before making improvements. The conversation included addressing technical debt, the potential for dedicated hardware, sharing results with the community, and automating alerts in the review process. The importance of relevant metrics and historical analysis was recognized. Overall, there was enthusiasm for expanding the performance testing system and increasing community involvement.

  • Establish a plan to enhance performance.
  • Ensure that the metrics currently being collected are both representative and reliable.
  • Identify metrics that are both representable and quick to execute.
  • Explore the possibility of running tests in a retrospective manner to identify points in the past that had either a positive or negative impact.
  • Create an environment that simplifies the process of adding a new performance test for an engineer.
  • Work on expanding the set of tests.

Sessions with the Red Hat Security team (slides)

Lessons learned from FIPS 140-3

Red Hat engineers discussed their journey towards FIPS-140-3 compliance, sharing relevant modifications and patches potentially beneficial for OpenSSL. A key topic was the new FIPS 140-3 concept of indicators, analysing their impacts on compatibility and the need for API changes.

  • Explore which downstream patches might actually be useful for OpenSSL.

Constant-Time P-384

We briefly discussed the needs for better implementation of the P-384 curve. It is the recommended curve by CNSA 1.0, but it is the slowest of all former Suite-B curves. We touched on ECCKiila and the necessity for assembly implementations across numerous hardware platforms - a task we welcome external contributions. It was noted that ECCKiila code is not currently acceptable due to its licensing.

Providers per-app initialization

We delved into solutions for managing parameters and configurations, allowing the use of providers programmatically configured by an application. Several approaches were discussed. The dialogue also encompassed the challenges of preserving backwards compatibility while integrating new functionality. We concluded with the consensus that this request is both valid and achievable.

  • Red Hat engineers will author a design and a proposal.

RNG simplifications on Linux

We discussed the challenges of accessing entropy sources from a provider and talked about enhancing randomness providers by decoupling entropy sources from deterministic random bit generators (DRBGs) to allow direct access. Red Hat emphasised the importance of modularity, customizability, and compatibility in improving the flexibility, efficiency, and quality of randomness generation in cryptographic systems. While acknowledging potential areas of improvement, we agreed on the need for a detailed proposal. Simo from Red Hat suggested that someone with a better understanding of the implementation details should work on it.

  • Explore areas for improvement and formulate a plan.
  • Follow up with Red Hat.
  • Enhance documentation on this subject.

Post-Quantum Cryptography

We engaged in discussions regarding the implementation and integration of quantum cryptography algorithms in OpenSSL. The focus of our conversation was centred around plans, concerns, and considerations associated with the adoption of quantum cryptography standards and the development of compatible software. Participants emphasised the importance of a transparent transition and compatibility between OQS and OpenSSL in the future. We also explored the possibility of multiple providers offering the same algorithm, which may introduce variations in names and tweaks. Furthermore, potential challenges were identified in maintaining compatibility over time, including potential naming and compatibility issues.

  • Ensure effective communication with the community when incorporating Post-Quantum Cryptography (PQC) into the OpenSSL core. It is crucial that no application suffers, and the transition should be seamless without requiring changes to the existing apps.

Some issues raised by Red Hat

Red Hat presented several significant issues they are eager to see resolved. Both openssl/openssl#20789 and openssl/openssl#20850 have been confirmed as bugs. Meanwhile, openssl/openssl#12467 is more of a feature that requires thorough consideration and decomposition. The openssl/openssl#20131, which involves EVP_SKEY, has been a long-standing internal discussion within OpenSSL and holds great importance, though it is not an immediate requirement. Additionally, the possibility of adding the ability to remove keys via OpenSSL store interface was discussed, and an example of in-memory session keys was provided.

  • Follow up on the tickets and prioritise the ones that we can actively work on.

PKCS#11 provider

Simo shared his experience in writing a PKCS#11 provider. The experience could be enhanced through improved documentation, blog posts, tutorials, and examples. This aspect emphasises the need for comprehensive documentation, informative blog posts, helpful tutorials, and practical examples to improve the overall experience.

Return to Face-to-face Summary page.