View Issue Details

IDProjectCategoryView StatusLast Update
000342910000-004: ServicesSpecpublic2016-12-20 16:57
Reportervmonfort Assigned ToMatthias Damm  
PrioritynormalSeveritymajorReproducibilityN/A
Status closedResolutionfixed 
Product Version1.02 
Summary0003429: (v 1.03) 5.5.2.1/6.1.4/Fig.22 Session services: Contradiction on certificate properties and validation
Description

5.5.2.1 requires ("shall verify") that certificates used for OpenSecureChannel service and Session services are the same and the "Application Instance Certificates" whereas 6.1.4 indicates it might not be the case which is in contradiction.

5.5.2.1:
"The Certificates used in the OpenSecureChannel service shall be the Application Instance Certificates. Clients and Servers shall verify that the same Certificates were used in the CreateSession and ActivateSession services. Certificates are not provided and shall not be verified if the securityPolicyUri is None."

6.1.4:
"In many cases, the Certificates used to establish the SecureChannel will be the Application Instance Certificates. However, some Communication Stacks might not support Certificates that are specific to a single application. Instead, they expect all communication to be secured with a Certificate specific to a user or the entire machine. For this reason, OPC UA Applications will need to exchange their Application Instance Certificates when creating a Session."

Additional Information

I then don't catch the explanation provided by 6.1.4, is there another reason to provide those certificates for session services ? And to validate those certificates as indicated in Fig. 22 since it could then just be checked that there are the same as indicated in 5.5.2.1 ?

TagsNo tags attached.
Commit Version
Fix Due Date

Relationships

duplicate of 0003440 closedMatthias Damm 6.7.4 (Table 35) Fix text 

Activities

vmonfort

2016-06-01 08:08

reporter   ~0006974

Hello,

Sorry but I think there is a misunderstanding, the "duplicated" ticket 3440 is dealing with inconsistencies between part 6 and part 4 but this ticket is dealing with inconsistencies between 2 sections of part 4. Moreover the section §6.7.4 of part 6 has nothing to do with §6.1.4 of part 4 I pointed out and the "shall" formulation of part 4 should not be overridden by another statement since it is a requirement due to its formulation.

Note: I also noted that §5.2.2 in Part 2 indicates the same thing as pointed out in §6.1.4 part 4

vmonfort

2016-06-27 07:14

reporter   ~0007032

Hello,

I am still waiting for a clarification on the specification regarding this point and duplicate classification should be removed since 0003440 issue is not related to this issue.

I am looking forward for your analysis and answer,
Regards.

vmonfort

2016-07-20 11:27

reporter   ~0007112

Hi,

Is there any progress in the ticket analysis ?

Best regards.

Jim Luth

2016-08-24 13:46

administrator   ~0007159

Hello Jim,
First, thank you for your answer and the meeting recording link. I can see you really discussed with interest about the issue I opened.
I listened carefully the recording and I caught the following statements:
1) Authentication of application should be considered independent of Secure Channel services (which means application authentication is done in Session services)
2) It is not mandatory that the implementation of secure channels complies with part 4 specification
3) Since the secure channels are implemented by the communication stack, part 4 statements are optional because part 6 overrides part 4

Concerning my opened issue I conclude the following:
A) From statement 1) it seems that it is not mandatory that secure channel uses application certificates therefore I would:

  • Change the (v1.03) part 4 §5.5.2.1 sentence:
    "The Certificates used in the OpenSecureChannel service shall be the Application Instance Certificates." replacing "shall" by "should" or "may".
  • Move the next sentence (in same paragraph) from the "Secure Channel service set" (§5.5) to "Session service set" (§5.6) since it then seems to be more an internal constraint of Session service set as stated in 1): "Clients and Servers shall verify that the same Certificates were used in the CreateSession and ActivateSession services."
    B) Statement 2) is an issue if we want to make communicate different communication stacks with each others but I cannot fight with facts if it is the case with some implementations.
    C) I understand that issue 0003429 has been marked as duplicated from 0003440 because of statement 3). The problem is that issue 0003429 is between 2 statements of part 4 (§5 "Secure Channel service set" and §6.1 "Services behavior" - "Security") and does not reference part 6 at all. That's why I am afraid that issue 0003429 will be forgotten since it will not be affected by the resolution of 0003440.

To conclude, I think the resolution A) is sufficient to close my issue 0003429 and to have coherent statements in part 4 (v1.03). As a consequence I think it is not necessary that I participate to one of your meetings. However, I would be pleased to join you if you wish to discuss the matter.
Best regards,
Vincent Monfort

Matthias Damm

2016-12-20 16:56

developer   ~0007670

Changed text in 5.5.2.1 to
If the protocol defined in Part 6 requires that Certificates used in the OpenSecureChannel service be the Application Instance Certificates, Clients and Servers shall verify that the same Certificates are used in the CreateSession and ActivateSession services. Certificates are not provided and shall not be verified if the securityPolicyUri is None.

Made changes in document version OPC UA Part 4 - Services 1.04 Specification Draft 06.docx

Jim Luth

2016-12-20 16:57

administrator   ~0007671

Agreed to text edited in the telecon.

Issue History

Date Modified Username Field Change
2016-05-11 15:24 vmonfort New Issue
2016-05-31 16:54 Jim Luth Relationship added duplicate of 0003440
2016-05-31 16:54 Jim Luth Assigned To => Matthias Damm
2016-05-31 16:54 Jim Luth Status new => assigned
2016-05-31 16:55 Jim Luth Target Version => 1.04
2016-06-01 08:08 vmonfort Note Added: 0006974
2016-06-27 07:14 vmonfort Note Added: 0007032
2016-07-20 11:27 vmonfort Note Added: 0007112
2016-08-24 13:46 Jim Luth Note Added: 0007159
2016-12-20 16:56 Matthias Damm Note Added: 0007670
2016-12-20 16:56 Matthias Damm Status assigned => resolved
2016-12-20 16:56 Matthias Damm Resolution open => fixed
2016-12-20 16:57 Jim Luth Note Added: 0007671
2016-12-20 16:57 Jim Luth Status resolved => closed
2016-12-20 16:57 Jim Luth Fixed in Version => 1.04