Fig. 8: Signature after Certificate message

[muhammad-usama-sardar]

In Fig. 8, signatures are computed before the Certificate message is sent. As per the discussion today, it should be the other way around; so that as per Sec. 4.4.3. of TLS, signatures can include the transcript hash over the sent Certificate message as well:

Transcript-Hash(Handshake Context, Certificate)

[ionut-arm]

I believe this relates to figure 8 in v3 of the draft. You're correct - the signature is computed before the Certificate message is sent - by which I mean that it's not computed before the Certificate message is composed. What I assume happens is that the messages are computed sequentially and then sent "together". So the Certificate message is created and ingested into the server's handshake transcript, after which the signature for CertificateVerify is computed. That's why the CAB (which in this case forms the certificate) is computed first, followed by a signature with the TIK.

Unfortunately I don't remember what the discussion was, but we can go over it again before cut-off.

[ionut-arm]

Okay, so for completeness: based on the conversation today, we've agreed to make some changes to the diagram and the text around it to better align with the terminology in RFC 8446.

[muhammad-usama-sardar]

I believe this relates to figure 8 in v3 of the draft.

Yes, v3 was the lastest version at the time of creation of issue. But the issue still exists in the corresponding figure 12 in v4 of the draft.

You're correct - the signature is computed before the Certificate message is sent - by which I mean that it's not computed before the Certificate message is composed. What I assume happens is that the messages are computed sequentially and then sent "together". So the Certificate message is created and ingested into the server's handshake transcript, after which the signature for CertificateVerify is computed. That's why the CAB (which in this case forms the certificate) is computed first, followed by a signature with the TIK.

Unfortunately I don't remember what the discussion was, but we can go over it again before cut-off.

Back then, we had a look at some RFCs of TLS WG and we found out that it is a non-standard way of showing this, and without clear specification in the text (which is missing in both Sec. 7.1 of v3 as well as Sec. 8.1 of v4 of draft), it could be misleading. The corresponding text in v3 (as well as v4) of draft says:

The server then signs the handshake transcript with the (attested) identity key

The problem with this text is that the term handshake transcript is very loosely used in the RFC8446, and with the way figure 8 in v3/figure 12 in v4 of the draft is drawn, it seems to propose that the Certificate message is itself not a part of the handshake transcript, which is indeed not our intention. A more precise terminology is to clarify the Transcript-Hash and Handshake Context.

---

Proposed fix

I propose the following fix:

• Figure: show Certificate message between the messages labelled CAB(KAT,PAT) and sign(TIK,hs).
• Text: specify that hs is Transcript-Hash(Handshake Context, Certificate) where Handshake Context is as specified in the table in Sec. 4.4 of RFC8446.

[thomas-fossati]

Partly addressed in #33