This also restores the charon.signature_authentication_constraints
functionality, that is, if no explicit IKE signature schemes are
configured we apply all regular signature constraints as IKE constraints.
This allows for different signature schemes for IKE authentication and
trustchain verification.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
This is particularly important for single valued rules (e.g.
identities). When copying values this is already handled correctly
by the enumerator and add().
Not sure if defining multiple CA constraints and enforcing _all_ of them,
i.e. the previous behavior, makes even sense. To ensure a very specific
chain it should be enough to define the last intermediate CA. On the
other hand, the ability to define multiple CAs could simplify configuration.
This can currently only be used with swanctl/VICI based configs as `rightca`
only takes a single DN.
Due to the issue described in c641974, purge() inadvertently destroyed
CA certificates that should have been kept (while the pointer to these
objects remained in the array). This lead to incorrect reference counts
and after a few reauthentications with multiple authentication rounds,
which cause calls to purge(TRUE), to crashes.
By using the default list enumerator and adding the rules with the public
add() method, clones of auth_cfg_t objects would return the values for
single-valued auth rules in the wrong order (i.e. the oldest instead of the
newest value was returned). Using the internal enumerator (which the comment
already suggested) fixes this, but the clone will not be a full clone as
it does not contain any old values for single-valued auth rules. Since
these will never be used anyway, this should be fine.
We previously only confirmed that rules contained in the first config are also
contained in the second, but since the number of rules does not have to
be equal, it might be that the second config contains rules that the
first one doesn't.
If it is set on an auth config IDr will not be sent, and later the configured
identity will not only be checked against the returned IDr, but also
against other identities contained in the responder's certificate.
These rules are now inserted at the front of the internal list, this
allows to retrieve the rule added last with get(). For other rules the
order in which they are added is maintained (this allows to properly
enumerate them).
Andreas Steffen