Draft: dtbootstrap-anima-keyinfra

Commentary: i think this is ready to merge in .
This document details protocols and messages to the endpoints to
answer the above questions.  The Registrar actions derive from Pledge
identity, third party cloud service communications, and local access
control lists.  The Pledge actions derive from a cryptographically
protected "voucher" message delivered through the Registrar.
The syntactic details of vouchers are described in detail in I-
D.ietf-anima-voucher.  This document details automated protocol
mechanisms to obtain vouchers.
This document details protocols and messages to the endpoints to
answer the above questions.  The Registrar actions derive from Pledge
identity, third party cloud service communications, and local access
control lists.  The Pledge actions derive from a cryptographically
protected "voucher" message delivered through the Registrar but
originating at a Manufacturer Authorized Signing Authority.
The syntactic details of vouchers are described in detail in I-
D.ietf-anima-voucher.  This document details automated protocol
mechanisms to obtain vouchers, including the definition of a
necessary 'voucher request' message that is a minor extension to the
voucher format (see voucher-request).
The voucher request is how an entity requests a voucher.  The Pledge
forms a voucher request and submits it to the Registrar.  The
Registrar in turn submits a voucher request to the MASA server.  A
voucher request is a voucher structure with an additional "prior-
signed-voucher-request" "leaf to support forwarding the Pledge's
initial voucher request.
Unless otherwise signaled (outside the voucher artifact), the signing
structure is as defined for vouchers, see I-D.ietf-anima-voucher.
The following tree diagram illustrates a high-level view of a voucher
request document.  The notation used in this diagram is described in
I-D.ietf-anima-voucher.  Each node in the diagram is fully described
by the YANG module in voucher-request-yang-module.  Please review the
YANG module for a detailed description of the voucher request format.
This section provides voucher examples for illustration purposes.
That these examples conform to the encoding rules defined in RFC7951.
The following example illustrates a Pledge generated voucher-
request.  The assertion leaf is indicated as 'proximity' and the
Registrar's TLS server certificate is included in the 'pinned-
domain-cert' leaf.  See RequestVoucherFromRegistrar.
The following example illustrates a Registrar generated voucher-
request.  The 'prior-signed-voucher-request' leaf is populated
with the Pledge's voucher request (such as the prior example).
See RequestVoucherFromMASA.
The following example illustrates a Registrar generated voucher-
request.  The 'prior-signed-voucher-request' leaf is not populated
with the Pledge's voucher request nor is the nonce leaf.  This
form might be used by a Registrar requesting a voucher when the
Pledge is offline or when the Registrar expects to be offline
during deployment.  See RequestVoucherFromMASA.
The following example illustrates a Registrar generated voucher-
request.  The 'prior-signed-voucher-request' leaf is not populated
with the Pledge's voucher request because the Pledge did not sign
it's own request.  This form might be used when more constrained
Pledges are being deployed.  The nonce is populated from the
Pledge's request.  See RequestVoucherFromMASA.
Following is a YANG RFC7950 module formally extending the I-D.ietf-
anima-voucher voucher into the voucher request.
An example JSON payload of a voucher request from a Pledge is in
voucher-request-examples Example 1.
If the Pledge provided a signed voucher request then it SHOULD be
included in the voucher request built by the Registrar.
Example JSON payloads of voucher requests from a Registrar are in
voucher-request-examples Example 2 through 4.