> Notably, it still relies on the server certificate being re-validated
> against the new SNI at the
> session resumption time.
Where is this specified? I can't find it in RFC 8446. (Sorry if I missed it.)
> However, in the absence of additional signals, it discourages using a
> session tick
On Wed, Aug 11, 2021 at 5:00 PM Carrick Bartle wrote:
> > Notably, it still relies on the server certificate being re-validated
> against the new SNI at the
> > session resumption time.
>
> Where is this specified? I can't find it in RFC 8446. (Sorry if I missed
> it.)
>
Does RFC 8446 actually
> - Ticket-based PSKs carry over the server certificate from the previous
> connection
What does "carry over" mean here? That the client literally holds on to the
certificate and re-evaluates it before resumption? Or just that the trust from
evaluating the certificate during the initial handsha
On Wed, Aug 11, 2021 at 5:49 PM Carrick Bartle
wrote:
> - Ticket-based PSKs carry over the server certificate from the previous
> connection
>
>
> What does "carry over" mean here? That the client literally holds on to
> the certificate and re-evaluates it before resumption? Or just that the
> tr
Okay, in that case, I wouldn't use the word "re-validated," since to me that
sounds like the certificate is to be completely validated again (e.g. checking
expiration). Instead I would say something like "attempt resumption only if the
certificate is valid for the new SNI," ideally with a refere
Hi all,
I recently did an RFC 5742 conflict review of a document that is
allocating new cipher suites for TLS 1.2 and also needs new signature
algorithms. The document currently requests two allocations from the old TLS
1.2 SignatureAlgorithm registry that TLS 1.3 replaced with the two-octet
Sign
