[Swan-dev] {left,right}rsasigkey2=...

[Andrew Cagney]

On Wed, 23 Sep 2020 at 02:18, Antony Antony <antony at phenome.org> wrote:

> On Tue, Sep 22, 2020 at 04:14:34PM -0400, Andrew Cagney wrote:
> > Regardless of the end, a line like:
> >    leftrsasigkey=
> >    leftrsasigkey2=...
> > will always add public keys like:
> >    (generated?) leftid / leftrsasigkey
> >    (generated?) leftid / leftrsasigkey2
> > to the list of raw public keys.  Left will then try all raw public keys
> > matching <id>.
> >
> > The problem is that the above aren't tied to "left".  Any connection,
> provided
> > the id matches, will use the raw public key; and sometimes use the wrong
> one.
>
> while it might be tempting to see this as a problem that need fix also
> consider pluto design of PSK secrets and possibly for certs too? They are
> all global. Ah, also xauth secrets, pam... PSK is global for sure. Once it
> is there any connection can use it. May be certs and intermediates got
> "fixed" they are per connection now. Previously it was not.
>
>

> Are there any ideas on how to extract us from this quirky mis-feature?
>
> I would be careful when attempting to fix it only for leftrsasigkey=.
> Consistancy across all authentication methods is good. If you think of
> using
> PSK per connection, think of backward compaitability too.
>
>
Sigh.  Including {left,right} yet ignoring it is appalling UI design.

I think I ran into the same when adding IPSECKEY from dns to pluto global
> pubkey store. I recollect OE assume the pubkey store is global and not per
> connection.
>
> > For
> > instance:
> > - let ipsec.secrets define raw public keys?
> > - come up with a syntax that makes it clear that it is shared?
> > - tie it to the connection's end somehow?
> > - drop it?
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20200923/de3286b2/attachment.html>