Draft: dtbootstrap-anima-keyinfra

Commentary: I 'd like to sync this in as it aligns BRSKI with current voucher doc
BRSKI addresses these issues by defining "voucher" and automation
extensions to the EST protocol.
BRSKI addresses these issues by defining extensions to the EST
protocol for the automated distribution of vouchers.
Signing the request is RECOMMENDED if the Pledge has sufficient
processing to perform the crypto operations.  Doing so allows the
Registrar and MASA to confirm the "proximity" assertion of the
Pledge.
The voucher request MAY contain an assertion of "proximity".
In a Pledge voucher request this is the Registrar certificate as
extracted from the TLS handshake (for example the first
certificate in the TLS 'certificate_list' sequence (see RFC5246).
This MUST be populated in a Pledge's voucher request if the
"proximity" assertion is populated.
All other fields MAY be ommitted in a voucher request.
The Registrar validates the client identity as described in EST
RFC7030 section 3.3.2.  The registrar performs authorization as
detailed in Section 3.3.2.  If authorization is successful the
Registrar obtains an Voucher from the MASA service (see
RequestVoucherFromMASA).
The received voucher request is forwarded to the Pledge.
Signing the request is RECOMMENDED if the Pledge has sufficient
processing to perform the crypto operations.  Doing so allows the
Registrar and MASA to confirm the 'proximity' assertion of the
Pledge.  If the request is signed the Registrar MAY confirm the
'proximity' asserion and associated 'pinned-domain-cert' are correct.
If these fields are not correct the Registrar SHOULD terminate the
bootstrapping attempt.
The Registrar validates the client identity as described in EST
RFC7030 section 3.3.2.  The registrar performs authorization as
detailed in Section 3.3.2.  If authorization is successful the
Registrar obtains an Voucher from the MASA service (see
RequestVoucherFromMASA) and returns that MASA signed voucher to the
pledge as described in VoucherResponse.
The request format is a JSON object optionally containing the nonce
value (as obtained from the bootstrap request) and the X.509 IDevID
extracted serial number (the full certificate is not needed and no
proof-of-possession information for the device identity is included).
The AuthorityKeyIdentifier value from the certificate is included to
ensure a statistically unique identity.  The Pledge's serial number
is extracted from the X.509 IDevID.  See IDevIDextension.
The request format is a JSON object optionally containing the nonce
value (as obtained from the Pledge voucher request) and the X.509
IDevID extracted serial number (the full certificate is not needed
and no proof-of-possession information for the device identity is
included).  The idevid-issuer value from the pledge certificate is
included to ensure a statistically unique identity.  The Pledge's
serial number is extracted from the X.509 IDevID.  See
IDevIDextension.  If the pledge provided a signed voucher request
then this SHOULD be included in the prior-signed-voucher field of the
Registrar's voucher request.
A Registrar MAY exclude the nonce from the request.  Doing so allows
the Registrar to request a Voucher when the Pledge is not online, or
when the target bootstrapping environment is not on the same network
as the MASA server (this requires the Registrar to learn the
appropriate DevIDSerialNumber field from the physical device labeling
or from the sales channel -- how this occurs is out-of-scope of this
document).  If a nonce is not provided the MASA server MUST
authenticate the Registrar as described in EST RFC7030 section 3.3.2
to reduce the risk of DDoS attacks.  The MASA performs authorization
as detailed in AcceptingTheEntity.
A Registrar MAY exclude the nonce from the request.  Doing so allows
the Registrar to request a Voucher when the Pledge is not online, or
when the target bootstrapping environment is not on the same network
as the MASA server (this requires the Registrar to learn the
appropriate DevIDSerialNumber field from the physical device labeling
or from the sales channel -- how this occurs is out-of-scope of this
document).  If a nonce is not provided the MASA server MUST
authenticate the Registrar as described in EST RFC7030 section 3.3.2
to reduce the risk of DDoS attacks and provide an authenticated
identity as an input to sales channel integration and authorizations
(out-of-scope of this document).
is an authorized Registrar of the unauthenticated domain.
is an authorized Registrar of the unauthenticated domain.  The MASA
server MAY verify that the Registrar's signed voucher includes the
'prior-signed-voucher' field populated with a voucher, signed by the
Pledge, that includes a pinned-domain-cert that is consistent with
the Registrar certificate chain.  The MASA server is aware of which
Pledge's support signing of their voucher requests and can use this
information to confirm proximity of the Pledge with the Registrar.
The voucher response to requests from the device and requests from a
Registrar are in the same format.  A Registrar either caches prior
MASA responses or dynamically requests a new Voucher based on local
policy.
The voucher response to requests from the Pledge and requests from a
Registrar are in the same format.  A Registrar either caches prior
MASA responses or dynamically requests a new Voucher based on local
policy.
The 'trusted-ca-certificate' element of the voucher contains the
domain CA's public key.  This is useful for bootstrapping a public
key infrastructure but to support bootstrapping other key
infrastructures additional domain identity types might be defined in
the future.
The pledge's EST clients MUST be prepared to ignore additional fields
they do not recognize.
the pledge MUST be prepared to parse and fail gracefully from an
Voucher response that does not contain a 'trusted-ca-certificate'
field at all.
The Pledge MUST use the 'trusted-ca-certificate' trust anchor to
immediately complete authentication of the provisional TLS
connection.
If a Registrar's credentials can not be verified using the trusted-
ca-certificate trust anchor from the voucher then the TLS connection
is immediately discarded and the Pledge abandons attempts to
bootstrap with this discovered registrar.  The pledge SHOULD send
voucher status telemetry (described below) before closing the TLS
connection.  The pledge MUST attempt to enroll using any other
proxies it has found.  It SHOULD return to the same proxy again after
attempting with other proxies.  Attempts should be attempted in the
exponential backoff described earlier.  Attempts SHOULD be repeated
as failure may be the result of a temporary inconsistently (an
inconsistently rolled Registrar key, or some other mis-
configuration).  The inconsistently could also be the result an
active MITM attack on the EST connection.
To ensure that the trusted-ca-certificate provide chain is able to
verify, the Registrar MUST use a certificate that chains to the
trusted-ca-certificate.
The Pledge's PKIX path validation of a Registrar certificate's
validity period information is as described in timeunknown.  Beyond
that once PKIX path validation is successful the TLS connection is no
longer provisional.
The trusted-ca-certificate is installed as an Explicit Trust Anchor
for future operations.  It can therefore can be used to authenticate
any dynamically discovered EST server that contain the id-kp-cmcRA
extended key usage extension as detailed in EST RFC7030 section
3.6.1; but to reduce system complexity the Pledge SHOULD avoid
additional discovery operations.  Instead the Pledge SHOULD
communicate directly with the Registrar as the EST server for future
key management operations.  The 'trusted-ca-certificate' is not a
complete distribution of the EST section 4.1.3 CA Certificate
Response which is an additional justification for the recommendation
to proceed with EST key management operations.
The 'pinned-domain-cert' element of the voucher contains the domain
CA's public key.  The Pledge MUST use the 'pinned-domain-cert' trust
anchor to immediately complete authentication of the provisional TLS
connection.
The Pledge MUST be prepared to parse and fail gracefully from an
Voucher response that does not contain a 'pinned-domain-cert' field.
The Pledge MUST be prepared to ignore additional fields it does not
recognize.
If a Registrar's credentials can not be verified using the pinned-
domain-cert trust anchor from the voucher then the TLS connection is
immediately discarded and the Pledge abandons attempts to bootstrap
with this discovered registrar.  The pledge SHOULD send voucher
status telemetry (described below) before closing the TLS connection.
The pledge MUST attempt to enroll using any other proxies it has
found.  It SHOULD return to the same proxy again after attempting
with other proxies.  Attempts should be attempted in the exponential
backoff described earlier.  Attempts SHOULD be repeated as failure
may be the result of a temporary inconsistently (an inconsistently
rolled Registrar key, or some other mis-configuration).  The
inconsistently could also be the result an active MITM attack on the
EST connection.
The Registrar MUST use a certificate that chains to the pinned-
domain-cert as its TLS server certificate.
The Pledge's PKIX path validation of a Registrar certificate's
validity period information is as described in timeunknown.  Once the
PKIX path validation is successful the TLS connection is no longer
provisional.
Not verifying ownership before responding with an Voucher.  This
is expected to be a common operational model because doing so
relieves the vendor providing MASA services from having to track
ownership during shipping and supply chain and allows for a very
low overhead MASA service.  A Registrar uses the audit log
information as a defense in depth strategy to ensure that this
does not occur unexpectedly (for example when purchasing new
equipment the Registrar would throw an error if any audit log
information is reported).
Not verifying ownership before responding with an Voucher.  This
is expected to be a common operational model because doing so
relieves the vendor providing MASA services from having to track
ownership during shipping and supply chain and allows for a very
low overhead MASA service.  A Registrar uses the audit log
information as a defense in depth strategy to ensure that this
does not occur unexpectedly (for example when purchasing new
equipment the Registrar would throw an error if any audit log
information is reported).  The MASA should verify the 'prior-
signed-voucher' information for Pledge's that support that
functionality.  This provides a proof-of-proximity check that
reduces the need for ownership verification.
The MASA server is exposed to DoS attacks wherein attackers claim an
unbounded number of devices.  Ensuring a Registrar is representative
of a valid vendor customer, even without validating ownership of
specific Pledge devices, helps to mitigate this.  Pledge signatures
on the initial voucher request, as forwarded by the Registrar in the
prior-signed-voucher field, significantly reduce this risk by
ensuring the MASA can confirm proximity between the Pledge and the
Registrar making the request.  This mechanism is optional to allow
for constrained devices.