2) The provisioning process should already make it clear that the DCA and other applications running on the Device are assigned ApplicationInstance Certificates and TrustLists. This process can ensure the applications can connect to the SKS.

I am reading OPC-10000-14 PubSub V1.05.06.

Section "5.4.5.3 Key acquisition handshakes" states:

"The Publisher or Subscriber use keys provided by a Security Key Service (SKS) to secure messages exchanged via the Message Oriented Middleware. [...] To pull keys, the Publisher or Subscriber creates an encrypted connection and provides credentials that allow it access to the SecurityGroup."

Pushing the keys via the SetSecurityKeys Method also talks about the establishment of this encrypted connection between SKS and key-target.

My Question: are there any details on how exactly this encrypted connection is to be established? Is this like the default OPC UA secure channel between Client and Server that is mutually authenticated with Application Instance Certificates? Meaning, prior to using PubSub, any Publisher/Subscriber needs to connect with an SKS via Client/Server secure channel to get the keys for subsequent PubSub use? If this is so, then would the onboarding procedure described in OPC-10000-21 to provision new applications with Application Instance Certificates also apply to devices wishing to use the PubSub architecture? Do Publishers and Subscribers need an Application Instance Certificate? Or does PubSub specify a different onboarding procedure to establish the initial trust anchor for new devices?

I'd appreciate any clarification 🙂

In Pull Management (Section 7.2), the DCA calls

on the Registrar to register managed Applications and obtain their ApplicationIds. The Registrar decides whether the DCA has the authorization to manage these Applications.

In Push Management, Section 7.3 describes that the CertificateManager can discover Applications through

objects exposed in the DCA's AddressSpace and push Certificates and TrustLists for those Applications.

My question is: How does the CertificateManager in Pull management know which Applications the DCA is actually authorized to manage?

I'd appreciate any clarification.

We are moving to a policy of always including the prefix 0: in specs to make it really obvious what is intended.

The concept of "define a name but not the namespace" does not exist in OPC UA. There may be rare examples but they have to explicitly call that out. If the spec is silent then BrowseName defined always means fixed Namespace.

https://mantis.opcfoundation.o.....p?id=11508

What the first connection with the DCA should use an IDevID as a client cert and the Registrar should accept it as untrusted.

i.e. authenticated but without trust.

The next steps establish trust.

Needs a mantis issue against Part21: 

https://mantis.opcfoundation.o.....default=no

I am reading OPC-10000-21 V1.05.04.

Section "7.1 - Overview" states:

"When using PullManagement (7.2) the DCA connects to the Registrar without security and calls the ProvideIdentities Method."

In section "7.2 Pull Management", the flow chart diagram in "Figure 4" makes it seem like "ProvideIdentities" is indeed called without security and the "Create SecureChannel" occurs at a later time.

However, section "9.2.3 ProvideIdentities" states:

"This Method shall be called from an authenticated SecureChannel."

Am I overlooking something or is this an inconsistency in the specification?

For "0:NodeVersion" (https://reference.opcfoundatio.....-40540/6.3) this rule is explicitly mentioned in the spec, should this also be changed to explicit "0:FileSystem" (https://reference.opcfoundatio.....0-20/4.3.2) to avoid confusion?

And for the BrowseName under the Objects (i=85) folder: Should we use 0:FileSystem or <instanceNs>:FileSystem (e.g. 5:FileSystem, when 5 is our FileSystem namespace)?

Clients can only detect if a Server supports the File Transfer - File System Spec by browsing the Objects-Folder (i=85) and filtering for *:FileSystem results, right?

Need to add IsDesignTool which will make it clear why it is not referenced.

You should never use i=16314

when to use the FileSystem NodeId i=16314 for a FileSystem instance? Is it reserved for FileSystem instances referenced directly under the Objects (i=85) folder?

The spec says, that the BrowseName has to match "<ns>:FileSystem" (not even restricts it to "0:FileSystem") but it does not define the standard NodeId (i=16314):

The Object representing the root of a file directory structure shall have the BrowseName FileSystem. An OPC UA Server may have different FileSystem Objects in the AddressSpace. HasComponent is used to reference a FileSystem from aggregating Objects like the Objects Folder or the Object representing a device.

The Opc.Ua.NodeSet2.xml contains this NodeId, but is not referenced:

<UAObject NodeId="i=16314" BrowseName="FileSystem">

Best regards,

Thomas