In case the certificate policy is not of type `AnyPolicy`
set the returned error code to `MBEDTLS_ERR_X509_FEATURE_UNAVAILABLE`
and continue parsing. If the extension is critical, return error anyway,
unless `MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION` is configured.
Fail parsing on any other error.
1) Fix typo in `mbedtls_x509_parse_subject_alt_name()` documentation.
2) Add a not in `mbedtls_x509_parse_subject_alt_name()` documentation,
stating that the lifetime of the target structure is restricted
by the lifetime ofthe parsed certificate.
Make `mbedtls_x509_subject_alternative_name` to be a single item
rather than a list. Adapt the subject alternative name parsing function,
to receive a signle `mbedtls_x509_buf` item from the subject_alt_names
sequence of the certificate.
The preceding calloc() already zeroizes that memory area, therfore the
memset() is not necessary. Compilers are likely to optimize this out,
but it still can be confusing to readers.
The previous behaviour of mbedtls_x509_parse_subject_alternative_name()
was to silently ignore errors coming from x509_get_other_name(). The
current commit fixes it and returns with an error.
In x509_info_subject_alt_name() we silently dropped names that we
couldn't parse because they are not supported or are malformed. (Being
malformed might mean damaged file, but can be a sign of incompatibility
between applications.)
This commit adds code notifying the user that there is something, but
we can't parse it.
Lengths are aleady checked in mbedtls_asn1_get_len() which is called in
mbedtls_asn1_get_tag(), therefore it is not necessary to check
the lengths explicitly afterwards.
Also with the previous flow data was left in the output buffer on some
errors.
Enabling the USE_CRYPTO_SUBMODULE option causes problems if the
crypto submodule isn't present. For example, when building
mbed-crypto as a submodule, it should use error.c from the parent
project if USE_CRYPTO_SUBMODULE is set. However if the parent
project isn't present, then the build will fail. Only enable it
if the submodule actually exists.
The documentation for some new structures and members was only a C style
comment and wasn't picked up by doxygen. This commit adds the missing
asterisks.
Only allow creating keys in the application (user) range. Allow
opening keys in the implementation (vendor) range as well.
Compared with what the implementation allowed, which was undocumented:
0 is now allowed; values from 0x40000000 to 0xfffeffff are now
forbidden.
Define a range of key identifiers for use by the application
(0..2^30-1), a range for use by implementations (2^30..2^31), and a
range that is reserved for future use (2^31..2^32-1).
Change the scope of key identifiers to be global, rather than
per lifetime. As a result, you now need to specify the lifetime of a
key only when creating it.
Record what key ids have been used in a test case and purge them. The
cleanup code no longer requires the key identifiers used in the tests
to be in a certain small range.
Declare algorithms for ChaCha20 and ChaCha20-Poly1305, and a
corresponding (common) key type.
Don't declare Poly1305 as a separate algorithm because it's a one-time
authenticator, not a MAC, so the API isn't suitable for it (no way to
use a nonce).
Make it a little easier to add ChaCha20-Poly1305.
This also fixes the error code in case mbedtls_gcm_setkey() fails with
a status that doesn't map to INVALID_ARGUMENT.
