Hi,
I had an additional question. Sorry if this was discussed yesterday on the call.
The suite of âusernameâ functions all make it possible for multiple user names to be defined for the CKU_USER role. The APIs make it clear how this all should
work. But what about the CKU_SO role? Is it your intent that there can only be one username for the SO role?
I could see a way to use (maybe abuse?) the new C_InitPINUserName function for an SO user to define additional usernames for the SO role. But the C_InitTokenUsername
function description makes it sound like there is only one SO username. The part of the description for initializing the token when it has not yet been initialized is clear. But the re-initialization description is worded as if there is only one SO user
name. Was this intentional?
If we wanted to support multiple SO usernames, which I think we should, then we would probably want to reword that part to validate the PIN and username against
all of the defined users. And additionally, we would need to decide if re-initialization affects any of the other SO users that are defined; or possibly leave that up to vendors to define as there are pros and cons to either approach.
Thanks
Darren
From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org>
On Behalf Of Tim Hudson
Sent: Thursday, April 27, 2023 12:00 AM
To: Dieter Bong <Dieter.Bong@utimaco.com>
Cc: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Groups - C_SetPINUser-C_InitPINUser-v2a.pdf uploaded
Interesting questions indeed - thanks for the feedback.
Can I get a sense of the TC viewpoint on extending this work item to encompase quorum based authentication - it is outside the scope of what I was looking at - but I can see how adding these interfaces could also allow for a standards based
way of handling quorum based authentication rather than the many vendor-specific approaches.
If there is sufficient interest, I can look at expanding the proposal.
On sizeof(char[])-1 compared to strlen - they should be consistent - and I was working to make them consistent without seeing the overall usage.
I do think that conceptually they really should be strlen usage rather than sizeof and the examples should be using char pointers rather than char arrays - and we should have a general discussion about that and pick one and make all the
examples consistent. I think the sizeof usage is historical and certainly not what any user of the interface will be using when working with the API - i.e. all users will not be operating out of fixed constant char arrays - so using those in our examples makes
them less "close" to the users of the APIs.
Tim,
Thank you for updating the proposal.
My thoughts regarding the questions you have raised in the Chair allocation request:
-
Return code CKR_USERNAME_INVALID or CKR_USERNAME_UNKNWON? Itâs correct that CKR_USERNAME_INVALID better matches existing return codes. But it sounds a bit like âusername is invalid because it contains invalid charactersâ. In my opinion CKR_USERNAME_UNKNOWN
better matches the meaning of this return code. Nevertheless, both are ok for me. We can have a (short) discussion in our next TC meeting and then decide.
-
New token flag CKF_USERNAME or CKF_USERNAME_REQUIRED? In case the meaning of the new token flag is CKF_USERNAME_REQUIRED, does that mean that the current functions C_InitToken, C_InitPIN, C_SetPIN, C_Login and C_LoginUser are not supported anymore by the token,
and the token returns CKR_FUNCTION_NOT_SUPPORTED when these functions are called? If thatâs the case, then behavior is the same as when trying to use new âusernameâ functions. As a consequence, should we then either have no new token flag at all, or two new
token flags CKF_USERNAME_SUPPORTED and CKF_USERNAME_REQUIRED? To be discussed â
And a few more questions and comments that may need discussion:
-
Should we have a new function C_LogoutUsername as well? Especially when implementing quorum authentication to an HSM using the C_LoginUsername functions, C_LogoutUsername may make sense. It is not required though: calling C_Logout will logout all users, and
then one can start with new C_LoginUsername again. Itâll be great to hear the opinion of other vendors.
-
Section C_InitTokenUsername, 2nd sentence: should we make (more) clear that the InitToken function applies to the SO by stating âpUsername points to the user name
of the SO, ââ?
-
I noticed that examples in your proposal use (â strlen(username) â sizeof(pin)-1â) , others use (â strlen(username) â strlen(pin)-1â). Comparing with PKCS#11 v3.1 specification, I found that only the example in C_InitToken uses strlen(), all other examples
use sizeof(). I suggest to consistently use sizeof() in all examples, and update the example in C_InitToken to use sizeof() as well.
Best regards,
Dieter
Submitter's message
Update version incorporating requested changes.
-- Tim Hudson
Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0,
www.utimaco.com
Seat: Aachen â Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Stefan Auerbach, Martin Stamm, Hacan Tiwemark
This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.
|