Draft: anima-brski-cloud

Commentary: what is the " EST  " ? It is not defined so far . Would n't it be better to use RFC 8995 terminology of " EST server " ? So if the cloud Registrar supplies the  and that redirects to an owner 's EST server , we can call that " EST server " or " owner EST server " . It 's not a Registrar , so not " EST  " or " owner  " . The latter term is already used for the server that provides a voucher to the pledge . ( Interesting to consider that the owner 's EST server could be a Registrar i.e. handing out vouchers in theory , even if the cloud - Registrar - supporting - pledge already got its voucher from the cloud - Registrar . But let 's not say such things in the document to avoid complicating it . )
The returned voucher contains an attribute, "est-domain", defined in
redirected below.  The pledge is directed to continue enrollment
using the EST registrar found at that URI.  The pledge uses the
pinned-domain-cert from the voucher to authenticate the EST
registrar.
The returned voucher contains an attribute, "est-domain", defined in
redirected below.  The pledge is directed to continue enrollment
using the EST server found at that URI.  The pledge uses the pinned-
domain-cert from the voucher to authenticate the EST server.
At this stage, the Pledge should be able to establish a TLS channel
with the EST Registrar.  The connection may involve crossing the
Internet requiring a DNS lookup on the provided name.  It may also be
a local address that includes an IP address literal including both
RFC1918 and IPv6 Unique Local Address.  The EST Registrar is
validated using the pinned-domain-cert value provided in the voucher
as described in BRSKI section 5.6.2.  This involves treating the
artifact provided in the pinned-domain-cert as a trust anchor, and
attempting to validate the EST Registrar from this anchor only.
There is a case where the pinned-domain-cert is the identical End-
Entity (EE) Certificate as the EST Registrar.  It also explicitly
includes the case where the EST Registrar has a self-signed EE
Certificate, but it may also be an EE certificate that is part of a
larger PKI.  If the certificate is not a self-signed or EE
certificate, then the Pledge SHOULD apply RFC6125 DNS-ID validation
on the certificate against the URL provided in the est-domain
attribute.  If the est-domain was provided by with an IP address
literal, then it is unlikely that it can be validated, and in that
case, it is expected that either a self-signed certificate or an EE
certificate will be pinned.
At this stage, the Pledge should be able to establish a TLS channel
with the EST server.  The connection may involve crossing the
Internet requiring a DNS lookup on the provided name.  It may also be
a local address that includes an IP address literal including both
RFC1918 and IPv6 Unique Local Address.  The EST server is validated
using the pinned-domain-cert value provided in the voucher as
described in BRSKI section 5.6.2.  This involves treating the
artifact provided in the pinned-domain-cert as a trust anchor, and
attempting to validate the EST server from this anchor only.
There is a case where the pinned-domain-cert is the identical End-
Entity (EE) Certificate as the EST server.  It also explicitly
includes the case where the EST server has a self-signed EE
Certificate, but it may also be an EE certificate that is part of a
larger PKI.  If the certificate is not a self-signed or EE
certificate, then the Pledge SHOULD apply RFC6125 DNS-ID validation
on the certificate against the URL provided in the est-domain
attribute.  If the est-domain was provided by with an IP address
literal, then it is unlikely that it can be validated, and in that
case, it is expected that either a self-signed certificate or an EE
certificate will be pinned.
In step 4, the Pledge establishes a TLS channel with the Cloud RA/
MASA, and optionally the pledge should send a request, steps 3.a and
establish a secure TLS channel with the EST Registrar.
In step 4, the Pledge establishes a TLS channel with the Cloud RA/
MASA, and optionally the pledge should send a request, steps 3.a and
establish a secure TLS channel with the EST server.
RFC8366bis contains the two needed voucher extensions: est-domain and
additional-configuration which are needed when a client is redirected
to a local EST Registrar.
RFC8366bis contains the two needed voucher extensions: est-domain and
additional-configuration which are needed when a client is redirected
to a local EST server.