[TLS] Re: Ambiguity of TLS Certificate Compression (RFC 8879)

[David Benjamin <[e-mail]>]

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=
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>