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: A 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) 2021 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
     (https://trustee.ietf.org/license-info).

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

    revision "2021-05-20" {
      description "Initial version";
      reference
        "RFC 8995: Bootstrapping Remote Secure Key Infrastructure
        (BRSKI)";

    }

    rc:yang-data "voucher-request-artifact";

    uses voucher-request-grouping;

    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 the 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 X.690.

             The first certificate in the registrar TLS server
             certificate_list sequence (the end-entity TLS
             certificate; see RFC 8446) presented by the registrar
             to the pledge.  This MUST be populated in a pledge's
             voucher-request when a proximity assertion is
             requested.";
            reference
              "ITU X.690: Information Technology - ASN.1 encoding
              rules: Specification of Basic Encoding Rules (BER),
              Canonical Encoding Rules (CER) and Distinguished
              Encoding Rules (DER)
               RFC 5280: Internet X.509 Public Key Infrastructure
              Certificate and Certificate Revocation List (CRL)
              Profile
               RFC 8446: The Transport Layer Security (TLS)
              Protocol Version 1.3";

          }
        }
      }
    }  // grouping voucher-request-grouping
  }  // module ietf-voucher-request