Log In
Register
Forum
Topic RSS
12:25, EEST
May 25, 2016
Offline
Hi,
I would like to get clarified about the following points,
1. The authorityKeyIdentifier extension field of the application instance certificate, according to specifications, Part 6 Mappings in table 23, it has been mentioned that the extension should be specified for self signed certificates, in this case the subjectKeyIdentifier and authorityKeyIdentifier values will be same so the purpose of specifying authorityKeyIdentifier extension is same as for any other certificate which is not self signed or there are any different use case?
2. Why the private key is also loaded for user identity token type X509 certificate, since I am trying to understand the protocol kindly correct me for any mistakes.
Thanks
Gajasri
14:35, EEST
April 17, 2013
Offline
Hello Gajasri,
Thank you for the very good questions.
1. The wording in the mentioned part 6 of OPC UA specification is:
It shall be specified for Certificates signed by a CA. It should be specified for self-signed Certificates.”
On the other hand, in the RFC3280 which originally specifies the X509 certificate fields, the wording is
“The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction. There is one exception; where a CA distributes its public key in the form of a “self-signed” certificate, the authority key identifier MAY be omitted”
The OPC UA specification uses word “should be specified” and the RFC uses “may be omitted”. The SubjectKeyIdentifier and AuthorityKeyIdentifier are identical in the case of self-signed certificates, but it’s not wrong in any way to always provide the AuthorityKeyIdentifier.
There’s also no special ‘different use case’ for this field in the OPC UA applications.
I believe that this was an informational question. If you have some practical problems related to the AuthorityKeyIdentifier field, please let us know.
2. The client uses the private key of the user identity to provide a signature which is then validated by the server using the public key of the user identity. I’m going to answer this question by quoting OPC UA specification version 1.03, part 4, page 26:
When a Client provides a user identity then it shall provide proof that it is authorized to use that user identity. The exact mechanism used to provide this proof depends on the type of the UserIdentityToken. If the token is a UserNameIdentityToken then the proof is the password that is included in the token. If the token is an X509IdentityToken then the proof is a signature generated with private key associated with the Certificate.
Let me know in case there was any misunderstanding or if you have further questions.
16:49, EEST
May 25, 2016
Offline
Hello Heikki Tahvanainen,
Thank you so much for the timely reply.
I am clear with the first point.
I have another question about my second query now,
I also saw about the userTokenSignature in the specification as you mentioned and in the Activate Session request parameters. Now in real time automation systems when a device is configured with user authentication details, it has to be provided with both the certificate and private key(for user identity token type certificate similar to the application instance certificate), is my understanding right ?
And the protection of the private key is done by the asset owner, like he can use a secure element to store the private key. Kindly clarify.
Thanks
Gajasri
22:27, EEST
April 17, 2013
Offline
Hi,
Storing and protecting the private keys is somewhat outside the scope of OPC UA specification. Also, this is a little bit application specific.
In the Prosys OPC UA Java SDK, there’s an example certificate validator implementation which stores the public and private keys in the file system. It’s application specific if this is secure enough for you or not. If you want to use another implementation, you can override the default one.
Of course, it’s also good to notice that you only need to store the private key on the OPC UA client host. The server only needs to know (and trust) the public key in order to verify the client credentials.
Most Users Ever Online: 1919
Currently Online:
30 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 726
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1529
Posts: 6471
Newest Members:
gabriellabachus, Deakin, KTP25Zof, Wojciech Kubala, efrennowell431, wilfredostuart, caitlynfajardo, jeromechubb7, franciscagrimwad, adult_galleryModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1032, Jimmy Ni: 26, Matti Siponen: 349, Lusetti: 0
Administrators: admin: 1
