module ietf-cwt-voucher {

    yang-version 1.1;

    namespace
      "urn:ietf:params:xml:ns:yang:ietf-cwt-voucher";

    prefix vcwt;

    import ietf-voucher {
      prefix v;
    }

    organization "IETF 6tisch Working Group";

    contact
      "WG Web:   <http://tools.ietf.org/wg/6tisch/>
    WG List:  <mailto:6tisch@ietf.org>
    Author:   Michael Richardson
              <mailto:mcr+ietf@sandelman.ca>";

    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 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 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 "2017-12-11" {
      description "Initial version";
      reference
        "RFC XXXX: Voucher Profile for Constrained Devices";

    }


    grouping voucher-cwt-grouping {
      description
        "Grouping to allow reuse/extensions in future work.";
      uses v:voucher-artifact-grouping {
        augment voucher {
          description
            "Base the CWT voucher upon the regular one";
          leaf pinned-domain-subject-public-key-info {
            type binary;
            description
              "The pinned-domain-subject replaces the
         pinned-domain-certificate in constrained uses of
         the voucher.  The pinned-domain-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.";
          }
        }
      }
    }  // grouping voucher-cwt-grouping
  }  // module ietf-cwt-voucher