Independant Submission N. Mittal Internet-Draft C. Hett Intended status: Informational Landis+Gyr Expires: 29 March 2027 September 2026 Manufacturer-Signed CA Certificate Distribution for EST and EST-coaps Deployments draft-mittal-est-coap-ca-certs-00 Abstract This document describes a manufacturer-assisted mechanism for distributing operational certification authority (CA) certificates to devices using Enrollment over Secure Transport (EST) or EST over secure CoAP (EST-coaps). The mechanism is intended for deployments in which a device is manufactured before the operational PKI and EST server trust anchors are known. The device is provisioned during manufacturing with a manufacturer trust anchor. An operational CA certificate bundle is subsequently signed by the manufacturer, or by a manufacturer- authorized signing authority, and delivered through a manufacturer- specific EST alias. The device validates the signed bundle using its manufacturer trust anchor before installing the contained CA certificates as operational trust anchors. This mechanism is limited to CA certificate bootstrap and does not change EST enrollment semantics, proof-of-possession requirements, certification authority policy, or authenticated EST operation following bootstrap. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Manufacturer-Specific EST Alias . . . . . . . . . . . . . . . 6 5. Manufacturer-Signed CA Certificate Bundle . . . . . . . . . . 6 5.1. ManufacturerSignedCACerts Structure . . . . . . . . . . . 7 5.2. CMS Content Requirements . . . . . . . . . . . . . . . . 7 5.3. Alias Binding . . . . . . . . . . . . . . . . . . . . . . 8 6. Bootstrap Transport Layer . . . . . . . . . . . . . . . . . . 8 6.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 9 6.5. CoAP Transport . . . . . . . . . . . . . . . . . . . . . 9 7. Client Processing Rules . . . . . . . . . . . . . . . . . . . 10 8. Server Processing Rules . . . . . . . . . . . . . . . . . . . 10 9. Denial-of-Service Considerations . . . . . . . . . . . . . . 11 Mittal & Hett Expires 29 March 2027 [Page 1] Internet-Draft EST-coaps-ca-certs September 2026 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10.1. Manufacturer Signing Key Protection . . . . . . . . . . 12 10.2. Separation of Manufacturer Signing Function . . . . . . 12 10.3. No Enrollment Before Trust Bootstrap . . . . . . . . . . 12 10.4. Cleartext Transport Risks . . . . . . . . . . . . . . . 12 10.5. Replay of Old CA Certificate Responses . . . . . . . . . 13 10.6. Alias Substitution . . . . . . . . . . . . . . . . . . . 13 10.7. Operational CA Compromise or Rollover . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Operational Scenario Example . . . . . . . . . . . . 15 A.1. Obtaining CA certificates with embedded manufacturer trust . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Mittal & Hett Expires 29 March 2027 [Page 2] Internet-Draft EST-coaps-ca-certs September 2026 1. Introduction Enrollment over Secure Transport (EST), defined in [RFC7030], provides certificate enrollment and CA certificate retrieval over HTTPS. EST-coaps, defined in [RFC9148], transports EST payloads over CoAP protected by DTLS for constrained IoT environments. [RFC9148] defines EST over secure CoAP and maps EST functions such as /cacerts, /simpleenroll, /simplereenroll, and /csrattrs to shorter EST-coaps resources such as /crts, /sen, /sren, and /att. In all of these functions, EST client is expected to authenticate the EST server before accepting EST responses. In many deployments, devices are manufactured before the operational PKI hierarchy or EST server trust anchors are known. Such devices may be provisioned only with a manufacturer trust anchor at manufacturing time. Provisioning customer-specific trust anchors after manufacturing can add operational complexity, increase the likelihood of configuration errors, and complicate shipment or deployment logistics. Although [RFC7030] already recognizes bootstrap distribution of CA certificates and allows a client to provisionally continue a TLS handshake to retrieve /cacerts when initial server authentication fails, it relies on manual or out-of-band authorization of the returned CA certificate data. This document provides a cryptographic authorization mechanism by defining a bootstrap mechanism that allows the client to retrieve operational CA certificates from a manufacturer-specific EST alias. The response is signed in advance by the manufacturer or a manufacturer-authorized signer. The client validates the response using the manufacturer trust anchor already provisioned in the device. This extension is limited to CA certificate retrieval. It does not permit certificate enrollment, re-enrollment, server-side key generation, or CSR attribute retrieval until the client has installed and validated the operational trust anchor and can establish a normally authenticated EST or EST-coaps session. This document does not modify [RFC7030] or [RFC9148]. It describes a deployment mechanism that may be used to securely distribute operator CA certificates to constrained devices prior to EST enrollment. Mittal & Hett Expires 29 March 2027 [Page 3] Internet-Draft EST-coaps-ca-certs September 2026 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. The terminology from [RFC7030] and [RFC9148] applies. This document additionally defines the following terms: +=====================+=============================================+ | Term | Definition | +=====================+=============================================+ | Manufacturer Trust | A trust anchor provisioned into the EST | | Anchor | client during manufacturing and used to | | | validate manufacturer-signed bootstrap | | | material. | +---------------------+---------------------------------------------+ | Manufacturer Alias | An EST or EST-coaps alias associated | | | with a manufacturer or manufacturer | | | trust domain. | +---------------------+---------------------------------------------+ | Operational Trust | A CA certificate used by the device to | | Anchor | authenticate the operational EST server | | | and operational PKI. | +---------------------+---------------------------------------------+ | Manufacturer-Signed | A CA certificate response whose exact | | CA Certificate | content is signed by the manufacturer | | Bundle | or a manufacturer-authorized signer. | +---------------------+---------------------------------------------+ | Bootstrap CA | The limited retrieval operation defined | | Certificate | by this document, used before the | | Retrieval | client can authenticate the EST server | | | using the operational trust anchor. | +---------------------+---------------------------------------------+ | Bootstrap-Only | A TLS or DTLS session in which normal | | Session | EST server authentication has not yet | | | succeeded and only the bootstrap CA | | | certificate retrieval operation is | | | permitted. | +---------------------+---------------------------------------------+ Table 1: Definitions Mittal & Hett Expires 29 March 2027 [Page 4] Internet-Draft EST-coaps-ca-certs September 2026 3. Trust Model The trust model is based on manufacturer authorization of the CA certificate response. During manufacturing: 1. The device is provisioned with a manufacturer trust anchor. 2. The manufacturer trust anchor is stored in a protected trust store. 3. The device is configured with the manufacturer alias or with a method to derive the appropriate manufacturer alias. During deployment: 1. The deployment operator identifies the operational CA certificate set. 2. The manufacturer, or a manufacturer-authorized signing authority, creates a ManufacturerSignedCACerts object containing the bootstrap alias, validity information, and operational CA certificate bundle. The ManufacturerSignedCACerts object is signed using CMS SignedData. The EST server publishes the resulting CMS SignedData object under a manufacturer-specific EST alias. 3. The EST server does not need to perform runtime signing for bootstrap retrieval. During bootstrap: 1. The EST client retrieves the CA certificate response from the manufacturer-specific alias. 2. The EST client validates the manufacturer signature using the manufacturer trust anchor. 3. If validation succeeds, the EST client installs the CA certificate set as operational trust anchors. 4. The EST client establishes a new authenticated EST or EST-coaps session using the installed operational trust anchors. Mittal & Hett Expires 29 March 2027 [Page 5] Internet-Draft EST-coaps-ca-certs September 2026 4. Manufacturer-Specific EST Alias The EST server SHALL expose a manufacturer-specific alias for bootstrap CA certificate retrieval. For EST over HTTPS, the alias MAY use the following form: /.well-known/est/{manufacturer-alias}/cacerts For EST-coaps, the corresponding short operation SHOULD use the EST- coaps /crts function under the manufacturer alias: coaps://est.example.com/.well-known/est/{manufacturer-alias}/crts [RFC9148] defines EST-coaps resource mappings, including the shorter /crts resource for CA certificate retrieval. The manufacturer alias identifies the manufacturer trust domain under which the response signature is validated. The manufacturer alias MUST be provisioned into the device during manufacturing or derived using a manufacturer-defined mechanism. The alias alone MUST NOT be treated as authorization to install the returned CA certificates. Authorization is established only through successful validation of the CMS signature chain to a trusted Manufacturer Trust Anchor and successful completion of all validation requirements specified in this document. A deployment MAY derive the manufacturer-specific EST alias from the manufacturer's IANA Private Enterprise Number (PEN). For example: /.well-known/est/mfg/{PEN} where {PEN} is the decimal representation of the manufacturer's assigned IANA Private Enterprise Number. Profiles adopting this mechanism MAY require use of this alias construction method to ensure interoperability. This document does not mandate a single alias construction method. 5. Manufacturer-Signed CA Certificate Bundle The EST server SHALL return the manufacturer-signed response in Cryptographic Message Syntax (CMS) format as defined by RFC [RFC5652]. The SignedData object encapsulates a structured bootstrap object known as ManufacturerSignedCACerts. The manufacturer, or a manufacturer-authorized signing authority, signs this structure before it is published by the EST server. The EST server acts solely Mittal & Hett Expires 29 March 2027 [Page 6] Internet-Draft EST-coaps-ca-certs September 2026 as a distribution point for the signed object and is not required to perform runtime signing. The client validates the CMS signature using the Manufacturer Trust Anchor provisioned during manufacturing. The client MUST successfully validate the CMS signature and all associated processing rules defined in this document before installing any returned CA certificates as operational trust anchors. 5.1. ManufacturerSignedCACerts Structure The CMS SignedData object SHALL encapsulate a ManufacturerSignedCACerts structure. ManufacturerSignedCACerts ::= SEQUENCE { version INTEGER (1..MAX), alias UTF8String, sequenceNumber INTEGER (0..MAX), notBefore GeneralizedTime, notAfter GeneralizedTime, caCertificates SEQUENCE SIZE (1..MAX) OF Certificate } The fields have the following meanings: version: Identifies the version of the ManufacturerSignedCACerts structure. alias: Identifies the bootstrap alias associated with the CA certificate bundle. sequenceNumber: An increasing value used by the client to detect replay and rollback attacks. notBefore: The beginning of the validity interval for the signed bundle. notAfter: The end of the validity interval for the signed bundle. caCertificates: The operational CA certificate bundle intended for installation by the EST client. 5.2. CMS Content Requirements The CMS SignedData object SHALL include: * A signature over the complete ManufacturerSignedCACerts structure. Mittal & Hett Expires 29 March 2027 [Page 7] Internet-Draft EST-coaps-ca-certs September 2026 * The manufacturer signing certificate. * Any intermediate certificates required to build a certification path to the Manufacturer Trust Anchor. * CMS signed attributes required to validate the signed content. The manufacturer signing certificate SHALL chain to a Manufacturer Trust Anchor provisioned in the device. The signer certificate SHOULD contain key usage and certificate policy information appropriate for bootstrap CA certificate response signing. The CMS SignedData object SHALL be conveyed using the "application/ pkcs7-mime" media type defined for CMS objects. 5.3. Alias Binding The alias field contained within the ManufacturerSignedCACerts structure is protected by the CMS signature. The client MUST verify that the alias contained in the signed structure matches the alias associated with the bootstrap request. If the alias values do not match, the client MUST reject the response and MUST NOT install any returned CA certificates. This validation prevents substitution of a valid manufacturer-signed bundle from one bootstrap alias into another alias context. 6. Bootstrap Transport Layer A client that does not yet possess the operational trust anchor may be unable to authenticate the EST server certificate during TLS or DTLS server authentication. In that case, the client MUST NOT perform general EST operations. The client MAY perform only the bootstrap CA certificate retrieval operation defined by this document. Until the manufacturer signature has been validated and the operational trust anchor has been installed, the client MUST treat the transport as unauthenticated for EST authorization purposes. The TLS or DTLS connection provides transport services only and MUST NOT be interpreted as establishing server identity or authorization for any EST operation other than bootstrap CA certificate retrieval. Mittal & Hett Expires 29 March 2027 [Page 8] Internet-Draft EST-coaps-ca-certs September 2026 6.4. HTTPS Transport For EST over HTTPS, the client MAY establish a TLS connection even when the EST server certificate cannot be validated against the client's current trust anchor store, but only for retrieving the manufacturer-signed CA certificate bundle. The client MUST NOT send certificate enrollment requests, CSRs, client credentials, long-term identifiers, or sensitive information over such a connection. The client MUST validate the manufacturer signature over the CA certificate response before installing any returned CA certificate. After the manufacturer signature is validated and the operational CA certificates are installed, the client MUST establish a new TLS session and perform normal EST server authentication before performing any non-bootstrap EST operation. 6.5. CoAP Transport For EST-coaps, the client has two deployment options: 1. CoAP over DTLS with unauthenticated server certificate during bootstrap * The client establishes DTLS to the EST-coaps server. * The server may present its operational certificate. * The client records that the DTLS server authentication has not yet been validated. * The client sends only the bootstrap /crts request. * The client validates the manufacturer signature before accepting the returned CA certificates. The unauthenticated TLS/DTLS connection provides transport services only and MUST NOT be interpreted as establishing server identity. 2. CoAP without DTLS for bootstrap-only retrieval * The client retrieves only the manufacturer-signed CA certificate bundle. * Integrity and origin authentication are provided by the manufacturer CMS signature, not by the transport. Mittal & Hett Expires 29 March 2027 [Page 9] Internet-Draft EST-coaps-ca-certs September 2026 * This mode MUST NOT be used for enrollment, re-enrollment, CSR attributes, server-side key generation, or any operation that exposes sensitive client information. The first option is RECOMMENDED when feasible because it provides confidentiality against passive observers, although it does not provide full server authentication until the operational trust anchor is installed. The second option MAY be used where DTLS cannot be established before operational trust is available, provided that the response is public bootstrap material and the client validates the manufacturer signature before installation. 7. Client Processing Rules The client MUST process the response as follows: 1. Retrieve the CMS SignedData certificate response from the manufacturer-specific alias. 2. Build a certification path from the manufacturer signing certificate to the locally configured manufacturer trust anchor. 3. Verify that the manufacturer signing certificate is authorized for bootstrap CA certificate response signing. 4. Verify the CMS signature over the exact CA certificate response body. 5. If validation succeeds, install the CA certificates into the operational trust anchor store. 6. If validation fails, discard the CA certificates and log the failure. The client MUST NOT install CA certificates unless the manufacturer signature validates successfully. The client MUST NOT use the retrieved CA certificates for certificate enrollment until they have been installed as operational trust anchors and used to authenticate a new EST or EST-coaps session. 8. Server Processing Rules The EST server SHALL publish only manufacturer-approved CA certificate responses under the manufacturer-specific alias. Mittal & Hett Expires 29 March 2027 [Page 10] Internet-Draft EST-coaps-ca-certs September 2026 The EST server MAY serve the same static manufacturer-signed object to all devices of the corresponding manufacturer trust domain. The EST server MUST NOT dynamically generate manufacturer signatures unless it possesses an authorized manufacturer signing credential or has access to a manufacturer-approved signing service. The EST server MAY serve the bootstrap response as a cacheable object when deployment policy allows. 9. Denial-of-Service Considerations Bootstrap CA certificate retrieval may occur before normal EST server authentication is available. Therefore, the EST server MUST be designed to resist unauthenticated requests. The server SHOULD apply the following protections: 1. Serve bootstrap CA certificate responses as static or precomputed objects. 2. Avoid per-client database lookups for unauthenticated bootstrap requests. 3. Avoid dynamic signing during request processing. 4. Rate limit requests per source address, network prefix, manufacturer alias, and server instance. 5. Use DTLS cookies or stateless retry mechanisms where DTLS is used. 6. Limit the set of methods allowed on bootstrap aliases to GET only. 7. Reject enrollment, re-enrollment, CSR attributes, and server-side key generation requests on bootstrap-only aliases. 8. Use CoAP Block-Wise Transfer carefully so that block state does not create unbounded server memory usage. 9. Apply response-size limits and amplification controls. 10.Log abnormal request rates and repeated invalid alias requests. 11.Allow operators to disable or throttle manufacturer aliases independently. Mittal & Hett Expires 29 March 2027 [Page 11] Internet-Draft EST-coaps-ca-certs September 2026 10. Security Considerations 10.1. Manufacturer Signing Key Protection The manufacturer signing private key is security critical. Compromise of this key could allow an attacker to create unauthorized CA certificate responses that devices may install as operational trust anchors. The manufacturer signing key SHOULD be protected using a Hardware Security Module (HSM), Key Management System (KMS), or equivalent protected environment. The key SHOULD be generated and stored according to manufacturer key management policy and protected against unauthorized export. Loss of control of the manufacturer signing key can compromise the security of all devices that trust the corresponding Manufacturer Trust Anchor. 10.2. Separation of Manufacturer Signing Function The manufacturer signing certificate SHOULD be dedicated to bootstrap CA certificate response signing. It SHOULD NOT be reused for TLS server authentication, CA certificate issuance, firmware signing, or other unrelated purposes. Separation of duties reduces the impact of compromise of any individual key and simplifies authorization policy within the client. 10.3. No Enrollment Before Trust Bootstrap The client MUST complete manufacturer signature validation and operational trust anchor installation before initiating any EST operation over a new TLS or DTLS transport. This ensures that all non-bootstrap EST operations continue to rely on authenticated server communication. 10.4. Cleartext Transport Risks The manufacturer CMS signature provides integrity and origin authentication for the CA certificate response. Mittal & Hett Expires 29 March 2027 [Page 12] Internet-Draft EST-coaps-ca-certs September 2026 If Cleartext HTTP or CoAP is used, it exposes the alias and the signed CA certificate bundle to passive observers. This is acceptable only if the bootstrap CA certificate response is considered public deployment metadata. Deployments that require confidentiality for the manufacturer alias and CA certificate bundle SHOULD use TLS or DTLS. Cleartext transport MUST NOT be used for credential exchange, enrollment requests, client authentication, or any operation involving sensitive client information. 10.5. Replay of Old CA Certificate Responses A validly signed but old CA certificate bundle might be replayed by an attacker. To mitigate these attacks, the signed response SHOULD include validity information such as a sequence number, version information, or signing time. Clients SHOULD store the highest accepted sequence number or version for each alias and SHOULD reject older bundles. If the client possesses a reliable source of time, the client MUST verify that the current time falls within the validity interval defined by notBefore and notAfter. If reliable time is unavailable, the client MAY defer validity interval verification and rely on sequenceNumber-based freshness validation. Once authenticated time is available, the client SHOULD verify the validity interval and apply local policy if the bundle falls outside the defined validity period. 10.6. Alias Substitution An attacker might attempt to substitute a signed object intended for one alias into the response for another alias. To prevent this, the alias MUST be included in the CMS-protected content. The client MUST verify that the protected alias matches the requested alias or an equivalent locally configured alias. 10.7. Operational CA Compromise or Rollover This mechanism can be used to distribute replacement operational trust anchors following operational CA rollover, CA expiration, CA compromise, or other trust-anchor transition events. A manufacturer- signed bundle may contain new operational CA certificates, replacement operational CA certificates, or a complete replacement trust-anchor set. Clients MUST apply local trust-anchor management policy when processing a newly validated bundle. Mittal & Hett Expires 29 March 2027 [Page 13] Internet-Draft EST-coaps-ca-certs September 2026 Deployments that permit trust-anchor replacement through manufacturer-signed bundles SHOULD ensure that sequence number processing prevents rollback to previously accepted trust-anchor sets. A successfully validated manufacturer-signed bundle MAY update, replace, or augment existing operational trust anchors in accordance with local policy and without requiring out-of-band authorization. 11. IANA Considerations This document does not define any new protocol message types, URI schemes, CoAP methods, HTTP methods, TLS extensions, DTLS extensions, certificate extensions, or registries. The manufacturer alias defined by this document is represented as part of the EST or EST- coaps URI path and is not an IANA-registered parameter. No IANA actions are required by this document. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5652] Housley, R., Ed., "Cryptographic Message Syntax (CMS)", RFC 5652, DOI 10.17487/RFC5652, September 2009, . [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9148] van der Stok, P., Kampanakis, P., Richardson, M., and S. Raza, "EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol", RFC 9148, DOI 10.17487/RFC9148, April 2022, . Mittal & Hett Expires 29 March 2027 [Page 14] Internet-Draft EST-coaps-ca-certs September 2026 Appendix A. Operational Scenario Example This section expands on the Operational Scenario Overviews by providing detailed examples of the messages. This appendix is informative and provided only as an example. A.1. Obtaining CA certificates with embedded manufacturer trust The following is an example of a valid /cacerts with manufacturer alias GET /.well-known/est/{manufacturer-alias}/cacerts HTTP/1.1 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 Host: 192.0.2.1:8085 Accept: */* In response, server provides the response: HTTP/1.1 200 OK Status: 200 OK Content-Type: application/cms Content-Transfer-Encoding: base64 Content-Length: 647 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggFOMIIBSjCB8aADAgECAgEBMAoGCCqGSM49BAMCMB4xHDAJBgNVBAYTAlJV MA8GA1UEAx4IAFQAZQBzAHQwHhcNMjMwNzE4MjAwNzE0WhcNMjQwNzE4MjAwNzE0 WjAeMRwwCQYDVQQGEwJSVTAPBgNVBAMeCABUAGUAcwB0MFkwEwYHKoZIzj0CAQYI KoZIzj0DAQcDQgAEr13czVhlDbc3Y3o/sYXvEWBxVIjEqMWQwo8eSvwJxkb5dZoV qoOcwoVYQ2ADq7+hpbzcosYF3Zm/fYUY//RV9qMgMB4wDwYDVR0TBAgwBgEB/wIB AzALBgNVHQ8EBAMCAAYwCgYIKoZIzj0EAwIDSAAwRQIhAPbH2ODIYTya2rRP6vz8 KERaH5Lro84ImJbePBzxRqd3AiBWWFI7bvNy9MtsWH/wDM9360E7vtRUdNvW0L7a Z72O7jGB+jCB9wIBATAjMB4xHDAJBgNVBAYTAlJVMA8GA1UEAx4IAFQAZQBzAHQC AQEwDQYJYIZIAWUDBAIBBQCgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0yMzA3MTgyMDA3MTRaMC8GCSqGSIb3DQEJBDEiBCCN5SFU PprUlKgWp/V/CxMLKKHU1mjtY/WttBvrXTN8DjAKBggqhkjOPQQDAgRHMEUCICRg kFOpxXsJIuKk8IQapP6tRweZmV7s8AZ3rXeW3wYsAiEArysc8vCTt6jFbXvdv72m T261hpld0ggKQEVbJ+ePjv8AAAAAAAA= Response content structure in CMS Format: ContentInfo { contentType id-signedData, //(Value = 1.2.840.113549.1.7.2) content SignedData } Mittal & Hett Expires 29 March 2027 [Page 15] Internet-Draft EST-coaps-ca-certs September 2026 SignedData { version CMSVersion, (Value = 3) digestAlgorithms SET OF DigestAlgorithmIdentifier, //(Value = 2.16.840.1.101.3.4.2.1) encapContentInfo EncapsulatedContentInfo, certificates CertificateSet, //(Manufacturer Signing Certificate with Full Chain) crls CertificateRevocationLists, //(Optional) signerInfos SET OF SignerInfo } SignerInfo { version CMSVersion, //(Value = 3) sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, //(Value = 2.16.840.1.101.3.4.2.1) signedAttrs SignedAttributes, signatureAlgorithm SignatureAlgorithmIdentifier, //(Value = 1.2.840.10045.4.3.2) signature SignatureValue, unsignedAttrs UnsignedAttributes //(Optional) } SignerIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyIdentifier [0] SubjectKeyIdentifier //(Preferred to Use) } SignedAttributes ::= SET SIZE (1..MAX) OF Attribute // (Sample Paramterse // ContentType - 1.2.840.113549.1.9.3 // MessageDigest - 1.2.840.113549.1.9.4 // SigningTime - 1.2.840.113549.1.9.5 // ) Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } AttributeValue ::= ANY EncapsulatedContentInfo ::= SEQUENCE { eContentType id-data, eContent [0] EXPLICIT OCTET STRING //ManufacturerSignedCACerts content } ManufacturerSignedCACerts ::= SEQUENCE { Mittal & Hett Expires 29 March 2027 [Page 16] Internet-Draft EST-coaps-ca-certs September 2026 version INTEGER, alias UTF8String, sequenceNumber INTEGER, notBefore GeneralizedTime, notAfter GeneralizedTime, caCertificates SEQUENCE SIZE (1..MAX) OF Certificate } Authors' Addresses Narinder Mittal Landis+Gyr Email: narinder.mittal@landisgyr.com Chris Hett Landis+Gyr Email: chris.hett@landisgyr.com Mittal & Hett Expires 29 March 2027 [Page 17]