With that spirit, I have proposed a small PR [0], which hopefully does the job.
I believe RFC8446bis may only clarify the general interpretation of messages in transcript hash being as sent or received on the wire, and future specifications should explicitly specify if they want to have an interpretation contrary to this. What do you think?
Feel free to wordsmith PR [0]. It is supposed to be a starting point for discussion, and not a final proposal.
Also see one opinion inline: On 11.02.26 21:03, David Benjamin wrote:
On Wed, Feb 11, 2026 at 1:54 PM David Benjamin <[email protected]>
wrote:
On Wed, Feb 11, 2026 at 4:36 AM Eric Rescorla <[email protected]> wrote:
Argh. This text was of course actually intended to add clarity
hence the "for concreteness"
at the front, and yes, the idea certainly was that it's all the
messages. Given that we are
currently doing RFC 8446-bis (albeit in AUTH48), this seems like a
good opportunity to
improve this text. Do you have any suggestions?
I put together a first pass here.
https://github.com/tlswg/tls13-spec/pull/1401
It's not enough to make RFC 8897 unambiguous because Certificate
is still listed by name elsewhere. It also is not enough to
unbreak a hypothetical extension that, say, injected a message
right after EncryptedExtensions. I'll see if I can do something
there, but it'll require quite a bit more surgery.
While I very much appreciate your detailed PRs, IMHO, the goal should
not be to fully disambiguate RFC 8879 within RFC8446bis. I believe that
can be done as Errata to RFC 8879 to clarify the interpretation there.
Thanks. -Usama [0] https://github.com/tlswg/tls13-spec/pull/1407
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
