Chapter 1.5 promised that every load-bearing claim would be collected with its status. This appendix is that table. A reader who wants to know what this paper establishes, as opposed to what it proposes, should read this page.
Statuses are as defined in §1.5: Verified — checked against OpenSSL source on the reference machine, reference given; Design — a specification of the proposed system, not built; Reported — attributed to the author of the system described, not independently reproduced.
| # | Claim | Status | Reference |
|---|---|---|---|
| 1 | A TLS 1.3 suite binds an AEAD algorithm and a handshake hash in one code point | Verified | ssl/s3_lib.c:39–56 |
| 2 | The TLS 1.3 suite list is a static table whose length is taken at compile time | Verified | ssl/s3_lib.c:26, :39 |
| 3 | Providers answer the TLS-GROUP and TLS-SIGALG capabilities | Verified | providers/common/capabilities.c:335–347 |
| 4 | ossl_prov_get_capabilities() returns 0 for any other capability name | Verified | providers/common/capabilities.c:344–346 |
| 5 | A group advertisement carries wire name, internal name, algorithm, id and security metadata | Verified | providers/common/capabilities.c:96–108 |
| 6 | Several named curves may map to one implementing algorithm | Verified | providers/common/capabilities.c:161–164 |
| 7 | A signature advertisement carries IANA name, algorithm name, OID, code point and security bits | Verified | providers/common/capabilities.c:292–302 |
| 8 | OpenSSL introduces ML-DSA signature algorithms to TLS through the capability mechanism | Verified | providers/common/capabilities.c:316–318 |
| 9 | Fetching by name is much slower than direct method-table access; prefetching is recommended | Verified | references/12-ossl-guide-migration.pod:223–228 |
| 10 | The ENGINE API is deprecated in 3.x; providers are its replacement | Verified | papers/openssl-3.5.5/03-ENGINE_add.pod:169; 09-openssl-engine.pod.in:25 |
| 11 | A property query selects implementations by key/value assertions | Verified | papers/openssl-3.5.5/07-openssl-glossary.pod:173–190 |
| 12 | A library context is a scope within which configuration applies | Verified | papers/openssl-3.5.5/07-openssl-glossary.pod:110–116 |
| 13 | Implicit fetching resolves an implementation on first use with default criteria | Verified | papers/openssl-3.5.5/07-openssl-glossary.pod:95–101 |
| # | Claim | Status | Chapter |
|---|---|---|---|
| 14 | The provider structure of §7.1–7.7 satisfies F8, F9, N3–N6 | Design | 7 |
| 15 | An AEAD component answering key, IV and tag lengths and accepting an external nonce satisfies F1 and C2 | Design | 8 |
| 16 | A hash component with deep duplication and accurate size reporting satisfies F2 | Design | 9 |
| 17 | A group component with validation and a capability entry satisfies F3 and F4 | Design | 10 |
| 18 | Registration requirements 1–5 are necessary for a usable suite | Design | 12.2 |
| 19 | The three negotiation failure modes of §12.3 are distinguishable | Design | 12.3 |
| 20 | A required property produces a clean fetch failure rather than fallback (F10) | Design | 14.2 |
| 21 | Changing the handshake hash changes the width of every secret in the schedule | Design, following from claim 1 and RFC 8446 | 15.2 |
| 22 | An overstated digest length can yield a working connection with weakened keys | Design (analysis) | 15.3 |
| 23 | The design cannot introduce a downgrade, because a provider cannot alter sequencing | Design, following from C1 | 17.6 |
| # | Claim | Status | Would be established by |
|---|---|---|---|
| 24 | The author's system adds cipher suites combining block cipher, elliptic-curve and hash algorithms through the provider interface | Reported | §19.5 L4, with §19.5.1 negative tests |
| 25 | Such suites are usable in TLS communication | Reported | §19.5 L4, confirming the negotiated suite per §B.3 step 5 |
On claims 24 and 25. This study had no access to the implementation and did
not reproduce them. They are recorded here as attributed statements so that a reader can see
precisely which parts of the paper rest on them — Chapter 12's framing, and nothing in
Chapters 2–11 or 13–19, all of which stand on the verified and design claims above. A reader
evaluating the work should ask for the Chapter 19 evidence, particularly the
openssl ciphers comparison with the provider activated and deactivated, which
settles the question directly.
Per §19.7, absence is reported rather than left to inference:
| Requirement | Addressed | Test that would establish it |
|---|---|---|
| F1, C2 | Ch. 8 | L1 AEAD vectors; §19.5.1 record corruption |
| F2, C3 | Ch. 9, 15 | L1 boundary lengths; L2 duplication; L3 schedule |
| F3, F4 | Ch. 10 | L1 key exchange; §19.5.1 invalid-curve and small-subgroup |
| F5, F10 | Ch. 14 | §19.5.1 provider deactivation |
| F6, C6 | Ch. 13 | §19.5.1 wrong library context |
| F7, C4 | Ch. 12, 16 | L4 handshake; L5 interoperability |
| F8 | Ch. 7, App. C | L2 parameter completeness |
| F9 | Ch. 7 | L2 coexistence |
| N1 | Ch. 18 | M5 prefetch benefit |
| N2, C5 | Ch. 17 | Binary-level verification (not proposed in detail) |
| N3–N6 | Ch. 7 | L2 teardown under a leak checker |