Conveying a Certificate Signing Request (CSR) in a Secure Zero-Touch Provisioning (SZTP) Bootstrapping Request
updates
- rfc-8572 — Secure Zero Touch Provisioning (SZTP)
Extracted elements (26)
How the signed certificate is conveyed inside the onboarding information is left outside the scope of this document; implementations may use a pre-configuration script or the SZTP 'configuration' node. This intentional underspecification preserves flexibility for diverse deployment scenarios.
The 'ietf-ztp-types' module is defined independently of 'ietf-sztp-csr' so that its three groupings can be reused by bootstrapping protocols other than SZTP. This separation allows future ZTP protocols to leverage the same CSR negotiation model without depending on the SZTP-specific augmentation module.
The SZTP-server communicates its CSR request via an HTTP 400 'missing-attribute' error rather than a normal RPC reply, because SZTP's 'get-bootstrapping-data' RPC was not originally designed to support a multi-round CSR exchange. This error-based signaling allows the extension without modifying the original RPC output structure.
A raw PKCS#10 CSR (p10-csr) does not support origin authentication in the CSR structure itself; external origin authentication must be provided via the ZTP-client's authentication to the ZTP-server at the transport layer (e.g., TLS). CMP and CMC formats support origin authentication using both PKI and a shared secret.
When 'key-generation' is absent from the client's 'csr-support', the ZTP-server MAY request a CSR using the asymmetric key associated with the device's existing identity certificate (e.g., an IDevID from IEEE 802.1AR), rather than requesting new key generation.
If the AlgorithmIdentifier in the certificate SubjectPublicKeyInfo field does not match the algorithm identified by the 'selected-algorithm' node, then the client MUST reject the certificate and raise an error.
The 'key-generation' node in the 'csr-request' response MUST only appear if the ZTP-client's 'csr-support' included the 'key-generation' node. The selected algorithm MUST be one of the algorithms specified in the client's 'supported-algorithms' node.
When an SZTP-client sends the 'csr-support' node and the SZTP-server wishes to request a CSR, the SZTP-server MUST respond with an HTTP 400 Bad Request error code with an 'ietf-restconf:errors' message having error-tag 'missing-attribute' and error-info containing the 'csr-request' structure.
When the SZTP-client sends a CSR node, the SZTP-server SHOULD respond with SZTP onboarding information containing a signed certificate. The SZTP-server MAY alternatively respond with another HTTP error containing another 'csr-request', in which case the SZTP-client MUST delete any key generated for the previously generated CSR.
When the SZTP-server provides a 'cert-req-info' (CertificationRequestInfo), the ZTP-client MUST use this structure to generate its CSR; failure to do so will result in a 400 Bad Request response containing another 'csr-request' structure.
The 'certificate-request-format' base identity and three derived identities ('p10-csr' per RFC 2986, 'cmp-csr' per RFC 4210, 'cmc-csr' per RFC 5272) define the extensible set of CSR formats. Additional derived identities MAY be defined by future efforts.
The 'csr-request' YANG structure is returned by the SZTP-server in the 'error-info' node of an HTTP 400 response. It specifies the selected key algorithm (DER-encoded AlgorithmIdentifier), selected CSR format (identityref), and an optional 'cert-req-info' (CertificationRequestInfo) the client must sign.
The 'csr-support' node allows an SZTP-client to signal CSR generation capability in a first 'get-bootstrapping-data' request. It includes an optional 'key-generation' presence container listing supported DER-encoded AlgorithmIdentifiers, and a 'csr-generation' container listing supported CSR format identityref values.
The 'ietf-sztp-csr' module augments the 'get-bootstrapping-data' RPC input with two mutually exclusive choices: 'csr-support' (indicating CSR generation capability and supported algorithms/formats) and 'csr' (conveying the generated CSR). It also defines a 'csr-request' YANG structure returned in RESTCONF error-info.
The 'ietf-ztp-types' module defines three reusable YANG groupings: 'csr-support-grouping' (client capability announcement), 'csr-request-grouping' (server's CSR request), and 'csr-grouping' (client's CSR submission). These are defined independently of 'ietf-sztp-csr' so other bootstrapping protocols can reuse them.
IANA has registered two URIs in the IETF XML Registry 'ns' registry: 'urn:ietf:params:xml:ns:yang:ietf-sztp-csr' and 'urn:ietf:params:xml:ns:yang:ietf-ztp-types', both registered by the NETCONF WG.
IANA has registered two YANG modules in the YANG Module Names registry: 'ietf-sztp-csr' (prefix: sztp-csr) and 'ietf-ztp-types' (prefix: ztp-types), both referencing RFC 9646.
It is RECOMMENDED that a new private key be generated for each CSR. When a new key cannot be protected as well as the built-in IDevID private key, it is RECOMMENDED to reuse the built-in private key rather than generate a less-protected new key. Implementations MUST use cryptographically strong PRNGs.
The CSR extension cannot be used when the SZTP-client connects to an untrusted SZTP-server, because the HTTP 400 error response containing 'csr-request' cannot be signed data per RFC 8572. SZTP-clients SHOULD NOT pass 'csr-support' to an untrusted SZTP-server and SHOULD instead pass 'signed-data-preferred'.
The deployment-generated LDevID certificate and associated private key are considered user data and SHOULD be cleared whenever the SZTP-client is reset to factory default state (e.g., via the 'factory-reset' RPC defined in RFC 8808), unlike the manufacturer-generated IDevID.
The private key used for the dynamically generated identity certificate MUST be protected from inadvertent disclosure to prevent identity fraud. It is RECOMMENDED that devices use a hardware security module (HSM) such as a TPM to generate and contain the private key within the HSM's security perimeter.
The SZTP-server MUST verify proof-of-possession by checking the CSR signature against the public key contained in the CSR, and verify proof-of-origin either by validating the IDevID certification path (when reusing the manufacturer key) or via CMP/CMC protocol authentication mechanisms (when using a fresh key).
When generating a new key for a CSR, the fresh public key serves as an implicit nonce enabling replay attack detection: the signed certificate returned by the SZTP-server will contain the client's fresh public key, confirming the response is not replayed. When reusing an IDevID key, replay detection is not guaranteed.
The CSR exchange follows a four-step flow: (1) SZTP-client sends 'csr-support' in first RPC; (2) SZTP-server responds with HTTP 400 containing 'csr-request' structure; (3) SZTP-client sends one of 'p10-csr', 'cmc-csr', or 'cmp-csr' in a second RPC; (4) SZTP-server responds with onboarding information containing the signed identity certificate.
Algorithm identifiers in 'supported-algorithms' and 'selected-algorithm' are encoded as DER-encoded AlgorithmIdentifier binary values per RFC 2986 and ITU-T X.690. Format identifiers use identityref values derived from the 'certificate-request-format' base identity (e.g., 'ietf-ztp-types:p10-csr').
The 'p10-csr' leaf carries a PKCS#10 CertificationRequest structure (type ct:p10-csr from RFC 9640). The 'cmc-csr' leaf carries a DER-encoded profiled CMC 'Full PKI Request'. The 'cmp-csr' leaf carries a DER-encoded CMP PKIMessage. All three are alternatives in a mandatory 'csr-type' choice.