Bootstrapping Data Bootstrapping data refers to a collection of data that a device obtains during the bootstrapping process. Bootstrapping data (both redirect and onboarding information) can be signed or unsigned. An ownership voucher, owner certificate, and conveyed information must be present in signed bootstrapping data. Signed data is trusted. If the signed data is redirect information, trust anchors for the bootstrap servers that are being redirected to are saved for future TLS handshakes. Signed onboarding information is trusted and is applied to the device. When a bootstrap server provides signed data, the data is considered trusted. However; this does not make the server trusted.
If the server is considered untrusted before receiving the data, it remains untrusted, and the server does not receive progress reports. Unsigned data do not need to present the ownership voucher and the owner certificate artifacts; infact, these are discarded, if present. Unsigned data is accepted only if it is redirect data or is received from a trusted server. Receiving unsigned data from an untrusted onboarding server is considered an error, and the device continues to the next server on its list. Ownership Voucher Assigning ownership is important to bootstrapping mechanisms. The ownership voucher is defined in Section 5.3 of RFC 8366.
The primary purpose of a voucher is to securely assign a pledge to an owner. The voucher provides the pledge with details of the entity, which the pledge should consider as its owner. The ownership voucher has a Cryptographic Message Syntax (CMS) structure, is Distinguished Encoding Rules-encoded (DER-encoded), and encloses YANG-modeled data. This is a sample ownership voucher: yang-data voucher-artifact: +---- voucher +---- created-on yang:date-and-time +---- expires-on? yang:date-and-time +---- assertion enumeration +---- serial-number string +---- idevid-issuer? binary +---- pinned-domain-cert binary +---- domain-cert-revocation-checks? boolean +---- nonce? binary +---- last-renewal-date?
yang:date-and-time The CMS structure is signed using a private key that corresponds to the device’s trust anchor. The device carries the public key (the trust anchor), which is the only thing it needs to verify the signature on the voucher. The private key is used by the Cisco MASA server when creating the voucher. The private key is securely stored in the Cisco Software Image Management (SWIM) server. The device uses its trust anchor to extract the actual ownership voucher from the CMS structure. The signature on the ownership voucher is verified by using the public key enclosed in the device’s trust anchor.
This verification may require additional intermediate X.509 certificates, in which case, these must be attached to the ownership voucher. After the signature on the ownership voucher is verified, the YANG-modeled data fields are extracted. If the created-on field is present, the device verifies whether the voucher was created in the past. If the expires-on field is present, the device verifies whether the voucher is expired or not. If these fields are not present, the voucher is rejected. Zero-Touch Provisioning Bootstrapping Data Zero-Touch Provisioning 7