[Swan-dev] nss vs newhostkey / showhostkey
Andrew Cagney
andrew.cagney at gmail.com
Wed May 25 17:14:02 UTC 2016
On 24 May 2016 at 17:36, Paul Wouters <paul at nohats.ca> wrote:
> On Tue, 24 May 2016, Andrew Cagney wrote:
>
>> In the old days this sort of thing worked:
>>
>> ipsec newhostkey --output /etc/ipsec.secrets
>> ipsec showhostkey --file /etc/ipsec.secrets
>
>
> the better term is "that sort of thing was required"
Ok. I think I'm getting to the right head space. The dogma is
s/ipsec.secrets/ipsec.d/. I.e., where as before it would meddle with
/etc/ipsec.secrets, it now meddles with /etc/ipsec.d.
In the case of newhostkey (a quick look at the man page shows it very
out-of-date):
[ --configdir <nssdbdir> ] the directory containing the NSS DB, by
default "/etc/ipsec.d" (some make variable)
--password <password> the password for accessing the NSS DB, if
required, should this be required. Nice to have is slurping the
password out of /etc/ipsec.secrets
and:
--output <ipsec.secrets> is either optional or gone and appending to
/etc/ipsec.secrets is not the default
(a way to dump the certificate into a file would be nice to have, mind)
so provided /etc/ipsec.d (and perhaps /etc/ipsec.secrets) are set up then:
ipsec newhostkey
will add a key to the NSS DB. I suspect it, in addition to:
[root at east nss-cert-ocsp-07-nourl]# ipsec newhostkey
Generated RSA key pair was stored in the NSS database
it should print information that identifies the generated key.
>> this was because newhostkey wrote all the details of the generated key
>> to /etc/ipsec.secrets where showhostkey could find it.
>> /etc/ipsec.secrets, in effect, was a "trust store" - a pool of
>> certificates that are blindly trusted.
>>
>> With NSS, this is no longer true. The keying material gets stored in
>> the database and instead a nickname or ckaid can be used to locate it.
>
>
> Right. If we can avoid id, neither public or private keys should require
> anything in ipsec.secrets.
>
>> But what should newhostkey / showhostkey do?
>>
>> - could be change to generate/parse ipsec.conf *ckaid= lines but I
>> suspect that wouldn't be helpful
>> a critical feature is certificate fall-over and specifying an exact
>> CKAID would prevent that
>> I could add ckaid2.... I guess
>
>
> I would say newhostkey should not touch ipsec.secrets at all.
> showhostkey should be able to find public keys (within a certificate
> or not) and return the (optional friendly_name), the cert it was in (if
> any) and the ckaid and pubkey blob.
>
>> - they could be changed to generate/parse ipsec.conf *rsasigkey= lines
>> directly
>>
>> So instead I'm changing newhostkey/showhostkey et.al. so that they
>> handle an ipsec.secrets file containing just:
>>
>> - generate/parse ipsec.secrets that contains a very minimal entry like:
>>
>> : RSA {
>> CKAIDNSS .....
>> }
>>
>> i.e, have ipsec.secrets specify a list of keys, that can be found in
>> NSS, to add to the 'trust store" (I've already changed to to require
>> just Modulus/PublicExponent/CAKIDNSS).
>
>
> What's the use of this?
>
> eg we just need something like:
>
> root at thinkpad:/etc/ipsec.d# certutil -K -d sql:/etc/ipsec.d
> certutil: Checking token "NSS Certificate DB" in slot "NSS User Private
> Key and Certificate Services"
> < 0> rsa 825c07463fabbe48abbc9d6b25e72be7329fd77d (orphan)
> < 1> rsa e413910e49698e8611cb0ca9fdc194689abbf002 (orphan)
And showhostkey will print the public bits in various formats.
> except we want to also display any potential friendly_name, and the
> pubkey blob as well. (the blob displayed now is ckaid)
It seems that the current friendly name is "(orphan)" aka NULL. I
guess, without --id (or ckaid or nickname?), it should list "orphans"
on the assumption that they are host keys.
> Paul
More information about the Swan-dev
mailing list