The has_issuer() and issued_by() methods relied on it to be defined, so
if the OCSP response wasn't successful (i.e. OCSP status indicates an
error and no OCSP response is parsed), a null-pointer dereference was
caused if the caller checked if the OCSP response was issued by a
specific certificate.
That's a side-effect of the referenced commit. Previously, error codes
caused the OCSP response to not get parsed successfully, which technically
wasn't correct as it's well formed and successfully parsed, it's just
indicating an error state.
Fixes: 00ab8d62c0 ("x509: Support generation of OCSP responses")
Seems this was forgotten in the referenced commit and actually could lead
to a buffer overflow. Since charon-tkm is untrusted this isn't that
much of an issue but could at least be easily exploited for a DoS attack
as DH public values are set when handling IKE_SA_INIT requests.
Fixes: 0356089d0f ("diffie-hellman: Verify public DH values in backends")
Fixes: CVE-2023-41913
Instead of the CA certificate's subjectKeyIdentifier erroneously
the CA's authorityKeyIdentifier was used as the authorityKeyIdentfier
of the certificate to be issued. This might work with a root CA
where the authorityKeyIdentifier equals its subjectKeyIdentfier
but introduces a severe regression when an intermediate CA is used.
Registered OCSP responders should return VALIDATION_SKIPPED for issuer
certificates they are not responsible for. However, VALIDATION_FAILED is
currently treated the same way, so that's fine as well.
The openxpki plugin directly access the certificates table in
the OpenXPKI's MariaDB in order to retrieve the status of an
issued X.509 certificate based on its serial number.
The kernel includes the XFRMA_REPLAY_ESN_VAL attribute when dumping
SAs since it was added with 2.6.39. So we basically added this attribute
twice to the message sent to the kernel, potentially exceeding the
message buffer if the window size is large.
The XFRMA_REPLAY_VAL attribute is only dumped since 3.19, so that might
still be relevant (Google seems to maintain a 3.18 kernel) and since we
have to query the current lifetime stats anyway, we can just avoid adding
this attribute twice.
Closesstrongswan/strongswan#1967
Instead of just generating an authorityKeyIdentifier based on the
issuer's public key, this allows CA certificates to be issued by a
different tool that doesn't use a SHA-1 hash of the subjectPublicKey
for the subjectKeyIdentifier.
Closesstrongswan/strongswan#1992
References strongswan/strongswan#1975
Maintaining the reqid when recreating a CHILD_SA from scratch night not
strictly be necessary as we usually don't have to replace any temporary
states in the kernel. However, there could be concurrent acquires that
might actually make it necessary (we use the reqid to keep track of
acquires and it's also part of the duplicate check).
Keeping a reference ensures that if the old SA expires before the new
one is installed, the previous reqid isn't reallocated to a concurrently
established CHILD_SA with different selectors.
Tobias Brunner