Hi all,
Klaus Darilion wrote:
Cesc wrote:
Hi all,
A couple of notes i would like to remark ...
- On the "tls name extensions" ... it is indeed needed and it is not
in openSSL. I do think we have a strong case for lobbying directly to OpenSSL core developers ... and i think openSER (and ser) have a rather strong arm. We could get in touch with the developer of the patch and openSSL core dev.
Thus, who will contact the openssl developers?
I can do the job, no prob...but should we do it via public lists or sending directly the relevant person (the guy that did the patch and the core developer of the project)
Meanwhile ... the solution of providing the patch ... i see it as complicated and it won't spread very far, thus limiting the usefulness ... it could be sold as a way of testing the name extension patch and speed up it's inclusion in openssl ... but until that time, i think we should focus on other scenarios of openSER-tls.
- Klaus' initial email and scenarios ... I think it is a very
enlightening explanation and it should be included in a tls-faq, but ... i would say that security is a very particular thing, and different people may wish to do things in a different way, thus we should provide a flexible solution. In my opinion, a core that sets up TLS connection plus a security-tls module which provides access to verification of certs against DB entries, tls connection management (tear down, etc), and this sort of stuff; this would be my choice. Provide the functinality, provide a nice FAQ and examples on standard practices, but give the user the power to do whatever he wants.
I agree with you. My scenarios were just some the possible examples.
ok -so we have a sort of agreement on the matter - I would say the first step will be extract all TLS management functionality and move it into a module. Than start building onto the module more control or monitoring functions (as Klaus suggested via AVPs).
regards, bogdan