Is there any technical (cf. practical) reason the client must obtain the certificate from the server it names, and contemporaneous with the client's HTTP command?
Is there any technical reason the client cannot obtain the certificate from other sources and/or not contemporaneously with the HTTP command?
For example, CurveCP explains how the public key can be inserted into (DNSCurve-encrypted) DNS RRs. Clients can obtain the public keys from DNS servers instead of from www servers. They might even obtain public keys in bulk in zone files rather than by piecemeal requests. Further, CurveCP provides for a "server extension", an identifier that allows multiple sites to use the same IP address and port, obviating the problem which SNI aims to solve.
For example, third party sources such as crt.sh provide repositories of certificates that users can download at a time they choose, not necessarily contemporaneous with when they send HTTP commands to the servers named in the certificates. There are a variety of sources of bulk certificates in addition to crt.sh. (Incidentally, crt.sh does not require SNI.)
The practice of third parties providing certificates versus letting clients obtain them from the named servers/issuing parties is seen among the few companies/organizations that write popular clients when they distribute collections of "trusted" certificates with the client software.
Another example is when a www server sends "intermediate certificates" along with the certificate that names the www server. This too demonstrates third party distribution of public keys to clients instead of letting clients get the keys from the entity to which they were issued.
No matter how the client obtains the server certificate, it still has to somehow tell the server which server certificate it has used for the public key which it has encrypted the premaster secret with.
Is there any technical reason the client cannot obtain the certificate from other sources and/or not contemporaneously with the HTTP command?
For example, CurveCP explains how the public key can be inserted into (DNSCurve-encrypted) DNS RRs. Clients can obtain the public keys from DNS servers instead of from www servers. They might even obtain public keys in bulk in zone files rather than by piecemeal requests. Further, CurveCP provides for a "server extension", an identifier that allows multiple sites to use the same IP address and port, obviating the problem which SNI aims to solve.
For example, third party sources such as crt.sh provide repositories of certificates that users can download at a time they choose, not necessarily contemporaneous with when they send HTTP commands to the servers named in the certificates. There are a variety of sources of bulk certificates in addition to crt.sh. (Incidentally, crt.sh does not require SNI.)
The practice of third parties providing certificates versus letting clients obtain them from the named servers/issuing parties is seen among the few companies/organizations that write popular clients when they distribute collections of "trusted" certificates with the client software.
Another example is when a www server sends "intermediate certificates" along with the certificate that names the www server. This too demonstrates third party distribution of public keys to clients instead of letting clients get the keys from the entity to which they were issued.