These definitions are directly derived from the RFC, so it should be safe
to cast them. clang complains about the different types, so cast them
explicitly.
The AES code historically has different build options for various size/speed
trade-offs. We never made use of them, so just drop the obsolete code. The code
now has four hard-coded fixed tables, both inverse and original.
The salt, or often called implicit nonce, varies between AEAD algorithms and
their use in protocols. For IKE and ESP, GCM uses 4 bytes, while CCM uses
3 bytes. With TLS, however, AEAD mode uses 4 bytes for both GCM and CCM.
Our GCM backends currently support 4 bytes and CCM 3 bytes only. This is fine
until we go for CCM mode support in TLS, which requires 4 byte nonces.
To avoid considering each cached OCSP response and evaluating its trustchain,
we limit the certificates considered for OCSP signing to:
- The issuing CA of the checked certificate
- A directly delegated signer by the same CA, having the OCSP signer constraint
- Any locally installed (trusted) certificate having the OCSP signer constraint
The first two options cover the requirements from RFC 6960 2.6. For
compatibility with non-conforming CAs, we allow the third option as exception,
but require the installation of such certificates locally.
This behavior was introduced with 6840a6fb to avoid key/signature strength
checking for the revocation trustchain as we do it for end entity certificates.
Unfortunately this breaks CA constraint checking under certain conditions, as
we merge additional intermediate/CA certificates to the auth config.
As key/signature strength checking of the revocation trustchain is a rather
exotic requirement we drop support for that to properly enforce CA constraints.
This validator checks for any attribute certificate it can find for validated
end entity certificates and tries to extract group membership information
used for connection authorization rules.
We still try to calculate these directly as it can avoid a dependency on
the pkcs1 or other plugins. But for e.g. PGPv3 keys we need to delegate the
actual fingerprint calculation to the pgp plugin.
Clang does not initialize padding in union members so hashing the
complete "arg" union could lead to different hashes if the hashed
plugin_feature_t does not have static storage duration.
Fixes#549.
This now works because all plugins use the same config namespace.
If <ns>.load_modular is true, the list of plugins to load is determined
via the value of the <ns>.plugins.<name>.load options.
Using includes the following is possible:
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
charon-cmd {
load_modular = yes
plugins {
include strongswan.d/charon-cmd/*.conf
}
}
Where each .conf file would contain something like:
<name> {
load = yes
<option> = <value>
}
To increase the priority of individual plugins load = <priority> can be
used (the default is 1). For instance, to use openssl instead of the
built-in crypto plugins set in strongswan.d/charon/openssl.conf:
openssl {
load = 10
}
If two plugins have the same priority their order in the default plugin
list is preserved. Plugins not found in that list are ordered
alphabetically before other plugins with the same priority.
Tobias Brunner