When the "same ciphersuite validation" was backported to 2.1, we
introduced the use of irrelevant defines in ssl_cli.c. all.sh catches
these as "Likely typos". Remove the code for ECJPAKE, a feature that doesn't exist in 2.1, from ssl_cli to fix this test failure.
******************************************************************
* test/build: declared and exported names
* Thu Apr 26 08:23:19 UTC 2018
******************************************************************
1175 macros
143 enum-consts
942 identifiers
771 exported-symbols
Exported symbols declared in header: PASS
Names of actual-macros: PASS
Names of enum-consts: PASS
Names of identifiers: PASS
Likely typos: FAIL
MBEDTLS_KEY_EXCHANGE_ECJPAKE
MBEDTLS_KEY_EXCHANGE_ECJPAKE_ENABLED
FAILED
* restricted/pr/469:
Improve comments style
Remove a redundant test
Add buffer size check before cert_type_len read
Update change log
Adjust 2.1 specific code to match the buffer verification tests
Add a missing buffer size check
Correct buffer size check
Clarify what MBEDTLS_ERR_ECP_SIG_LEN_MISMATCH and
MBEDTLS_ERR_PK_SIG_LEN_MISMATCH mean. Add comments to highlight that
this indicates that a valid signature is present, unlike other error
codes. See
https://github.com/ARMmbed/mbedtls/pull/1149#discussion_r178130705
Conflict resolution:
* ChangeLog
* tests/data_files/Makefile: concurrent additions, order irrelevant
* tests/data_files/test-ca.opensslconf: concurrent additions, order irrelevant
* tests/scripts/all.sh: one comment change conflicted with a code
addition. In addition some of the additions in the
iotssl-1381-x509-verify-refactor-restricted branch need support for
keep-going mode, this will be added in a subsequent commit.
The relevant ASN.1 definitions for a PKCS#8 encoded Elliptic Curve key are:
PrivateKeyInfo ::= SEQUENCE {
version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKey PrivateKey,
attributes [0] IMPLICIT Attributes OPTIONAL
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}
ECParameters ::= CHOICE {
namedCurve OBJECT IDENTIFIER
-- implicitCurve NULL
-- specifiedCurve SpecifiedECDomain
}
ECPrivateKey ::= SEQUENCE {
version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
privateKey OCTET STRING,
parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
publicKey [1] BIT STRING OPTIONAL
}
Because of the two optional fields, there are 4 possible variants that need to
be parsed: no optional fields, only parameters, only public key, and both
optional fields. Previously mbedTLS was unable to parse keys with "only
parameters". Also, only "only public key" was tested. There was a test for "no
optional fields", but it was labelled incorrectly as SEC.1 and not run because
of a great renaming mixup.
In mbedtls_ssl_derive_keys, don't call mbedtls_md_hmac_starts in
ciphersuites that don't use HMAC. This doesn't change the behavior of
the code, but avoids relying on an uncaught error when attempting to
start an HMAC operation that hadn't been initialized.
