Internet-Draft EST-coaps-ca-certs September 2026
Mittal & Hett Expires 29 March 2027 [Page]
Workgroup:
Independant Submission
Internet-Draft:
draft-mittal-est-coap-ca-certs-00
Published:
Intended Status:
Informational
Expires:
Authors:
N. Mittal
Landis+Gyr
C. Hett
Landis+Gyr

Manufacturer-Signed CA Certificate Distribution for EST and EST-coaps Deployments

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

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.

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.

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:

Table 1: Definitions
Term Definition
Manufacturer Trust Anchor A trust anchor provisioned into the EST 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 Anchor A CA certificate used by the device to authenticate the operational EST server and operational PKI.
Manufacturer-Signed CA Certificate Bundle A CA certificate response whose exact content is signed by the manufacturer or a manufacturer-authorized signer.
Bootstrap CA Certificate Retrieval The limited retrieval operation defined by this document, used before the client can authenticate the EST server using the operational trust anchor.
Bootstrap-Only Session A TLS or DTLS session in which normal EST server authentication has not yet succeeded and only the bootstrap CA certificate retrieval operation is permitted.

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.

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 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.
  • 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.

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.
    • 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.

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.

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.

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.

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, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5652]
Housley, R., Ed., "Cryptographic Message Syntax (CMS)", RFC 5652, DOI 10.17487/RFC5652, , <https://www.rfc-editor.org/info/rfc5652>.
[RFC7030]
Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, , <https://www.rfc-editor.org/info/rfc7030>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[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, , <https://www.rfc-editor.org/info/rfc9148>.

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
}

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 {
                        version             INTEGER,
                        alias               UTF8String,
                        sequenceNumber      INTEGER,
                        notBefore           GeneralizedTime,
                        notAfter            GeneralizedTime,
                        caCertificates      SEQUENCE SIZE (1..MAX) OF Certificate
}

Authors' Addresses

Narinder Mittal
Landis+Gyr
Chris Hett
Landis+Gyr