Appendix C. Parameter Reference
Requirement F8 obliges every algorithm to report its parameters, and §5.5 stated the rule
that everything the protocol must know crosses the boundary as a parameter. This appendix
collects, per component, what must be answered and what consumes it. A parameter that is not
answered does not produce an error at the provider; it produces a failure at the consumer, often
far away (§8.3, §15.3).
C.1 Digest
| Parameter | Type | Answered by | Consumed by | If wrong |
size | size_t | Algorithm | Key schedule; secret, Finished and transcript widths | Truncated or over-read secrets (15.3) |
blocksize | size_t | Algorithm | HMAC inside HKDF | Every HKDF step wrong, immediately |
C.2 AEAD cipher
| Parameter | Type | Answered by | Consumed by | If wrong |
keylen | size_t | Algorithm | Traffic key derivation | Wrong key length; handshake fails after keys are installed |
ivlen | size_t | Algorithm | Static IV derivation; nonce construction | Nonce misconstruction — catastrophic (8.4) |
taglen | size_t | Algorithm | Record sizing | Record-length errors (8.3) |
blocksize | size_t | Algorithm | Buffer arithmetic | Buffer sizing errors |
mode | uint | Algorithm | Consumer's mode dispatch | Treated as non-AEAD |
aead | int | Algorithm | AEAD capability check | Rejected for TLS 1.3 use |
tag | octets | Context | Retrieved after encrypt; supplied before decrypt | Integrity failure or false accept (8.6) |
ivlen (ctx) | size_t | Context | Per-operation IV width | As above |
| AAD | octets | Context | Record header binding | Header not authenticated |
C.3 Key management and key exchange
| Item | Direction | Consumed by | Note |
| Public key export encoding | Provider to core | key_share construction | This encoding is the wire encoding (10.2) |
| Public key import | Core to provider | Peer share reconstruction | Validation happens here (10.4) |
| Derive output length | Provider to core | Shared secret buffer | Must be the fixed field size, not the computed length (10.3) |
| Group name / internal name / algorithm | Capability | Negotiation | Wire name decoupled from implementation name (4.3.1) |
| Group id | Capability | supported_groups | From a registry or private-use range (10.6) |
| Security bits | Capability | Security-level filtering | Understated filters it out; overstated defeats a control (11.3) |
| Min / max TLS | Capability | Version gating | Confine to TLS 1.3 (16.3) |
C.4 Signature
| Item | Direction | Consumed by | Note |
| IANA name | Capability | Configuration and protocol identity | Two-layer naming (11.3) |
| Algorithm name | Capability | Fetch |
| OID | Capability | Certificate matching | Brings encoders/decoders into scope (11.4) |
| Code point | Capability | signature_algorithms | As for groups |
| Security bits | Capability | Policy ranking | As above |
| Signature max length | Two-call convention | Caller allocation | Must be the maximum, not the typical |
C.5 Checklist
A component is parameter-complete when, for every row above that applies to it, the parameter
appears in the gettable list and is answered by the get function. The two are separate
obligations: a parameter advertised but not answered, or answered but not advertised, is a
defect that some consumers tolerate and others do not, which produces the worst kind of bug —
one that depends on the consumer.