[Swan-dev] How to specify a CKAID in the config file
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:
> 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,
> 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.
>> 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
> 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:
More information about the Swan-dev