Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Specific query on application instance certificate extension and private keys
May 24, 2017
12:25, EET
Avatar
Gajasri
Member
Members
Forum Posts: 6
Member Since:
May 25, 2016
sp_UserOfflineSmall 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

May 24, 2017
14:35, EET
Avatar
Heikki Tahvanainen
Moderator
Members

Moderators
Forum Posts: 402
Member Since:
April 17, 2013
sp_UserOfflineSmall 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.

May 24, 2017
16:49, EET
Avatar
Gajasri
Member
Members
Forum Posts: 6
Member Since:
May 25, 2016
sp_UserOfflineSmall 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

May 24, 2017
22:27, EET
Avatar
Heikki Tahvanainen
Moderator
Members

Moderators
Forum Posts: 402
Member Since:
April 17, 2013
sp_UserOfflineSmall 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.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online: Jouni Aro
13 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 103

pramanj: 86

ibrahim: 70

kapsl: 57

gjevremovic: 49

TimK: 41

Fransua33: 39

fred: 38

Rainer Versteeg: 32

Thomas Reuther: 31

Member Stats:

Guest Posters: 0

Members: 1160

Moderators: 15

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1048

Posts: 4416

Newest Members:

jonas.rahm, sophiekohler, zqecortney, adeletoscano947, forestgenders23, auroratrumper, ericmclain04, rblu, starlowery23194, dakotadalgety82

Moderators: Jouni Aro: 853, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 579, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Teppo Uimonen: 21, Markus Johansson: 24, Matti Siponen: 72, Lusetti: 0

Administrators: admin: 1