2015-07-31 0:48 GMT+03:00 Vadim Zhukov <persg...@gmail.com>: > 2015-07-31 0:17 GMT+03:00 Stuart Henderson <s...@spacehopper.org>: >> On 2015-07-30, Vadim Zhukov <persg...@gmail.com> wrote: >>> 2015-07-30 20:16 GMT+03:00 Stuart Henderson <s...@spacehopper.org>: >>>> On 2015-07-30, Ted Unangst <t...@tedunangst.com> wrote: >>>>> Michael McConville wrote: >>>>>> > Another meat could be, why you're using self-signed certificates? >>>>>> > Given the plethora of options for getting free (valid) certificates. >>>>>> >>>>>> He mentioned in his original email that it's a requirement where he >>>>>> works. That's common, from what I hear, although probably not the >>>>>> safest. >>>>> >>>>> I would consider a cert signed by somebody I actually trust (me) safer >>>>> than >>>>> delegating that trust to 300 strangers. >>>> >>>> I think cert.pem should move to the etc set, so you can remove >>>> CAs from the file (as well as add new ones) without risk of those >>>> changes getting reverted. >>>> >>>> Downside: CA changes will then only take effect after running >>>> sysmerge. Is that a problem? >>> >>> I think it is. This is the same as with /etc/examples: less stuff to >>> merge, less errors to happen. >> >> cert.pem is pretty much a required file, we can't just move it to examples/. >> For people who don't touch it, it's a simple no-touch sysmerge update. >> For people who do, having sysmerge ask about merging it is a lot safer >> than just overwriting. > > No, I didn't want to move /etc/ssl/cert.pem it to /etc/examples. I > think that its current contents could be provided in other way... > >>> I'd ask another question: why can't software use /etc/ssl/myown.pem, >>> or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make >>> "trust" and "untrust" operations as simple as possible. Noone in >>> healthy mind would place junk in /etc/ssl anyway, right? >> >> Some software allows you to set a different certificate file; other >> software doesn't. Patching everything in ports that verifies SSL certs >> to allow the user to specify an alternative file would just be insane. > > Hm-m, I always tried to live in a separate room with SSL beasts. Now I > realize that I saved a lot of nerves myself, and as a result I'm > living in a pink pony world. Thanks for getting back to the ground. > > I thought that there was some "default" in OpenSSL (and its > decendants) that programs tends to use. Now I realize there is no such > place. Okay, this variant gets busted. > >> And of course then there's no single way to tell programs to use the >> alternative file; "ftp -S cafile=/path/to/cert.pem", >> "env SSL_CERT_FILE=/path/to/cert.pem lynx" >> >>> Or we may ship /etc/ssl/base.pem in base tgz, and install >>> /etc/ssl/cert.pem -> base.pem at installation time. This way things >>> will work by default, and if you need to have your own trust path, you >>> just change symlink. What do you think? >> >> That doesn't really help. One common scenario is wanting to add a >> single CA to the standard file, but otherwise pick up updates (e.g. with >> sysmerge), this method doesn't allow that. > > Well, I see four scenarios:
Those should be "three", of course. :) > 1. Using the defaults supplied with OpenBSD only. Typical for home/personal > use. > > 2. Use the defaults supplied with OpenBSD, and one or more additional > CAs. Typical for corporate use. > > 3. Use personal set of CAs. Usually means either white-, or > blacklisting entries from "base" certs pack. > > After more thinking I see that symlink idea is not good. But we can do > some other thing: > > 1. Have "base" certs installed into /etc/examples/certs.pem. > 2. Additional certs, if any, should go into /etc/ssl/local.pem. > 3. Have sysmerge handle certs specially: comparing not (old) > /etc/examples/cert.pem with /etc/ssl/cert.pem, but > /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In > case they do match, sysmerge would regenerate /etc/ssl/cert.pem by > concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem. > > What do you think? -- WBR, Vadim Zhukov
