Delegated Authority for Bootstrap Voucher Artifacts

1.1. Requirements for the Delegation

This voucher artifact satisfies the following requirements:¶

1.2. Overview of Proposed Solution

The MASA will issue a voucher that delegates it's signing authority for one or more devices to a specific Registrar. This is called a "delegation voucher".¶

This Registrar can then operate as an authorized signing authority for the manufacturer, and can subsequently issue additional vouchers binding the pledge to new Registrars.¶

This delegation can potentially be repeated multiple times to enable second, third, or n-th level of resale.¶

The delegation voucher may be stored by the pledge for storage, to be included by the pledge in subsequent bootstrap operations. The inclusion of the delegation voucher permits next Registrar with heuristics that permit it to find the delegated authorized signing authority (DASA).¶

The delegation voucher pins the identity of the delegated authority using a variety of different mechanisms which are covered in Section 7.¶

3.1. YANG Module

This module uses the grouping that was created in [RFC8366] to extend the definition.¶

<CODE BEGINS> file "ietf-voucher-delegated@2020-01-06.yang"

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

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

  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";
  }

  // maybe should import from constrained-voucher instead!
  import ietf-voucher {
    prefix "v";
  }

  organization
   "IETF ANIMA Working Group";

  contact
   "WG Web:   <http://tools.ietf.org/wg/anima/>
    WG List:  <mailto:anima@ietf.org>
    Author:   Michael Richardson
              <mailto:mcr+ietf@sandelman.ca>";

  description
  "This module extends the RFC8366 voucher format to provide
   a mechanism by which the authority to issue additional vouchers
   may be delegated to another entity

   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 BCP 14 RFC 2119, and RFC8174.";

  revision "2020-01-06" {
    description
     "Initial version";
    reference
     "RFC XXXX: Voucher Profile for Delegation Vouchers";
  }

  rc:yang-data voucher-delegated-artifact {
    // YANG data template for a voucher.
    uses voucher-delegated-grouping;
  }

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

    uses v:voucher-artifact-grouping {

      refine voucher/pinned-domain-cert {
          mandatory  false;
      }

      augment "voucher" {
        description "Base the delegated voucher
                     upon the regular one";

        leaf delegation-enable-flag {
          type boolean;
          description
            "A global enable flag to the pledge that it can be
             delegated (true) or not (false). With default,
             this flag is false, which is consistent with
             the voucher artifact in RFC8366. ";
        }

        leaf pinned-delegation-cert-authority {
          type binary;
          description
            "An subject-public-key-info for a public key of the
             certificate authority that is to be trusted to issue
             a delegation voucher to the Registrar.
             This is not used by end-vouchers, and only valid
             when delegation-enable-flag is true.";
        }

        leaf pinned-delegation-cert-name {
          type binary;
          description
            "A string for the rfc822Name SubjectAltName contents
             which will be trusted to issue delegation vouchers.
             This is not used by end-vouchers, and only valid
             when delegation-enable-flag is true.";
        }

        leaf delegation-voucher {
          type binary;
          description
            "The intermediate voucher that delegates
             authority to the entity that signs this voucher
             is to be included here, and only valid
             when delegation-enable-flag is true.";
        }

        leaf intermediate-identities {
          type binary;
          description
            "A set of identities that will be needed to
             validate the chain of vouchers, and only valid
             when delegation-enable-flag is true. MAY BE REDUNDANT";
        }

        leaf delegation-countdown {
          type int16;
          description
          "Number of delegations still available, and only valid
             when delegation-enable-flag is true. If zero
           or omitted, then this is a terminal voucher and
           may not be further delegated";
        }
      }
    }
  }
}

<CODE ENDS>

3.2. Bundling of The Vouchers

[RFC8995] defines a mechanism to return a single voucher to the pledge.¶

This protocol requires a number of additional items to be returned to the pledge for evaluation: the series of Intermediate Vouchers that leads to the DASA, and the public keys (often as certificates) of the Registrars on the Delegation Path that leads to each Authority.¶

3.3. Delegation of Multiple Devices

A MASA MAY delegate multiple devices to the same Registrar by putting an array of items in the "serial-number" attributes. (XXX-how to describe this in the YANG, and the detailed mechanism, are TBD)¶

5.1. Discovering The Most Recent Delegated Authority to Use

The pledge continues to use its manufacturer issued IDevID when performing BRSKI-style onboarding. The IDevID contains an extension, the MASA URL (see [RFC8995] section 2.3.2). The IDevID certificate is not expected to be updated when the device is resold, nor may it be practical for an intermediate owner to be able to replace the IDevID with their own. (Some devices may support having an intermediate owner replace the IDevID, in which case this section does not apply)¶

The Registrar needs to be informed that it should not contact a MASA using the URL in the IDevID, but rather to contact the previous owner's DASA.¶

This can be accomplished by local override, as described in [RFC8995] section 5.4:¶

Registrars MAY include a mechanism to override
the MASA URL on a manufacturer-by-manufacturer basis, and within that
override it is appropriate to provide alternate anchors.  This will
typically used by some vendors to establish explicit (or private)
trust anchors for validating their MASA that is part of a sales
channel integration.

The above override needs to be established on a per-device basis. It requires per-device configuration which is very much non-autonomic.¶

There are two other alternatives:¶

1. The Manufacturer could be aware of any Delegation Vouchers that it has issued for a particular device, and when contacted by the Registrar, it could redirect the Registrar to its DASA. And the DASA may redirect the Registrar to its delegated DASA, this process is recursive to the final DASA.¶
2. The Pledge could provide a signed statement from the manufacturer providing the Registrar with a pointer to the DASA.¶

Option 1 requires that the Registrar still contact the MASA, violating most of the goals from Section 1.1.¶

Option 2 requires a signed artifact, and conveniently, the Delegation Voucher is exactly the item needed. The most difficult problem is that the Pledge needs to (a) store one or more Delegation Vouchers in a non-volatile storage that survives factory reset operations, (b) attach these items to the pledge's voucher-request.¶

The extension to the [RFC8995] voucher-request described below provides for a contained for these Delegation Vouchers.¶

6.1. Case 1: Resale

This case has many application scenarios.¶

The simplest is that a device, previously owned by one entity is sold to another entity. This would include many large home appliances (furnace, stove, refriderator) which are either sold with the home (because they are attached), or for which there is a frequent resale market. Entire systems (HVAC, physical security, elevators) in commercial buildings also fall into this category. Many of these devices exist for decades.¶

The initial onboarder would obtain a delegated voucher, and would keep this voucher safe. Should the device need to be resold, this voucher is provided to the new owner. This protects the first owner from situations where the manufacturer is unwilling, or goes into bankruptcy.¶

A creditor, such as a bank, which may take the property, including required systems as collatoral for a loan could require that a delegated voucher be obtained. A bank would find a building that needed new systems installed difficult to resale should the bank have to foreclose. It is likely that this requirement would make devices which do not come with delegated vouchers significant liabilities, and that financial institutions (banks, insurance companies) might refuse to lend in this case.¶

As a different example, an owner might initially start with some hosted Registrar (in the cloud perhaps, as a service). Later on, the owner wishes to bring the Registrar in-house (or just change who is providing the Registrar service). Such an activity is effectively a "resale".¶

It is common when a company goes bankrupt that many of it's assets (routers, switches, desktops, as well as furniture) are sold by the court. There are many resellers of digital equipment, and they typically take the devices, factory reset them, verify that they work, and then list them for resale. Such an entity would want to have a delegated voucher for each device. Whether the delegated voucher would be obtained from the original (bankrupt) company, by the court, or directly from the manufacturer is probably a legal problem.¶

Further, the pledges may be resaled many times, and when onboarding, they will receive all vouchers in order with the sale chain, firstly masa vouchour, then 1st intermidate, 2nd intermidate, till to the final dealer. In this case, the pledge's authorization form a signed voucher chain.¶

The following illustrates a delegation voucher for a pledge: { "ietf-voucher-delegated:voucher": { "created-on": "2020-07-14T06:28:31Z", "expire-on": "2022-07-31T01:61:80Z", "assertion": "logged", "serial-number": "JADA123456789", "delegation-enable-flag": true, "pinned-delegation-cert-authority": "base64encodedvalue", "pinned-delegation-cert-name": "base64encodedvalue", "delegation-voucher": "base64encodedvalue", "intermediate-identities": "intermediateId1", "delegation-enable-flag": 1, } }¶

6.2. Case 2: Assembly

In some application, many pledges which come from multiple component assembled by a system integrated. They need to to be assembled together in the first sale. In this time, the owner is assembly controller, so the pledge's voucher need to include these delegation options.¶

In addition, there are also transparent assembly, for example rail wagon scenario. Firstly, the assembly onboards normally to get all pledges' vouchers, then this assembly acts as intermidate registrar, who "sell" these pledges to every rail wagon registrar.¶

9.1. Delegation Vouchers do not expire

A significant feature of the [RFC8366] voucher is that it can be short-lived, and often renewed if needed. This goes along with the arguments that renewal is better than revocation explained better in [RFC8739]. However, in order for a delegated voucher to be useful it has to have a life longer than the pessimistic expected life of the manufacturer (MASA). This argues for the expiry time of a voucher to be rather long (decades), if not actually infinite.¶

[RFC8995] makes arguments for why a Pledge dos not need to have a clock that it can trust, because it can use a nonce to verify freshness of the resulting Voucher. The Delegated Voucher can not use a nonce to verify the chain of delegated vouchers presented, although it can use a nonce for the last (non-delegated) voucher.¶

10.1. The IETF XML Registry

This document registers a URI in the "IETF XML Registry" [RFC3688]. IANA is asked to register the following:¶

     URI: urn:ietf:params:xml:ns:yang:ietf-voucher-delegated
     Registrant Contact: The ANIMA WG of the IETF.
     XML: N/A, the requested URI is an XML namespace.

10.2. YANG Module Names Registry

This document registers a YANG module in the "YANG Module Names" registry [RFC6020]. IANA is asked to register the following:¶

     name:         ietf-voucher-delegated
     namespace:    urn:ietf:params:xml:ns:yang:ietf-voucher-delegated
     prefix:       NONE
     reference:    THIS DOCUMENT