ietf-voucher-request.yang

module ietf-voucher-request {
  yang-version 1.1;

  namespace
    "urn:ietf:params:xml:ns:yang:ietf-voucher-request";
  prefix "vcr";

  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 vch;
    description "This module defines the format for a voucher,
        which is produced by a pledge's manufacturer or
        delegate (MASA) to securely assign a pledge to
        an 'owner', so that the pledge may establish a secure
        connection to the owner's network infrastructure";

    reference "RFC 8366: Voucher Artifact for
               Bootstrapping Protocols";
  }

  organization
   "IETF ANIMA Working Group";

  contact
   "WG Web:   <https://datatracker.ietf.org/wg/anima/>
    WG List:  <mailto:anima@ietf.org>
    Author:   Kent Watsen
              <mailto:kent+ietf@watsen.net>
    Author:   Michael H. Behringer
              <mailto:Michael.H.Behringer@gmail.com>
    Author:   Toerless Eckert
              <mailto:tte+ietf@cs.fau.de>
    Author:   Max Pritikin
              <mailto:pritikin@cisco.com>
    Author:   Michael Richardson
              <mailto:mcr+ietf@sandelman.ca>";

  description
   "This module defines the format for a voucher request.
    It is a superset of the voucher itself.
    It provides content to the MASA for consideration
    during a voucher request.

    The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
    NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
    'MAY', and 'OPTIONAL' in this document are to be interpreted as
    described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
    they appear in all capitals, as shown here.

    Copyright (c) 2019 IETF Trust and the persons identified as
    authors of the code. All rights reserved.

    Redistribution and use in source and binary forms, with or
    without modification, is permitted pursuant to, and subject
    to the license terms contained in, the Simplified BSD License
    set forth in Section 4.c of the IETF Trust's Legal Provisions
    Relating to IETF Documents
    (http://trustee.ietf.org/license-info).

    This version of this YANG module is part of RFC XXXX; see the RFC
    itself for full legal notices.";

  revision "YYYY-MM-DD" {
    description
     "Initial version";
    reference
     "RFC XXXX: Bootstrapping Remote Secure Key Infrastructure";
  }

  // Top-level statement
  rc:yang-data voucher-request-artifact {
    uses voucher-request-grouping;
  }

  // Grouping defined for future usage
  grouping voucher-request-grouping {
    description
      "Grouping to allow reuse/extensions in future work.";

    uses vch:voucher-artifact-grouping {
      refine "voucher/created-on" {
        mandatory false;
      }

      refine "voucher/pinned-domain-cert" {
        mandatory false;
        description "A pinned-domain-cert field
                     is not valid in a voucher request, and
                     any occurrence MUST be ignored";
      }

      refine "voucher/last-renewal-date" {
        description "A last-renewal-date field
                     is not valid in a voucher request, and
                     any occurrence MUST be ignored";
      }

      refine "voucher/domain-cert-revocation-checks" {
        description "The domain-cert-revocation-checks field
                     is not valid in a voucher request, and
                     any occurrence MUST be ignored";
      }

      refine "voucher/assertion" {
        mandatory false;
        description "Any assertion included in registrar voucher
              requests SHOULD be ignored by the MASA.";
      }

      augment "voucher"  {
        description
          "Adds leaf nodes appropriate for requesting vouchers.";

        leaf prior-signed-voucher-request {
          type binary;
          description
           "If it is necessary to change a voucher, or re-sign and
            forward a voucher that was previously provided along a
            protocol path, then the previously signed voucher SHOULD
            be included in this field.

            For example, a pledge might sign a voucher request
            with a proximity-registrar-cert, and the registrar
            then includes it as the prior-signed-voucher-request
            field.  This is a simple mechanism for a chain of
            trusted parties to change a voucher request, while
            maintaining the prior signature information.

            The Registrar and MASA MAY examine the prior signed
            voucher information for the
            purposes of policy decisions. For example this
            information could be useful to a MASA to determine
            that both pledge and registrar agree on proximity
            assertions. The MASA SHOULD remove all
            prior-signed-voucher-request information when
            signing a voucher for imprinting so as to minimize
            the final voucher size.";
        }

        leaf proximity-registrar-cert {
          type binary;
          description
           "An X.509 v3 certificate structure as specified by
            RFC 5280, Section 4 encoded using the ASN.1
            distinguished encoding rules (DER), as specified
            in [ITU.X690.1994].

            The first certificate in the Registrar TLS server
            certificate_list sequence  (the end-entity TLS
            certificate, see [RFC8446]) presented by the Registrar
            to the Pledge.
            This MUST be populated in a Pledge's voucher request
            when a proximity assertion is requested.";
        }
      }
    }
  }

}