netconfcentral logo


  module ietf-voucher-request {

    yang-version 1.1;


    prefix vch;

    import ietf-restconf {
      prefix rc;
        "This import statement is only present to access
the yang-data extension defined in RFC 8040.";
        "RFC 8040: RESTCONF Protocol";

    import ietf-voucher {
      prefix v;
      description "FIXME";
        "RFC ????: Voucher Profile for Bootstrapping Protocols";


    organization "IETF ANIMA Working Group";

      "WG Web:   <>
    WG List:  <>
    Author:   Kent Watsen
    Author:   Max Pritikin
    Author:   Michael Richardson
    Author:   Toerless Eckert

      "This module... FIXME

    The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
    the module text are to be interpreted as described in RFC 2119.

    Copyright (c) 2017 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

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

    revision "2017-10-30" {
      description "Initial version";
        "RFC XXXX: Voucher Profile for Bootstrapping Protocols";


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

    uses voucher-request-grouping;

    grouping voucher-request-grouping {
        "Grouping to allow reuse/extensions in future work.";
      uses v:voucher-artifact-grouping {
        augment voucher {
            "Adds leaf nodes appropriate for requesting vouchers.";
          leaf prior-signed-voucher-request {
            type binary;
              "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 proximity voucher, which
             an intermediate registrar then re-signs to make its own
             proximity assertion.  This is a simple mechanism for a
             chain of trusted parties to change a voucher, while
             maintaining the prior signature information.

             The pledge MUST ignore all prior voucher information when
             accepting a voucher for imprinting. Other parties 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 information when signing
             a voucher for imprinting so as to minimize the final
             voucher size.";

          leaf proximity-registrar-cert {
            type binary;
              "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-T X.690.

             The first certificate in the Registrar TLS server
             certificate_list sequence  (see [RFC5246]) presented by
             the Registrar to the Pledge. This MUST be populated in a
             Pledge's voucher request if the proximity assertion is
    }  // grouping voucher-request-grouping
  }  // module ietf-voucher-request