The prototype calculated with wrong limb size and not taken into account
the overflow in the shared limb.
Signed-off-by: Gabor Mezei <gabor.mezei@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>
IAR was warning that conditional execution could bypass initialisation of
variables, although those same variables were not used uninitialised.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Since only a single hash algorithm is currenlty supported, this avoids
having to perform hashing more than once.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
A CMS signature can have internal data, but mbedTLS does not support
verifying such signatures. Reject them during parsing.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
Since only one content type (signed data) is supported, storing the
content type just wastes memory.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
The lstrlenW() function isn't available to UWP apps, and isn't necessary, since
when given -1, WideCharToMultiByte() will process the terminating null character
itself (and the length returned by the function includes this character).
Resolves#2994
Signed-off-by: Tom Cosgrove <tom.cosgrove@arm.com>
