Hi Taehoon Kim,

+1 for using the existing API for your platform if the provision made as mentioned by Jackson (i.e., adding the required host ROTPKs into the provisioning bundle passed to the RSE, and having TF-A fetch them via the existing API). If, however, the intention is to avoid using this API altogether, one alternative could be:

* derive/generate a subsidiary key from the ROTPK (or provision a separate subordinate root key),

* include the hash of the subsidiary public key in TF-A BL1 (as the pinned trust anchor),

* then use that subsidiary key as the RoT on the AP side and build the CoT for TF-A components from BL2 onwards based on it.

This keeps BL1 as the trust anchor while allowing the rest of the TF-A CoT to chain off the subsidiary key, without requiring host ROTPK retrieval at runtime. Thanks, Manish Badarkhe

________________________________ From: Jackson Cooper-Driver Jackson.Cooper-Driver@arm.com Sent: 05 January 2026 15:23 To: Olivier Deprez Olivier.Deprez@arm.com; Taehoon Kim gth1919@adtek.co.kr Cc: Raef Coles Raef.Coles@arm.com; Nishant Sharma Nishant.Sharma@arm.com; Rohit Mathew Rohit.Mathew@arm.com; Manish Pandey2 Manish.Pandey2@arm.com; Manish Badarkhe Manish.Badarkhe@arm.com; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: Re: Questions about Chain-of-Trust and RSE Connectivity

Hi Taehoon Kim,

There is no change to the system RoT as a result of that patch, it is still the intention that platforms can continue to make use of the RSE to provide host ROTPKs for use by TF-A. The reason this API and test was removed was because the RSE no longer provisions host ROTPKs by default in the TC platform. Therefore, the test no longer made any sense to run (it would fail to fetch any keys), and we did not think it was worth leaving an unused API in TF-A.

If required by your platform, you may add additional host ROTPKs to the provisioning bundle which is passed to the RSE. These can then be fetched by TF-A using the existing API.

Thanks,

Jackson

From: Olivier Deprez Olivier.Deprez@arm.com Date: Monday, 5 January 2026 at 14:23 To: Taehoon Kim gth1919@adtek.co.kr Cc: Raef Coles Raef.Coles@arm.com, Jackson Cooper-Driver Jackson.Cooper-Driver@arm.com, Nishant Sharma Nishant.Sharma@arm.com, Rohit Mathew Rohit.Mathew@arm.com, Manish Pandey2 Manish.Pandey2@arm.com, Manish Badarkhe Manish.Badarkhe@arm.com, tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: Re: Questions about Chain-of-Trust and RSE Connectivity

+ TF-A list

________________________________ From: Olivier Deprez Sent: 05 January 2026 15:11 To: Taehoon Kim gth1919@adtek.co.kr Cc: Raef Coles Raef.Coles@arm.com; Jackson Cooper-Driver Jackson.Cooper-Driver@arm.com; Nishant Sharma Nishant.Sharma@arm.com; Rohit Mathew Rohit.Mathew@arm.com; Manish Pandey2 Manish.Pandey2@arm.com; Manish Badarkhe Manish.Badarkhe@arm.com Subject: Questions about Chain-of-Trust and RSE Connectivity

Hi Taehoon Kim,

We seem to experience an issue with the mailing list where messages are not properly dispatched. I reproduced your initial email sent Dec 18th 2025 below and Cced relevant folks just in case.

Regards, Olivier.

____________________________________________________________

Hello, I'm firmware developer for RD-V3-R1 chipset.

I have developed our firmware based on Neoverse Reference Platform RD-INFRA-2025.07.03, but I have also kept an eye on the code to ensure we remain in step with the latest release.

While inquiring on the TF-M forum to update the TF-M code, I also developed a query regarding the TF-A section. Re: Several Questions related to RSE Provisioning - TF-M - lists.trustedfirmware.orghttps://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.org/thread/REI5EEFX3ROQU325JDD43J5YORU5NO2O/ This link includes that RSE API codes are removed in the SotA TF-A codes. I check this in the TF-A commit. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/46314

I was already aware that this API was not used outside of test code. However, I would like to know the reason why that code was removed, beyond the simple fact that it was not being used. Is it possible that Chain-of-Trust is established in whole firmware stack from RSE ROM to AP BL33 bootloader, without RSE assist? If possible, what does TF-A rely upon as the basis for trust in establishing the Root of Trust?

Our team believed that CoT was established on the premise of the RSE API, and was therefore designing to ensure the trustworthiness of the entire firmware using that code. However, we recognise that to use the latest version of the code, we must abandon that belief and design in a different manner. Before the new version of RD-INFRA is released, we intend to resolve this internally as a team.

Should you feel the scope of the question extends beyond what is typically addressed in the forum, please do not hesitate to let us know. Thank you for reading this mail.

Best Regard, Taehoon Kim