library/certs.c provides some hardcoded certificates that
are used e.g. by the test applications ssl_server2, ssl_client2
in case no certificates are provided on the command line.
The certificates used are from the tests/data_files folder
and have been updated in the latest commits. This commit
updates their copies in certs.c. It also adds comments
indicating the files from which the data is taken, in
order to ease update in the future.
Previous commits have added or modified build instructions for
server1*, server2*, server5*, test-ca*, cli-rsa* in the Makefile
tests/data_files/Makefile, or the apps they invoke have been changed.
This commit regenerates those files to make sure they are in match with
the build instructions.
Previously, when checking whether a CRT was revoked through
one of the configured CRLs, the library would only consider
those CRLs whose `issuer` field binary-matches the `subject`
field of the CA that has issued the CRT in question. If those
fields were not binary equivalent, the corresponding CRL was
discarded.
This is not in line with RFC 5280, which demands that the
comparison should be format- and case-insensitive. For example:
- If the same string is once encoded as a `PrintableString` and
another time as a `UTF8String`, they should compare equal.
- If two strings differ only in their choice of upper and lower case
letters, they should compare equal.
This commit fixes this by using the dedicated x509_name_cmp()
function to compare the CRL issuer with the CA subject.
Fixes#1784.
This commit introduces variants test-ca_utf8.crt,
test-ca_printablestring.crt and test-ca_uppercase.crt
of tests/data_files/test-ca.crt which differ from
test-ca.crt in their choice of string encoding and
upper and lower case letters in the DN field. These
changes should be immaterial to the recovation check,
and three tests are added that crl.pem, which applies
to test-ca.crt, is also considered as applying to
test-ca_*.crt.
Previously, CSRs and CRTs from the server1* family in testa/data_files
were generated through OpenSSL. This commit changes the build instructions
to use Mbed TLS' example applications programs/x509/cert_write and
programs/x509/cert_req instead.
This commit adds a command line option `md` to the example application
`programs/x509/cert_req` allowing to specify the hash algorithm to use
when signing the CSR.
Return the condition compilation flags surrounding
`mbedtls_ecdh_compute_shared()`, `mbedtls_ecdh_gen_public()`,
`mbedtls_ecdsa_sign()` and `mbedtls_ecdsa_verify()` that were accidentally
removed in a previous merge.
Resolves#2163
This commit modifies a bounds check in `mbedtls_ecp_check_budget()` to
be correct even if the requested number of ECC operations would overflow
the operation counter.
Context:
The macro `MBEDTLS_ECP_BUDGET()` is called before performing a
number of potentially time-consuming ECC operations. If restartable
ECC is enabled, it wraps a call to `mbedtls_ecp_check_budget()`
which in turn checks if the requested number of operations can be
performed without exceeding the maximum number of consecutive ECC
operations.
Issue:
The function `mbedtls_ecp_check_budget()` expects a the number
of requested operations to be given as a value of type `unsigned`,
while some calls of the wrapper macro `MBEDTLS_ECP_BUDGET()` use
expressions of type `size_t`.
This rightfully leads to warnings about implicit truncation
from `size_t` to `unsigned` on some compilers.
Fix:
This commit makes the truncation explicit by adding an explicit cast
to `unsigned` in the expansion of the `MBEDTLS_ECP_BUDGET()` macro.
Justification:
Functionally, the new version is equivalent to the previous code.
The warning about truncation can be discarded because, as can be
inferred from `ecp.h`, the number of requested operations is never
larger than 1000.
Use `( x >> y ) & z` instead of `x >> y & z`. Both are equivalent
by operator precedence, but the former is more readable and the
commonly used idiom in the library.
Correct a typo in an AES XTS implementation comment where the relevant
NIST standard was incorrectly referred to as NIST 80-38E instead of NIST
800-38E.
It is inaccurate to call a data unit a "sector". A disk sector is a
common use case for the data unit, but there exist other types of data
units that are not sectors.
