Since the implementation no longer needs to know the oid, it makes more
sense for the error message to be an invalid name.
Signed-off-by: Agathiyan Bragadeesh <agathiyan.bragadeesh2@arm.com>
If no oid is found, and x509_attr_descr_from_numericoid returns NULL,
previously the memory allocated for the oid wasn't freed.
Signed-off-by: Agathiyan Bragadeesh <agathiyan.bragadeesh2@arm.com>
If the data is a bitstring or an octet string, instead use the hexstring
of the BER encoding (RFC 4514 Section 2.4)
Signed-off-by: Agathiyan Bragadeesh <agathiyan.bragadeesh2@arm.com>
This refactor is to accomodate future support of numericoid/hexstring
attributetype value pairs.
Signed-off-by: Agathiyan Bragadeesh <agathiyan.bragadeesh2@arm.com>
Converts none ascii to escaped hexpairs in mbedtls_x509_dn_gets and
interprets hexpairs in mbedtls_x509_string_to_names.
Signed-off-by: Agathiyan Bragadeesh <agathiyan.bragadeesh2@arm.com>
This escapes special characters according to RFC 4514 in
mbedtls_x509_dn_gets and de-escapes in mbedtls_x509_string_to_names.
This commit does not handle hexpairs.
Signed-off-by: Agathiyan Bragadeesh <agathiyan.bragadeesh2@arm.com>
"Fix PBKDF2 with empty salt on platforms where malloc(0)=NULL" took care of
making an empty salt work. But it didn't fix the case of an empty salt
segment followed by a non-empty salt segment, which still invoked memcpy
with a potentially null pointer as the source. This commit fixes that case,
and also simplifies the logic in the function a little.
Test data obtained with:
```
pip3 install cryptodome
python3 -c 'import sys; from Crypto.Hash import SHA256; from Crypto.Protocol.KDF import PBKDF2; cost = int(sys.argv[1], 0); salt = bytes.fromhex(sys.argv[2]); password = bytes.fromhex(sys.argv[3]); n = int(sys.argv[4], 0); print(PBKDF2(password=password, salt=salt, dkLen=n, count=cost, hmac_hash_module=SHA256).hex())' 1 "" "706173737764" 64
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The hardware module name otherName SAN contains 2 OIDs:
OtherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
HardwareModuleName ::= SEQUENCE {
hwType OBJECT IDENTIFIER,
hwSerialNum OCTET STRING }
The first, type-id, is the one that identifies the otherName as a
HardwareModuleName. The second, hwType, identifies the type of hardware.
This change fixes 2 issues:
1. We were erroneously trying to identify HardwareModuleNames by looking
at hwType, not type-id.
2. We accidentally inverted the check so that we were checking that
hwType did NOT match HardwareModuleName.
This fix ensures that type-id is correctly checked to make sure that it
matches the OID for HardwareModuleName.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
When parsing a subject alternative name of type otherName, retain the
type-id field of the otherName. Previously this was not copied to the
mbedtls_x509_san_other_name struct when it should have been.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
