Server doing only Pass 1 or 2?

[csosto-pk]

What does the client do if the server only does Pass 1 and compresses / omits the chain certs but does not compress the end-entity certs (Pass 2)?

The client should be fine with that. It should be able to reconstruct the chain and used the uncompressed end-entity cert. It should not fail the handshake.

I am suggesting for the Implementation Complexity Section to say something like

Servers MAY chose to compress just the cert chain or the end-certificate depending on their ability to perform Pass 1 or 2 respectively. Client MUST be able to process a compressed chain or an end-entity certificate independently.

or something like that.

[dennisjackson]

I can see two different ways to handle it. Either as you suggest, we have it be a runtime decision and we just prefix the compressed form with a byte to indicate whether pass 2 has been used. Alternatively, we can define two codepoints, (pass 1 + pass 2, pass 1).

I'd suggest we gather performance figures first, then make a decision on the right way forward.

[csosto-pk]

Maybe these will not matter for the scenario I am considering:

Let’s say the client advertised support for draft-ietf-tls-cert-abridge. And the server sent back

• CompressedCertificate which includes the 2 identifiers for the ICA and RootCA from Pass 1.
• uncompressed, traditional CertificateEnty of the end-entity certificate

Or it sent back

• uncompressed, traditional CertificateEnties for the ICA and RootCA certs
• CompressedCertificate which includes the ZStandard compressed (based on the Pass2 dictionary) end-entity cert

My point is that nothing should prevent the client from being able to handle these two scenarios and normative language should point that out. Any software that can parse certs in compressed form, ought to be able to parse them in regular form if the server did not support Pass1 (CA cers were not available for some reason) or Pass2 (eg. if CT Logs were not available for some reason).

Am I overseeing something?