Dear Manuel,

 

No need to say how popular MBEDTLS is, no need to say how important it is for embedded system that choose it to setup security connections.

We kindly hope MBEDTLS team will take this issue as a high priority issue and fix it with high priority.

If my team could do anything helpful, just let us know, we want to and hope to contribute as much as we could.

 

Have a good day!

 

B.R.

 

Xiao Nian Jun.

 

From: Manuel Pegourie-Gonnard <Manuel.Pegourie-Gonnard@arm.com>
Sent: Tuesday, December 29, 2020 8:50 PM
To: Xiao, Nian Jun (RC-CN DI FA BL CTR-SL PRC2) <nianjun.xiao@siemens.com>
Cc: He, Shu Shan (RC-CN DI FA BL CTR-SL PRC2) <shushan.he@siemens.com>; Xia, Juan (RC-CN DI FA BL CTR-SL PRC2) <juan.xia@siemens.com>; mbed-tls@lists.trustedfirmware.org
Subject: Re: MBEDTLS issue I found

 

Dear Xiao Nian Jun,

 

Thanks for your response! Knowing the practical impact of the issue will help us prioritize it.

 

Best regards,
Manuel


From: Xiao, Nian Jun <nianjun.xiao@siemens.com>
Sent: 29 December 2020 02:43
To: Manuel Pegourie-Gonnard <Manuel.Pegourie-Gonnard@arm.com>
Cc: He, Shu Shan <shushan.he@siemens.com>; Xia, Juan <juan.xia@siemens.com>
Subject: RE: MBEDTLS issue I found

 

Dear Manuel,

 

Really appreciate for your quick and detail feedback.

 

We think this is more like an  interoperability issue, we found this issue during we developing webserver feature using MBEDTLS. Google Chrome treat such certificate as invalid. Follow below steps will reproduce this issue.

1.     Generate a self-signed root certificate with ECC256 key.(using genKey and certWrite program of MBEDTLS)

2.     Using above root certificate to sign a device certificate which also using ECC256 as its private key. (using genKey and certWrite program of MBEDTLS)

3.     Install root certificate so Chrome can see it.

4.     using Nginx or some other opensource web server, modify its configuration so it will use the device certificate and corresponding private key as the ciphers to setup TLS communication.

5.     Open Chrome and visit default Nginx web page(or some other web server tools’ default web page), you can see Chrome won’t let user to continue because it treat the device certificate as invalid.

6.     According to our test, Chrome has this issue, fire fox, IE, etc. doesn’t have this issue.

7.     If I modify function mbedtls_asn1_write_algorithm_identifier like I said yesterday, Chrome will accept it and other browser also will accept it, happy life back again.

 

Have a good day and looking for your feedback again!

 

B.R.

 

Xiao Nian Jun.

 

From: Manuel Pegourie-Gonnard <Manuel.Pegourie-Gonnard@arm.com>
Sent: Monday, December 28, 2020 9:23 PM
To: mbed-tls@lists.trustedfirmware.org; Xiao, Nian Jun (RC-CN DI FA BL CTR-SL PRC2) <nianjun.xiao@siemens.com>
Cc: He, Shu Shan (RC-CN DI FA BL CTR-SL PRC2) <shushan.he@siemens.com>
Subject: Re: MBEDTLS issue I found

 

Dear Xiao Nian Jun,

 

Thanks for your kind words and for reporting this issue you found.

 

I checked RFC 7427 and indeed while parameters must be present and NULL for all RSA algorithms, appendix A.3 is clear that they must be absent for ECDSA. Since RFC 7427 is about IKEv2 rather than about X.509 certificates, I also checked RFC 5480 (updating RFC 3279 which defines the X.509 profile used by the IETF), and it concurs: for ECDSA, parameters are absent (appendix A).

 

Our behaviour is not conformant, and this should be fixed. Just to help us evaluate the severity of the issue, I'd like to know if this is something you found by inspecting the generated certificate yourself, or if it caused the generate certificate to be rejected by some other X.509 implementation or verification tool. Said otherwise, is this only a compliance issue, or also an interoperability issue?

 

Regarding your fix, I think it works as long as you are only generating ECC-signed X.509 certificates, but as you suggest, I'm afraid it only fixes the problem by creating another one: it would suppress the NULL parameters for RSA as well, but unfortunately, they're mandatory there (I wish the standards were more consistent). So, we'll probably have to do something similar, but only for ECDSA.

 

I was going to create a ticket for that in our bug tracker when I noticed we already have a ticket tracking that: https://github.com/ARMmbed/mbedtls/issues/2924 - Ill add a link to your message in the ticket.

 

Thanks again for your report.

 

Best regards,
Manuel

 


From: mbed-tls <mbed-tls-bounces@lists.trustedfirmware.org> on behalf of Xiao, Nian Jun via mbed-tls <mbed-tls@lists.trustedfirmware.org>
Sent: 28 December 2020 03:24
To: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Cc: He, Shu Shan <shushan.he@siemens.com>
Subject: [mbed-tls] MBEDTLS issue I found

 

Dear MBEDTLS team,

 

I’m a developer at SIEMENS, my name is Xiao Nian Jun. Please accept my sincere gratitude for your excellent work and to spend extra time to read my email.

We are using MBEDTLS to generate ECC key and certificates, we found an issue regarding algorithm identifier in the final ASN.1 certificate. For certificate signed by ECC key, the algorithm identifier is “NULL” which doesn’t conforms to RFC7427 specification.

 

You can see the “NULL” string in the certificate, Chrome will treat this kind of certificate as invalid.

                                                                            

This issue has blocked us for a while, and after some investigation, we found an easy fix –- probably immature fix --- to make it works right--- we just commented out this line of code “MBEDTLS_ASN1_CHK_ADD( len, mbedtls_asn1_write_null( p, start ) )" in function mbedtls_asn1_write_algorithm_identifier.

To be honesty, we’ve been using MBEDTLS for very short time, probably this is not an issue, probably our fix will end up break up something…currently, it’s just looks correct.

 

Please check if my fix works or not, if not, please do not hesitate to correct me.

 

 

B.R.

 

Xiao Nian Jun.