module ietf-voucher-constrained {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-voucher-constrained";
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: Esko Dijk
Author: Panos Kampanakis
";
description
"This module defines the format for a voucher, which
is produced by a pledge's manufacturer or its delegate
(MASA) to securely assign one or more pledges to an 'owner',
so that a pledge may establish 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 either a pinned Raw Public Key of the Registrar, or by a
pinned X.509 certificate of the Registrar or domain CA.
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 "2021-04-15" {
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-pubk {
type binary;
description
"The pinned-domain-pubk may replace the
pinned-domain-cert in constrained uses of
the voucher. The pinned-domain-pubk
is the Raw Public Key of the Registrar.
This field is encoded as a Subject Public Key Info block
as specified in RFC7250, in 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-domain-pubk-sha256 {
type binary;
description
"The pinned-domain-pubk-sha256 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
specification which can define a new leaf for another
hash type.";
}
}
}
}
}