Hi,
I support this.
Could certs.c live in `tests/data_files`? We should also make sure this file is automatically synced with the actual CRT and key files in that directory. There is a script which does that, but IIRC it's not called as part of the CI, which lead to certs.c and the data files get out of sync multiple times in the past.
Best Hanno ________________________________ From: mbed-tls mbed-tls-bounces@lists.trustedfirmware.org on behalf of Manuel Pegourie-Gonnard via mbed-tls mbed-tls@lists.trustedfirmware.org Sent: Monday, April 20, 2020 10:49 AM To: mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [mbed-tls] 3.0 plans - move certs.c out of the library
Hi all,
In this new installment of "let's discuss ideas for Mbed TLS 3.0" [1]: should we move certs.c out of the library?
[1]: https://developer.trustedfirmware.org/w/mbed-tls/tech-plans-3.0/
Currently the X.509 library includes test certificates and keys, which are enabled by default in config.h - `MBEDTLS_CERTS_C`.
These are used in the following places:
- in library/x509.c in mbedtls_x509_self_test() - in tests/suites/test_suite_ssl.function - in programs/fuzz and programs/ssl
In Mbed TLS 3.0, as part of our effort to clean up and minimize our API, we'd like to remove certs.h and the certificates it contains from the library (except perhaps one static cert for mbedtls_x509_self_test()). Tests and example programs that need built-in certificates could still get them using any mechanism, included a file certs.c similar to the current one - but this file would no longer live in library or be included when building libmbedx509.
Reasons include:
- Including test certificates and keys in the library provides little value, as users will want to use their own certificates and keys anyway.
- Shipping private keys as part of the library is bad practice, even under the `mbedtls_test_` sub-namespace. There's a slight risk that some users could use them for prototyping and then inadvertently keep using unsafe private keys in production.
If you disagree or have concerns, please speak up! Also, if want to suggest ideas for where the replacement to library/certs.c should live or how it could be maintained, now's a good time as well!
Regards, Manuel. -- mbed-tls mailing list mbed-tls@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Hanno,
Could certs.c live in `tests/data_files`?
I don't have a strong opinion about that. Actually we could even have multiple such files for different uses cases, living in different places (for example one in programs/ssl, one in tests/suites, I'm not saying this makes sense, just that we could). Or for each cert and key that we have in `tests/data_files`, we could have a companion `foo.crt.h` file that contains just the data for this file (with an appropriate naming convention). This could for example be useful to modify `test_suite_x509parse` to run usefully on targets that do now have a filesystem - again I'm not saying this would be the best approach, just throwing out ideas.
We should also make sure this file is automatically synced with the actual CRT and key files in that directory. There is a script which does that, but IIRC it's not called as part of the CI, which lead to certs.c and the data files get out of sync multiple times in the past.
Unless I'm mistaken, this script is only present in the baremetal branch so far and hasn't been upstreamed yet (partly due to questions about its implementation language): https://github.com/ARMmbed/mbedtls/pull/2596
But I strongly agree this or these files should be generated (and automatically checked to be up-to-date). Actually, I think we should even provide a general-purpose script (and/or python module) for generating a C version of a certificate. There are several workflows where you want to embed certificates in an application (for example a list of trusted CAs) and too often I've seen people embedding a PEM representation of a certificate, which is the easiest thing to do but is a waste of resources: not only because the cert data itself is larger that way, but because you then need to include PEM_C and BASE64_C in your config, which your probably wouldn't need otherwise. I can only guess that one of the reasons is because PEM looked easy and people didn't always know there was a better way - if we provided a convenient script to generate suitable data (from a certificate in any format), it would probably help with that.
(By the way when I say "people" that includes us: before the baremetal branch we couldn't run (non-PSK) SSL tests without adding BASE64+PEM to the config. We still can't in the upstream branch - unless you count programs/ssl/mini_client.c, which has a hand-generated, hence probably outdated, copy of test-ca2.crt embedded.)
Regards, Manuel.
mbed-tls@lists.trustedfirmware.org
-
Hanno Becker -
Manuel Pegourie-Gonnard