This commit also updates test_suite_pkparse.data file adding
MBEDTLS_CIPHER_C dependencies whenever PKCS[5/12] is used.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Each DER-encoded OID byte can only store 7 bits of actual data, so take
account of that.
Calculate the number of bytes required as:
number_of_bytes = ceil(subidentifier_size * 8 / 7)
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Instead, require the length of the string to be passed. This is more
useful for our use-case, as it is likely we will parse OIDs from the
middle of strings.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Allocate enough memory to guarantee we can store the OID, encode into
the buffer, then realloc and copy into a buffer of exactly the right
size.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
A few tests are also added which test the feature with a correct certificate and multiple ones with erroneous ASN1 tags.
Signed-off-by: toth92g <toth92g@gmail.com>
After this, only PK, X.509 and TLS remain to be done.
Deterministic uses HMAC-DRBG which uses MD, so it needs crypto_init()
when using a driver-only hash.
Also, remove a special-purpose macro that's no longer needed.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
When passed an empty OID, mbedtls_oid_get_numeric_string would read one
byte from the zero-sized buffer and return an error code that depends on
its value. This is demonstrated by the test suite changes, which
check that an OID with length zero and an invalid buffer pointer does
not cause Mbed TLS to segfault.
Also check that second and subsequent subidentifiers are terminated, and
add a test case for that. Furthermore, stop relying on integer division
by 40, use the same loop for both the first and subsequent
subidentifiers, and add additional tests.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
1. Parse through to get the required buffer length.
2. Having allocated a buffer, parse into the buffer.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Root nodes 0 and 1 may have up to 40 children (0 - 39), not 39 children
(0 - 38) as previously thought.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
OID subidentifiers are encoded as follow. For every byte:
* The top bit is 1 if there is another byte to come, 0 if this is the
last byte.
* The other 7 bits form 7 bits of the number. These groups of 7 are
concatenated together in big-endian order.
Overlong encodings are explicitly disallowed by the BER/DER/X690
specification. For example, the number 1 cannot be encoded as:
0x80 0x80 0x01
It must be encoded as:
0x01
Enforce this in Mbed TLS' OID DER-to-string parser.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The first 2 components of an OID are combined together into the same
subidentifier via the formula:
subidentifier = (component1 * 40) + component2
The current code extracts component1 and component2 using division and
modulo as one would expect. However, there is a subtlety in the
specification[1]:
>This packing of the first two object identifier components recognizes
>that only three values are allocated from the root node, and at most
>39 subsequent values from nodes reached by X = 0 and X = 1.
If the root node (component1) is 2, the subsequent node (component2)
may be greater than 38. For example, the following are real OIDs:
* 2.40.0.25, UPU standard S25
* 2.49.0.0.826.0, Met Office
* 2.999, Allocated example OID
This has 2 implications that the current parsing code does not take
account of:
1. The second component may be > 39, so (subidentifier % 40) is not
correct in all circumstances.
2. The first subidentifier (containing the first 2 components) may be
more than one byte long. Currently we assume it is just 1 byte.
Improve parsing code to deal with these cases correctly.
[1] Rec. ITU-T X.690 (02/2021), 8.19.4
Signed-off-by: David Horstmann <david.horstmann@arm.com>
As a public header, it should no longer include common.h, just use
build_info.h which is what we actually need anyway.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
