[Swan-dev] How to specify a CKAID in the config file

Andrew Cagney andrew.cagney at gmail.com
Thu Apr 28 16:48:39 UTC 2016

On 27 April 2016 at 21:57, Paul Wouters <paul at nohats.ca> wrote:
> On Wed, 27 Apr 2016, Andrew Cagney wrote:
>> My question is; how to specify this in the config file and on the
>> whack command line?
>> For the moment I've got:
>>    leftrsasigkey=%ckaid
>>    leftcert=22169af2dd143838caa67837bcfede1fde5d4e2a
> My preference is for leftcert= to be for certificates in the NSS DB,
> not pubkeys.

The current CKAID only looks in the NSS DB for a certificate that
matches.  This is because ...

> Unless we are going to generate pubkeys and store them
> in certificates in the NSS DB.

(For my testing I need to figure that out anyway.)

.. the user's workflow, and pluto's behaviour, when it comes to raw
pubkeys, starts to get a little weird.

- raw pubkeys can be fed into pluto using
(there's also /etc/ipsec.secrets, while I'm sitting on a patch to make
parsing this more liberal I'm trying to ignore it :-)

- midway through parsing ipsec.conf the raw pubkey gets sent as an
out-of-band message to pluto where it is appended to &pluto_pubkeys

- since, as best I can tell and please prove me wrong, nothing ties
the raw key to a connection end, something like leftrsasigkey2=...
might end up being used by "left" to authenticate/sign "right" (or is
that round the other way :-)

I think of this as the java "trust-store" model - if a pubkey is in
the trust-store then it is implicitly trusted.

But how should this interact with CKAID?  If rsasigkey=CKAID is used
then the ability to load up the trust-store with a raw key is lost
(lets pretend I didn't suggest rsasigkey=CKAID,
rsasigkey2=<pubkey-matching-ckaid> :-)

> So I would prefer: leftrsasigkey=22169af2dd143838caa67837bcfede1fde5d4e2a
> That is, if we recognise it is not %specialvalue or 0sPUBKEY or
> 0xHEXKEY, that we assume it is a CKAID. I would like to avoid
> calling something a cert when it is not.

Yes, "0s" identifies the encoding (base-64), not that it is a pubkey.
Anything ttodata accepts, which includes:


are allowed.  What I don't like is having to interpret:


as a CKAID, but:


as a raw pubkey.  It strikes me as that little bit too magic - both
read like we're specifying the raw pubkey.

Hence my preference to more clearly identify line noise like the CKAID.

> We could also introduce a new keyword, leftckaid= or make leftckaid=
> an alias for leftrsasigkey= although we will still need to have
> leftrsasigkey= for the remote endpoint when we configure it by public
> key. And it should get renamed leftpubkey= with leftrsasigkey= as
> a backwards compatible alias.

>> and:
>>    whack .. --ckaid 22169af2dd143838caa67837bcfede1fde5d4e2a ...
> that works for me.
>> I'm not so sure about the config file; in part because I'm suspicious
>> of the existing behaviour.  For instance, I suspect:
>> -  leftrsasigkey=%dnsondemand leftcert=east
>>   still loads "east"
> That is a bogus configuration anyway. It is undefined behaviour as far
> as I am concerned.

What's the saying: what isn't explicitly denied is allowed :-(

>> - leftrsasigkey=<raw-cert> leftrsasigkey2=%dnsondemand
>>  leads to leftrsasigkey2 being ignored
> The "on demand" option is for remote keys, not local keys. The 2nd key
> option is only for local keys. So again undefined behaviour.
>> - and come ECC, having something like "rsasigkey=%cert" will be decidedly
>> weird.
> Yes, it should be renamed leftpubey.

Technical nit, a new *pubkey field with somewhat compatible behaviour.
Not an alias.  For instance:

*pubkey=anything-parsed-by-ttodata - an rfc2537 encoded pubkey tied to "*"???

and if someone decides to change the CKAID algorithm:


and also:



More information about the Swan-dev mailing list