OASIS PKCS 11 TC

Hi,   Here is the draft motion for our PKCS 11 TC meeting and drafts of 2 additional paragraphs that I will need to submit with the request (if the motion passes).   Regards, Bob   Draft motion: I move that the PKCS 11 TC co-chairs request TC Administration to hold a Special Majority Vote to approve submitting the following documents as Candidate OASIS Standards: PKCS #11 Cryptographic Token Interface Base Specification v2.40 Committee Specification cs02 at http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/cs02/pkcs11-base-v2.40 PKCS #11 Cryptographic Token Interface Current Mechanisms Specification v2.40 Committee Specification cs02 at http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/cs02/pkcs11-curr-v2.40-cs02.doc   PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification v2.40 Committee Specification cs02 at http://docs.oasis-open.org/pkcs11/pkcs11-hist/v2.40/cs02/pkcs11-hist-v2.40-cs02.doc   PKCS #11 Cryptographic Token Interface Profiles v2.40 Committee Specification cs01 at http://docs.oasis-open.org/pkcs11/pkcs11-profiles/v2.40/cs01/pkcs11-profiles-v2.40-cs01.zip   (d) A clear English-language summary of the specification The PKCS #11 standard defines the data types and functions available to an application using the Cryptoki application programming interface (API). PKCS #11 isolates an application from the details of the specifics of a cryptographic device. The application does not have to change to interface to devices offering the same cryptographic functions or to be able to run in a different environment; thus, the application is portable between devices from different vendors and devices operating in different environments.   The PKCS #11 Base Specification provides the normative _expression_ of the application programming interface for the standard, including objects, attributes, operations and other elements.   The PKCS #11 Current Mechanisms Specification defines mechanisms that are anticipated for use with the current version of PKCS #11.   The PKCS #11 Historical Mechanisms Specification defines mechanisms for PKCS #11 that are no longer in general use.   The PKCS #11 Profiles document describes profiles that define a set of normative constraints for employing PKCS #11 within a particular environment or context of use for developers and architects who wish to design systems and applications that conform to the PKCS #11 Cryptographic Token Interface standard.     (e) A statement regarding the relationship of this specification to similar work of other OASIS TCs or other standards developing organizations; PKCS #11 is one of the family of standards called Public-Key Cryptography Standards (PKCS), originally developed under the leadership of and published by RSA Laboratories. Minimal further development is anticipated at this time for the other standards within the PKCS family, some of which remain under RSA leadership and others of which have been transferred to IETF. Activity in support of cryptographic standardization is also occurring in a number of other venues, including OASIS Technical Committees such the Key Management Interoperability Protocol (KMIP). The PKCS 11 Technical Committee seeks to align its technical activities and deliverables with other standardization initiatives in order to support harmonized vocabularies, avoid unnecessary duplication of effort, and promote interoperability and integration with respect to cryptographic objects and operations. Toward this end, the OASIS PKCS 11 Technical Committee has established a formal TC Liaison relationship with OASIS KMIP TC. (Should we mention other efforts as well, such as Technical Committee, JCA (Java Cryptography Architecture) and JCE (Java Cryptography Extension) frameworks and under vendor sponsorship such as the Microsoft CNG (Cryptography Next Generation) APIs. Other standards groups working on cryptography-related standards include IEEE (P1619), IETF (KeyProv), ANSI (X9.31) and  ISO (ISO/IEC 9796)? )  

Hi All,     I thought this would be of interest to the group: https://www.p6r.com/articles/2015/01/02/integrating-kmip-pkcs-11-and-ssh/ Integrating KMIP, PKCS 11, and SSH P6R has implemented a PKCS 11 Baseline Consumer as part of a SSH server’s Public Key Authentication protocol (i.e., RFC 4252). This implementation provides centralized Public Key management for SSH installations via the use of  KMIP . With our PKCS 11 Consumer, the SSH server looks up a user’s Public Key on a remote KMIP server rather than some file system directory. This scheme makes adding or removing a user’s SSH login authentication as easy as creating or removing a set of keys from a KMIP server. This PKCS 11 Consumer is both a PKCS 11 and KMIP client. Regards, Mark Joseph, Ph.D.  President P6R,  Inc 408-205-0361  mark@p6r.com  Skype: markjoseph_sc http://www.linkedin.com/pub/mark-joseph/0/752/4b4  

Thanks, Mark! Could you please include that on our wiki: https://wiki.oasis-open.org/pkcs11/KnownPKCS11Implementations Going forward, I think that would be the best place to put these announcements, as it creates an archive and keeps us all on the same page. Also, people not a member of this committee can easily find that data. I believe the KMIP TC has a similar page (as we copied from them) :-) Valerie On 01/ 5/15 08:10 AM, Mark Joseph wrote: Hi All, I thought this would be of interest to the group: https://www.p6r.com/articles/2015/01/02/integrating-kmip-pkcs-11-and-ssh/ Integrating KMIP, PKCS 11, and SSH P6R has implemented a PKCS 11 Baseline Consumer as part of a SSH server’s Public Key Authentication protocol (i.e., RFC 4252). This implementation provides centralized Public Key management for SSH installations via the use of KMIP < https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip >. With our PKCS 11 Consumer, the SSH server looks up a user’s Public Key on a remote KMIP server rather than some file system directory. This scheme makes adding or removing a user’s SSH login authentication as easy as creating or removing a set of keys from a KMIP server. This PKCS 11 Consumer is both a PKCS 11 and KMIP client. Regards, Mark Joseph, Ph.D. President P6R, Inc 408-205-0361 mark@p6r.com Skype: markjoseph_sc http://www.linkedin.com/pub/mark-joseph/0/752/4b4

From the Base Specification Version 2.40 In Section 5.4 General-purpose functions, C_Finalize() the following text appears: If several applications are using Cryptoki, each one should call C_Finalize. Each application’s call to C_Finalize should be preceded by a single call to C_Initialize; I interpret this to mean: each successful call to C_Initialize should have a matching call to C_Finalize.  What if the call to C_Initialize returns CKR_ARGUMENTS_BAD or CKR_CRYPTOKI_ALREADY_INITIALIZED, does the application still call C_Finalize ?? I looked in the User Guide and found nothing to clarify this point. Thanks, Mark Joseph  

On 5/15/2015 8:35 AM, Mark Joseph wrote: From the Base Specification Version 2.40 In Section 5.4 General-purpose functions, C_Finalize() the following text appears: "If several applications are using Cryptoki, each one should call C_Finalize. Each application’s call to C_Finalize should be preceded by a single call to C_Initialize;" I interpret this to mean: each *successful* call to C_Initialize should have a matching call to C_Finalize. What if the call to C_Initialize returns CKR_ARGUMENTS_BAD or CKR_CRYPTOKI_ALREADY_INITIALIZED, does the application still call C_Finalize ?? I looked in the User Guide and found nothing to clarify this point. Hi Mark- Sorry missed this email before. You have interpreted it the same way that we have, that every successful call to C_Initialize requires a call to C_Finalize In our documentation, we actually have special advice regarding the use of C_Finalize with respect to libraries: the advice is don't call it. From our libpkcs11 man page: Because C_Initalize() might have been called by both an application and a library, it is not safe for a library or its plugins to call C_Final- ize(). A library can be finished calling functions from libpkcs11, while an application might not. Valerie -- NOTE: Using voice recognition software, forgive typos/grammar mistakes! Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.

On 5/15/2015 8:35 AM, Mark Joseph wrote: >  From the Base Specification Version 2.40 > > In Section 5.4 General-purpose functions, C_Finalize() the following text appears: > > If several applications are using Cryptoki, each one should call C_Finalize. > Each application’s call to > C_Finalize should be preceded by a single call to C_Initialize; > > I interpret this to mean: each *successful* call to C_Initialize should have a > matching call to C_Finalize.  What if > the call to C_Initialize returns CKR_ARGUMENTS_BAD or > CKR_CRYPTOKI_ALREADY_INITIALIZED, does the application > still call C_Finalize ?? > > I looked in the User Guide and found nothing to clarify this point. Hi Mark- Sorry missed this email before. You have interpreted it the same way that we have, that every successful call to C_Initialize requires a call to C_Finalize In our documentation, we actually have special advice regarding the use of C_Finalize with respect to libraries: the advice is don't call it. From our libpkcs11 man page:        Because C_Initalize() might have been called by both an application and        a library, it is not safe for a library or its plugins to call C_Final-        ize(). A library can be  finished  calling  functions  from  libpkcs11,        while an application might not. Valerie Thanks Valerie, but couldn't the above result in memory leaks? If only the code that received CKR_OK from C_Initialize() calls C_Finalize() and C_Initialize() returns an error already initialized if previously called, then that should work and avoid memory leaks right? Otherwise the PKCS11 has to implement reference counting?

On 5/28/2015 3:47 PM, Mark Joseph wrote: On 5/15/2015 8:35 AM, Mark Joseph wrote: > From the Base Specification Version 2.40 > > In Section 5.4 General-purpose functions, C_Finalize() the following text appears: > > "If several applications are using Cryptoki, each one should call C_Finalize. > Each application’s call to > C_Finalize should be preceded by a single call to C_Initialize;" > > I interpret this to mean: each *successful* call to C_Initialize should have a > matching call to C_Finalize. What if > the call to C_Initialize returns CKR_ARGUMENTS_BAD or > CKR_CRYPTOKI_ALREADY_INITIALIZED, does the application > still call C_Finalize ?? > > I looked in the User Guide and found nothing to clarify this point. Hi Mark- Sorry missed this email before. You have interpreted it the same way that we have, that every successful call to C_Initialize requires a call to C_Finalize In our documentation, we actually have special advice regarding the use of C_Finalize with respect to libraries: the advice is don't call it. From our libpkcs11 man page: Because C_Initalize() might have been called by both an application and a library, it is not safe for a library or its plugins to call C_Final- ize(). A library can be finished calling functions from libpkcs11, while an application might not. Valerie Thanks Valerie, but couldn't the above result in memory leaks? If only the code that received CKR_OK from C_Initialize() calls C_Finalize() and C_Initialize() returns an error "already initialized" if previously called, then that should work and avoid memory leaks right? Otherwise the PKCS11 has to implement reference counting? We are able to do a lot of this by taking advantage of Solaris linker technology. The linker maintains a sort of reference counts for how many people are using this, and when the last user of this loaded module goes away, things are cleaned up. __fini() is the function we use. I wonder if Red Hat has a different solution? I think ours is kind of a special purpose area, because we are providing a general-purpose library for an operating system that could be used by many things the stack. For example, liba could load libb for some tasks, and both of those libraries might use libpkcs11. So we have to rely on the Solaris linker to let us know when we are truly done, and be very careful with memory use as well. Valerie -- NOTE: Using voice recognition software, forgive typos/grammar mistakes! Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.