Here is the latest proposal from Karl:

Last week we said that we would introduce an additional header to resolve the interop issue with certificates.
I wonder if this is really necessary - just for this purpose.

In 1.01 both Client and Server always had to pass their certificate, in 1.02 both "shall not send an ApplicationInstanceCertificate if the securityPolicyUri is None". Therefore we could simply add that "if the Client passes a Certificate, the Server shall return its Certificate".

Proposed ERRATA Text:

Topic: CreateSession on a SecureChannel with SecurityPolicy = None.
In OPC UA Version 1.01 the handling of instance certificates in the CreateSession Service when using SecurityPolicy None is ambiguous. While our lowest level profile does not require an instance certificate, the CreateSession service in Version 1.01 requires the exchange of certificates. Version 1.02 removes this ambiguity. As a consequence however, connectivity between 1.01 and 1.02 applications may be impacted. The following additional rules to V1.02 are introduced to minimize connectivity problems.

ERRATA for V1.02 Servers:
Servers assume that a V1.01 Client is connecting if a clientCertificate is passed in the CreateSession request. Therefore, if the clientCertificate argument is not Null, the Server should also return a serverCertificate (if it has one) rather than returning Null.
As specified, however, 1.02 Servers shall not validate the clientCertificate.
Note, that although it is allowed for embedded Servers to only support the NoSecurity profile it is recommended that these Servers still provide a self-signed certificate so that interoperability with older Clients can be achieved.

ERRATA for V1.02 Clients:
Clients can not determine whether the Server complies with version 1.01 or 1.02. Therefore, they may need two attempts to create a Session. In the first attempt, they pass Null as clientCertificate. If this fails for unknown reasons, they shall call CreateSession with a valid clientCertificate.
As specified, however, 1.02 Clients shall always ignore the serverCertificate of the CreateSession response.
Note, that although it is allowed for embedded Clients to only support the NoSecurity profile it is recommended that these Clients still provide a self-signed certificate so that the two-step connect can be executed.

Alternative:
ERRATA for V1.02 Clients:
Clients can not determine whether the Server complies with version 1.01 or 1.02. Therefore, they shall call CreateSession with a valid clientCertificate if they have one.
Clients shall always ignore the serverCertificate of the CreateSession response.
Note, that although it is allowed for embedded Clients to only support the NoSecurity profile it is recommended that these Clients still provide a self-signed certificate so that interoperability with older Servers can be achieved.

Perhaps the following sentence at the end of the last paragraph in 5.5.2 may need some slight rewording:

[current]
"Clients and Servers shall verify that the same Certificates were used in the CreateSession and ActivateSession services."

[proposed]
"Clients and Servers shall verify that the same Certificates were used in the CreateSession and ActivateSession services if security is used, i.e. not set to 'None'."

Randy to add errata to forum. The we will assign for fix in Part 4.

Added errata:

http://www.opcfoundation.org/forum/viewtopic.php?p=17511#17511

CMPWG Nov-8-2012:

The errata needs to reference multiple areas of the spec, including OpenSecureChannel (in addition to CreateSession).

The errata needs to be describe the scenarios where certificates will be returned, and when they will be omitted. The use of Liam's truth-table would be ideal.

Most importantly, the CMPWG has test-cases and UACTT-scripts that require the specific details of the server behavior for when:
The client issues a certificate, but the server doesn't have a certificate.

In the above case, what should the server do?
a. return null
b. return a copy of the client's certificate
c. return a ByteString with "hello world" as the text

I will do some testing with the scenarios above and will update this issue with those findings. This will happen before the next meeting.

The 1.02 specs state that for GetEndpoints service call, the server should not return a certificate "If the securityPolicyUri is NONE and none of the UserTokenPolicies requires encryption".

The clients created with the SDK have a null check for the returned server certificates (by GetEndpoints), when using http transport protocol, therefor the "older" clients will be incompatible with the "new" servers on HTTP.

Added text based on proposed errata to CreateSession parameters clientCertificate, serverCertificate and serverEndpoints .
Resolved in document IEC 62541-4 - Services [Pre-CDV] 1.02.02.doc

Revised decision

Modified original changes from 1.02

GetEndpoints:
If the securityPolicyUri is NONE and none of the UserTokenPolicies requires encryption,
Removed: the Server shall not send an ApplicationInstanceCertificate and
Kept: the Client shall ignore the ApplicationInstanceCertificate

OpenSecureChannel Request - clientCertificate
If the securityPolicyUri is None,
Removed: the Client shall not send an ApplicationInstanceCertificate and
Kept: the Server shall ignore the ApplicationInstanceCertificate.

CreateSession Request - clientCertificate
If the securityPolicyUri is None,
Removed: the Client shall not send an ApplicationInstanceCertificate and
Kept: the Server shall ignore the ApplicationInstanceCertificate.

CreateSession Response - serverCertificate
If the securityPolicyUri is NONE and none of the UserTokenPolicies requires encryption,
Removed: the Server shall not send an ApplicationInstanceCertificate and
Kept: the Client shall ignore the ApplicationInstanceCertificate

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

Reviewed Errata and agreed to changes made in the meeting.