module ietf-constrained-voucher { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; prefix "constrained"; import ietf-restconf { prefix rc; description "This import statement is only present to access the yang-data extension defined in RFC 8040."; reference "RFC 8040: RESTCONF Protocol"; } import ietf-voucher { prefix "v"; } organization "IETF ANIMA Working Group"; contact "WG Web: WG List: Author: Michael Richardson Author: Peter van der Stok Author: Panos Kampanakis "; description "This module defines the format for a voucher, which is produced by a pledge's manufacturer or delegate (MASA) to securely assign one or more pledges to an 'owner', so that the pledges may establis a secure connection to the owner's network infrastructure. This version provides a very restricted subset appropriate for very constrained devices. In particular, it assumes that nonce-ful operation is always required, that expiration dates are rather weak, as no clocks can be assumed, and that the Registrar is identified by a pinned Raw Public Key. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described in RFC 2119."; revision "2019-08-01" { description "Initial version"; reference "RFC XXXX: Voucher Profile for Constrained Devices"; } rc:yang-data voucher-constrained-artifact { // YANG data template for a voucher. uses voucher-constrained-grouping; } // Grouping defined for future usage grouping voucher-constrained-grouping { description "Grouping to allow reuse/extensions in future work."; uses v:voucher-artifact-grouping { refine voucher/created-on { mandatory false; } refine voucher/pinned-domain-cert { mandatory false; } augment "voucher" { description "Base the constrained voucher upon the regular one"; leaf pinned-domain-subject-public-key-info { type binary; description "The pinned-domain-subject-public-key-info replaces the pinned-domain-cert in constrained uses of the voucher. The pinned-domain-subject-public-key-info is the Raw Public Key of the Registrar. This field is encoded as specified in RFC7250, section 3. The ECDSA algorithm MUST be supported. The EdDSA algorithm as specified in draft-ietf-tls-rfc4492bis-17 SHOULD be supported. Support for the DSA algorithm is not recommended. Support for the RSA algorithm is a MAY."; } leaf pinned-sha256-of-subject-public-key-info { type binary; description "The pinned-hash-subject-public-key-info is a second alternative to pinned-domain-cert. In many cases the public key of the domain has already been transmitted during the key agreement process, and it is wasteful to transmit the public key another two times. The use of a hash of public key info, at 32-bytes for sha256 is a significant savings compared to an RSA public key, but is only a minor savings compared to a 256-bit ECDSA public-key. Algorithm agility is provided by extensions to this specifications which define new leaf for other hash types"; } } } } }