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:
WG List:
Author: Kent Watsen
Author: Michael H. Behringer
Author: Toerless Eckert
Author: Max Pritikin
Author: Michael Richardson
";
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)";
}
// 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 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";
}
}
}
}
}