6. Requirements and Design Goals

This chapter states what the designed system must do, in terms precise enough that Chapters 7–15 can be checked against them and Chapter 19 can propose tests for them. Functional requirements are labelled F, non-functional N, and constraints C.

6.1 Functional requirements

6.2 Non-functional requirements

6.3 Constraints

6.4 The fail-closed principle

Requirement F10 deserves separate treatment because it is the requirement most often violated by systems of this kind, and the violation is not visible in testing that only checks the happy path.

A deployment that introduces an algorithm for a compliance reason needs the connection to fail when the algorithm is unavailable. The alternative — falling back to a standard algorithm and completing the handshake — produces a working connection that does not satisfy the requirement the deployment exists to satisfy, and produces it silently.

OpenSSL's property mechanism supports this directly: a required property that no implementation satisfies causes the fetch to fail, and the fetch failure propagates. The design must therefore be careful never to specify its properties as merely preferred where the deployment intends them as mandatory. Chapter 14 develops the distinction, and Chapter 19 proposes a negative test for it — a test that deliberately deactivates the provider and asserts that the handshake fails rather than succeeding by another route.

6.5 Explicit non-goals

The following are outside the design, and stating them prevents the evaluation chapters from being read as having neglected them:

• A new cryptographic primitive. The design integrates algorithms; it does not propose new ones. Any primitive used should be one with published analysis.
• FIPS validation. The provider is not a validated module and its algorithms are not approved. Chapter 17 discusses what validation would additionally require.
• Protocol changes. Excluded by C1.
• TLS 1.2 support. The suite structure differs and the key schedule is different; supporting both would double the design without illuminating it.
• Performance competitiveness. The design aims to be correct and measurable, not fast. Chapter 18 proposes how speed would be assessed if it mattered.

6.6 Traceability

Each requirement is addressed by an identified chapter, and Appendix D carries the matrix forward to the claim table. A requirement with no corresponding design section is a gap, and a design section addressing no requirement is scope creep; the matrix is maintained to make both visible.