The way how mantis 0004661 is resolved is probably wrong.

I think the new wording in 7.1.2.3/7.1.2.4 contradicts what 6.7.4 says:

6.7.4 OpenSecureChannel says this:

"The ClientProtocolVersion and ServerProtocolVersion parameters are not defined in Part 4 and
are added to the Message to allow backward compatibility if OPC UA-SecureConversation
needs to be updated in the future. Receivers always accept numbers greater than the latest
version that they support. The receiver with the higher version number is expected to ensure
backward compatibility.

If OPC UA-SecureConversation is used with the OPC UA-TCP protocol (see 7.1) then the
version numbers specified in the OpenSecureChannel Messages shall be the same as the
version numbers specified in the OPC UA-TCP protocol Hello/Acknowledge Messages. The
receiver shall close the channel and report a Bad_ProtocolVersionUnsupported error if there
is a mismatch."

This means that each side sends it's highest supported protocol version and the receiver
with the higher version number is expected to ensure backward compatibility, the other
side is expected to accept versions that are higher tan the latest version they support.
And furthermore the version in the HELLO is to be checked against the version in the OSC request,
and the version in the ACK is checked against the version in the OSC response.

We implemented this check in our stack in response the the BSI security review, as you know.
Now the new wording implies the ACK has a version lower than what the server supports
and the old wording was the ACK has the version that the server supports.

In the worst case this can mean a protocol downgrade, since the server shall by the new
wording use the protocol that the client requested in the HELLO but that is unsecured,
and can be modified, respond with an ACK of the lower version, and since the client
receives the ACK with a lower version it shall also use the lower version in the encrypted
OSC request, but OTOH, now the version in the OSC request is different than the one
in the HELLO and the server shall close the connection, right?

Now the wording here is no longer compatible with the new wording in the ACK message
below:

The new wording of 7.1.2.3 HELLO message is now

"The latest version of the UACP protocol supported by the Client.
The Server may reject the Client by returning Bad_ProtocolVersionUnsupported.
If the Server accepts the connection is responsible for ensuring that it returns Messages
that conform to this version of the protocol."

and 7.1.2.4 ACK message is now

"A version of the UACP protocol supported by the Server that is less than or equal to the
the version requested in the Hello Message.
If the Client accepts the connection is responsible for ensuring that it sends Messages that
conform to this version of the protocol."

The previous wording was compatible with 6.7.4:

HELLO message:

"The latest version of the UACP protocol supported by the Client.
The Server may reject the Client by returning Bad_ProtocolVersionUnsupported.
If the Server accepts the connection is responsible for ensuring that it returns
Messages that conform to this version of the protocol.
The Server shall always accept versions greater than what it supports."

ACK message:

"The latest version of the UACP protocol supported by the Server.
If the Client accepts the connection is responsible for ensuring that it sends Messages
that conform to this version of the protocol.
The Client shall always accept versions greater than what it supports."

The old wording here was at least symmetric, and is what we implemented so far.
It should have been added a similar statement as in 6.7.4, that the Receiver with the higher
supported version is responsible to ensure backward compatibility.

And, actually we are unable to find where the current protocol version is specified,
part 4 refers to part 7 and part 6 does not say which protocol version it defines.
It is version 0, and has always been, right? Where is this version number
specified?