RFC 7030 (Enrolment over Secure Transport or EST) defines a mechanism for the distribution of Certificates to devices. This appendix summarizes the capabilities provided by EST and how the same capabilities are provided by the CertificateManager defined in Clause 7.

In EST a web operation returns the CA certificates. In OPC UA the CA Certificates are returned when the CertificateManager client reads the Trust List assigned to the application from the CertificateManager. Prior to these operations the Client should verify that the server is authorized to provide CAs. Table 75 compares how EST clients verify the EST server with how CertificateManager clients verify a CertificateManager.

Table 75 – Verifying that a Server is allowed to Provide Certificates

EST	OPC UA
Compare the URL for the EST server with the HTTPS certificate returned in the TLS handshake.	Compare the URL for the CertificateManager with the OPC UA Certificate returned in GetEndpoints.
Preconfigure the client to trust the EST Server’s HTTPS certificate.	Preconfigure the client by adding the CertificateManager Certificate to the client Trust List.
Manual approval of the CA Certificate after comparing the certificate with out of band information.	Manual approval of the CertificateManager Certificate after comparing the Certificate with out of band information.
Pre-shared credentials for use with certificate-less TLS.	No equivalent.

In EST a web operation is used to enrol a client. The EST server authenticates and authorizes the EST client before allowing the operation to proceed. In OPC UA, a Method is used to request a Certificate. The CertificateManager also authenticates and authorizes the client before allowing the operation to proceed. Table 76 compares how EST servers verify the EST client with how a CertificateManager verifies a CertificateManager client.

Table 76 – Verifying that a Client is allowed to request Certificates

EST	OPC UA
TLS with a client certificate which is previously issued by the EST server.	The CertificateManager client has a previously certificate previously issued by the GDS.
TLS with a previously installed certificate which is trusted by the EST server.	The CertificateManager client has a certificate which is trusted by the CertificateManager.
Shared credentials distributed out of band which are used for certificate-less TLS.	No equivalent.
HTTPS username/password authentication.	The CertificateManager client provides appropriate user credentials when it establishes the session.

In EST a certificate issued by the EST server can be used to as an HTTPS client certificate. This can be used to authorize the re-issue of the certificate. In OPC UA a certificate issued by the GDS can be used to establish a secure channel. This would then allow the GDS client to request that the certificate be re-issued.

In both EST and OPC UA clients can fall back to the authentication mechanisms used for Initial Enrolment if it is not possible to use the current certificate to establish a secure channel with the server.

Both EST and OPC UA allow clients to request new private keys. Both specifications require that encryption be used when returning private key data.

EST allows clients to explicitly request that separate encryption be applied to the private key. The algorithms are specified in the CSR (certificate signing request).

OPC UA allows clients to password protect the key (which uses encryption), however, OPC UA does not allow the client to directly specify the algorithm used. That said, the envelope used to transport private keys can be specified with the PrivateKeyFormat parameter and the set of envelope formats supported by the CertificateManager is published in the Address Space. It is expected that the envelope format will specify the algorithms used either by explicitly encoding the algorithm within the envelope or as part of the definition of the envelope.

EST allows the client to request the list of CSR attributes the EST server supports. The attributes can indicate what additional metadata the client can provide or the algorithms that will be used.

In OPC UA the CSR metadata required is fixed by the specification and there is no mechanism to publish extensions. Clients are free to include additional metadata in the CSR, however, the CertificateManager may ignore it.

There is no mechanism in OPC UA to publish the algorithms which need to be used for the CSR, however, the CertificateManager will reject CSRs that do not meet its requirements.

______________