On 09/11/2018 19:42, Viktor Dukhovni wrote: > On Fri, Nov 09, 2018 at 06:42:28PM +0000, Matt Caswell wrote: > >>> I am having a bit of trouble finding the equivalent information for >>> the 3rd line on the server side. Anyone know how, in TLS 1.3 where >>> these are not implied by the ciphersuite, to determine the signature >>> algorithm (and curve for ECDSA), the hash algorithm and key exchange >>> public key (with bit count for DH or curve name for ECDSA)? >> >> I don't believe we currently expose the signature algorithm selected on >> the server side. It's held in s->s3->tmp.sigalg, but AFAICT that is only >> ever used internally. > > Thanks for confirming, it is then not surprising I failed to find > the relevant interfaces. :-) > >> Similarly the key exchange public key is held in s->s3->peer_tmp. We do >> expose that via SSL_get_server_tmp_key(), but its a client side only >> function. We explicitly check that and return 0 if called on the server >> side. > > Quick question about that, since the client may also sign the key > exchange when a client certificate is requested and returned, what > is held on the server in s->s3->tmp.sigalg? [ I expect still the > signature the server used in its CertificateVerify. And on the > client side, I would expect this to hold the algorithm used by the > client to sign its ClientVerify if a client cert was used. ] Right - exactly that. s->s3->tmp.sigalg always holds the sigalg the endpoint selected to sign its own CertificateVerify (whether that be client or server). > > And it seems that on the server side s->s3->peer_tmp does actually > hold the client's key exchange public key, which is necessarily for > the same group as the server, so all we'd need to do is remove that > 'explicit check' and that key be visible on the server side, right? > Right - although we might want to think about the name of the function. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
