A YANG Data Model for a Truststore
Extracted elements (22)
Built-in trust anchors (e.g., manufacturer or public CA certificates pre-installed on a device) are outside the scope of YANG configuration; they appear in <operational> and <system> datastores with 'or:origin' set to 'or:system', not in <intended>.
The 'truststore-grouping' grouping exists separately from the protocol-accessible 'truststore' container to allow the truststore structure to be instantiated in other data model locations, in addition to or instead of the central top-level instance.
The 'ietf-truststore' module is part of a layered RFC suite (crypto-types, truststore, keystore, tcp/ssh/tls/http-client-server, netconf/restconf-client-server) where truststore depends on RFC 9640 (crypto-types) and is depended upon by the keystore and client/server grouping modules.
Server implementations MUST ensure that the truststore contents are protected from unauthorized modifications when at rest.
Servers that wish to define alternate truststore locations MUST augment in custom 'case' statements into the 'inline-or-truststore' choice statements to supply leafrefs to those alternate locations.
The intended purpose for each public-key-bag MUST be described via the 'description' leaf.
Where 'truststore-grouping' is used in other contexts, implementations MUST augment new 'case' statements into the various inline-or-truststore 'choice' statements to supply leafrefs to the model-specific location(s).
Each public key in a public-key-bag is defined by a 'name' (string), 'public-key-format' (identityref), and 'public-key' (binary), using the 'public-key-grouping' from RFC 9640. The format identity allows for SSH public key format and SubjectPublicKeyInfo format among others.
Four features gate truststore functionality: 'central-truststore-supported' (server implements the module), 'inline-definitions-supported' (locally defined trust anchors), 'certificates' (certificate-bags subtree), and 'public-keys' (public-key-bags subtree).
Four typedefs are defined for referencing truststore entries: 'central-certificate-bag-ref', 'central-certificate-ref', 'central-public-key-bag-ref', and 'central-public-key-ref'. All extend the YANG 'leafref' base type and point into the central truststore's list nodes.
The 'cert-data' leaf within the certificate list is of type 'trust-anchor-cert-cms', a CMS structure that can contain a chain of one or more certificates. It is marked 'mandatory true' when used via the inline grouping.
The 'certificate-expiration' notification (defined in RFC 9640's 'trust-anchor-cert-grouping') is exposed within the truststore's certificate list nodes and carries an 'expiration-date' leaf of type 'yang:date-and-time', alerting clients when a certificate is nearing or has passed expiration.
The 'ietf-truststore' module defines a central truststore composed of named 'bags' of certificates and named 'bags' of public keys. The top-level 'truststore' container is gated by the 'central-truststore-supported' feature and uses the 'truststore-grouping' grouping.
The 'inline-or-truststore-certs-grouping' grouping presents a mandatory YANG 'choice' between an inline certificate definition (list of named certificates using 'trust-anchor-cert-grouping' from RFC 9640) and a reference to a certificate bag in the central truststore.
The 'inline-or-truststore-public-keys-grouping' grouping presents a mandatory YANG 'choice' between an inline public key definition (list of named public keys using 'public-key-grouping' from RFC 9640) and a reference to a public key bag in the central truststore.
The 'truststore-grouping' grouping defines two subtrees: 'certificate-bags' (enabled by the 'certificates' feature) and 'public-key-bags' (enabled by the 'public-keys' feature). Each bag has a name, optional description, and a list of named certificate or public key entries.
IANA has registered the module 'ietf-truststore' with namespace 'urn:ietf:params:xml:ns:yang:ietf-truststore' and prefix 'ts' in the YANG Module Names registry (RFC 6020).
IANA has registered the URI 'urn:ietf:params:xml:ns:yang:ietf-truststore' in the 'ns' registry of the IETF XML Registry (RFC 3688).
All writable data nodes defined by the 'ietf-truststore' module have the NACM 'default-deny-write' extension set, because any modification to a trust anchor or reference to a trust anchor may dramatically alter the implemented security policy.
The 'cert-data' node uses the NACM 'default-deny-all' extension (inherited from RFC 9640 Section 3.8), restricting read access to certificate data by default.
The module is designed for access via YANG management protocols (NETCONF, RESTCONF) that have mandatory-to-implement secure transport (SSH, TLS, QUIC) and mandatory-to-implement mutual authentication. The NACM model provides access control for users.
Trust anchors configured via this module are implicitly trusted to validate certification paths for any name and any purpose. Implementations are free to use auxiliary structures to impose constraints, but no such constraints are mandated by the module itself.