Summary

  • RFC 9646 uses two get-bootstrapping-data requests with an HTTP 400 response between them: capability advertisement, server selection and the returned CSR are three different records.
  • A CSR signature proves possession of its private key; it does not by itself prove device origin, CA approval, certificate delivery, installation or authorized use.
  • Because the csr-request travels in an HTTP error that cannot be signed as SZTP bootstrapping data, this enrollment mechanism must not be used through an untrusted bootstrap server.

The red status was an instruction

RFC 9646 extends Secure Zero Touch Provisioning so that a device can obtain a production-purpose identity certificate while it is being onboarded. Its choreography is unusual enough to defeat a generic HTTP success dashboard.

The device first calls RFC 8572's get-bootstrapping-data operation. In a csr-support node, it says whether it can generate a fresh asymmetric key, identifies the key algorithms it supports and lists the CSR formats it can produce. The server does not immediately return onboarding information. If it wants a CSR, it responds with HTTP 400 and puts a csr-request structure inside RESTCONF error-info.

That structure selects the key algorithm and request format and may supply certificate-request content. The device then makes a second get-bootstrapping-data call, this time carrying a PKCS #10, CMC or CMP request. Only after the server, registration authority or certification authority validates the request and approves it does the server return onboarding information that may contain the signed certificate.

The first operational mistake is therefore semantic compression. A transport observer sees 400 and records failure. A protocol observer sees the selected branch. Neither observation proves that a certificate was issued. A good receipt preserves both meanings: the response was syntactically an HTTP client-error status and functionally the expected request for the next SZTP step.

Capability is not execution

The first message advertises possibility. A list of supported algorithms does not show which one the device used. A list of formats does not show whether it later produced p10-csr, cmc-csr or cmp-csr. A claim that a fresh key can be generated does not show that a new key appeared, that its randomness was adequate or that its private half remained inside an approved security boundary.

The server's response narrows that possibility. It chooses an algorithm and format. Yet a selection is still an instruction, not an accomplished key ceremony. The device must generate or select the key, build the requested object and send the second call. Every transition can fail independently, and each needs a different record.

This distinction follows the discipline in Lu Heng's Minimum Initial Specification: standardize the smallest interoperable exchange, then leave local policy visible rather than smuggling it into the shared vocabulary. RFC 9646 standardizes the handoff. It does not standardize a universal CA approval policy, an installation method or a right to use the resulting identity.

Possession and origin answer different questions

All three request forms can carry a public key and a request signed by the corresponding private key. The server verifies proof of possession by checking that signature with the public key in the CSR. This is a strong, narrow result: whoever created the request controlled that private key at that moment.

It is not proof of origin. A raw PKCS #10 object has no origin-authentication facility inside the CSR structure. Origin may instead be inferred from an authenticated TLS or HTTP relationship, but then the audit must preserve that external identity and its binding to the request. A detached CSR stored without its session context cannot borrow origin from the fact that its signature verifies.

CMC and CMP offer richer choices. They can bind a newly generated local-device key to an existing manufacturer identity or protect the request with a shared secret. They can also pass through a registration authority before reaching the CA. Those mechanisms improve the evidence available; they do not make every request legitimate. The verifier still has to validate the manufacturer certification path, the shared-secret reference or the appropriate protocol protection and then apply its issuance policy.

When an existing IDevID key is reused, RFC 9646 says origin verification includes validating the IDevID certification path and confirming that the CSR uses the same key pair. When a fresh key is used, CMC or CMP can carry origin authentication based on the manufacturer key or a shared secret. These are different evidence routes. Reporting them all as “CSR verified” erases the decision that matters.

Freshness has a receipt of its own

RFC 9646 recommends a new private key for each request. If the device really generates one after the server asks, the key's randomness also serves a nonce-like role. When the returned signed certificate contains that fresh public key, the device gains evidence that the response belongs to the current exchange rather than a replay of an older certificate.

That property disappears if the implementation claims fresh generation but reuses a key. It is also weaker when the manufacturer key is deliberately reused: the key may be well protected, but it does not distinguish this request from an earlier one by freshness alone.

There is a real trade-off. The RFC recommends HSM or TPM protection for the dynamic key. If a newly generated key cannot be protected as well as the built-in manufacturer key, it recommends reusing the better-protected built-in key rather than manufacturing a weaker secret merely to claim freshness. Security cannot be reduced to “new is better.” The receipt should state which key path was used, why, where the private key lived and which replay property followed.

The unsigned middle message fixes the trust boundary

RFC 8572 permits a special path in which a device contacts a bootstrap server it does not yet trust and relies on signed bootstrapping data. RFC 9646 cannot simply inherit that protection. Its csr-request is conveyed inside an HTTP error message, and that error cannot be signed as RFC 8572 bootstrapping data.

The consequence is explicit: the CSR mechanism cannot be used when the client connects to an untrusted bootstrap server. In that situation the client should not send csr-support; it should ask for signed data instead. This is not an optional hardening preference. It is a boundary created by the location of an authoritative instruction.

An implementation that accepts a selected algorithm, subject content or request format from an untrusted server is not merely missing a log field. It has allowed an unsigned party to shape the device's production identity request. A compliant-looking CSR later in the exchange cannot repair that earlier authority failure.

Issuance is not delivery, and delivery is not use

After receiving the CSR, the server may work with a registration authority or CA to validate origin and possession and decide whether to issue. The decision can incorporate inventory, ownership, policy, requested attributes and operational approval. RFC 9646 does not collapse these checks into the CSR signature.

Nor does it define exactly how the signed certificate is carried inside onboarding information. It gives examples involving configuration and the RFC 9642 keystore, but the conveyance choice is outside its scope. That leaves a deliberate boundary between issuance and transport.

Installation creates another boundary. The certificate must be associated with the intended key, committed to the intended store and selected by the intended service. First successful authentication creates still another receipt. A returned onboarding response does not prove that the device installed the certificate; an installed certificate does not prove that a peer accepted it; a successful TLS session does not prove the application authorized the requested action.

Lu Heng's Running-Code Primacy is useful here: privilege the executed transitions and their effects over the symbolic comfort of a complete model. The YANG modules describe a common exchange. The evidence chain shows which branch ran.

Build the enrollment receipt

Start with the trusted relationship: bootstrap-server identity, trust-anchor path, TLS and HTTP authentication facts, and whether signed-data-preferred or csr-support was sent. Preserve the first request, including device nonce, hardware and software identifiers, supported algorithms and formats.

Record the HTTP 400 as a protocol transition. Store the exact csr-request, its selected algorithm and format, requested certificate information, response time and correlation identifier. Then capture key generation or reuse: public-key fingerprint, entropy or HSM evidence, private-key protection boundary and whether the key is fresh for this exchange.

For the second request, hash the CSR and record its format. Verify proof of possession separately from proof of origin. Name the IDevID path, shared secret, TLS identity or HTTP identity used for origin and preserve the RA/CA policy decision, approver and issued-certificate fingerprint.

Finally, record how the certificate entered onboarding information, how it was installed, which key it matched, which service selected it, the first successful peer validation and the eventual reset or rotation event. Reality Layers makes the principle plain: status code, instruction, possession, origin, institutional approval, installed state and operational effect are adjacent realities, not interchangeable verdicts.

Sources