[Swan-dev] nss vs newhostkey / showhostkey

[Paul Wouters]

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"

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

except we want to also display any potential friendly_name, and the
pubkey blob as well. (the blob displayed now is ckaid)

Paul