Device-ownership callout. Currently the callout can be configured, but it is not used by the code yet.

Tenant view device types. Currently, tenants can set a valid ‘device-types’ value only if provided to them out-of-band. These values are only set at the “host” level, (on purpose) outside the tenant’s purview. A tenant’s clients should be able use either an RPC/action to get the supported device-types from the host, or have that information exposed as opstate (i.e., read-only “config false” values)³.

Validating the end-entity certificates, when being configured, match the associated private key. Currently the system trusts that the user passes in valid key/cert pairs.

Validating base64 contents (CMS). Currently trusts that valid structures are configured. Only later, when using the structures will SZTPD decode them and potentially find errors. Exceptions will be thrown, but the error messages are not always helpful. Tests would include, e.g., that a CMS containing a sequence of certificates does not contain any spurious certificates.

Remove support for mode ‘1’. This change would affect the NBI only (no impact on the device-facing ‘rfc8572’ SBI).

• Reasons to remove mode ‘1’:

  1. It may be important for non-production use environments (e.g., those used for evals and demos) to exactly mimic production environments.

  2. Eliminates an artificial constraint for Mode ‘1’ deployments, in they can easily configure an additional “tenant” for whatever reason. It also eliminates need to ever have to migrate mode-1 deployments to a mode-x deployment, which would require a database migration..

  3. The tenant-view provided by Mode ‘x’ quite nicely isolates system-level configuration enabling IT organizations to do the system-level install and then pass an “application” view that excludes the system-level install to another organization within the company.

  4. Only supporting Mode-x could greatly simplify the YANG modules. This could be important to developers as they might need to look at the YANG modules in order to understand the data model exposed by the API. While the current YANG is navigable, it could be even more so if only supporting Mode-x.

  5. Further simplify the YANG modules. Note that mode ‘0’ is already almost completely phased out, and yet the YANG modules have yet to be simplified…somewhat due to waiting to determine if also phasing out mode ‘1’.

• Reasons to NOT remove mode ‘1’:

  1. It is unclear what the market expectations are regarding metered based subscriptions versus flat-rate tiers for enterprises and service providers. Hesitant to change anything without some feedback.

Remove support for more than one API interface per listening port. Currently the ‘use-for’ leaf-list has ‘max-elements’ set to ‘1’. (Update Adminstrator’s Guide too).

RESTCONF entity-tag (ETag) Support. The HEAD and GET operations would return the “ETag” HTTP header field. The POST, PUT, and DELETE operations would inspect request headers for the “If-Match”, and “If-None-Match” fields. Support for Etag is a MUST in RFC 8040 only on the top-level datastore resource, and unspecified for inner-resources.

The RESTCONF/HTTP “OPTIONS” method. This needs to be added in order to notify clients that XML is NOT supported.

Filtering (depth + fields) query parameters. These query parameters are described by Section 4.8 of RFC 8040 to reduce the amount of data returned to the client. Workaround is for the client to discard the unwanted parts of the response itself.

Ordering (point + insert) query parameters. These query parameters are described by Section 4.8 of RFC 8040 to enable maintaining user-ordered lists. Workaround is to recreate the entire list in the correct order.

Paging (offset + limit) query parameters. It is desirable to introduce proprietary query parameters for interacting with potentially long lists (i.e., audit-log, bootstrapping log, devices, tenants, etc.)

Authorization / access-control. It is planned to implement the admin-account “access” node, which sets an enumerated value being one of “unrestricted”, “typical”, and “minimal”.

Implicit change tracking. This is needed to support a few of the features listed below. It is also needed to detect when any part of the “transport” configuration changes, so that a SIGHUP can be issued. Currently SIGHUP is issued only when an “endpoint” is added or removed.

Device record counters. It is planned to track when the device records are created, last modified, and the total number of modifications. Similarly, to track when the bootstrapping device first connected, last connected, and the total number of connections.

Reference tracking. It is desired to track references to objects in the system. In YANG terms, these are the ‘leafref’ statements that reference a ‘list’ statement’s ‘key’ node. Tracking includes the current number of references and the time of last reference.

Automated purging with notifications. It is desired to send notifications when unreferenced objects have been without a reference, for some configurable amount of time. A series of notifications with escalating urgency can be to sent to configurable notification receivers. A final notification is sent when the purging occurs.

Password expirations with notifications. This feature goes with the previously mentioned “automated purging with notifications” feature, but has its own “preferences” setting for when the timeouts should be.

Email-based admin activations. It is intended that SZTPD will send email based notifications to newly created admins when their accounts are first created. It is important to validate the email address because the same email address may be emailed later when the password expiration date is approaching. This is why the email address is the primary key for the admin accounts.

Password minimum length constraints. Currently the “preference” setting for the admin account password’s minimum length constraint is ignored.

Client certificate based auth to NBIs. Currently SZTPD implements client cert based auth to the SBI (i.e, ‘rfc8572-interface’). This is to extend that configuration into the NBIs also (i.e., ‘native’ and ‘tenant’). This would provide 2FA to the NBI.

Webhook-based callouts for response manager (Callback-based callouts can be used as a workaround until supported).

Plugin-based callout for notifications (Webhook-based callouts can be used as a workaround until supported).

RESTCONF “Last-Modified” support. The HEAD and GET operations would return the “Last-Modified” HTTP header field. The POST, PUT, and DELETE operations would inspect request headers for the “If-Modified-Since” and “If-Unmodified-Since” fields. Support for timestamps is a SHOULD in RFC 8040.

The RESTCONF/HTTP “PATCH” method. Though a MUST in RFC 8040, it seems mostly like a nice-to-have in SZTPD…

XML-based messages in SBI. RESTCONF enables the Content-Type to be “application/yang.data+xml” signaling that the server supports encoding XML messages. Currently, SZTPD only supports “application/yang.data+json” for a JSON-only SBI interface. There is a question of market-demand as for if needed. All clients (both NBI and SBI) must use JSON-encoded RESTCONF messages.

Support a callout to retrieve an ownership voucher from an external system. This would implement the “supply-ownership-voucher” RPC defined in the “wn-sztpd-callbacks” module. The RPC is currently protected by a ‘feature’ statement called “supply-ownership-voucher”, thus programmatically signalling that it is not supported, though visible in the YANG.

Support signing conveyed information sent from SZTPD using the private key associated with a configured owner certificate.

Support encrypting conveyed information sent from SZTPD using the device’s public key from its identity certificate (e.g., IDevID).

Support stapling revocation responses to CMS objects returned to devices.

• only needed for signed data? (what about the redirect-info’s trust-anchor CMS?)

Private key encryption. It is desirable for SZTPD to have an ability to encrypt private keys via a “root” key. Note that this is above and beyond DB-level encryption; it purpose to to shield keys even from administrators having appropriate access. This root key would be protected by access control and/or an HSM.

Actions: None of the ‘action’ statements defined in the YANG modules are implemented yet. Primarily this effects the ability to create keys, and generate certificate signing requests. The workaround is to generate the keys and certs using an external PKI and then pass those values in as configuration.