On Thu, Oct 10, 2013 at 4:44 PM, Dr Stephen Henson
shen...@opensslfoundation.com wrote:
On 10/10/2013 23:18, Trevor Perrin wrote:
How would you expect the code to track the Cert - ServerInfo
relationship between these points?
AFAICS the certificate and key files both go through the function
ssl_cmd_check_aidx_max and store the filenames with an associated index. At
that
point you could save the last index used and store any associated ServerInfo
with the same index.
Sure.
I *think* you then have to delve into ssl_pphrase_Handle() [note the comment
on
the way in] and somehow link the ServerInfo index with something you can use
to
recognise it later. The algorithm type 'at' might be usable or perhaps turn
the
algorithm type into one of the SSL_AIDX_ALGORITHM values?
I don't see a direct way to map ssl_algo_t to the SSL_AIX_* that's
needed later. I suppose something could be kludged out of
ssl_util_algotypestr() and ssl_asn1_keystr().
But maybe the easiest way to handle this is to create another hash
table like tPublicCert (e.g. tServerInfoFile or tSSLConfCmd).
This table could be populated in ssl_pphrase_Handle at the same time
that the tPublicCert table is populated, and read in
ssl_server_import_certs()?
This would be easy to do as a directive, since only a ServerInfoFile
string would be stored in the hash table, and no OpenSSL changes are
needed.
As an SSL_CONF_CMD, there's more work:
- Add some indicator to distinguish per-cert vs global commands (?)
- Serialize/deserialize SSL_CONF_CMD name/value lists into the hashtable
- OpenSSL work:
- Implement SSL_CONF_CMD for ServerInfoFile
- Implement SSL_CONF_cmd_type(...) for relative path handling
It seems like you guys are contemplating a larger redesign of cert/key
handling based around SSL_CONF_CMD.
Perhaps I could just do a directive for now, and let all this be swept
into a big redesign later?
(Yes, I'm trying to do the minimum work possible :-)
Trevor
