While for most uses the length is fixed and public (e.g. PRF/MAC outputs),
there are a few (e.g. in xauth-generic) that compare variable length
data.
The previous code directly leaked a differing length by short-circuiting
before comparing anything. While we could limit the comparison by the
minimum length (and call `memeq_const()`), that could still leak the
length because the time will plateau once the secret's length is reached.
Similarly, if the comparison was bound by the longer chunk (would prevent
the use of `memeq_const()`), the length could also be revealed once the
input gets longer than the secret and the time increases.
This changes the semantics of the function by declaring the first
argument the expected/reference secret and the second the variable input.
This strictly makes the function constant-time, bound by the secret's
length. So the length can't be guessed by providing different input (but
if an attacker can trigger the comparison against different secrets, of
potentially known lengths, it might still be possible). If the chunks
are known to have the same length, the order doesn't matter.
Callers of this function have been updated accordingly.
This allows setting the log level before initializing the library and
loading the plugins, as well as having the top-level command itself in
an options file.
When using OpenXPKI, the subject DN in the renewal request has to match
the previous DN exactly. However, because OpenXPKI may add a bunch of
DC/O RDNs to subjects of issued certificates, running --scep with the
same --dn that was used for the original request won't work (results in
a "Client error / malformed request badRequest" error even after enabling
`renewal_via_pkcs_req`). This simplifies renewals as --dn can just be
omitted and extracted from the original certificate to avoid this issue.
References strongswan/strongswan#1689
As indicated by the comparisons and the parsing in scep_parse_caps()
this should be a bitmask.
Fixes: 7c7a5a0260 ("pki: Enroll an X.509 certificate with a SCEP server")
Closesstrongswan/strongswan#1607
The flags encoded in the PKCS#10 structure (or derived from the encoded
profile name) might not be appropriate in some instances. This allows
overriding them without having to issue a new certificate request.
The x509 plugin retrieves serial numbers with two's complement
encoding whereas the openssl plugin partially returns them without
leading zeroes.
Serial numbers in X.509 certificates, X.509 CRL, X.509 attribute
certificates, OCSP Requests and OCSP responses are now returned in
canonical form without prepended zero octets.
Content-Transfer-Encoding is actually not a valid HTTP header, but a MIME
header, and must not be used. The original RFC7030 specifies this wrong,
and an errata discusses this issue.
The use of base64 encoding has been clarified in RFC8951, and the
recommendation is to always use/expect base64 encoding, but not send/expect
the Content-Transfer-Encoding header.
When an X.509 certificate has to be renewed it is helpful to use
the old PKCS#10 certificate request as a template, so that the
distinguishedName (DN), the subjectAlternativeName (SAN) and
a certificate profile name don't have to be typed-in again.
The old public key in the existing certreq is replaced with the
new key and the signature is re-generated using the new private key.
Tobias Brunner