Change:
what is the "EST Registrar"? It is not defined so far. Wouldn't it be better to use RFC 8995 terminology of "EST server" ? So if the cloud Registrar supplies the Voucher 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 Registrar" or "owner Registrar". 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.)

Discussion:
The returned voucher contains an attribute, "est-domain", defined in redirected below.  The pledge is directed to continue enrollment <del> using the EST registrar found at that URI.  The pledge uses the pinned-domain-cert from the voucher to authenticate the EST registrar. </del> <ins> using the EST server found at that URI.  The pledge uses the pinned- domain-cert from the voucher to authenticate the EST server. </ins> The process starts, in step 1, when the Pledge establishes a Mutual TLS channel with the Cloud RA/MASA using artifacts created during the

includes its assigned EST domain in the est-domain attribute. At this stage, the Pledge should be able to establish a TLS channel <del> with the EST Registrar.  The connection may involve crossing the </del> <ins> with the EST server.  The connection may involve crossing the </ins> Internet requiring a DNS lookup on the provided name.  It may also be a local address that includes an IP address literal including both <del> 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 </del> <ins> 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 </ins> artifact provided in the pinned-domain-cert as a trust anchor, and <del> attempting to validate the EST Registrar from this anchor only. </del> <ins> attempting to validate the EST server from this anchor only. </ins> There is a case where the pinned-domain-cert is the identical End- <del> Entity (EE) Certificate as the EST Registrar.  It also explicitly includes the case where the EST Registrar has a self-signed EE </del> <ins> Entity (EE) Certificate as the EST server.  It also explicitly includes the case where the EST server has a self-signed EE </ins> 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

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 3.b, to the Cloud RA/MASA to inform it that the Pledge was able to <del> establish a secure TLS channel with the EST Registrar. </del> <ins> establish a secure TLS channel with the EST server. </ins> The Pledge then follows that, in step 5, with an EST Enroll request with the CSR and obtains the requested certificate.  The Pledge must

RFC8366bis contains the two needed voucher extensions: est-domain and additional-configuration which are needed when a client is redirected <del> to a local EST Registrar. </del> <ins> to a local EST server. </ins> 6.