Fetch client certificate from a connection and DH creation

[ondrap]

If I used the client certificates, is there a way to fetch the client-provided certificate? If I wanted to use the client certificate to distinguish the clients, is there a way to do it?

Also, is there a way to create the DHParam? I see there is a section to set DHparam in server configuration, but didn't find a way to actually create the datatype.

[vincenthz]

there should be a way to distinguish clients by certificate. it's probably not very hard to tweak the API to allow querying the client certificate use.

[tolysz]

@ondrap You create DHParam via cryptonite. I guess it could be more clear that DHParam == cryptonite-Crypto.PubKey.DH.Param but otherwise it works.

[ocheron]

For the remaining part I don't find this easy at all.
We could just expose existing function getClientCertificateChain.
The certificate chain would be available after a full handshake.
But not after an abbreviated handshake (session resumption) because there is no certificate exchange in this case.

I guess application code will want authentication info in both cases.
I'm reluctant to add something large like a certificate (chain) directly inside SessionData.
Applications usually need a very small portion of the certificate.
And SessionData is supposed to be encryptable into a small session ticket.

So I'm thinking the client CertificateChain could be an additional argument to sessionEstablish.
Users would have to deal with resuming a client certificate in their session manager code.

[vdukhovni]

FWIW, in OpenSSL the session ticket retains only the leaf certificate (not the full chain) and the (cached) validation status. A server using session tickets should be able to run completely stateless (no per session state, just a bit of state for a periodically changing ticket encryption key, current for encoding/decoding and previous just for decoding). On resumption servers can then extract the client certificate and wether it is valid or not from the session ticket. Thus with a full handshake servers have access to the complete client certificate chain, but with resumption only the leaf certificate and its validation status.

With hs-tls, the full handshake case can be handled via onClientCertificate saving whatever it wants from the chain, so the library code need not hold on to the full chain. But just the leaf certificate along with whether it validated originally or not (so perhaps the list of failure reasons), should probably end up saved in the ticket.

This then means that servers will need to provide an interface to query the peer leaf certificate and its validation status in a resumed session (whether by ticket or stateful session-ID-based server-side cache). That interface can be a resumption callback that gets access to the leaf certificate and validation result.

Alternatively, if I'm wrong about the issue that's requesting leaf certificates in Information, just the peer leaf certificate could always be saved in the context, and made available via Information, but necessarily along with the failure reason list or at least a boolean to indicate whether the list was empty. Session tickets and stateful sessions need to capture at least that much state. Session resumption without peer identity is not terribly useful on servers that make use of client certificates.