RFC 5280 defines many type of names to be used in the subjectAltName
extension of certificate. So far we only supported dNSName, but there is
demand for IP addresses too.
This is the first step, support for verification will be added in the next
commit.
The name is actually check against either SAN or CN, so mentioning only one
in the error string might wrongfully suggest the other was ignored.
OTOH, keep the same error code for both, as the distinction between both types
is a rather low-level detail (and anyway changing the error code returned in
some cases would be an API change so is not an option at this point).
Remove check on the pathLenConstraint value when looking for a parent to the
EE cert, as the constraint is on the number of intermediate certs below the
parent, and that number is always 0 at that point, so the constraint is always
satisfied.
The check was actually off-by-one, which caused valid chains to be rejected
under the following conditions:
- the parent certificate is not a trusted root, and
- it has pathLenConstraint == 0 (max_pathlen == 1 in our representation)
fixes#280
* iotssl-515-max-pathlen:
Add Changelog entries for this branch
Fix a style issue
Fix whitespace at EOL issues
Use symbolic constants in test data
Fixed pathlen contraint enforcement.
Additional corner cases for testing pathlen constrains. Just in case.
Added test case for pathlen constrains in intermediate certificates
This helps in the case where an intermediate certificate is directly trusted.
In that case we want to ignore what comes after it in the chain, not only for
performance but also to avoid false negatives (eg an old root being no longer
trusted while the newer intermediate is directly trusted).
closes#220
Assume we have two trusted CAs with the same name, the first uses ECDSA 256
bits, the second RSA 2048; cert is signed by the second. If we do the keysize
check before we checked the key types match, we'll raise the badkey flags when
checking the EC-256 CA and it will remain up even when we finally find the
correct CA. So, move the check for the key size after signature verification,
which implicitly checks the key type.
Just applying rename.pl with this file:
mbedtls_cipher_get_key_size mbedtls_cipher_get_key_bitlen
mbedtls_pk_get_size mbedtls_pk_get_bitlen
MBEDTLS_BLOWFISH_MIN_KEY MBEDTLS_BLOWFISH_MIN_KEY_BITS
MBEDTLS_BLOWFISH_MAX_KEY MBEDTLS_BLOWFISH_MAX_KEY_BITS
- allows to express 'none' or 'all' more easily than lists
- more compact and easier to declare statically
- easier to check too
Only drawback: if we ever have more than 32 curves, we'll need an ABI change to
make that field a uint64_t.
* mbedtls-1.3:
Mark unused constant as such
Update ChangeLog for recent external bugfix
Serious bug fix in entropy.c
Fix memleak with repeated [gc]cm_setkey()
fix minor bug in path_cnt checks
Conflicts:
include/mbedtls/cipher.h
library/ccm.c
library/entropy.c
library/gcm.c
library/x509_crt.c
If the top certificate occurs twice in trust_ca (for example) it would
not be good for the second instance to be checked with check_path_cnt
reduced twice!
- more freedom for us to change it in the future
- enforces hygiene
- performance impact of making accessors no longer inline should really be
negligible
