Part 6 - 6.6.4 clarifies that the certificate must be used for channel renewal. It is a spec change being requested - not a bug. A spec change that would break all existing implementations.

"The RevisedLifetime tells the Client when it shall renew the SecurityToken by sending another OpenSecureChannel request. The Client shall continue to accept the old SecurityToken until it receives the OpenSecureChannel response. The Server has to accept requests secured with the old SecurityToken until that SecurityToken expires or until it receives a Message from the Client secured with the new SecurityToken. The Server shall reject renew requests if the SenderCertificate is not the same as the one used to create the SecureChannel or if there is a problem decrypting or verifying the signature. The Client shall abandon the SecureChannel if the Certificate used to sign the response is not the same as the Certificate used to encrypt the request."

Another issue with real-time applications. It relates to sequence numbers. Part 6:
"The SequenceNumber shall be incremented by exactly one for each MessageChunk sent unless the communication channel was interrupted and re-established"
This doesn't allow to execute RSA algorithms asynchronously, because the sequence number is a part of signature. This may be solved if OpenSecureChannel uses different sequence numbers (sequences for data chunks and OpenSecureChannel chunks different)

This issue was discussed at the WG meeting last month.

There is a fix that we will not add to the spec now but it is a slight modification to the specification that can be added in the future.

Right now the the Server implementations start sending messages secured with the new token right away. This is not technically required because the Server is required to keep accepting the old token until it expires or until the client sends a message with the new token.

The Server can be changed to keep using the old token until it receives a message secured with a new token. This would allow the client to process the OpenSecureChannel response in the background.

Note: the .NET implementation could handle servers that did this. The only reason not to change the spec now is we don't know if all stack implementations can handle this so you could change your applications to do this a test it out.

The rule on sequence numbers can also be relaxed.

May be v1.02?
It's not known when v2.0 will be released. But this issue is critical for embedded implementations that supports more than several channels. For example, on the Geode platform (500 Mhz) it takes about 80 ms of pure CPU time to calculate RSA. Suppose, a device supports 20 channels and has 30% of CPU time for a network logic (70 % is a PLC logic). So we may have delay 20380 = 4.8 seconds.
If it is critical for current vendor implementations, Part 6 defines "ProtocolVersion" field.

Perhaps, only two things are required:

1. Delay usage of a new server token until the client begins to use its own new token (Part 4).
2. Remove requirements "SequenceNumber shall be incremented by exactly one" for the OpenSecureChannel message.

Discussed in Dallas F2F meeting

Proposed change in 5.5.2.1 Description
Change
b) Servers should use the existing SecurityToken to secure outgoing Messages until the SecurityToken expires or the Server receives a Message secured with a new SecurityToken.
to
b) Servers shall use the existing SecurityToken to secure outgoing Messages until the SecurityToken expires or the Server receives a Message secured with a new SecurityToken.

Check with stack implementation if this is an issue and how they implement it today.
.NET Stack does use the new token directly.

Verify with ANSI C stack + JAVA stack how they behave

Feedback ANSI C stack:
Like .NET Stack, the ANSI C stack does use the new token directly.

Change would be not trivial but possible.

Interoperability problems with existing ANSI C stack based clients are not expected.

Feedback JAVA Stack:
It will change the "active token" of the secure channel, which is used to send the responses back, only when a data package with the new token is received.

Changed should to shall
5.5.2 OpenSecureChannel
b) Servers shall use the existing SecurityToken to secure outgoing Messages until the SecurityToken expires or the Server receives a Message secured with a new SecurityToken.

Resolved in document IEC 62541-4 - Services [Pre-CDV] 1.02.06.doc

Agreed to changes in doc in telecon. Awaiting 1.02 Errata to close the issue.

Agreed to Errata changes.