MIME-Version: 1.0
In-Reply-To: <rt-3.8.6-2430-1416007201-1405.37814-5-0@isc.org>
References: <RT-Ticket-37814@isc.org> <546678C0.6040008@redhat.com> <rt-3.8.6-2430-1416007201-1405.37814-5-0@isc.org>
Message-ID: <5473A65B.5040903@redhat.com>
Content-Type: text/plain; charset=utf-8
Organization: Red Hat
Subject: Re: [ISC-Bugs #37814] PKCS#11 support for TSIG algorithms
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
Date: Mon, 24 Nov 2014 22:42:51 +0100
To: bind-suggest@isc.org
Content-Transfer-Encoding: 8bit
From: Petr Spacek <pspacek@redhat.com>
RT-Message-ID: <rt-3.8.6-2430-1416865378-1681.37814-0-0@isc.org>
Content-Length: 1904

Hello,

and thank you for your answer!

On 15.11.2014 00:20, Francis Dupont via RT wrote:
> I am currently out of my office (~12000 km) and
> I'll go back in some hours, so I apologise for
> the likely delay for a detailed answer.
> 
> BTW there is a new PKCS#11 standard (specs
> still required a final vote, include files are not
> yet available) but it won't change something as
> HMAC has been covered since a long time.
> 
> The native PKCS#11 supports *all* the standard
> crypto functions needed by named, including hash
> and HMAC. So there is nothing to change on this side.
> 
> If I understand well you'd like to put secrets in the HSM.
Yes, exactly.

> Currently this is supported only for RSA and ECDSA
> key pairs (look for a fromlabel methos in dst_funct
> arrays. Note for OpenSSL only RSA keys are supported
> (sound as ECC is not supported by the PKCS#11
> OpenSSL engine).
I'm thinking more about direct/native PKCS#11 support. OpenSSL's PKCS#11
engine never worked for me and generally with standard Red Hat packages ...

> Anyway it seems reasonable to extend fromlabel to
> HMAC secrets as HMAC is already in the DST stuff.
> Now I need the opinion of my colleagues if the result
> will be to get a PKCS#11 specific feature.
> 
> Note I don't yet fully understand your point about
> rndc tsig-list. I am afraid the current only way to
> configure TSIG keys (aka secrets) is to put them
> in the named config file... Surely something which
> requires ASAP improvements...

You understand me perfectly. I was making the point that TSIG keys stored in
key files (produced by dnssec-keygen) located in "keys-directory" are ignored
by named and and are not usable in zone "update-policy".

Maybe this could be a way how to separate keys from named config file and to
allow dynamic key management at run-time (with an equivalent of rndc loadkeys
for these TSIG keys).

-- 
Petr^2 Spacek