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 (山本和彦) <kazu= [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]
