Hi Mate,
I had a look and I couldn’t find such a feature implemented either. I don’t think that Mbed TLS supports that at the moment.
Best regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Z.Máté via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org>
Reply to: "Z.Máté" <enleszekakalozkiraly(a)gmail.com>
Date: Monday, 2 November 2020 at 21:01
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Write private key into buffer using encrypted PEM format
Dear mbedtls list members!
Sorry if this is the second time I ask, I'm not sure the previous question is still on the list.
I'm asking if there's a way to export a private key into a buffer in an encrypted format. So that mbedtls_pk_parse_key() has to be called with a password.
In the example program key_app.c (I hope that's how it's called) I can see there are password encrypted PEM formatted keys. But how to generate one?
For clarity, this is the type of header I'm looking for.
—–BEGIN RSA PRIVATE KEY—–
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,AB8E2B5B2D989271273F6730B6F9C687
……………………………………………….
……………………………………………….
………………………………………
—–END RSA PRIVATE KEY—–
I was only able to generate something like this by, using command line openssl. But I'd like a better solution, in code, using mbedtls.
Yours
Zombor Máté
Hello,
Thank you for your interest in the PSA crypto API.
On 28/10/2020 15:20, François Beerten via mbed-tls wrote:
>
> Hi everybody,
>
> After reading the PSA Crypto API specs (as on
> https://armmbed.github.io/mbed-crypto/html/overview/functionality.html)
> and looking at the mbed TLS library, a few questions came up.
>
> Is there some repository with the sources of the PSA Crypto API specs
> where one can follow the evolution and eventually send proposals and
> patches ?
>
The PSA specification drafts are not public. You can send feedback about
the PSA Crypto application and driver interfaces on the psa-crypto
mailing list (psa-crypto(a)lists.trustedfirmware.org,
https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto). If you
prefer to send confidential feedback, you can email mbed-crypto(a)arm.com
(feedback at this address will only be discussed inside Arm). An issue
in the Mbed TLS repository will also reach PSA Crypto architects.
> A note says "Hash suspend and resume is not defined for the SHA3
> family of hash algorithms". Why are they not defined for SHA3 ?
>
The hash suspend/resume operations marshall the internal state of the
hash operation. They mimic an existing JavaCard API
(https://docs.oracle.com/javacard/3.0.5/api/javacard/security/InitializedMes…).
There is a de facto standard representation of the internal state for
common Merkle-Damgård constructions, which covers all the currently
defined hash algorithms except SHA3. If there's interest in this
functionality, we could standardize a representation for SHA3.
> How can or should one add support in PSA Crypto AP for not yet defined
> algorithms (for example a KDF) ?
>
Answer from a PSA Crypto architect: preferably by requesting an encoding
for this KDF as a PSA_ALG_xxx value (as well as new
PSA_KEY_DERIVATION_INPUT_xxx values if applicable). If you can't do
that, use an encoding in the vendor range (most significant bit set).
The world of key derivation functions is unfortunately messy: there are
many similar, but not functionally equivalent constructions (such as
hashing a secret together with a nonce, formatted in all kinds of
different ways). The set of KDF in PSA Crypto 1.0.0 was the minimum set
required for the TLS protocol. We expect 1.0.x updates to define more
KDF algorithms.
Answer from an Mbed TLS maintainer: contributing an implementation would
be appreciated (but not required).
> In multipart operations, can the user reuse the input buffers
> immediately after doing an 'update' (for example after
> psa_hash_update()) ? And can he reuse the input buffers immediately
> after some "setup" functions like psa_cipher_set_iv() or
> psa_aead_set_nonce() ?
>
Yes. PSA crypto API functions that take a buffer as a parameter never
take ownership of that buffer. Once the function returns, you can do
whatever you want with the buffer.
The PSA specification even guarantees that you can use the same buffer,
or overlapping buffers, as inputs and outputs to the same function call.
However beware that the Mbed TLS implementation does not always support
such overlap (https://github.com/ARMmbed/mbedtls/issues/3266).
> Do you plan to support (pure) ED25519 and ED448 only via
> psa_sign_message() and psa_verify_message() ? What about messages in
> multiple chunks ?
>
We plan to add a multi-part message signature interface, both for the
sake of pureEdDSA and suitable for Mbed TLS's restartable ECDSA. I
expect the design to be “what you'd expect” but I haven't yet verified
that there aren't any gotchas.
> In psa_asymmetric_encrypt(), why is the salt provided explicitely.
> Shouldn't it be generated randomly internally when needed ?
>
Some applications use a fixed or deterministic salt which they check on
decryption. Note that this parameter is what PKCS#1 calls “label”.
> With PSA Crypto API, you define a flexible API for cryptographic
> operations. Apparently, other providers could make their own
> implementation of PSA Crypto API. Will mbed TLS then be able to use
> those alternate PSA Crypto API implementations ? How would that work
> practically ?
>
The X.509 and TLS layer of Mbed TLS are currently designed to use the
mbedtls_xxx crypto API. We have already added partial support for the
psa_xxx crypto API (with MBEDTLS_USE_PSA_CRYPTO), however it is not yet
possible to fully decouple the X.509/TLS layers from the Mbed TLS crypto
implementation. (I think this is already possible for a small set of
cipher suites, but it isn't something that we've tried or currently
actively support.) Before this can happen, some Mbed TLS APIs need to
change, which will happen in 2021 with Mbed TLS 3.0. After that, we plan
to decouple the PSA crypto reference implementation (Mbed TLS's current
crypto implementation) from the X.509/TLS layer (which will remain “Mbed
TLS”). Our plans
(https://developer.trustedfirmware.org/w/mbed-tls/roadmap/) that far
into the future are still vague and may change.
Note that for the most common case of wanting a different implementation
of cryptography, which is to leverage hardware such as accelerators and
secure elements, PSA is defining a driver interface which is currently
being implemented in Mbed TLS
(https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…).
The driver interface lets you combine mechanisms supported by your
hardware with Mbed TLS's implementation for mechanisms without hardware
support.
--
Gilles Peskine
PSA Cryptography architect and Mbed TLS developer
> Thank you for your attention,
>
> François.
>
>
>
Dear mbedtls list members!
Sorry if this is the second time I ask, I'm not sure the previous question
is still on the list.
I'm asking if there's a way to export a private key into a buffer in an
encrypted format. So that mbedtls_pk_parse_key() has to be called with a
password.
In the example program key_app.c (I hope that's how it's called) I can see
there are password encrypted PEM formatted keys. But how to generate one?
For clarity, this is the type of header I'm looking for.
—–BEGIN RSA PRIVATE KEY—–
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,AB8E2B5B2D989271273F6730B6F9C687
……………………………………………….
……………………………………………….
………………………………………
—–END RSA PRIVATE KEY—–
I was only able to generate something like this by, using command line
openssl. But I'd like a better solution, in code, using mbedtls.
Yours
Zombor Máté
Hi All,
Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT.
See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/
Thanks,
Shebu
-----Original Appointment-----
From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com>
Sent: Friday, October 23, 2020 12:32 AM
To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman
Subject: Mbed TLS Virtual Workshop
When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London.
Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…
You have been invited to the following event.
Mbed TLS Virtual Workshop
When
Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix
Where
Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>)
Calendar
shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>
Who
•
Don Harbin - creator
•
shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>
•
mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>
•
psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org>
•
dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com>
more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>
Hi,
Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop.
The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss
* The future direction of the project and
* Ways to improve community collaboration
Here is the agenda for the workshop.
Topic Time (in GMT)
Welcome 2.00 - 2.10pm
Constant-time code 2.10 – 2.30pm
Processes - how does work get scheduled? 2.30 – 2.50pm
PSA Crypto APIs 2.50 – 3.20pm
PSA Crypto for Silicon Labs Wireless
MCUs - Why, What, Where and When 3.20 – 3.50pm
Break
Roadmap, TLS1.3 Update 4.10 – 4.30pm
Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm
How do I contribute my first review
and be an effective Mbed TLS reviewer 5.00 – 5.30pm
Regards,
Don Harbin
Trusted Firmware Community Manager
==============Zoom details below:====================
Trusted Firmware is inviting you to a scheduled Zoom meeting.
Topic: Mbed TLS Virtual Workshop
Time: Nov 3, 2020 02:00 PM Greenwich Mean Time
Join Zoom Meeting
https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…>
Meeting ID: 953 1520 0315
Passcode: 143755
One tap mobile
+16699009128,,95315200315# US (San Jose)
+12532158782,,95315200315# US (Tacoma)
Dial by your location
+1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
888 788 0099 US Toll-free
877 853 5247 US Toll-free
Meeting ID: 953 1520 0315
Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…>
Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>
Invitation from Google Calendar<https://www.google.com/calendar/>
You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event.
To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.
Dear mbedtls list members!
Is there a way to write a private key into a buffer, in PEM format, by
using a password for encryption? Mbedtls is able to parse encrypted PEM
files so can I write one? I couldn't really find any info regarding it,
only an older, unfinished github issue ...
Yours
Zombor Máté
Hello François,
The following is my understanding, I am not a maintainer but a user of
mbedtls. My response below only addresses a few of your questions.
PSA appears to be bound to what mbedtls currently supports, this does not
include Ed25519 or Ed448 at this time. A pull request is currently open for
this feature development https://github.com/ARMmbed/mbedtls/pull/3245
Further development may be necessary to include those in PSA.
The only implementation of PSA that I know of is one that wraps around
mbedtls.
Best,
Levi
On Wed, Oct 28, 2020 at 9:20 AM François Beerten via mbed-tls <
mbed-tls(a)lists.trustedfirmware.org> wrote:
> Hi everybody,
>
> After reading the PSA Crypto API specs (as on
> https://armmbed.github.io/mbed-crypto/html/overview/functionality.html)
> and looking at the mbed TLS library, a few questions came up.
>
> Is there some repository with the sources of the PSA Crypto API specs
> where one can follow the evolution and eventually send proposals and
> patches ?
>
> A note says "Hash suspend and resume is not defined for the SHA3 family of
> hash algorithms". Why are they not defined for SHA3 ?
>
> How can or should one add support in PSA Crypto AP for not yet defined
> algorithms (for example a KDF) ?
>
> In multipart operations, can the user reuse the input buffers immediately
> after doing an 'update' (for example after psa_hash_update()) ? And can
> he reuse the input buffers immediately after some "setup" functions like
> psa_cipher_set_iv() or psa_aead_set_nonce() ?
>
> Do you plan to support (pure) ED25519 and ED448 only via
> psa_sign_message() and psa_verify_message() ? What about messages in
> multiple chunks ?
>
> In psa_asymmetric_encrypt(), why is the salt provided explicitely.
> Shouldn't it be generated randomly internally when needed ?
>
> With PSA Crypto API, you define a flexible API for cryptographic
> operations. Apparently, other providers could make their own implementation
> of PSA Crypto API. Will mbed TLS then be able to use those alternate PSA
> Crypto API implementations ? How would that work practically ?
>
> Thank you for your attention,
>
> François.
>
>
> --
> mbed-tls mailing list
> mbed-tls(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
>
I make a CA certificate for JITR using BouncyCastle lib in the android app as the below example
And a device certificate is generated by this certificate in mbed_tls. At this time, JITR is not working.
Namely, a device certificate is not registered in AWS.
But In the case of making a ca certificate using OPENSSL, JITR works normally.
Below is CA certificate based BouncyCastle lib.
-----BEGIN CERTIFICATE-----
MIIB8jCCAZegAwIBAgIVAK0ct2HFXVdS/k2NblxYGoxyuabfMAoGCCqGSM49BAMC
MDIxCzAJBgNVBAYTAktSMRAwDgYDVQQKDAdUcnVzdEZpMREwDwYDVQQDDAhtZWdh
em9uZTAeFw0yMDEwMjcwMDAwMDBaFw0zNTAxMDEwMDAwMDBaMDIxCzAJBgNVBAYT
AktSMRAwDgYDVQQKDAdUcnVzdEZpMREwDwYDVQQDDAhtZWdhem9uZTBZMBMGByqG
SM49AgEGCCqGSM49AwEHA0IABEknYdqI3CdVlmMkTmqKS63HnHc5PbyBff1RokGG
6NE6z31ilA8Yt2fGFHIln1kQtx//6stBA1bIqiqsSo8wad6jgYkwgYYwHQYDVR0O
BBYEFBHaQtHvagaDPkpWxQurErTekm2cMB8GA1UdIwQYMBaAFBHaQtHvagaDPkpW
xQurErTekm2cMA8GA1UdEwEB/wQFMAMBAf8wEQYJYIZIAYb4QgEBBAQDAgAHMAsG
A1UdDwQEAwIBBjATBgNVHSUEDDAKBggrBgEFBQcDAzAKBggqhkjOPQQDAgNJADBG
AiEA9HSXn3FpGUYLagsI3qaHz3VicMSuADUz/QBYEKN9STkCIQC+8BX/TPADpPOy
ClmBIkjxdDt0Fh7HTDn9UwBUxYA3/g==
-----END CERTIFICATE-----
-----BEGIN EC PRIVATE KEY-----
MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgU9pUZUfplZyhC+mH
Pt8pthLItdpbJ+Qy47r7gJKTNvCgCgYIKoZIzj0DAQehRANCAARJJ2HaiNwnVZZj
JE5qikutx5x3OT28gX39UaJBhujROs99YpQPGLdnxhRyJZ9ZELcf/+rLQQNWyKoq
rEqPMGne
-----END EC PRIVATE KEY-----
BRs.
Hyunung Park
Hi everybody,
After reading the PSA Crypto API specs (as on
https://armmbed.github.io/mbed-crypto/html/overview/functionality.html)
and looking at the mbed TLS library, a few questions came up.
Is there some repository with the sources of the PSA Crypto API specs
where one can follow the evolution and eventually send proposals and
patches ?
A note says "Hash suspend and resume is not defined for the SHA3 family
of hash algorithms". Why are they not defined for SHA3 ?
How can or should one add support in PSA Crypto AP for not yet defined
algorithms (for example a KDF) ?
In multipart operations, can the user reuse the input buffers
immediately after doing an 'update' (for example after
psa_hash_update()) ? And can he reuse the input buffers immediately
after some "setup" functions like psa_cipher_set_iv() or
psa_aead_set_nonce() ?
Do you plan to support (pure) ED25519 and ED448 only via
psa_sign_message() and psa_verify_message() ? What about messages in
multiple chunks ?
In psa_asymmetric_encrypt(), why is the salt provided explicitely.
Shouldn't it be generated randomly internally when needed ?
With PSA Crypto API, you define a flexible API for cryptographic
operations. Apparently, other providers could make their own
implementation of PSA Crypto API. Will mbed TLS then be able to use
those alternate PSA Crypto API implementations ? How would that work
practically ?
Thank you for your attention,
François.
Hi Frank,
The issue exists because you are downloading a tag and not the release. The 2.16.8 release is available here:
https://github.com/ARMmbed/mbedtls/archive/v2.16.8.tar.gz
Best regards,
Janos
On 28/10/2020, 12:15, "mbed-tls on behalf of Frank Bergmann via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote:
Hi Gilles,
I noticed that the "double name" does still exist in some archive files:
$ wget -q -O - https://github.com/ARMmbed/mbedtls/archive/mbedtls-2.16.8.tar.gz|tar tzf -|head
mbedtls-mbedtls-2.16.8/
mbedtls-mbedtls-2.16.8/.github/
mbedtls-mbedtls-2.16.8/.github/issue_template.md
mbedtls-mbedtls-2.16.8/.github/pull_request_template.md
mbedtls-mbedtls-2.16.8/.gitignore
mbedtls-mbedtls-2.16.8/.globalrc
mbedtls-mbedtls-2.16.8/.pylintrc
mbedtls-mbedtls-2.16.8/.travis.yml
mbedtls-mbedtls-2.16.8/CMakeLists.txt
mbedtls-mbedtls-2.16.8/CONTRIBUTING.md
cheers,
Frank
On Tue, Aug 04, 2020 at 09:18:56PM +0000, Gilles Peskine via mbed-tls wrote:
[...]
> The naming with mbedtls-mbedtls- must be a bug in our release script.
[...]
--
Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753
SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606
http://tdyn.de/freel -- Redirect to profile at freelancermap
http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP
--
mbed-tls mailing list
mbed-tls(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi Gilles,
I noticed that the "double name" does still exist in some archive files:
$ wget -q -O - https://github.com/ARMmbed/mbedtls/archive/mbedtls-2.16.8.tar.gz|tar tzf -|head
mbedtls-mbedtls-2.16.8/
mbedtls-mbedtls-2.16.8/.github/
mbedtls-mbedtls-2.16.8/.github/issue_template.md
mbedtls-mbedtls-2.16.8/.github/pull_request_template.md
mbedtls-mbedtls-2.16.8/.gitignore
mbedtls-mbedtls-2.16.8/.globalrc
mbedtls-mbedtls-2.16.8/.pylintrc
mbedtls-mbedtls-2.16.8/.travis.yml
mbedtls-mbedtls-2.16.8/CMakeLists.txt
mbedtls-mbedtls-2.16.8/CONTRIBUTING.md
cheers,
Frank
On Tue, Aug 04, 2020 at 09:18:56PM +0000, Gilles Peskine via mbed-tls wrote:
[...]
> The naming with mbedtls-mbedtls- must be a bug in our release script.
[...]
--
Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753
SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606
http://tdyn.de/freel -- Redirect to profile at freelancermap
http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP
Hi Sawyer,
Thank you for your interest in Mbed TLS. Currently the status of these CVE’s is:
- CVE-2020-16150 has been fixed in the latest Mbed TLS release
- CVE-2018-1000520 is not a security issue, it had been studied and rejected
- CVE-2016-3739 is a vulnerability in an application using Mbed TLS but not in Mbed TLS itself, also it too had been fixed.
Does this answer your question?
(Also, I would like to make a minor clarification: we are not Arm Support. As far as I know Arm does not offer official support for Mbed TLS. Arm only contributes engineers to the Mbed TLS project, and at the moment these engineers are the maintainers of Mbed TLS. We are on this mailing list and try to answer questions, but we are not doing that as official support provided by Arm, but as members of the community. Mbed TLS is supported by the community and this mailing list is indeed the right place to get that support. I apologise for the nitpick, I just wanted to make sure that we are not giving the wrong impressions.)
Best regards,
Janos
(Mbed TLS developer)
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Sawyer Liu via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Reply to: Sawyer Liu <sawyer.liu(a)nxp.com>
Date: Wednesday, 28 October 2020 at 01:59
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] About mbedtls CVE
Hello ARM Support,
About below CVEs, any update? Thanks.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16150<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre…>
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000520https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3739
Best Regards
Sawyer Liu
Microcontrollers, NXP Semiconductors
From: 박현웅 <hupark(a)ictk.com>
Sent: Wednesday, October 28, 2020 6:21 PM
To: 'mbed-tls(a)lists.trustedfirmware.org.' <mbed-tls(a)lists.trustedfirmware.org.>
Subject: JITR in mbedtls
Hi
I make a certificate using BouncyCastle lib in android app as the below.
JITR is not working.
Namely a device certificate is not registered in aws iot.
In case of making ca certificate using openssl, JITR works normally.
Could you please help me?
-----BEGIN CERTIFICATE-----
MIIB8jCCAZegAwIBAgIVAK0ct2HFXVdS/k2NblxYGoxyuabfMAoGCCqGSM49BAMC
MDIxCzAJBgNVBAYTAktSMRAwDgYDVQQKDAdUcnVzdEZpMREwDwYDVQQDDAhtZWdh
em9uZTAeFw0yMDEwMjcwMDAwMDBaFw0zNTAxMDEwMDAwMDBaMDIxCzAJBgNVBAYT
AktSMRAwDgYDVQQKDAdUcnVzdEZpMREwDwYDVQQDDAhtZWdhem9uZTBZMBMGByqG
SM49AgEGCCqGSM49AwEHA0IABEknYdqI3CdVlmMkTmqKS63HnHc5PbyBff1RokGG
6NE6z31ilA8Yt2fGFHIln1kQtx//6stBA1bIqiqsSo8wad6jgYkwgYYwHQYDVR0O
BBYEFBHaQtHvagaDPkpWxQurErTekm2cMB8GA1UdIwQYMBaAFBHaQtHvagaDPkpW
xQurErTekm2cMA8GA1UdEwEB/wQFMAMBAf8wEQYJYIZIAYb4QgEBBAQDAgAHMAsG
A1UdDwQEAwIBBjATBgNVHSUEDDAKBggrBgEFBQcDAzAKBggqhkjOPQQDAgNJADBG
AiEA9HSXn3FpGUYLagsI3qaHz3VicMSuADUz/QBYEKN9STkCIQC+8BX/TPADpPOy
ClmBIkjxdDt0Fh7HTDn9UwBUxYA3/g==
-----END CERTIFICATE-----
-----BEGIN EC PRIVATE KEY-----
MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgU9pUZUfplZyhC+mH
Pt8pthLItdpbJ+Qy47r7gJKTNvCgCgYIKoZIzj0DAQehRANCAARJJ2HaiNwnVZZj
JE5qikutx5x3OT28gX39UaJBhujROs99YpQPGLdnxhRyJZ9ZELcf/+rLQQNWyKoq
rEqPMGne
-----END EC PRIVATE KEY-----
BRs.
Hyunung Park
Hi Fabian,
Unfortunately https://tls.mbed.org/how-to-get is out of date. As
indicated on https://tls.mbed.org/download, newer releases (since 2.17)
are distributed under Apache license only. Only the long-time support
branches (2.7.x and 2.16.x) still have GPL releases.
--
Gilles Peskine
Mbed TLS developer
On 20/10/2020 14:19, Fabian Keil via mbed-tls wrote:
> Hi,
>
> tls.mbed.org currently sends mixed signals regarding
> the license of future MbedTLS releases.
>
> Quoting https://tls.mbed.org/download:
> | In packaged form, mbed TLS 2.1.0 to mbed TLS 2.16 are
> | available in both an Apache 2.0 licensed version (our
> | primary open source license) and in a GPL 2.0 licensed version.
> |
> | Newer versions will be available under the Apache 2.0 license.
>
> Quoting https://tls.mbed.org/how-to-get:
> | All the current versions of the mbed TLS library are distributed
> | under the Apache 2.0 license and available from our Download area.
> | In addition there are packaged versions of the mbed TLS library
> | that are distributed with the GNU Public License Version 2.0 (GPL v2.0).
> |
> | The Apache-licensed and GPL-licensed versions of mbed TLS are
> | identical in source code (with the exception of the license
> | headers at the top of files).
> |
> | We plan to keep both licensed versions around.
>
> Can anyone estimate when "newer releases" will no longer
> be dual licensed?
>
> We recently added MbedTLS support for Privoxy and a
> MbedTLS license switch from dual license to Apache 2.0
> complicates the license terms.
>
> Thanks
> Fabian
>
Hi Máté,
On 26/10/2020 12:04, Z.Máté via mbed-tls wrote:
> Dear mbedtls mailing list members!
>
> I hope you recieve my message now, previously I had problems posting
> to this list. :(
>
> My first question is actually about the PEM format. As far as I'm
> aware the PEM format either contains the Private key (signalled by the
> ---- BEGIN PRIVATE KEY ---- header) or a public key (---- BEGIN PUBLIC
> KEY -----). In my application I have to work on an app that stores key
> pairs in a special, secure storage solution (Secure Storage of OPTEE
> if you've heard about it). I decided to export the keys in PEM format,
> so that reading and handling them is equal to moving a large string
> buffer around. Using the PEM format, is there a way to store both
> private and public keys in the same "file"? Does mbedtls allow for
> such a solution (does such a solution even exist?).
There are actually several PEM formats. Some private key formats
actually store both the private key and the public key, while others
only store the private key. However, it is always possible to calculate
the public key from the private key. So if you want to have the whole
key pair, just write the private key in any format.
If you have a private key file, you can extract the public key with the
Mbed TLS sample program key_app_writer (untested command line, typed
directly into my mail client):
programs/pkey/key_app_writer mode=private filename=my_private_key.pem
output_mode=public output_file=my_public_key.pem
or with OpenSSL:
openssl pkey -in my_private_key.pem -pubout -out my_public_key.pem
>
> If not, is there a simple way to get the public key from a private key
> object? Does the mbedtls_pk_context, (that parsed up with a private
> key) contain the information needed to export the public key into a
> PEM buffer? As far as I know mbedtls allows for exporting the private
> key and the public key with the functions mbedtls_write_key_pem and
> ...write_pubkey_pem (or something along those lines) does that mean I
> can only export one at a time and there's no way to save the
> information for both into one PEM buffer?
>
> If there's a way to save both private and public keys into one PEM
> file, do I have to parse the private key and public key into separate
> objects then? With parse_key and parse_pubkey? This isn't really a
> problem just clarifying.
Once you have an mbedtls_pk_context, if you want to export both keys to
a file, use mbedtls_write_key_pem(). If you want to have a separate file
that only contains the public key, call mbedtls_write_pubkey_pem() on
the same mbedtls_pk_context.
>
> If you can point me to an actually good description of the PEM format
> and what CAN be stored inside of it, I'd be very grateful! :)
PEM is just an encoding: base64 data between a header and footer. The
base64-encoded data can have several different formats depending on the
header. It can represent a private key (several formats depending on the
header), a public key or a certificate. A complete description is spread
across about half a dozen RFC. Fortunately, I don't think you need to
dig into those.
>
> I also have a question regarding the example SSL server program. In
> it, the server needs a private key and a certificate for obvious
> reasons. It also loads a certificate and as far as I know, the
> certificate has to be tied to a known CA for it to be valid.
>
> I would like to test the program with a self generated key pair, do I
> need to change the Certificate and CAs to a new one as well? To
> authenticate the new keypair? Does the mbedtls ssl_client1 example
> program work with self signed certs? Or do I need to take care of the
> CA validation myself (that would probably beyond the scope of the
> project I'm working on).
The sample program ssl_server does not check the client certificate. The
test program ssl_server2 can check the client certificate: pass the
command line options "auth_mode=required ca_file=my_ca.crt". If you have
a self-signed client certificate, you can pass it as the ca_file.
--
Gilles Peskine
Mbed TLS developer
>
> Thank you in advance!
>
> Yours truly,
> Máté Zombor
>
Dear mbedtls mailing list members!
I hope you recieve my message now, previously I had problems posting to
this list. :(
My first question is actually about the PEM format. As far as I'm aware the
PEM format either contains the Private key (signalled by the ---- BEGIN
PRIVATE KEY ---- header) or a public key (---- BEGIN PUBLIC KEY -----). In
my application I have to work on an app that stores key pairs in a special,
secure storage solution (Secure Storage of OPTEE if you've heard about it).
I decided to export the keys in PEM format, so that reading and handling
them is equal to moving a large string buffer around. Using the PEM format,
is there a way to store both private and public keys in the same "file"?
Does mbedtls allow for such a solution (does such a solution even exist?).
If not, is there a simple way to get the public key from a private key
object? Does the mbedtls_pk_context, (that parsed up with a private key)
contain the information needed to export the public key into a PEM buffer?
As far as I know mbedtls allows for exporting the private key and the
public key with the functions mbedtls_write_key_pem and ...write_pubkey_pem
(or something along those lines) does that mean I can only export one at a
time and there's no way to save the information for both into one PEM
buffer?
If there's a way to save both private and public keys into one PEM file, do
I have to parse the private key and public key into separate objects then?
With parse_key and parse_pubkey? This isn't really a problem just
clarifying.
If you can point me to an actually good description of the PEM format and
what CAN be stored inside of it, I'd be very grateful! :)
I also have a question regarding the example SSL server program. In it, the
server needs a private key and a certificate for obvious reasons. It also
loads a certificate and as far as I know, the certificate has to be tied to
a known CA for it to be valid.
I would like to test the program with a self generated key pair, do I need
to change the Certificate and CAs to a new one as well? To authenticate the
new keypair? Does the mbedtls ssl_client1 example program work with self
signed certs? Or do I need to take care of the CA validation myself (that
would probably beyond the scope of the project I'm working on).
Thank you in advance!
Yours truly,
Máté Zombor
You have been invited to the following event.
Title: Mbed TLS Virtual Workshop
Hi,Trustedfirmware.org community project would like to invite you to the
Mbed TLS Virtual Workshop. The purpose of the workshop is to bring
together the Mbed TLS community including maintainers, contributors and
users to discussThe future direction of the project andWays to improve
community collaborationHere is the agenda for the workshop.Topic
Time (in GMT)Welcome
2.00 - 2.10pmConstant-time code
2.10
– 2.30pmProcesses - how does work get scheduled? 2.30 –
2.50pmPSA Crypto APIs
2.50 –
3.20pmPSA Crypto for Silicon Labs Wireless MCUs
- Why, What, Where and When 3.20 –
3.50pmBreak
Roadmap,
TLS1.3 Update
4.10
– 4.30pmMbed TLS 3.0 Plans, Scope
4.30 – 5.00pmHow do I contribute my first review
and be an effective Mbed TLS reviewer
5.00 – 5.30pmRegards,Don Harbin Trusted Firmware Community
Manager==============Zoom details below:====================Trusted
Firmware is inviting you to a scheduled Zoom meeting.Topic: Mbed TLS
Virtual WorkshopTime: Nov 3, 2020 02:00 PM Greenwich Mean TimeJoin Zoom
Meetinghttps://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT09Meeting
ID: 953 1520 0315Passcode: 143755One tap mobile+16699009128,,95315200315#
US (San Jose)+12532158782,,95315200315# US (Tacoma)Dial by your
location +1 669 900 9128 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston) +1 646 558 8656 US
(New York) +1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
888 788 0099 US Toll-free 877 853 5247 US
Toll-freeMeeting ID: 953 1520 0315Find your local number:
https://linaro-org.zoom.us/u/apL3hgti4
When: Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix
Where: Zoom:
https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…
Calendar: mbed-tls(a)lists.trustedfirmware.org
Who:
* Don Harbin - creator
* shebu.varghesekuriakose(a)arm.com
* mbed-tls(a)lists.trustedfirmware.org
* psa-crypto(a)lists.trustedfirmware.org
* dave.rodgman(a)arm.com
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this
event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Hi,
tls.mbed.org currently sends mixed signals regarding
the license of future MbedTLS releases.
Quoting https://tls.mbed.org/download:
| In packaged form, mbed TLS 2.1.0 to mbed TLS 2.16 are
| available in both an Apache 2.0 licensed version (our
| primary open source license) and in a GPL 2.0 licensed version.
|
| Newer versions will be available under the Apache 2.0 license.
Quoting https://tls.mbed.org/how-to-get:
| All the current versions of the mbed TLS library are distributed
| under the Apache 2.0 license and available from our Download area.
| In addition there are packaged versions of the mbed TLS library
| that are distributed with the GNU Public License Version 2.0 (GPL v2.0).
|
| The Apache-licensed and GPL-licensed versions of mbed TLS are
| identical in source code (with the exception of the license
| headers at the top of files).
|
| We plan to keep both licensed versions around.
Can anyone estimate when "newer releases" will no longer
be dual licensed?
We recently added MbedTLS support for Privoxy and a
MbedTLS license switch from dual license to Apache 2.0
complicates the license terms.
Thanks
Fabian
Hi Dave,
Thanks for your reply.
The particular reasons for bringing up 2.7 and 2.16 first is that my
employer is currently using 2.7 and would prefer using a small increment.
Having said that, if adding features to LTS is not advisable (especially
given that 2.7 has less than 6 months of projected life), I think I can
present the arguments against using the 2.7.
Additional consideration is the timing. My employer needs fragmentation
support as soon as possible, with the intent of running it on a desktop
environment. Historically, when the engineers are able to provide my
employer with what is needed now, they are allowed more time for
incremental improvements.
The third consideration involves the MPS project by Hanno Becker. I've been
collaborating with Hanno, and with Hannes Tschofenig and Thomas Fosetti on
the project of adding QUIC support to mbedTLS. This goal depends on TLS 1.3
support (Hannes has written a prototype, which I was able to add QUIC in an
internal version), and on MPS. I would like to avoid putting a duplicate
effort into non-MPS fragmentation support.
Unfortunately, if I want to meet the timing requirements of my employer, I
will not be able to use MPS, since it needs more maturing.
Because of the above considerations, I would like to suggest the following
plan of actions:
As the first step, I would like to add the MVP (minimal viable product)
fragmentation to the development version. The MVP takes the following
assumptions:
1. The RAM footprint is not a concern for the MVP (my employer is going
to run it in the desktop environment).
2. Unification of the fragmentation between TLS and DTLS is not a
concern for the MVP
3. LTS is not a concern for the MVP (potentially not at all)
Because of the above simplifying assumptions, I believe that the change can
be small and focused. I think I can have code ready for review in a couple
of weeks.
As the second step, I would like to put my effort into helping Hanno Becker
with his MPS system. Once sufficiently mature, the MPS will supersede the
MVP fragmentation, and will open the doors for adding support for QUIC. The
simplifying assumptions 1. (RAM) and 2. (TLS <=> DTLS) will be addressed by
MPS. Addressing the last assumption may not be required.
What are your thoughts?
On Wed, Oct 14, 2020 at 10:28 AM Dave Rodgman <dave.rodgman(a)arm.com> wrote:
> Hi Omer,
>
>
>
> Thanks for offering to help us with this feature.
>
>
>
> Normally, we wouldn’t add new features directly to an older branch, for a
> few reasons. 2.7 is quite old and is in fact only guaranteed to be
> supported until Feb 21, so it’s not the ideal place to spend effort on new
> features. Introducing new features here would also create the situation
> where 2.7 has features not in development, and vice-versa, creating an
> upgrade dilemma for users (unless we were to port the feature to all
> supported branches). And adding significant new features to LTS branches
> can always introduce some risk of destabilising it.
>
>
>
> So for these reasons, we would normally recommend targeting the
> development branch for new features (with backports only where there is a
> strong reason to do so), and then picking up the next stable release that
> contains the new feature.
>
>
>
> Is there a particular reason you’re focusing on 2.7, rather than
> development, or would it be viable for you to add this to development and
> pick up the next release?
>
>
>
> Thanks
>
>
>
> Dave
>
>
>
> *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf
> of Omer Shapira via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
> *Reply to: *Omer Shapira <omer.shapira(a)gmail.com>
> *Date: *Monday, 12 October 2020 at 20:04
> *To: *"mbed-tls(a)lists.trustedfirmware.org" <
> mbed-tls(a)lists.trustedfirmware.org>
> *Subject: *[mbed-tls] Working on TLS handshake record fragmentation
> (#1840)
>
>
>
> Hello,
>
> My employer (Facebook) is willing to give me some time to TLS handshake
> fragmentation support to MbedTLS 2.7 [0] . This would be my first
> contribution to MbedTLS, and I have several novice questions:
>
> 1. What is the best way to add the feature to MbedTLS 2.7?
> 2. Trade-off between the consistency of the fragmentation code across the
> branches, vs. the consistency of the branches.
>
>
> Question 1: Best way to add the feature to MbedTLS 2.7
>
> One constraint that I am facing is the code must be added to the upstream
> branch that is as close as possible to the 2.7.xx. My understanding of the
> Contribution Guidelines[1] is that while the LTS branches are mostly meant
> for the bug fixes, backporting of the new features is welcomed as long as
> the API/ABI compatibility is maintained and the disruption to the users is
> minimized.
>
> If adding support to the LTS branches is not advisable, are there any
> other possibilities of contributing the code to an upstream branch that is
> very close to the 2.7.xx?
>
> Question 2: Trade-off between the consistency of the fragmentation code
> across the branches, vs. the consistency of the branches.
>
> Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a
> trade-off between the consistency of the fragmentation code across the
> branches, vs. the consistency of the branches. The `development` branch
> supports variable-length buffers[2] . Variable messages sizes would make
> the fragmentation easier in the development branch. In addition, there is
> the MPS effort by Hanno Becker which would make the fragmentation support
> even easier in the development branch. None of that is present in the 2.7
> or the 2.16 branches.
>
> What is the preferable trade-off in such a situation:
> a. Minimizing the change to the "host" version (2.7 or 2.16), on the
> expense the implementation of the feature differ between 2.7 and
> `development`, or
> b. Minimizing the differences in the implementation of the feature, on
> the expense of more intrusive changes to the earlier versions?
>
>
> [0] https://github.com/ARMmbed/mbedtls/issues/1840
> [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md
> [2]
> https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.…
>
> --
>
> Sincerely Yours,
> Omer Shapira
>
--
Sincerely Yours,
Omer Shapira
--
Sincerely Yours,
Omer Shapira
Hi Omer,
Thanks for offering to help us with this feature.
Normally, we wouldn’t add new features directly to an older branch, for a few reasons. 2.7 is quite old and is in fact only guaranteed to be supported until Feb 21, so it’s not the ideal place to spend effort on new features. Introducing new features here would also create the situation where 2.7 has features not in development, and vice-versa, creating an upgrade dilemma for users (unless we were to port the feature to all supported branches). And adding significant new features to LTS branches can always introduce some risk of destabilising it.
So for these reasons, we would normally recommend targeting the development branch for new features (with backports only where there is a strong reason to do so), and then picking up the next stable release that contains the new feature.
Is there a particular reason you’re focusing on 2.7, rather than development, or would it be viable for you to add this to development and pick up the next release?
Thanks
Dave
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Omer Shapira via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Reply to: Omer Shapira <omer.shapira(a)gmail.com>
Date: Monday, 12 October 2020 at 20:04
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Working on TLS handshake record fragmentation (#1840)
Hello,
My employer (Facebook) is willing to give me some time to TLS handshake fragmentation support to MbedTLS 2.7 [0] . This would be my first contribution to MbedTLS, and I have several novice questions:
1. What is the best way to add the feature to MbedTLS 2.7?
2. Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches.
Question 1: Best way to add the feature to MbedTLS 2.7
One constraint that I am facing is the code must be added to the upstream branch that is as close as possible to the 2.7.xx. My understanding of the Contribution Guidelines[1] is that while the LTS branches are mostly meant for the bug fixes, backporting of the new features is welcomed as long as the API/ABI compatibility is maintained and the disruption to the users is minimized.
If adding support to the LTS branches is not advisable, are there any other possibilities of contributing the code to an upstream branch that is very close to the 2.7.xx?
Question 2: Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches.
Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. The `development` branch supports variable-length buffers[2] . Variable messages sizes would make the fragmentation easier in the development branch. In addition, there is the MPS effort by Hanno Becker which would make the fragmentation support even easier in the development branch. None of that is present in the 2.7 or the 2.16 branches.
What is the preferable trade-off in such a situation:
a. Minimizing the change to the "host" version (2.7 or 2.16), on the expense the implementation of the feature differ between 2.7 and `development`, or
b. Minimizing the differences in the implementation of the feature, on the expense of more intrusive changes to the earlier versions?
[0] https://github.com/ARMmbed/mbedtls/issues/1840
[1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md
[2] https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.…
--
Sincerely Yours,
Omer Shapira
While waiting for opinions regarding the question of adding features to the
LTS versions, I have written a draft design doc.
I discussed the "design review process" with Hanno Becker, and we decided
to try and use GitHub for the design review.
I have created PR #3783 [0], which
includes `docs/proposed/hs_fragmentation.md` [1].
I will appreciate your comments, and will update the design doc following
the feedback.
Once there is clarity on the approach, I will proceed with the
implementation PRs.
[0] https://github.com/ARMmbed/mbedtls/pull/3783
[1]
https://github.com/ARMmbed/mbedtls/pull/3783/commits/8be34f22237ee3cd3c1db2…
On Mon, Oct 12, 2020 at 12:04 PM Omer Shapira via mbed-tls <
mbed-tls(a)lists.trustedfirmware.org> wrote:
> Hello,
>
> My employer (Facebook) is willing to give me some time to TLS handshake
> fragmentation support to MbedTLS 2.7 [0] . This would be my first
> contribution to MbedTLS, and I have several novice questions:
>
> 1. What is the best way to add the feature to MbedTLS 2.7?
> 2. Trade-off between the consistency of the fragmentation code across the
> branches, vs. the consistency of the branches.
>
> Question 1: Best way to add the feature to MbedTLS 2.7
>
> One constraint that I am facing is the code must be added to the upstream
> branch that is as close as possible to the 2.7.xx. My understanding of the
> Contribution Guidelines[1] is that while the LTS branches are mostly meant
> for the bug fixes, backporting of the new features is welcomed as long as
> the API/ABI compatibility is maintained and the disruption to the users is
> minimized.
>
> If adding support to the LTS branches is not advisable, are there any
> other possibilities of contributing the code to an upstream branch that is
> very close to the 2.7.xx?
>
> Question 2: Trade-off between the consistency of the fragmentation code
> across the branches, vs. the consistency of the branches.
>
> Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a
> trade-off between the consistency of the fragmentation code across the
> branches, vs. the consistency of the branches. The `development` branch
> supports variable-length buffers[2] . Variable messages sizes would make
> the fragmentation easier in the development branch. In addition, there is
> the MPS effort by Hanno Becker which would make the fragmentation support
> even easier in the development branch. None of that is present in the 2.7
> or the 2.16 branches.
>
> What is the preferable trade-off in such a situation:
> a. Minimizing the change to the "host" version (2.7 or 2.16), on the
> expense the implementation of the feature differ between 2.7 and
> `development`, or
> b. Minimizing the differences in the implementation of the feature, on
> the expense of more intrusive changes to the earlier versions?
>
>
> [0] https://github.com/ARMmbed/mbedtls/issues/1840
> [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md
> [2]
> https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.…
>
> --
> Sincerely Yours,
> Omer Shapira
> --
> mbed-tls mailing list
> mbed-tls(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
>
--
Sincerely Yours,
Omer Shapira
Hello,
My employer (Facebook) is willing to give me some time to TLS handshake
fragmentation support to MbedTLS 2.7 [0] . This would be my first
contribution to MbedTLS, and I have several novice questions:
1. What is the best way to add the feature to MbedTLS 2.7?
2. Trade-off between the consistency of the fragmentation code across the
branches, vs. the consistency of the branches.
Question 1: Best way to add the feature to MbedTLS 2.7
One constraint that I am facing is the code must be added to the upstream
branch that is as close as possible to the 2.7.xx. My understanding of the
Contribution Guidelines[1] is that while the LTS branches are mostly meant
for the bug fixes, backporting of the new features is welcomed as long as
the API/ABI compatibility is maintained and the disruption to the users is
minimized.
If adding support to the LTS branches is not advisable, are there any other
possibilities of contributing the code to an upstream branch that is very
close to the 2.7.xx?
Question 2: Trade-off between the consistency of the fragmentation code
across the branches, vs. the consistency of the branches.
Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a
trade-off between the consistency of the fragmentation code across the
branches, vs. the consistency of the branches. The `development` branch
supports variable-length buffers[2] . Variable messages sizes would make
the fragmentation easier in the development branch. In addition, there is
the MPS effort by Hanno Becker which would make the fragmentation support
even easier in the development branch. None of that is present in the 2.7
or the 2.16 branches.
What is the preferable trade-off in such a situation:
a. Minimizing the change to the "host" version (2.7 or 2.16), on the
expense the implementation of the feature differ between 2.7 and
`development`, or
b. Minimizing the differences in the implementation of the feature, on the
expense of more intrusive changes to the earlier versions?
[0] https://github.com/ARMmbed/mbedtls/issues/1840
[1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md
[2]
https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.…
--
Sincerely Yours,
Omer Shapira
Hi All,
Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT.
The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss
* The future direction of the project and
* Ways to improve community collaboration
The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days.
Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community
* Constant-time code
* How to be an effective Mbed TLS reviewer
* Processes - how does work get scheduled?
* Roadmap, Mbed TLS3.0
* PSA Crypto APIs
* How Do I contribute my first review.
Thanks,
Shebu
(TrustedFirmware.org Co-Chair,
Mbed TLS Technology Manager)
* https://lists.trustedfirmware.org/mailman/listinfo/mbed-tlshttps://lists.trustedfirmware.org/mailman/listinfo/psa-crypto
Hi Innocenti,
The official list of defects is available on github:
https://github.com/ARMmbed/mbedtls/issues?q=is%3Aissue+is%3Aopen+label%3Abug
The revision of fixing is in the Bugfix sections of the ChangeLog file in the source. Eg. for the latest release:
https://github.com/ARMmbed/mbedtls/blob/mbedtls-2.24.0/ChangeLog
The entries here usually reference the issue number they fixed.
Is this something that you can use for your evaluation?
Regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Innocenti, Michele via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org>
Reply to: "Innocenti, Michele" <michele_innocenti(a)baxter.com>
Date: Thursday, 1 October 2020 at 14:04
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Official bug list
Hi,
We are evaluating Mbed TLS library and we need to know if it’s available an official list of defects and revision of fixing.
I’m not looking for CVEs but for bugs in the library.
Thanks!
Michele
Hi,
We are evaluating Mbed TLS library and we need to know if it's available an official list of defects and revision of fixing.
I'm not looking for CVEs but for bugs in the library.
Thanks!
Michele