What David said: any other interpretation wouldn't interoperate and this is pretty widely deployed now.
Suggestion: > After decompression, the Certificate message MUST be processed as if it were > encoded without being compressed, with the exception of the handshake > transcript. The CompressedCertificate message is hashed into the handshake > transcript (Section whatever of [TLS]) in place of a Certificate message. On Fri, Jan 30, 2026, at 15:07, David Benjamin wrote: > BoringSSL also uses the messages as received on the wire, so > CompressedCertificate. I think that's most natural for an > implementation that largely just adds what it sends or receives to the > transcript. It also avoids introducing a source of transcript > malleability, which probably would never matter in practice but ought > to be to locked in. > > But I agree that the spec seems to be ambiguous. That's unfortunate. > Errata I suppose? With the number of implementations that take > use-what-was-sent/receives interpretation, I think we have to take this > one as correct. (I remember this coming up in standardization, and I > think this was the intent, but it was some time ago.) > > I think the problem is that we all "know" the transcript is just a > record of what's send/received and sampled at the appropriate time, but > then we write it as specific messages, and things like this get lost in > the gap. :-( > > David > > On Thu, Jan 29, 2026, 22:47 Kazu Yamamoto (山本和彦) > <[email protected]> wrote: >> Hello, >> >> Though implementation of certificate compression, I felt that >> RFC 8879 is ambiguous on how to calculate transcript hash. >> >> RFC 8446 defines the content for Certificate Verify as follow: >> >> Transcript-Hash(Handshake Context, Certificate) >> >> This is natural reuse of transcript hash. So, AFAIK, "tlsfuzzer" and >> facebook.com use the following as the content: >> >> Transcript-Hash(Handshake Context, CompressedCertificate) >> >> But RFC 8879 says: >> >> After decompression, the Certificate message MUST be processed as >> if it were encoded without being compressed. >> >> I think the following original interpretation is possible for the >> content: >> >> Transcript-Hash(Handshake Context, Certificate) >> >> Clarification would be helpful. >> >> --Kazu >> >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
