Draft: anima-brski-cloud

Commentary: [ EST ] and [ RFC7030 ] are duplicates . 
 s / are / is/ That sentence is really hard to decode . Please rewrite using more words ! Please define VAR . Please define EST . Hard to parse . Maybe you mean " does not discover a local domain registrar or an owner registrar " ?
Two high level use cases are documented here.  There are more details
provided in sections redirect2Registrar and voucher2EST.  While both
use cases aid with incremental deployment of BRSKI infrastructure,
for many smaller sites (such as teleworkers) no further
infrastructure are expected.
Two high level use cases are documented here.  There are more details
provided in sections redirect2Registrar and voucher2EST.  While both
use cases aid with incremental deployment of BRSKI infrastructure,
for many smaller sites (such as teleworkers) no further
infrastructure is expected.
While a Cloud Registrar will typically handle all the devices of a
particular product line from a particular manufacturer there are no
restrictions on how the Cloud Registrar is horizontally (many sites)
or vertically (more equipment at one site) scaled.  It is also
entirely possible that all devices sold by through a particular VAR
might be preloaded with a configuration that changes the Cloud
Registrar URL to point to a VAR.  Such an effort would require
unboxing each device in a controlled environment, but the
provisioning could occur using a regular BRSKI or SZTP RFC8572
process.
A Cloud Registrar will typically handle all the devices of a
particular product line from a particular manufacturer.  This
document places no restrictions on how many different deployments or
owner sites the Cloud Registrar can handle, or how many devices per
site that the Cloud Registrar can handle.  It is also entirely
possible that all devices sold by through a particular Value Added
Reseller (VAR) might be preloaded with a configuration that changes
the Cloud Registrar URL to point to a VAR.  Such an effort would
require unboxing each device in a controlled environment, but the
provisioning could occur using a regular BRSKI or SZTP RFC8572
process.
A pledge is bootstrapping where the owner organization does not yet
have an owner registrar deployed.  The cloud registrar issues a
voucher, and the pledge completes trust bootstrap using the cloud
registrar.  The voucher issued by the cloud includes domain
information for the owner's EST service the pledge should use for
certificate enrollment.
In one use case, an organization has an EST service deployed, but
does not have yet a BRSKI capable Registrar service deployed.  The
pledge is deployed in the organization's domain, but does not
discover a local domain, or owner, registrar.  The pledge uses the
cloud registrar to bootstrap, and the cloud registrar provides a
voucher that includes instructions on finding the organization's EST
service.
A pledge is bootstrapping where the owner organization does not yet
have an owner registrar deployed.  The cloud registrar issues a
voucher, and the pledge completes trust bootstrap using the cloud
registrar.  The voucher issued by the cloud includes domain
information for the owner's Enrollment over Secure Transport (EST)
RFC7030 service the pledge should use for certificate enrollment.
In one use case, an organization has an EST service deployed, but
does not have yet a BRSKI capable Registrar service deployed.  The
pledge is deployed in the organization's domain, but does not
discover a local domain registrar or owner registrar.  The pledge
uses the cloud registrar to bootstrap, and the cloud registrar
provides a voucher that includes instructions on finding the
organization's EST service.
The pledge MUST use an Implicit Trust Anchor database (see EST) to
authenticate the cloud registrar service.  The Pledge can be done
with pre-loaded trust-anchors that are used to validate the TLS
connection.  This can be using a public Web PKI trust anchors using
RFC6125 DNS-ID mechanisms, a pinned certification authority, or even
a pinned raw public key.  This is a local implementation decision.
The pledge MUST use an Implicit Trust Anchor database (see EST
RFC7030) to authenticate the cloud registrar service.  The Pledge can
be done with pre-loaded trust-anchors that are used to validate the
TLS connection.  This can be using a public Web PKI trust anchors
using RFC6125 DNS-ID mechanisms, a pinned certification authority, or
even a pinned raw public key.  This is a local implementation
decision.