[bind10-dev] [sprint planning] estimate result discussion for sprint ending 2013-03-19

[Francis Dupont]

> FYI, this has in fact been one of the reasons to choose Botan so far;
> the idea was that in the end we'd only use a PKCS#11 interface instead
> of any 'raw' crypto library, and 'plug in' for instance SoftHSM as the
> software default (so that we'd only have one code path for our crypto
> calls, and not several depending on what is being used). But before we
> got to that point we needed something to do the relatively few
> cryptographic operations we use now.

=> BTW it failed to do it correctly, cf 2402...

> We then chose Botan for a couple of reasons;
> - - SoftHSM used Botan (AFAIK plans are to make it work with several
> backends as well but I am not fully up-to-date on current
> development),

=> SoftHSMv2 supports both OpenSSL and Botan backends.

> so if we did end up using SoftHSM the indirect
> dependency pain wouldn't be as much
> - - OpenSSL was especially annoying regarding PKCS#11

=> if you mean the PKCS#11 engine stuff I afraid you are even more
right than you believe.

> - - Diversity is indeed good

=> it is both a good idea but against the economics of software.

> Of course, there were a number of things we (or at least I) did not
> fully realize at that point;
> - - Python uses, and depends on, openssl (not sure how hard it would be
> to have python but not necessarily openssl)
> - - The chicken-egg problem with botan is a bit bigger than I had
> anticipated
> - - I had figured we'd be well past the pkcs11 part by now.

=> the main problem is SoftHSMv2 is going slowly and out of
our control, so we know it will happen but not when.

> Now in principle we did put all the actual backend calls in a separate
> unit, and in theory most crypto systems are pretty much alike, so TBH
> i don't think replacing it would be insanely hard.

=> it is not cf 2406.

> So I was almost
> convinced we should 'just' move to OpenSSL. I did not expect pushback
> on that :) Either way I still think the long-term goal should be the
> pkcs#11 approach, with transparent software implementation for those
> that just want software support (i.e. almost everyone).

=> IMHO we can (so should) wait. The only thing which must be
addressed in a reasonable timeframe is 2402. BTW I don't recommend
to change the crypto twice, i.e., 2406 should remain what it was
from the beginning: a check that Botan is not (yet) too wired
in the BIND 10 code.

Regards

Francis Dupont <fdupont at isc.org>