Open thibmeu opened 6 months ago
I'd suggest keeping the language as it currently is in the draft, since afaik that matches what most structures created using TLS presentation language in other drafts tend to do (where you're explicit about the type of the embedded structure and the sizes internally aren't adjusted based on external constraints). It would be even more messy if Extension was embedded in multiple places with different maximum lengths based on the enclosing structs (ie SignedExtensions (max 2^16-1) with extensions list (max 2^16-3) with an Extension (max 2^16-5).
Current
The current draft defines
Extensions
as followAs observed by @armfazh, an Extension maximum length in network byte order being
2 (type) + 2 (data length) + 2^16 (data)
. This does not fit inExtensions
.Proposed
We suggest the following:
Changes:
opaque
to avoid confusion between the extension length being the number of extensions or the length in network byte order of the serialized extensionsExtensions
data structure.This should not change existing implementation, apart from adding one more constraint on what constitute a valid extension.