OASIS PKCS 11 TC

 View Only
  • 1.  SO login into non-initialized token

    Posted 08-29-2018 13:09
    All,   maybe you ’ ve also seen this new question on StackExchange ( https://crypto.stackexchange.com/questions/61822/what-is-the-proper-return-code-for-c-login-when-a-cku-so-attempts-to-log-into-a ):   Looking at the PKCS#11 2.4 spec, C_Login returns CKR_USER_PIN_NOT_INITIALIZED when a "normal user's PIN has not yet been initialized with C_InitPIN". However, I can not find anything that would be analogous to a situation when a user calls C_Login for a CKU_SO user on a token that has not been initialized using C_InitToken.   That ’ s actually a good question IMO.   We simply return CKR_USER_PIN_NOT_INITIALIZED also in this case, but thinking about it now this doesn ’ t seem to be correct according to the description of this error code in the standard. But all other return values do not fit either.   Any opinions?   Thanks, Daniel   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: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO This communication is confidential. We only send and receive email on the basis of the terms set out at https://www.utimaco.com/en/e-mail-disclaimer/


  • 2.  RE: SO login into non-initialized token

    Posted 08-29-2018 15:25
    Hi, We do the same here… we return CKR_USER_PIN_NOT_INITIALIZED in this case.   That is unfortunate that the error code is described that way.  In hind sight, I would have preferred if the description was so that it applies to the whichever role (CKU_SO or CKU_USER) is attempting to login via C_Login. Should we consider modifying the description as such?   I agree, none of the existing error codes seem to fit this scenario.  Should we introduce CKR_SO_PIN_NOT_INITIALIZED?   I don’t have a strong opinion either way, but if I was forced to pick one, I think I prefer modifying the description.  Most of the other CKR_USER_XXX error codes apply to both roles (CKU_SO and CKU_USER).  I think this one probably should as well.   Thanks DJ   From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Daniel Minder Sent: Wednesday, August 29, 2018 9:09 AM To: pkcs11@lists.oasis-open.org Subject: [pkcs11] SO login into non-initialized token   All,   maybe you ’ ve also seen this new question on StackExchange ( https://crypto.stackexchange.com/questions/61822/what-is-the-proper-return-code-for-c-login-when-a-cku-so-attempts-to-log-into-a ):   Looking at the PKCS#11 2.4 spec, C_Login returns CKR_USER_PIN_NOT_INITIALIZED when a "normal user's PIN has not yet been initialized with C_InitPIN". However, I can not find anything that would be analogous to a situation when a user calls C_Login for a CKU_SO user on a token that has not been initialized using C_InitToken.   That ’ s actually a good question IMO.   We simply return CKR_USER_PIN_NOT_INITIALIZED also in this case, but thinking about it now this doesn ’ t seem to be correct according to the description of this error code in the standard. But all other return values do not fit either.   Any opinions?   Thanks, Daniel     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: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO This communication is confidential. We only send and receive email on the basis of the terms set out at https://www.utimaco.com/en/e-mail-disclaimer/ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.


  • 3.  RE: SO login into non-initialized token

    Posted 08-29-2018 16:43
    Hi,   the finding that most of the other CKR_USER_* codes apply to both roles is very convincing. Just extending the error description in such a way that it applies to the SO as well seems to be the easiest solution.   Thanks, Daniel     From: Johnson Darren [mailto:darren.johnson@gemalto.com] Sent: Mittwoch, 29. August 2018 17:25 To: Daniel Minder <Daniel.Minder@utimaco.com>; pkcs11@lists.oasis-open.org Subject: RE: SO login into non-initialized token   Hi, We do the same here… we return CKR_USER_PIN_NOT_INITIALIZED in this case.   That is unfortunate that the error code is described that way.  In hind sight, I would have preferred if the description was so that it applies to the whichever role (CKU_SO or CKU_USER) is attempting to login via C_Login. Should we consider modifying the description as such?   I agree, none of the existing error codes seem to fit this scenario.  Should we introduce CKR_SO_PIN_NOT_INITIALIZED?   I don’t have a strong opinion either way, but if I was forced to pick one, I think I prefer modifying the description.  Most of the other CKR_USER_XXX error codes apply to both roles (CKU_SO and CKU_USER).  I think this one probably should as well.   Thanks DJ 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: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO This communication is confidential. We only send and receive email on the basis of the terms set out at https://www.utimaco.com/en/e-mail-disclaimer/