The GDS is expected to update the trustlist first with the CA and the new CRL.

If the UpdateCertificate is missing a CRL needed to validate the new cert it should return applyChangesRequired=true and check if the CRL was uploaded as a separate operation.

Regarding this issue which was discussed today (Jan 10, 2024) in the Security WG meeting. I spoke with an engineer at my company on this and got a little more clarity. The proposed workflow of updating the
TrustList
first and then provisioning the
Certificate
is perfectly fine. However, the issue/question is regarding the text in Part 12. In Part 12, the
UpdateCertificate
method has a parameter "issuerCertificates", with the description "The issuer
Certificates
needed to verify the signature on the new
Certificate
". This implies that rather than using an existing
TrustList
this parameter is used to verify the
Certificate
, in which case we have this problem of not having a CRL. So I think if we want to use the workflow where an existing
TrustList
verifies the
Certificate
then we should update the spec to be clear about that.

[1:06 PM] Randy Armstrong (OPC)
The issuers argument should be deprecated with text indicating the transaction approach

The Server shall follow the validation process defined in OPC 10000-4 on the Certificate and all of the issuer Certificates. If errors occur the Bad_SecurityChecksFailed error is returned. Note that the validation process requires that the TrustList associated with the CertificateGroup already contain the Issuer Certificates and their CRLs or that the issuers support online CRL checks.