Date: Sun, 3 Dec 2017 13:34:17 +0530 X-RT-Interface: Email X-Spam-Status: No, score=0.0 required=5.0 tests=LOTS_OF_MONEY autolearn=unavailable autolearn_force=no version=3.4.1 X-RT-Incoming-Encryption: Not encrypted Message-ID: <20171203080417.GA30282@jurassic.lan.banu.com> In-Reply-To: To: "Evan Hunt via RT" content-type: text/plain; charset="utf-8" From muks@isc.org Sun Dec 3 08:04:29 2017 X-Original-To: bind9-public@bugs.isc.org References: <20171202142323.GA20227@jurassic.lan.banu.com> <20171203015127.GA13120@isc.org> <20171203040422.GA28025@jurassic.lan.banu.com> <20171203071312.GA16117@isc.org> Delivered-To: bind9-public@bugs.isc.org User-Agent: Mutt/1.9.1 (2017-09-22) X-RT-Original-Encoding: utf-8 Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.pao1.isc.org", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by bugs.isc.org (Postfix) with ESMTPS id CE9D0D78B0A for ; Sun, 3 Dec 2017 08:04:28 +0000 (UTC) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by mx.pao1.isc.org (Postfix) with ESMTP id ED6293AC793 for ; Sun, 3 Dec 2017 08:04:25 +0000 (UTC) Received: from jurassic.lan.banu.com (unknown [115.118.211.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 2BA7456A034A; Sun, 3 Dec 2017 08:04:21 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.pao1.isc.org MIME-Version: 1.0 Content-Disposition: inline Return-Path: From: "Mukund Sivaraman" Subject: Re: [ISC-Bugs #46749] Update PKCS #11 OpenSSL engine usage documentation in ARM RT-Message-ID: Content-Length: 2962 On Sun, Dec 03, 2017 at 07:13:16AM +0000, Evan Hunt via RT wrote: > > > I agree the doc should be updated though. Native PKCS#11 is much more > > > useful now and ought to be emphasized. > > > > How is it more useful? > > I meant it's more useful than it was when we first shipped it, > because there are more HSMs that support it now. > > > I want us to minimize the amount of crypto code we have in BIND tree. I > > want us to drop the native PKCS #11 code and stick to the OpenSSL engine > > code. With that we'll use a single crypto implementation in the tree. > > Okay, I misunderstood you then, and I disagree. Unless things have > changed substantially since I last looked, OpenSSL doesn't support > PKCS#11; the pkcs11 engine is implemented by the patches we provide, > which were never accepted by the upstream maintainers, and they don't > really work all that well; debugging is huge pain. Francis also came back to me with similar arguments about OpenSSL PKCS #11 support. I have checked that his specific claims are untrue. If you can list things that don't work, I can check these too. Look at: https://github.com/OpenSC/libp11 This is the better way to install a PKCS #11 OpenSSL engine, not our OpenSSL patching and custom build method. -- As example, with Fedora you can install this as the "engine_pkcs11" package. If you also have p11-kit installed, you don't have to configure anything except the HSM provider (there's no need to configure the OpenSSL engine). p11-kit list-modules should show you the crypto providers that are available. With softhsm2 as module, you can use softhsm2-util to configure the HSM (create tokens and configure PIN to access them). To create keys on the tokens, you can use p11tool provided by gnutls-utils. After that, OpenSSL can be passed a label string that selects a particular , e.g., using dnssec-keyfromlabel -E pkcs11 -l "". If there are any quirks (such as debug logging for extra cases that are not already provided by the engine), it is better to address them as patches to the pkcs11 engine rather than implement it BIND. > I think if we're going to support PKCS#11, native is the better way to > go. If I recall correctly, the only reason we kept OpenSSL PKCS#11 was > that you couldn't run native PKCS#11 with the AEP Keyper. (And that > may not even be true anymore.) We currently have 2 implementations of code to do crypto in BIND (3 if you also consider hashing). Which other server maintains so many forms of crypto? Application level crypto code should not be like this. How many operators does native PKCS #11 benefit? Why should we have it in BIND? From what we have right now, one would imagine root and TLD operators (and the handful of others who need to use a HSM) would be funding upwards of a million dollars to hire more people to maintain native PKCS #11 for their benefit for us to deal with CVEs due to it. Mukund