Some algorithm identifiers are not correctly encoded

[RonEld]

Description

Raised in the forum by Michal Kochel:

I think there is an error in function mbedtls_asn1_write_algorithm_identifier (library\asn1write.c).
Depending on par_len it encodes par_len or NULL. But there is a third option.
If we look at https://tools.ietf.org/html/rfc7427#page-14 there are some algorithm identifiers which do not have parameter and NULL should not be placed.

We can see this problem when comparing what OpenSSL and Mbed TLS produces.

Mbed TLS produces following ASN.1

10:d=3 hl=2 l= 1 prim: INTEGER :00
13:d=2 hl=2 l= 3 prim: INTEGER :652040
18:d=2 hl=2 l= 12 cons: SEQUENCE
20:d=3 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
30:d=3 hl=2 l= 0 prim: NULL
32:d=2 hl=2 l= 53 cons: SEQUENCE

OpenSSL produces following ASN.1

4:d=1 hl=4 l= 279 cons: SEQUENCE
8:d=2 hl=2 l= 3 prim: INTEGER :652040
13:d=2 hl=2 l= 10 cons: SEQUENCE
15:d=3 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256
25:d=2 hl=2 l= 53 cons: SEQUENCE
27:d=3 hl=2 l= 11 cons: SET

Problem was found when I wanted to create a CA certificate and an endpoint certificate (both with keys based on elliptic curves).
When CA certificate was created with RSA key, everything was correct.
There was no problem when endpoint certificate had key based on elliptic curves.
When I used keys based on elliptic curves with CA certificate Chrome reported NET::ERR_CERT_INVALID during SSL_do_handshake.

Issue request type

[ ] Question
[ ] Enhancement
[x ] Bug

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/IOTCRYPT-1046

[mkochel]

When can we expect correction of this bug?