Oops for got a comment on #2 On 1/15/14, 4:17 PM, "Ron Barber" <rbar...@yahoo-inc.com> wrote:
>James, Thanks for the quick feedback... > >On 1/15/14, 3:08 PM, "James Peach" <jpe...@apache.org> wrote: > >>On Jan 15, 2014, at 10:46 AM, Ron Barber <rbar...@yahoo-inc.com> wrote: >> >>> All, >>> >>> I have been asked to address TS-612 >>> (https://issues.apache.org/jira/browse/TS-612) by Œthe man¹. I made a >>> proposal on the ticket regarding configuration and would like some >>> feedback at your leisure (well pretty quick since I am on it now). >> >>1. The 'builtin' dialog may be a problem, since traffic_server would be >>the one running the dialog, and it's a couple of processes down the fork >>chain. > >Was going to include it primarily for completeness (and for my testing >it’s useful). Certainly I can remove it if it’s problematic (maybe it >will create more questions), but just like it’s helpful for me, it may be >useful to the person trying to implement/test his own exec or pipe >solution. >> >>2. Compatibility with the Apache http dialog would be a good thing. >>However, there's no ATS requirement to specify a dest_ip >>(servername:portnumber in the httpd documentation), so I don't know that >>it makes sense. You are correct, thank you for pointing that out. In looking at the docs (https://trafficserver.readthedocs.org/en/latest/reference/configuration/ss l_multicert.config.en.html#std:configfile-ssl_multicert.config) the only required field is ssl_cert_name, so I will make that first and provide the other 2 if provided. >> >>Are you planning to implement the httpd prompt-minimization logic? >> >>It's difficult for me to see how a program could select a passphrase >>using the http logic. It doesn't seem like there's a way for the program >>to really know which key it is being prompted for. If the dialog was >>specified in ssl_multicert.config, then it would be possible. > >Short answer: No. I thought that was a really cool feature in httpd so I >looked at the implementation. Httpd tries each password that it has seen >previously before asking for another password..in order to do that it >would take refactoring of the SSL config code which is beyond what I have >time for. > >> >>While you are at it, consider whether we can consolidate the number of >>places in our code that calls fork+exec into a libts API that looks a lot >>like posix_spawn. > >Will look at that. > >> >>While this is useful from a compatibility point of view, I'd like the >>provisioning and protection of private keys to go much further. The linux >>kernel keychain looks like the most promising infrastructure for key >>management, and I'd like us to support that. Additionally, I think that >>using a privileged helper (eg. traffic_manager?) is the right way to go >>for accessing keys that are read-only for root, or protected in some >>other fashion. > >I agree with the idea (not sure keychain capability is available in all >supported OSs) but is outside of my time horizon (and knowledge base atm). > >> >>J >
