[Swan-dev] nss vs newhostkey / showhostkey

[Andrew Cagney]

In the old days this sort of thing worked:

   ipsec newhostkey --output /etc/ipsec.secrets
   ipsec showhostkey --file /etc/ipsec.secrets

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.
For instance, ipsec.conf might contain:

   conn asdfa
      leftckaid=5f2d6ad2982122dde1e88dcf518d3a4f7dfe3ff2

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

- they could be changed to generate/parse ipsec.conf *rsasigkey= lines directly
  this, with something of a struggle (read user has to edit the
generated config file), preserve certificate fall-over

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

If this isn't reasonable, speak now or ...

Andrew