module ietf-voucher-request {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-voucher-request";
prefix "vch";
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;
description
"FIXME";
reference "RFC ????: Voucher Profile for Bootstrapping Protocols";
}
organization
"IETF ANIMA Working Group";
contact
"WG Web:
WG List:
Author: Kent Watsen
Author: Max Pritikin
Author: Michael Richardson
Author: Toerless Eckert
";
description
"This module... FIXME
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.
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
(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 "2017-10-30" {
description
"Initial version";
reference
"RFC XXXX: Voucher Profile for Bootstrapping Protocols";
}
// 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 v:voucher-artifact-grouping {
refine "voucher/created-on" {
mandatory false;
}
refine "voucher/pinned-domain-cert" {
mandatory false;
}
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 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;
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-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
populated.";
}
}
}
}
}