[lamps] Re: New Individual Draft: Manufacturer-Signed CA Certificate Distribution for EST and EST-coaps Deployments

[Tomas Gustavsson <[e-mail]>]

Indeed, establishing trust in the operational root has always been a challenge in these types of deployments. The simplified approach that I have seen is that the bundle delivered with the first enrolled operational certificate is set as trusted. Assuming that if you are able to get a certificate that is possible to use in the operational infrastructure, it must have been from the right CA. Otherwise the device would not be able to function (in the correct operational network). I guess that works under specific threat scenarios, but maybe not under all.

I definitely prefer a separate URI, It makes optional and failure cases much simpler to untangle. Would it not be possible for the same /signedCACerts to carry bundles signed by different signers? I.e. should the query contain some "expected signer" component, so the server can answer with a detailed error message like "no bundle from that signer available", that would be different from "no bundle at all available".

Cheers,
Tomas


________________________________
From: Mittal, Narinder <Narinder.Mittal=[e-mail]>
Sent: Thursday, October 29, 2026 7:29 PM
To: [e-mail] <[e-mail]>
Cc: Hett, Chris <[e-mail]>
Subject: [lamps] Re: New Individual Draft: Manufacturer-Signed CA Certificate Distribution for EST and EST-coaps Deployments

Hi Tomas Thanks for comments Yes, the draft does overload the `cacerts` URI. The proposed behavior addresses cases where a client cannot validate the EST server. Clients that do not support this capability can continue using the existing CACerts

Hi Tomas

Thanks for comments


Yes, the draft does overload the `cacerts` URI. The proposed behavior addresses cases where a client cannot validate the EST server. Clients that do not support this capability can continue using the existing CACerts workflow, which the EST server must still honor. The server would return the newly proposed structure only when configured to do so.

The client would need a hardcoded manufacturer alias known to the manufacturer; for example, the alias could be the manufacturer’s IANA number. The client could either:

  *
Always use the hardcoded alias to request the EST CA certificates; or
  *
First attempt to establish DTLS and, if validation fails, use the alias to request the certificates.

EST server vendors would need to implement this capability to support it, while the default path could remain valid.

Alternatively, rather than overloading the existing CACerts URI, we could define a separate URI such as `/signedCACerts`. This would keep the implementations independent.

The key point is that if an EST client cannot trust the TLS session with the EST server, it needs a way to establish that trust. An alternative such as BRSKI could be used, but it is considerably more complex to deploy than this approach.

Thanks
​
Narinder Mittal
Principal Engineer, System Architecture
CISSP, CCSP, CISM
​Email: [e-mail]<mailto:[e-mail]>
landisgyr.com<https://urldefense.com/v3/__https://www.landisgyr.com__;!!BjbSd3t9V7AnTp3tuV-82YaK!29K_K6seVx_jhP5KmWHUvkm5cQHgHm8C-dpkrf-ltkowaSprCdFAVPwQyvksvypxu1LGCgNyuHg5itdeG0ORyiMdMXvtwOgFlxN_v2f9$>
​

[cid:c1131ecb-1da2-4b9f-bdd0-bf3a6a2399ff]
[cid:a0e5fe78-49a8-4a2b-aa92-41fa7569b063]<https://urldefense.com/v3/__https://x.com/landisgyr__;!!BjbSd3t9V7AnTp3tuV-82YaK!29K_K6seVx_jhP5KmWHUvkm5cQHgHm8C-dpkrf-ltkowaSprCdFAVPwQyvksvypxu1LGCgNyuHg5itdeG0ORyiMdMXvtwOgFl9DyiMkN$>  [cid:368e6512-17b9-4c93-a334-5232ceeafd2a] <https://urldefense.com/v3/__https://www.youtube.com/@LandisGyrOfficial__;!!BjbSd3t9V7AnTp3tuV-82YaK!29K_K6seVx_jhP5KmWHUvkm5cQHgHm8C-dpkrf-ltkowaSprCdFAVPwQyvksvypxu1LGCgNyuHg5itdeG0ORyiMdMXvtwOgFl8G9MZUm$>      [cid:4a4cff4e-b874-40f9-b53d-1410dc35a969] <https://urldefense.com/v3/__https://www.linkedin.com/company/landis/__;!!BjbSd3t9V7AnTp3tuV-82YaK!29K_K6seVx_jhP5KmWHUvkm5cQHgHm8C-dpkrf-ltkowaSprCdFAVPwQyvksvypxu1LGCgNyuHg5itdeG0ORyiMdMXvtwOgFlzhhd7TB$>


P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.