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@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
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
