I think this feature should replace the existing PKCS11_generate_key()API function instead of adding a new one.

Otherwise, I really like this implementation.

@mtrojnar the PKCS11_generate_key is marked as deprecated (until 0.5), that's why I didn't replace it.

At the time it seemed to make sense to deprecate it, but fixing it instead may be a better idea. This is at least until we add an API that would not be limited to RSA.

So yes, maybe we also need another function(s) for key generation, only more flexible than the current one.

What do you advise?

1. replace the current PKCS11_generate_key with my function
2. change the names of this functions with something more clear?
   i.e. PKCS11_generate_RSA_keyair
   PKCS11_generate_token_keypair

Yes, please replace the existing function. We shouldn't break compatibility with legacy code. Those function names were chosen when OpenSSL didn't even have EC...

Designing a future key generation interface is a separate task. I'll be glad to discuss it.

@mtrojnar Let me know if I have to make other changes

Please also keep the original parameters, and not only the name...

Hi, what do you think about this prorotype

extern int PKCS11_generate_key(PKCS11_TOKEN * token,
	int algorithm, unsigned int bits,
	char *label, unsigned char* id, size_t id_len, ...);

using vargs to maintain the current function prototype ( @mtrojnar request) and add "flags" to choose the key functionalities (sign,decrypt,...) to satisfy @mouse07410 request

After some studies, I've found that the only way to use variadic function without passing va_list size is use a terminator, so the function call would be.

PKCS11_generate_key(token,0, 2048,label, id, id_len, P11_KEY_DECRYPT, P11_KEY_SIGN,P11_KEY_END);

PK11_KEY_END will be the va_list terminator.

I don't think that's an elegant solution don't you?

Possibile solutions:
1 variadic function with terminator
Pro
only one function maintaining the retro compatibility
Con
the key functionality list need a terminator

2 a new function with boolean params

PKCS11_generate_key(PKCS11_TOKEN * token,
	int algorithm, unsigned int bits,
	char *label, unsigned char* id, size_t id_len, 
        const short decrypt, const short sign, const short derive)

Pro
easy to use
Con
not expandible

3 a new function

PKCS11_generate_key(PKCS11_TOKEN * token,
	int algorithm, unsigned int bits,
	char *label, unsigned char* id, size_t id_len,int type)

the type param would be like open function flags param so used with OR (|) operator

the call should be something like that
PKCS11_generate_key(token,0, 2048,label, id, id_len, P11_KEY_DECRYPT| P11_KEY_SIGN);
Pro
expandible options and easy to use

I'm inclined to third solution, but before, I would really appreciate a suggestion.

I suggest for this PR to only implement RSA key generation on the token. This feature should not require any changes in the API. Please let me know if you disagree.

The next step (after closing this PR) might be to design and implement a new, more flexible interface algorithms other than RSA. I doubt varargs would be the most elegant way to do it. Again, I'll be glad to discuss it.

@dengert wrote:

It appears that the libp11 tries to hide much or all the PKCS#11 from the user is this a good idea?

Yes, this is the purpose of libp11. We all understand there is a trade-off between simplicity (ease of use) and flexibility. libp11 aims at delivering features sufficient for common applications, while being as simple to use as possible (but not more). The goal was never to expose the full flexibility (and thus complexity) of PKCS#11.

Well is it possible for an application to use libp11 to do all the hard work, like loading objects and authentication. But also expose some of the PKCS#11 sessions, objects, tokens so an application can do some of the PKCS#11 itself? Are the libp11 structures opaque? Or do you intend to make them opaque to keep an application from accessing the the PKCS#11 sessions, objects or tokens?

@dengert Yes, most libp11 data structures are defined in libp11-int.h. All pointers to PKCS#11 CK_* objects are protected this way. I'm not going to expose PKCS#11 internals to end-users.

There are 5 basic libp11 data structures exposed to end-user in libp11.h:

• PKCS11_KEY
• PKCS11_CERT
• PKCS11_TOKEN
• PKCS11_SLOT
• PKCS11_CTX

At some point it may be a good idea to define getters/setters and make those structures opaque. This is, however, not something I intend to do anytime soon.

@mtrojnar I've just pull the new master, but is it correct that PKCS11_generate_key still be deprecated (line 439 lib11.h P11_DEPRECATED_FUNC ) ?

@n3wtron Yes, I still intend to remove all the legacy RSA-only API functions. Don't worry. Removing them will take years rather than months. Also, for PKCS11_generate_key() we still don't have a modern replacement...

Hi all,
I am using libp11 to generate private key and store key to HSM (currently, I am using softhsm2 for simulating HSM device). My source code here:

if (slot->token->loginRequired && argc > 2) {
/* perform pkcs #11 login */
rc = PKCS11_login(slot, 1, argv[2]);
printf("\n======= rc = %d \n", rc);
error_queue("PKCS11_login");
CHECK_ERR(rc < 0, "PKCS11_login failed", 6);

/* Generate private key */
rc = PKCS11_generate_key(slot->token, 0, 2048, NULL, "key_id", sizeof("key_id"));
if (rc==-1) {
	error_queue("PKCS11_generate_key");
	CHECK_ERR(rc == -1, "Generate private key failed", 7);
	goto end;
}

}

And I got the error:
PKCS11_generate_key generated errors:
140713798612648:error:81082101:PKCS#11 module:func(130):User not logged in:p11_key.c:194:
Generate private key failed
Failed (error code 7).

I believe that I have already logged in to softhsm. I am using latest release libp11-0.4.9

Could you have any suggestion to fix this issue?

R/O login is not sufficient to modify your HSM.
You need:

rc = PKCS11_login(slot, 0, argv[2]);

instead of:

rc = PKCS11_login(slot, 1, argv[2]);