22 Nov
2005
22 Nov
'05
5:55 p.m.
Hi all,
Klaus Darilion wrote:
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
Cesc wrote:
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)
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?
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.