[Swan-dev] nss vs newhostkey / showhostkey

[Paul Wouters]

On Wed, 25 May 2016, Andrew Cagney wrote:

> 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.

Right. well NSS db to be exact.

> 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

The nss passwd can be stored in /etc/ipsec.d/nsspasswd.

> and:
>
>  --output <ipsec.secrets> is either optional or gone and appending to
> /etc/ipsec.secrets is not the default

It should be removed when newhostkey no longer touches ipsec.secrets or
its includes.

> (a way to dump the certificate into a file would be nice to have, mind)

Yes. There is probably a certutil way?

> 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.

Yes. It would be nice if we could still give it an identifier and log
that into NSS for the key, similar to the "friendly_name" of
certificates. But I do not know if nss supports that.

>> 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.

If we can set those to something specified, that would be great. Like
FQDN per default?

Paul