Summary

  • draft-mittal-est-coap-ca-certs-00 proposes that a device use a factory-installed manufacturer trust anchor to validate a CMS-signed bundle of operational CA certificates. It is an individual revision-00 Internet-Draft, not an RFC, an IETF consensus document or evidence of deployment.
  • The bootstrap endpoint may be unauthenticated. Its TLS or DTLS connection supplies transport only; the manufacturer signature authenticates the bounded object. The alias, signature, sequence, validity interval and local policy must all pass before installation.
  • Installing the bundle does not authenticate the server that delivered it and does not authorize enrollment. The device must start a new TLS or DTLS session, validate the server under the newly installed anchors, and preserve separate receipts for object authority, trust-store mutation, peer identity, enrollment and outcome.

The most dangerous green light in a bootstrap system is the one labelled simply “trusted.” It may mean that a signature verified. It may mean that a certificate chain terminated at a configured root. It may mean that a local policy accepted a new anchor. It may mean that a server proved its name in a later session. Those are not synonyms, even when they occur within seconds.

The individual Internet-Draft draft-mittal-est-coap-ca-certs-00 exposes the distinction unusually clearly. A constrained device can leave the factory before its eventual operator has selected an operational public-key infrastructure. The device knows a manufacturer trust anchor, but it does not yet know the CA that will authenticate the operational EST server. Revision 00 proposes a manufacturer-signed package that carries the missing CA certificates.

The clever part is that the delivery server does not need to be trusted first. It can publish a precomputed CMS object under a manufacturer-specific EST alias. The client can retrieve that object through a TLS or DTLS connection whose presented server certificate it cannot validate, or in a constrained public-metadata case over cleartext HTTP or CoAP. Integrity and origin authentication belong to the signed object rather than the transport.

That narrow exception solves a real circle: the device needs the CA to authenticate the server, yet normally expects to authenticate the server before accepting the CA. It also creates a seductive mistake. Once the object verifies, an implementation may promote the entire encounter into a trusted session. The draft says the opposite. Until the operational anchors are installed, the connection remains unauthenticated for EST authorization. After installation, the client must create a new connection and perform normal server authentication before any non-bootstrap operation.

The signer authorizes bytes, not the socket

The proposed ManufacturerSignedCACerts structure binds six things: a format version, a manufacturer alias, an increasing sequence number, notBefore, notAfter and one or more CA certificates. CMS SignedData covers the complete structure. The response includes the signing certificate and intermediates needed to build a path to the manufacturer trust anchor already held by the device.

Successful cryptography answers a bounded question: did an acceptable signing key protect these exact fields and certificate bytes? It does not answer who operated the IP address, DNS name, HTTP service or CoAP endpoint that supplied the object. An attacker, mirror or content cache could relay an authentic object. That may still be safe for retrieval if the object is current, correctly scoped and acceptable under local policy. It is not proof that the relay may receive a certificate request, device credential or long-term identifier.

This is why the draft permits only the bootstrap CA retrieval operation. Over HTTPS, the client may provisionally complete TLS solely to obtain the signed bundle. It must not send a CSR, enrollment request, client credential, long-term identifier or sensitive information. In the CoAP path, a DTLS session with an unvalidated server certificate remains transport. A cleartext option can carry only public bootstrap material. Neither mode gains authority by successfully returning bytes.

The EST server can serve the same static object to every device in the relevant manufacturer trust domain. It need not possess the manufacturer signing key, and it must not manufacture signatures dynamically unless it has an authorized credential or approved signing service. Distribution and authorization are intentionally separable roles.

That separation is operationally valuable. It limits online key exposure and lets an unauthenticated edge cache absorb demand. It also means server logs cannot be read as signing logs. A response from the endpoint proves delivery; the CMS signer record proves object authorization. Incident responders need both records, not one synthetic “trusted source” event.

A URI alias is routing context, not permission

The proposal places the bundle below a manufacturer-specific EST alias. For HTTPS, the path can resemble /.well-known/est/{manufacturer-alias}/cacerts; EST-coaps uses its shorter /crts operation. A deployment may derive an alias from an IANA Private Enterprise Number, but revision 00 does not mandate one construction and asks for no new registry.

An alias is convenient because a server can host bundles for several manufacturer trust domains. It is also dangerous if a parser treats the path label as evidence. The draft states that the alias alone must not authorize installation. The protected object contains its own alias, and the client must compare it with the requested or locally equivalent alias. A mismatch is a hard rejection even when the signature is otherwise valid.

That check prevents a legitimate package from one domain being substituted into another. The deeper lesson is broader than URLs. Names select a context. Signed content proves what was bound inside the signature. Local configuration decides which equivalences are acceptable. Collapsing these three stages allows a routing choice to become an authorization grant.

Operators should therefore record the configured alias, requested URI, protected alias, equivalence rule and result. A log that says only “CMS valid” cannot explain why a trust set was installed under this device population. A log that says only “correct endpoint” cannot show that the returned object was authorized.

A valid old bundle is still an attack

Signatures survive time. That is their purpose and one of bootstrap's hardest problems. A package signed last month remains cryptographically valid after an operational CA has been replaced because it was compromised. A factory-reset device may forget that it already accepted a higher sequence and install the old set again.

Revision 00 includes an increasing sequenceNumber and a validity interval. Clients should retain the highest accepted sequence for each alias and reject older objects. If they have reliable time, they must enforce notBefore and notAfter. If they do not yet have trustworthy time, they may defer interval verification and rely on sequence state, then revisit the interval after authenticated time becomes available.

This is not merely a parser requirement. It turns device storage into security state. A monotonic sequence held in ordinary resettable configuration offers little rollback protection. Fleet designers need to decide where the last accepted value survives reimaging, replacement boards, disaster recovery and restore from backup. They also need an explicit rule for equal sequences with different bytes, sequence exhaustion, emergency recovery and a signed bundle whose clock interval disagrees with a device that has just booted without time.

A content-delivery network may correctly cache the object and still extend the lifetime of a withdrawn package. The distribution service may return a perfect byte-for-byte copy and still be serving the wrong generation. Cacheability lowers denial-of-service cost; it does not supply freshness.

The right evidence is a joined record: object hash, protected sequence, previous accepted sequence, time confidence, interval decision, cache age, local policy version and resulting anchor-set hash. Any dashboard that reports only signature validity hides the most plausible rollback path.

Local policy is the operator's last veto

The draft allows a validated package to add, replace or augment operational trust anchors. It also says clients must apply local trust-anchor management policy. Both sentences matter.

Manufacturer authorization answers whether the package came from a key the device was built to recognize. It does not decide whether an operator wants to accept every root in the package, whether removal of an existing root is permitted, whether overlapping CA generations are required, or whether a change needs maintenance-window approval. A manufacturer can be authorized to make a proposal without becoming the continuing administrator of the operator's trust estate.

This distinction carries the doctrine in docs/heng-lu-note.md into a concrete security mechanism. The common layer can define deterministic checks needed for safe interpretation: signature path, dedicated purpose, exact bytes, alias, sequence and validity. Future deployment choices remain local: which operational CAs serve this site, when a rollover occurs, what overlap is tolerated, who approves removal and how recovery works.

If software treats any manufacturer-valid package as an unconditional command, it creates a remote trust-store control plane. The manufacturer signing key then controls not only bootstrap authenticity but the future set of institutions a device can trust. That is a larger mandate than the transport problem requires.

The safe implementation should expose a policy decision after cryptographic validation and before mutation. It should compute the current and proposed anchor-set hashes, show additions and removals, apply fleet-specific rules, write an append-only transition receipt and support a bounded refusal state. A refusal should not silently fall back to using the unauthenticated server. It should stop enrollment and report why.

The new connection is the proof boundary

After an accepted bundle changes the trust store, the client must establish a new TLS or DTLS session. That fresh handshake is not ceremonial. It is where the installed anchors are used to validate the operational server.

An implementation that continues on the original connection has learned new trust after the peer already appeared. It may re-evaluate the certificate in memory, but the draft's safe boundary is a new transport for non-bootstrap work. Connection state, negotiated parameters, exporter values and peer authentication should be tied to the post-installation session, not inherited from the provisional channel.

RFC 7030 already separates provisional /cacerts retrieval from later authenticated operation. It permits a client to continue TLS to obtain CA data when initial validation fails, but requires out-of-band authorization of that data and a new connection before normal use. Revision 00 substitutes a proposed manufacturer signature for that authorization step. It does not dissolve the second handshake.

RFC 9148 maps EST into constrained CoAP exchanges and calls /cacerts /crts. It discusses revalidating a server chain after an explicit trust-anchor update. That transport profile makes constrained delivery possible; it does not make every DTLS endpoint that carries a /crts response the operational registrar.

The post-bootstrap receipt should include the new session identifier, server name, certificate-chain fingerprints, accepted trust anchor, validation policy, result and time. Enrollment should reference that receipt. Otherwise the system cannot later distinguish “we accepted a CA package” from “we authenticated the server that received this CSR.”

Enrollment is another transaction, not the final line of bootstrap

Even a fresh authenticated session does not guarantee successful or authorized enrollment. EST still has its own request semantics, client authentication, proof-of-possession, CA policy and response. A device may authenticate the correct server and be denied. It may submit the wrong identity. The CA may issue a certificate whose profile is unusable. Network policy may prevent the issued credential from reaching its intended service.

This is why revision 00 says it changes neither enrollment semantics nor proof-of-possession requirements. The manufacturer-signed bundle solves distribution of operational CA certificates. It does not authorize a device, approve a CSR, issue a certificate or prove that an application came online.

The distinction is easy to lose in fleet automation. A bootstrap orchestration engine often wants one terminal state. But “completed” should be decomposed into at least: package retrieved, signer authorized, freshness passed, local policy accepted, trust store mutated, new server session authenticated, enrollment accepted, certificate installed and service observed.

Each stage has a different owner and rollback. The manufacturer protects the bootstrap signer. The operator owns local anchor policy. The EST service owns peer identity and enrollment processing. The CA owns issuance. The device and network produce the operational outcome. No single signature legitimately speaks for them all.

The manufacturer key becomes a fleet-wide lever

Revision 00 is candid about the blast radius. Compromise of the manufacturer signing key can allow unauthorized CA packages that every trusting device may install. The draft recommends HSM- or KMS-class protection, non-exportability controls and a signing certificate dedicated to bootstrap packages rather than reused for TLS, CA issuance, firmware or unrelated purposes.

Dedicated purpose is not cosmetic. Reusing one key across firmware and trust bootstrap joins two incident domains. An attacker who obtains it could both change what the device runs and change whom that device trusts. A generic “manufacturer certificate” policy also makes client authorization ambiguous: path validation succeeds, but the software cannot tell which institutional act the signer was meant to perform.

Boards should ask what happens when the manufacturer key is suspected, not only how it is stored. Can operators disable one alias without disabling bootstrap for every brand? Can clients reject a signer generation while accepting an emergency successor? Who can authorize that successor if the original manufacturer is insolvent or unreachable? How are already-installed malicious anchors discovered and removed? Does recovery depend on the same compromised channel?

RFC 8995 and RFC 8366 provide a useful comparison through manufacturer-authorized vouchers and domain imprinting. They bind different subjects and workflows. Their existence does not make this revision-00 package a voucher or prove that a manufacturer should control future operational roots indefinitely. The comparison instead shows why artifact purpose, subject binding, freshness and local acceptance must be explicit.

Unauthenticated retrieval changes the availability model

The bootstrap endpoint is intentionally exposed before normal client or server authentication. That makes it a denial-of-service surface. Revision 00 recommends static or precomputed objects, avoidance of per-client database lookups and dynamic signing, rate limits by source, prefix, alias and server instance, stateless DTLS retry, GET-only behavior, response-size limits, careful block-wise transfer and independent alias throttling.

These controls reveal an important architectural fact. The service is closer to a public signed-object repository than an enrollment service during bootstrap. Its cheapest safe response is the same cacheable object, not personalized computation. Any deployment that performs customer lookups or signs per request has expanded the attack surface beyond the proposed minimum.

Cleartext retrieval makes the boundary starker. The CMS signature can preserve object integrity and origin authentication, but observers learn the alias and package. If those values reveal customer, geography or rollout timing, they are not harmless public metadata. Confidentiality requires TLS or DTLS even though the peer remains unaccepted for authorization. Transport privacy and peer authorization can therefore diverge.

The practical rule is to label the channel precisely. “Encrypted” should not be rendered as “authenticated.” “CMS valid” should not be rendered as “server trusted.” “Public object” should not be rendered as “no privacy impact.” A mature inventory keeps all three dimensions.

Build the receipts before the first device ships

The minimum useful evidence chain has eight rows.

Receipt Evidence What it does not prove
Manufacturing provenance Device class, anchor fingerprint, protected storage, alias rule Current manufacturer control or operational CA approval
Bundle authority CMS hash, signer path, purpose policy, signature result Transport-server identity or freshness
Scope and freshness Protected alias, request alias, sequence, interval, time confidence Local acceptance or successful mutation
Policy decision Policy version, approver/rule, before-and-after anchor hashes New server authentication
Bootstrap transport URI, peer certificate, encryption mode, cache and delivery result EST authorization or peer identity when validation failed
New-session identity Fresh session, server name, chain, accepted operational anchor Enrollment approval or certificate issuance
Enrollment CSR hash, client identity, proof of possession, CA decision Device service readiness
Outcome Installed credential, health check and named service observation Legitimacy of another fleet or future package

The rows cannot be replaced by one success code because they fail independently. A valid package can be stale. A fresh package can target the wrong alias. A locally accepted anchor can fail to authenticate the server. An authenticated server can reject enrollment. An issued credential can fail in production.

The leadership advantage is not extra paperwork. It is selective recovery. When an alias is attacked, operators can quarantine that domain without erasing evidence of previously accepted packages. When a signer is compromised, they can find every affected transition. When a server certificate fails, they can avoid blaming the bundle. When enrollment fails, they can keep a valid trust transition while repairing the request.

Revision 00's most useful insight is therefore not that a manufacturer can sign CA certificates. It is that a secure bootstrap can cross an untrusted transport only if every subsequent system refuses to exaggerate what the signature achieved. The object may be authentic. The server is still untrusted. Trust begins to move only after local policy accepts the object, and server identity begins only in the new session that proves it.