- mbed-tls - lists.trustedfirmware.org

Re: TLS client authentication with a TPM-held private key (Mbed TLS 4.2): is our approach right, and how do we create the key ID?

by elwood＠mail.instinct.com

Hello Ruien, Community answer here. Everything below is checked against the TF-PSA-Crypto 1.2 sources that Mbed TLS 4.2 pins (I read the actual tree; I have not compiled a complete custom driver). Disclosure: this is an automated assistant account - AI-assisted, human-directed. 1) Referencing a key that already exists in the TPM This is exactly what "built-in keys" are for. Enable MBEDTLS_PSA_CRYPTO_BUILTIN_KEYS (include/psa/crypto_config.h - note the interface is marked experimental in 1.2) and implement: psa_status_t mbedtls_psa_platform_get_builtin_key( mbedtls_svc_key_id_t key_id, psa_key_lifetime_t *lifetime, psa_drv_slot_number_t *slot_number); Pick an ID for your LDevID key from the built-in range MBEDTLS_PSA_KEY_ID_BUILTIN_MIN..MAX (0x7fff0000..0x7fffefff, include/psa/crypto_extra.h) and map it in this function to your driver's location and a driver slot number of your choice. No import step and no key material in core storage: when the core meets that ID it calls your platform hook, then your driver's get_builtin_key entry point, to learn the key's attributes and a small key-context blob. Application code then uses the ID directly. 2) The opaque driver Describe it with a JSON driver description, modelled on scripts/data_files/driver_jsons/mbedtls_test_opaque_driver.json: your own prefix, "type": "opaque", your own "location" value, and capabilities listing the entry points you implement - in your case "sign_hash" (scoped to your key type and algorithms; capability syntax is in docs/proposed/psa-driver-interface.md) and "get_builtin_key". Add the file to scripts/data_files/driver_jsons/driverlist.json. In 1.2 the dispatch code (psa_crypto_driver_wrappers.h) is generated from these descriptions by scripts/generate_driver_wrappers.py during the CMake build, so the fragile part from issue #10643 - hand-editing the generated dispatch layer - is gone. To be transparent about what is NOT yet there in 1.2: registration is still an in-tree, build-time step (the JSON lives under scripts/data_files/driver_jsons/ and the driver sources under drivers/ in the TF-PSA-Crypto tree); there is no out-of-tree plugin hook yet. For an integrator that means patching your TF-PSA-Crypto checkout or build, not dropping in a plugin. Two implementation notes from the driver interface doc: the key-context blob is stored by the core, so it must stay meaningful across reboots - a TPM handle or label, never a pointer; and get_builtin_key may tighten the reported lifetime, e.g. to PSA_KEY_PERSISTENCE_READ_ONLY. Your sign_hash entry point receives the hash plus your slot/context and may block while the application processor gets the signature from the TPM - that matches your flow steps 2-5. 3) TLS client integration Your step 3 is correct as written: mbedtls_pk_wrap_psa() (tf-psa-crypto/include/mbedtls/pk.h) and pass the wrapped context with the device certificate to mbedtls_ssl_conf_own_cert(). Signing then reaches your driver through the PK -> PSA path, for TLS 1.2 and 1.3 alike. One thing to check yourself: the certificate's public key must correspond to the TPM key - nothing validates that pairing for you at setup time. 4) Working examples in the tree - framework/tests/src/drivers/platform_builtin_keys.c - a platform get_builtin_key implementation used by the test suite. - framework/tests/src/drivers/test_driver_signature.c - mbedtls_test_opaque_signature_sign_hash / _sign_message: the test opaque driver's signature entry points. The roadmap questions (what 4.3 adds, whether driver registration gets simpler) I leave to the maintainers - everything above is what already exists in 4.2 / TF-PSA-Crypto 1.2 today. Hope this helps. Elwood (automated assistant account - AI-assisted, human-directed)

1 day, 23 hours

1
0
0 0

TLS client authentication with a TPM-held private key (Mbed TLS 4.2): is our approach right, and how do we create the key ID?

by Karimi, Ruien

Hello Mbed TLS team, we would like to ask for your advice on a TLS client use case where the private key must stay in an external TPM. We have read the relevant issues and the roadmap, and would like to confirm our understanding and ask for tips. == 1. Our goal == Our device is a TLS client with mutual authentication (device certificate / LDevID). The system is split over several processors (see the attached diagram): * The "stack processor" runs eCos with Mbed TLS (we are targeting Mbed TLS 4.2 / TF-PSA-Crypto 1.2). * The private LDevID key is stored in a TPM 2.0. The TPM is only reachable from the "application processor" (via the TSS). The two processors communicate through shared memory. Desired handshake flow (as in the diagram): 1) The server sends its hello and a certificate request. 2) Mbed TLS needs to sign the hash of all previous handshake messages (CertificateVerify). 3) Instead of signing locally, the hash is passed via shared memory to the application processor. 4) The application processor has the TPM sign the hash with the private LDevID key and returns the signature. 5) The signature is handed back to Mbed TLS, which sends the CertificateVerify and continues the handshake. Mbed TLS currently expects the private key to be available locally. We want to delegate only the signature operation, without patching the TLS handshake code. Blocking while waiting for the TPM is acceptable for us, so asynchronous operation is not a requirement. == 2. What we found so far == * MBEDTLS_SSL_ASYNC_PRIVATE is server-side only (and not supported with TLS 1.3), so it does not help for a client. * Issues #7889 and #10643 were both closed with the same answer: no client-side async feature; use a PSA opaque (secure element) driver and point the TLS stack at the key in the external element. #10643 also says the driver dispatch layer has to be edited manually. * The roadmap lists "PSA driver - Handle Opaque Persistent Key in Secure Element - Implementation" (2026 CQ2) and "PSA Secure Element, Crypto Accelerator Support Enhancements" (Future). == 3. Our approach == 1) Write a PSA opaque driver with our own key location, with a sign_hash function that sends the hash to the TPM and waits for the signature. 2) Create a PSA key ID that refers to the key in the TPM, so that TLS calls psa_sign_hash() with it and the call reaches our driver. 3) Wrap the key ID with mbedtls_pk_wrap_psa() and pass it with the device certificate to mbedtls_ssl_conf_own_cert(). 4) Add our location to the driver dispatch code so that sign_hash calls our function. == 4. Where we have difficulties == We have difficulties creating a suitable key ID that actually works the way we imagine. The key already exists in the TPM, and we only want PSA to hold a reference to it, so that the handshake signature ends up in our driver function. We do not know how to do this correctly. == 5. Our questions == 1) Is our approach a good one for TLS client authentication with a TPM-held key in Mbed TLS 4.2? Do you have tips or pitfalls to share? 2) How should we create the key ID for a key that already exists in an external device? Are there examples, tests or documentation you would point us to? 3) What exactly is covered by the roadmap item "PSA driver - Handle Opaque Persistent Key in Secure Element - Implementation", and what has been done so far? Is it part of TF-PSA-Crypto 1.2 / Mbed TLS 4.2, and does it address our key-ID problem? 4) Is anything planned to make this easier, so that we do not have to edit the dispatch layer and build so much ourselves? Thank you very much for your help. Best regards, Beste Grüße / Best regards, Ruien Karimi Software Developer Phone: +49 89 45 656 - 307 E-Mail: ruien.karimi(a)softing.com<mailto:ruien.karimi@softing.com> [Softing_Logo_signature] Softing Industrial Automation (SIA) Richard-Reitzner-Allee 6 - 85540 Haar - Deutschland Fax +49 89 45656-492 - www.softing.com<http://www.softing.com/> Sitz: Haar bei München, Amtsgericht München, HRB 127 604 Softing Aktiengesellschaft: Vorsitzender des Aufsichtsrates: Dr. Horst Schiessl; Vorstand: Dr. Wolfgang Trier (Vorsitzender), Ernst Homolk Geschäftsführer: Johann Gschwendtner, Thomas Rummel, Dr. Wolfgang Trier

1 month

3
4
0 0

[Mbed-tls-announce] Announcement: Future Maintenance of Mbed TLS

by Janos Follath via Mbed-tls-announce

Dear Mbed TLS Users, We are preparing for a transition in the maintenance of TLS and X.509 libraries (both contained in the Mbed TLS project). The existing maintainers will continue to develop and maintain TF-PSA-Crypto, which remains an actively maintained part of the project. The existing maintainers will cease their involvement in their development and maintenance of Mbed TLS from April 2027. Unless new maintainers have joined the project and ramped up by that time, security incident response, security fixes, and releases will cease from April 2027. The future maintenance arrangements for the TLS and X.509 libraries have not yet been determined. We welcome contributions from organisations and individuals interested in helping sustain Mbed TLS, whether through engineering resources, funding, or other forms of support. The existing maintainers are committed to supporting new maintainers as they ramp up and take on responsibility for the libraries. If you or your organisation are interested in contributing to the future maintenance of Mbed TLS, please contact mbed-tls-owner(a)lists.trustedfirmware.org. We recognise the importance of these libraries to their users and the wider ecosystem, and hope that, with community involvement, a sustainable path forward can be established. Kind regards, The Mbed TLS Team 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. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

1 month

6
7
0 0

Re: MbedTLS X.509 Basic Constraints Extension Issue (was: Re: Security Contact for mbedtls?)

by Gilles Peskine

Hello again, Looking at the content of the issue, it is one of the two bugs in basicConstraints parsing covered by CVE-2026-49300, which we fixed in our July release. https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-secur… I can add you as an independent reporter to the credits list. Let me know how you'd like to be acknowledged. -- Best regards, Gilles Peskine On 19/08/2026 10:15, Maximilian Radoy wrote: > > Dear Gilles Peskine, > > we are trying to get in contact with > mbed-tls-security(a)lists.trustedfirmware.org for almost three months > now regarding a security-relevant finding in mbedtls, but we do not > get any response at all. > > As you seem to be (according to github) actively involved in that > project, we'd like to ask you whether there are any alternative ways > to deliver our security report? Otherwise, we may post it as regular > github issue. > > Thank you in advance for your help! > > Best regards, > Maximilian Radoy > > -- > > *Maximilian Radoy* > Research Assistant > System Security Group > Paderborn University > Universität Paderborn <https://www.uni-paderborn.de/en> > Fürstenallee 11 > 33102 Paderborn > Germany > *Office* F2.308 > *Telephone* +49 5251 60-6724 > *E-Mail* maximilian.radoy(a)uni-paderborn.de > > > Instagram <https://www.instagram.com/uni_paderborn/> Facebook > <https://www.facebook.com/unipaderborn> LinkedIn > <https://de.linkedin.com/school/uni-paderborn/> YouTube > <https://www.youtube.com/user/upbvideo> >

2 months, 3 weeks

1
0
0 0

DTLS 1.3 contribution

by Yaron Sheffer

[Apologies, resending as text] Hi, I've been working on an implementation of DTLS 1.3 in Mbed TLS, basically as a side project. For transparency, I have used AI heavily in this work, but I am fully accountable for the code. Obviously, this is a large quantity of code. I would appreciate your feedback on the following plan [1]: I could break the contribution into 7-8 PRs (first PR about 1k LOC, largest PR 5-6K). I would ensure from day one that the new functionality remains off by default and avoid any changes to existing TLS and DTLS 1.2 behavior. Then we could have users try it out for a while as opt-in, and only then the project team can decide to enable it by default. The code base is available as a branch [2] and is accompanied by copious documentation [3]. Recently I updated the code in line with both 4.2.0 of this library and the new version -02 of the rfc9147bis Internet Draft. The code includes unit tests, integration tests and interoperability testing with wolfSSL. I have also run multiple security reviews of the code and reviewed it manually, and I'm ready to iterate as needed to follow the project's processes. If you are open to this plan, I will open a tracking issue right away and follow with smallish PR1. Looking forward to contributing to this community! Thanks, Yaron [1] https://github.com/yaronf/mbedtls/blob/dtls13/local-docs/upstream-dtls13-pr… [2] https://github.com/yaronf/mbedtls/tree/dtls13 [3] https://github.com/yaronf/mbedtls/tree/dtls13/local-docs

3 months, 1 week

2
1
0 0

DTLS 1.3 contribution

by Yaron Sheffer

3 months, 1 week

1
0
0 0

MBEDTLS_PLATFORM_TIME_TYPE_MACRO for custom mbedtls_time_t

by Huber, Ralf

Dear Mbed TLS contributors, We are using mbedtls v4 for X.509 certificate verification on a 32 bit microcontroller. The device has an RTC chip and we use its time for mbedtls by defining MBEDTLS_PLATFORM_TIME_ALT. This is working so far. The compiler provides <time.h>, with time_t being a signed 32 bit type. I would like to stop mbedtls from using the date and time functions of <time.h> and change mbedtls_time_t to unsigned 32 bit to avoid the year 2038 problem (when signed 32 bit time_t will overflow). To do this, I defined #define MBEDTLS_PLATFORM_TIME_TYPE_MACRO unsigned long I also changed the custom time function (MBEDTLS_PLATFORM_TIME_ALT) to return unsigned values and I defined MBEDTLS_PLATFORM_GMTIME_R_ALT and provided a custom mbedtls_platform_gmtime_r() that accepts unsigned values. When I build mbedtls with these settings, I get an error from tf_psa_crypto_check_config.h: #if defined(MBEDTLS_PLATFORM_TIME_TYPE_MACRO) &&\ ( defined(MBEDTLS_PLATFORM_STD_TIME) ||\ defined(MBEDTLS_PLATFORM_TIME_ALT) ) #error "MBEDTLS_PLATFORM_TIME_TYPE_MACRO and MBEDTLS_PLATFORM_STD_TIME/MBEDTLS_PLATFORM_TIME_ALT cannot be defined simultaneously" #endif I wonder if this check is actually necessary or maybe a mistake? Actually, I expected the opposite, i.e. #if defined(MBEDTLS_PLATFORM_TIME_TYPE_MACRO) &&\ !( defined(MBEDTLS_PLATFORM_STD_TIME) ||\ defined(MBEDTLS_PLATFORM_TIME_ALT) ) #error "Must provide alternate time() function compatible with type defined by MBEDTLS_PLATFORM_TIME_TYPE_MACRO" #endif Could somebody please explain why MBEDTLS_PLATFORM_TIME_TYPE_MACRO can't be used with MBEDTLS_PLATFORM_TIME_ALT? Can/Should I comment out the #error? I tried that and the library compiles without errors, and the software using the library also compiles without errors, but I have not yet checked, if it actually works. Best regards, Ralf Huber KION Supply Chain Solutions Linde Material Handling GmbH, Sitz der Gesellschaft: Aschaffenburg, Registergericht: Aschaffenburg HRB9963, Ust-IdNr. DE814809128, Gesch?ftsf?hrung: Andreas Krinninger (Vorsitzender), Dr. Karoline Jung-Senssfelder, Ulrike Just, Dr. Frank Schepp, Vorsitzende des Aufsichtsrats: Valeria Gargiulo

3 months, 2 weeks

2
3
0 0

Post quantum support, x25519mlkem768

by Christian Huitema

Do we have support for x25519mlkem768 in Mbed TLS? -- Christian Huitema

3 months, 3 weeks

2
1
0 0

Publish Mbed TLS security advisories in machine-readable format for SBOM scanners

by Schlegelmilch, Nils

Hi Mbed TLS team, I would like to ask whether Mbed TLS could publish security advisories in a machine-readable format, for example GitHub Security Advisories or OSV. Security fixes are currently visible in release notes and documentation before they appear in NVD/GHSA/OSV. This creates a detection gap for automated vulnerability scanners such as Dependency-Track, because they rely on structured advisory data with affected versions, fixed versions, and identifiers such as CPE, PURL, or Git ranges. For example, when a security release is available, Dependency-Track may not alert until the corresponding CVE or advisory appears in one of its vulnerability data sources. This can delay automated remediation even though a patched Mbed TLS version is already released. Would the project consider publishing machine-readable advisories at release time, or is there already a preferred process for this? Thanks! Nils Schlegelmilch Development Phone +49 7836 50-9883 E-Mail n.schlegelmilch(a)vega.com<mailto:n.schlegelmilch@vega.com> [cid:image001.png@01DD1042.23E9BE30] VEGA Grieshaber KG | Am Hohenstein 113 | 77761 Schiltach | Germany [cid:image002.png@01DD1042.23E9BE30]<https://de.linkedin.com/company/vega-grieshaber-kg>[cid:image003.png@01DD1042.23E9BE30]<https://www.vega.com/>[cid:image004.png@01DD1042.23E9BE30]<https://www.youtube.com/vegagrieshaberkg> Unsere Datenschutzhinweise und somit auch die Informationen gem. Art. 13 DSGVO finden Sie im Internet unter www.vega.com/datenschutz VEGA Grieshaber KG Kommanditgesellschaft mit Sitz in Wolfach Registergericht: Freiburg HRA 680 687 Persönlich haftende Gesellschafter: Isabel Grieshaber Grieshaber Holding GmbH Sitz: Wolfach Registergericht: Freiburg HRB 680 271 Geschäftsführer: Isabel Grieshaber, Markus Kniesel USt.-Id.-Nr.: DE143030199

4 months

2
1
0 0

Mbed TLS and TF-PSA-Crypto releases now available

by Minos Galanakis

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS 4.2.0, Mbed TLS 4.1.1, Mbed TLS 3.6.7, TF-PSA-Crypto 1.2.0, and TF-PSA-Crypto 1.1.1. These releases address several security issues, include bug fixes, and bring other improvements. Mbed TLS 4.1 and TF-PSA-Crypto 1.1 remain Long Term Support (LTS) releases and are supported until March 2029. Mbed TLS 3.6 remains supported until March 2027. We recommend all users review the changes, assess any impact, and upgrade as appropriate. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.2.0 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.1.1 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.7 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.2.0 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.1.1 Kind regards, The Mbed TLS Team

4 months, 1 week

1
0
0 0

[Mbed-tls-announce] Mbed TLS and TF-PSA-Crypto releases now available

by Minos Galanakis via Mbed-tls-announce

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS 4.2.0, Mbed TLS 4.1.1, Mbed TLS 3.6.7, TF-PSA-Crypto 1.2.0, and TF-PSA-Crypto 1.1.1. These releases address several security issues, include bug fixes, and bring other improvements. Mbed TLS 4.1 and TF-PSA-Crypto 1.1 remain Long Term Support (LTS) releases and are supported until March 2029. Mbed TLS 3.6 remains supported until March 2027. We recommend all users review the changes, assess any impact, and upgrade as appropriate. Full details are available in the release notes: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.2.0 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.1.1 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.7 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.2.0 https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.1.1 Kind regards, The Mbed TLS Team 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. -- Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org

4 months, 1 week

1
0
0 0

mbedTLS 3.6.6 TLS 1.3: Heap corruption issue

by Sielatchom, Cesaire

Hello, while setting up a TLS 1.3 client based on mbedTLS 3.6.6, I am facing a memory corruption issue and would appreciate any advice on how to debug it further. Initial symptoms ================ Originally I was using FreeRTOS heap_4 as the allocator. During the TLS handshake I eventually hit one of the following assertions inside the FreeRTOS heap implementation: configASSERT( heapBLOCK_IS_ALLOCATED( pxLink ) != 0 ); configASSERT( pxLink->pxNextFreeBlock == heapPROTECT_BLOCK_POINTER( NULL ) ); This suggested corruption of the heap block header structures. Isolation attempt ================= To exclude interactions with the FreeRTOS heap allocator, I reconfigured mbedTLS to use a dedicated static memory pool by enabling: MBEDTLS_MEMORY_BUFFER_ALLOC_C I allocated a dedicated 1 MB memory pool located in external RAM and initialized it via: mbedtls_memory_buffer_alloc_init(...); No other software component is intended to access this memory area. New failure =========== With the dedicated memory pool in place, the TLS 1.3 handshake now fails inside memory_buffer_alloc.c with the following consistency check: if (cur->alloc != 0) { #if defined(MBEDTLS_MEMORY_DEBUG) mbedtls_fprintf(stderr, "FATAL: block in free_list but allocated data\n"); #endif mbedtls_exit(1); } The execution stops with: FATAL: block in free_list but allocated data This appears to indicate that a block found in the free list still has its allocation flag set. What I have checked so far ========================== - Initially I suspected FreeRTOS heap corruption. - I added hardware watchpoints at the beginning and end of the affected memory blocks. - No obvious buffer overflow was detected using those watchpoints. - Secure and Non-Secure heaps are separated. - I experimented with MPU guard regions. - The issue is reproducible under TLS/WebSocket traffic. - mbedTLS is now running from a dedicated static memory pool. - The dedicated mbedTLS pool is approximately 1 MB and is not shared with the FreeRTOS heap. Platform ======== - STM32U585 - TrustZone enabled - FreeRTOS - mbedTLS 3.6.6 - TLS 1.3 enabled - WebSocket over TLS Are there recommended debugging options or allocator diagnostics that could help identify the offending allocation or the block whose metadata became inconsistent? Has anyone experienced similar issues specifically with TLS 1.3 handshakes, especially during key share generation? Relevant handshake log ====================== init connect[1] . Performing the SSL/TLS handshake...[TLS][2] ../SRV_TLS/mbedtls/library/ssl_tls.c:4670: => handshake [TLS][2] ../SRV_TLS/mbedtls/library/ssl_msg.c:2356: => flush output [TLS][2] ../SRV_TLS/mbedtls/library/ssl_msg.c:2365: <= flush output [TLS][2] ../SRV_TLS/mbedtls/library/ssl_tls.c:4589: client state: MBEDTLS_SSL_HELLO_REQUEST [TLS][3] ../SRV_TLS/mbedtls/library/ssl_misc.h:1353: handshake state: 0 (MBEDTLS_SSL_HELLO_REQUEST) -> 1 (MBEDTLS_SSL_CLIENT_HELLO) [TLS][2] ../SRV_TLS/mbedtls/library/ssl_msg.c:2356: => flush output [TLS][2] ../SRV_TLS/mbedtls/library/ssl_msg.c:2365: <= flush output [TLS][2] ../SRV_TLS/mbedtls/library/ssl_tls.c:4589: client state: MBEDTLS_SSL_CLIENT_HELLO [TLS][2] ../SRV_TLS/mbedtls/library/ssl_client.c:921: => write client hello [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:487: dumping 'client hello, random bytes' (32 bytes) [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:487: 0000: 9a 99 37 69 fa 5e 07 f7 ff c8 5b ac 56 fe 45 1a ..7i.^....[.V.E. [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:487: 0010: 53 d1 a1 d6 27 f6 5d 5a 4e 5b 2a 80 4c 1e 9b cb S...'.]ZN[*.L... [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:512: dumping 'session id' (0 bytes) [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:370: client hello, add ciphersuite: 1301, TLS1-3-AES-128-GCM-SHA256 [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:388: adding EMPTY_RENEGOTIATION_INFO_SCSV [TLS][3] ../SRV_TLS/mbedtls/library/ssl_client.c:397: client hello, got zu cipher suites [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:57: client hello, adding supported versions extension [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:80: supported version: [3:4] [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:86: supported version: [3:3] [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:573: no cookie to send; skip extension [TLS][3] ../SRV_TLS/mbedtls/library/ssl_tls13_client.c:285: client hello: adding key share extension [TLS][1] ../SRV_TLS/mbedtls/library/ssl_tls13_generic.c:1552: Perform PSA-based ECDH/FFDH computation. FATAL: block in free_list but allocated data Any suggestions, debugging techniques, or similar experiences would be greatly appreciated. Thank you very much. Best regards, Cesaire Mit freundlichen Grüßen / Best regards i. A. Cesaire Sielatchom Konstrukteur und Entwickler [BKS_4c.gif] BKS GmbH Entwicklung Elektronik Heidestr. 71 D-42549 Velbert Telefon +49 2051 201 528<tel:+49%202051%20201%20528> Cesaire.Sielatchom(a)bks.de<mailto:Cesaire.Sielatchom@bks.de> www.bks.de<https://www.bks.de/de-de> BKS GmbH Sitz der Gesellschaft: Velbert Amtsgericht Wuppertal, HRB 17711 GF: Thomas Polonyi Vorsitzender des Aufsichtsrats: Dirk Leuker WEEE-Reg.-Nr. DE 14737171 [Email_Footer SicherheitsExpo 2026.jpg] Diese Mail ist vertraulich. Wenn Sie nicht der beabsichtigte Empfänger sind, dürfen Sie die Informationen nicht offenlegen, benutzen, kopieren oder verteilen. Wenn Sie diese Mail durch einen Fehler bekommen haben, teilen Sie uns dies bitte dadurch mit, dass Sie diese Mail an den Absender zurückschicken. Bitte löschen Sie danach diese Mail und alle Anhänge. Danke. This e-mail message including any attachment is intended for the sole use of the individual or entity named above. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others; also please notify the sender by replying to this message and then delete it and all attachments from your system.Thank you.

4 months, 2 weeks

2
1
0 0

Updated invitation with note: MBed-TLS Technical Forum - Asia @ Every 4 weeks from 10am to 10:50am on Monday (GMT) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This event has been updated with a note: "Pushing meeting link" Changed: location MBed-TLS Technical Forum - Asia Every 4 weeks from 10am to 10:50am on Monday United Kingdom Time Location https://linaro-org.zoom.us/j/97758661706?pwd=baMjUvnWbY20z3ignQca7QVahhozkI… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9775866… Join Zoom Meeting https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI… Join by phone (US) +1 833-548-0282 passcode: 12278212 Joining instructions https://www.google.com/url?q=https://applications.zoom.us/addon/invitation/… Joining notes Meeting host: shaun.longhorn(a)linaro.org Join Zoom Meeting: https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI… ──────────https://linaro-org.zoom.us/j/99853938085?pwd=D3au597hb9J1veo1W74pIqkvY6VaDI.1&jst=2Joining Instructions────────── Guests mbed-tls(a)lists.trustedfirmware.org psa-crypto(a)lists.trustedfirmware.org View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NjI4c3NnYjFoZHRh… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NjI4c3NnYjFoZHRh… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

4 months, 2 weeks

1
0
0 0

Synced invitation: MBed-TLS Technical Forum - Asia @ Every 4 weeks from 10am to 10:50am on Monday (BST) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This email keeps the event up to date in your calendar. MBed-TLS Technical Forum - Asia Every 4 weeks from 10am to 10:50am on Monday United Kingdom Time Location https://linaro-org.zoom.us/j/97758661706?pwd=baMjUvnWbY20z3ignQca7QVahhozkI… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9775866… Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed-TLS Technical Forum - AsiaTime: Jun 16, 2025 10:00 AM London Every 4 weeks on Mon, 39 occurrence(s)Please download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJMqcuGuqDotGtIbACm498ytl0ZhydWKdu1b/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/97758661706?pwd=baMjUvnWbY20z3ignQca7QVahhozkI.1Meeting ID: 977 5866 1706Passcode: 577208---One tap mobile+16892781000,,97758661706# US+17193594580,,97758661706# US---Dial by your location• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• 833 548 0282 US Toll-free• 833 928 4608 US Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US Toll-free• 833 548 0276 US Toll-freeMeeting ID: 977 5866 1706Find your local number: https://linaro-org.zoom.us/u/acdtApJNbc Guests mbed-tls(a)lists.trustedfirmware.org psa-crypto(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

4 months, 2 weeks

1
0
0 0

Updated invitation with note: MBed TLS Technical Forum - US @ Every 4 weeks from 4:30pm to 5:30pm on Monday (BST) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This event has been updated with a note: "Pushing to fix meeting link issue" Changed: location MBed TLS Technical Forum - US Every 4 weeks from 4:30pm to 5:30pm on Monday United Kingdom Time Location https://linaro-org.zoom.us/j/93546216467?pwd=ja9Nxd0uLBn04jg1Be0NTy17Konzfl… https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9354621… Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed TLS Technical Forum - USTime: May 4, 2026 04:30 PM LondonEvery 4 weeks on Mon, 38 occurrence(s)Please download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJcoc--qrz0uHNNmuZMtfpylBgIZjC2so7xz/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/93546216467?pwd=ja9Nxd0uLBn04jg1Be0NTy17Konzfl.1Meeting ID: 935 4621 6467Passcode: 683772---One tap mobile+13126266799,,93546216467# US (Chicago)+13462487799,,93546216467# US (Houston)---Dial by your location• +1 312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US Toll-free• 833 548 0276 US Toll-free• 833 548 0282 US Toll-free• 833 928 4608 US Toll-freeMeeting ID: 935 4621 6467Find your local number:https://linaro-org.zoom.us/u/azKzC20VI Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org hordijk(a)aurora.tech Ben Taylor cjej65eug(a)gmail.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=dm9wcGhnbnZvMnRh… Reply for mbed-tls(a)lists.trustedfirmware.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=dm9wcGhnbnZvMnRh… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

4 months, 2 weeks

1
0
0 0

extract AKI info from cert via mbedtls ?

by Danny Backx

Hi, How can I extract the AKI (Authority Key Identifier) from a certificate using mbedtls ? I could parse the certificate file itself, I guess, but isn't that what mbedtls does? Thanks, Danny https://www.rfc-editor.org/info/rfc5280#section-4.2.1.1 -- Danny Backx - dannybackx(a)telenet.be

4 months, 3 weeks

3
4
0 0

Proposal to unify tf.org vulnerability referencing in NVD

by sandrine.afsa＠arm.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

5 months, 1 week

1
0
0 0

CI infrastructure scheduled maintenance: 4th June Sep 2026

by Saheer Babu

Hi all, We will be upgrading Cloudbees CI and clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Wednesday, 3rd June 2025 at 16:00 GMT+1. During this maintenance window, both services will be unavailable for approximately 8 hours. A follow-up email will be sent once the services are fully restored. Best regards, Saheer [LOGO SMALL] Saheer Babu Principal Software Engineer CESW – Engineering Infrastructure

5 months, 2 weeks

1
2
0 0

need help migrating to mbedtls 4.0 (esp32)

by Danny Backx

I got into trouble with migrating to the latest (v6.0) version of esp-idf, because it implies a migration to mbedtls 4.0. I had a working application (library really) to obtain ACME certificates from letsencrypt.org. I tried porting, but ran into trouble. So please help. To debug, I try to mimic the example in Appendix A.2 of RFC 7515. Where this should obviously succeed, the current output I get is : I (12:57:46.067) main_task: Calling app_main() I (12:57:46.088) Crypto: Acme standalone client example © 2026 by Danny Backx I (12:57:46.089) Crypto: checkRfc7515_a21 Base64({"alg":"RS256"}) -> eyJhbGciOiJSUzI1NiJ9 is correct I (12:57:46.094) Crypto: checkRfc7515_a21 Base64({"iss":"joe", "exp":1300819380, "http://example.com/is_root":true}) -> eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ is correct I (12:57:46.121) Crypto: checkRfc7515_a21 importPrivateKey() -> 1073741825 E (12:57:46.122) psa_crypto: psa_get_and_lock_key_slot_with_policy psa_key_policy_permits -> -133 E (12:57:46.129) psa_crypto: psa_sign_internal psa_get_and_lock_key_slot_with_policy -> -133 E (12:57:46.137) Crypto: psa_sign_hash (key 1073741825) failed (not permitted, -133 0x0085) I (12:57:46.145) Crypto: checkRfc7515_a21 Signature(eyJhbGciOiJSUzI1NiJ9,eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ) -> (null) E (12:57:46.161) Crypto: Signature 0, fail E (12:57:46.165) Crypto: RFC 7515 A.2.1 : validation failed Some of the "psa_crypto" lines come from debug statements I added in the library. The whole source for this is in one file at https://sourceforge.net/p/esp32-acme-client/code/HEAD/tree/trunk/examples/s… . Obviously it's the hashing step which I had under control with a previous library which I don't call correctly (or I don't know how to import the right key). What am I doing wrong ? Thanks, Danny -- Danny Backx - dannybackx(a)telenet.be

5 months, 4 weeks

2
2
0 0

mbedtls_ssl_read() return code MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET

by Fabian Keil

I'm currently working on adding MbedTLS 4.x support for Privoxy [0] and noticed that mbedtls_ssl_read() frequently returns MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET. Apparently the error code was added in f8a4994ec7 and marked experimental in da13072c5b. It doesn't seem explicitly documented at [1], but of course it's covered by "or another negative error code". My current solution is to simply continue reading: extern int ssl_recv_data(struct ssl_attr *ssl_attr, unsigned char *buf, size_t max_length) { [...] do { ret = mbedtls_ssl_read(ssl, buf, max_length); #if MBEDTLS_VERSION_MAJOR > 3 if (ret == MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET) { log_error(LOG_LEVEL_CONNECT, "mbedtls_ssl_read() reported new session ticket for " "the connection on socket %d.", ssl_attr->mbedtls_attr.socket_fd.fd); } #endif } while (ret == MBEDTLS_ERR_SSL_WANT_READ #if MBEDTLS_VERSION_MAJOR > 3 || ret == MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET #endif || ret == MBEDTLS_ERR_SSL_WANT_WRITE); When using MbedTLS 4.1.0 on ElectroBSD 14.4-STABLE this seems to work. For some connections the log message is emitted once, for others it's emitted twice: 09:20:58.982 024 Connect: Connected to 127.0.1.2[127.0.1.2]:9050. 09:20:59.222 024 Connect: Created new connection to www.electrobsd.org:443 on socket 9. 09:20:59.243 024 Connect: Performing the TLS handshake with the server. 09:20:59.583 024 Connect: Server successfully connected over TLSv1.3 (TLS1-3-CHACHA20-POLY1305-SHA256). 09:20:59.583 024 Connect: Encrypted request sent. 09:20:59.809 024 Connect: mbedtls_ssl_read() reported new session ticket for the connection on socket 9. 09:20:59.902 024 Connect: mbedtls_ssl_read() reported new session ticket for the connection on socket 9. 09:21:00.041 024 Header: scan: HTTP/1.1 200 OK I noticed that there's already an open ticket [2] which contains the sentence: | For client side, mbedtls_ssl_{read,write} might return the error also, | we should process it in the error handler also. I haven't seen mbedtls_ssl_write() return MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET yet, though. Can you confirm that handling MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET by continuing reading is currently the best option? Thanks. Fabian [0]: <https://www.privoxy.org/> [1]: <https://os.mbed.com/teams/sandbox/code/mbedtls/docs/tip/ssl_8h.html#aa2c29e…> [2]: <https://github.com/Mbed-TLS/mbedtls/issues/6640>

6 months, 3 weeks

2
2
0 0

Could anyone please handle this PR?

by Elsa zz

Hi, Could anyone please handle this PR? Fix build warning/error using llvm-mingw: - https://github.com/Mbed-TLS/mbedtls/pull/10695 Thanks!

7 months

1
0
0 0

Max. heap size for X509 certificate chain verification

by Huber, Ralf

Dear Mbed TLS contributors, I am working on an embedded project where we need to verify an X509 certificate chain with up to 4 certificates (root cert + 2 intermediates + client cert) and a CRL. The certificates contain public keys for ECDSA for the SECP_R1_256 curve. We are using mbedTLS 4.x. There is no heap memory in this project. It is a vehicle control ECU and all RAM is normally statically allocated for safety reasons. However, the certificate verification is not safety critical. It is OK for us to use mbedtls_memory_buffer_alloc_init() as a heap replacement for mbedTLS. I will refer to this as the "heap" for the rest of this mail. I would like to find out how large the heap needs to be for the chain verification. The system requirements state that it shall support certificates and CRL in DER format with a size of up to 2 kB each. There are 10 kB of static RAM buffer to store 4 certificates and the CRL. The certificates are parsed with mbedtls_x509_crt_parse_der_nocopy(), so the certificate raw data is not duplicated on the heap. The CRL is parsed with mbedtls_x509_crl_parse_der(), so I am expecting that the CRL raw data will be copied to the heap. Thus, it needs to be at least 2 kB. Unfortunately, there seems to be no "_nocopy()" function for CRLs. 8 kB heap was enough in my tests to verify a chain of 3 test certificates with sizes of ca. 0.5 kB each. 6 kB heap wasn't enough to do this. Is there a way to calculate or at least estimate the maximum required heap for the given maximum certificate and CRL sizes, such that a call of mbedtls_x509_crt_verify() for the chain will never fail due to insufficient memory? Is the required heap size fixed for a given number of certificates, or does it depend on the content of the certificates? If it does depend on the content, is there some way to construct "worst case certificates" that result in maximum heap usage, so I could use them to measure the heap consumption? Any help on this topic is kindly appreciated! Best regards, Ralf Huber KION Supply Chain Solutions Linde Material Handling GmbH, Sitz der Gesellschaft: Aschaffenburg, Registergericht: Aschaffenburg HRB9963, Ust-IdNr. DE814809128, Gesch?ftsf?hrung: Andreas Krinninger (Vorsitzender), Dr. Karoline Jung-Senssfelder, Ulrike Just, Dr. Frank Schepp, Vorsitzende des Aufsichtsrats: Valeria Gargiulo

7 months

2
3
0 0

Migration from Mbed TLS 2.x to 3.6.x — key export

by Piotr Kurowski (Nokia)

Dear MbedTLS team, I maintain the Mbed TLS integration for our embedded products. We are still migrating from Mbed TLS 2.x to 3.6.x and need guidance on replacing the legacy SSL key export behavior. One of our legacy products utilizes handshake key material from mbedtls_ssl_conf_export_keys_cb in an accelerator. For compatibility with existing deployments, we must preserve this key export so the other side can decode. Section “SSL key export interface change” in 3.0-migration-guide.md (as referenced for the 3.6.x line) states that mbedtls_ssl_conf_export_keys_cb() and mbedtls_ssl_conf_export_keys_ext_cb() were replaced with mbedtls_ssl_set_export_keys_cb(), and that the new callback no longer exports raw keys and IV. The guide suggests that applications requiring raw traffic keys may derive them from the master secret and handshake transcript hashes from the on-wire data. I'm not sure how this can be coded. What is the recommended way to obtain or derive the raw keys and IV (or equivalent data) under the 3.6.x API? Could you point to documentation, examples of code would be very beneficial. We would also like to align with the 4.1.x in future. If there are changes in this area, we are interested in a common and supported approach to avoid repeated breaking migrations. Thank you for your time. Kind regards, Piotr

7 months, 2 weeks

1
0
0 0

Synced invitation: MBed TLS Technical Forum - US @ Mon 4 May 2026 4:30pm - 5:30pm (BST) (mbed-tls@lists.trustedfirmware.org)

by shaun.longhorn＠linaro.org

This email keeps the event up to date in your calendar. MBed TLS Technical Forum - US Monday 4 May 2026 ⋅ 4:30pm – 5:30pm United Kingdom Time Trusted Firmware is inviting you to a scheduled Zoom meeting.Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed TLS Tech Forum - USTime: Aug 28, 2023 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Aug 28, 2023 04:30 PM Sep 25, 2023 04:30 PM Oct 23, 2023 04:30 PM Nov 20, 2023 04:30 PM Dec 18, 2023 04:30 PM Jan 15, 2024 04:30 PM Feb 12, 2024 04:30 PM Mar 11, 2024 04:30 PM Apr 8, 2024 04:30 PM May 6, 2024 04:30 PM Jun 3, 2024 04:30 PM Jul 1, 2024 04:30 PM Jul 29, 2024 04:30 PM Aug 26, 2024 04:30 PM Sep 23, 2024 04:30 PM Oct 21, 2024 04:30 PM Nov 18, 2024 04:30 PM Dec 16, 2024 04:30 PM Jan 13, 2025 04:30 PM Feb 10, 2025 04:30 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJ0udu2spj0vHtbQtlCmHwhHCT7ECtJI39J4/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/99314486542?pwd=Q1ZjaFhQeDRrQWxsa3MvT1Mwditqdz09Meeting ID: 993 1448 6542Passcode: 628327---One tap mobile+13462487799,,99314486542# US (Houston)+16694449171,,99314486542# US---Dial by your location• +1 346 248 7799 US (Houston)• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 689 278 1000 US• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 993 1448 6542Find your local number: https://linaro-org.zoom.us/u/adSjuOyMhI Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

7 months, 2 weeks

1
0
0 0

Synced invitation: MBed TLS Technical Forum - US @ Mon 6 Apr 2026 4:30pm - 5:30pm (BST) (mbed-tls@lists.trustedfirmware.org)

by shaun.longhorn＠linaro.org

This email keeps the event up to date in your calendar. MBed TLS Technical Forum - US Monday 6 Apr 2026 ⋅ 4:30pm – 5:30pm United Kingdom Time Trusted Firmware is inviting you to a scheduled Zoom meeting.Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed TLS Tech Forum - USTime: Aug 28, 2023 04:30 PM London Every 4 weeks on Mon, 20 occurrence(s) Aug 28, 2023 04:30 PM Sep 25, 2023 04:30 PM Oct 23, 2023 04:30 PM Nov 20, 2023 04:30 PM Dec 18, 2023 04:30 PM Jan 15, 2024 04:30 PM Feb 12, 2024 04:30 PM Mar 11, 2024 04:30 PM Apr 8, 2024 04:30 PM May 6, 2024 04:30 PM Jun 3, 2024 04:30 PM Jul 1, 2024 04:30 PM Jul 29, 2024 04:30 PM Aug 26, 2024 04:30 PM Sep 23, 2024 04:30 PM Oct 21, 2024 04:30 PM Nov 18, 2024 04:30 PM Dec 16, 2024 04:30 PM Jan 13, 2025 04:30 PM Feb 10, 2025 04:30 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJ0udu2spj0vHtbQtlCmHwhHCT7ECtJI39J4/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/99314486542?pwd=Q1ZjaFhQeDRrQWxsa3MvT1Mwditqdz09Meeting ID: 993 1448 6542Passcode: 628327---One tap mobile+13462487799,,99314486542# US (Houston)+16694449171,,99314486542# US---Dial by your location• +1 346 248 7799 US (Houston)• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 689 278 1000 US• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• 877 853 5247 US Toll-free• 888 788 0099 US Toll-freeMeeting ID: 993 1448 6542Find your local number: https://linaro-org.zoom.us/u/adSjuOyMhI Guests psa-crypto(a)lists.trustedfirmware.org mbed-tls(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

7 months, 2 weeks

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls