On Wed, 16 Sep 2020, Andrew Cagney wrote:
First, I believe ikev2-03-basic-rawrsa-ckaid is fixed. It uses the CKAID to
directly locate the raw key in the NSS DB. To confirm it is
working, look in west.pluto.log for "CKAID".The use case for this test is
pretty easy:- generate the raw key
- use certutil to find the ckaid
- add ...ckaid= to the config file
(how does the other end get the pubkey?)
To me this is not a real solution. It is a hack of loading multiple
partial conns to get one working conn out of it. You created this
test case, but I don't see the point in it. You are basically
re-arranging the deck chairs from : RSA {} into a partial conn.
So what's the use case for basic-pluto-01-nosecrets?
It is the simple one conn case real humans would configure. It shows a
need for the : RSA {} section in ipsec.secrets or else it fails to load
and work. Ideally, this : RSA {} is not needed and it can just load the
connection and find the private key once it oriented and requires the
private key.
For what it is worth, the fix means either a double lookup at "up" time:
-> using @west find the raw rsapubkey
-> using the raw rsapubkey's ckaid find the raw private key in the NSS DB
or, like basic-pluto-01, an attempt to load the raw key during "add" time
loading a conn is a sufficiently rare event that doing a double lookup
does not seem to be a big impact?
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
