OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: long key (pair) generation


All,

 

The current proposal for simply returning CKR_OPERATION_TIMEOUT if an operation "takes longer to complete than a timeout determined by the device" has some drawbacks. Mainly, it's unclear how to determine if another operation call shall continue the previous operation or actually start a new (parallel) operation.

 

Two properties of the token determine the process:

1. Can the token continue to run the operation in the background after returning to caller ("BT" for background task in the following) or must the caller continuously call an operation to actively trigger progress ("AT" for active trigger in the following)?

2. Does the token support more than one of such unfinished operations at the same time ("MO" for multiple operations in the following) or is only a single operation allowed ("SO" for single operation in the following)?

 

Note that in the following only key (pair) generation is considered as operation. In principle, also other operations could require more time to process (to be confirmed - is this true and shall we consider it now?). However, it is not obvious how other operations can be referenced in case of MO.

 

Also note that some key pair generations can take quite a long time. The proposed mechanism needs to be robust to session interruptions. Therefore, progressing an operation (for AT), querying its status or cancelling must be possible independent of the session from which the operation has been started.

 

Main process:

- First call to operation is done with complete mechanism parameter and template. It returns with CKR_NOT_FINISHED, either immediately for BT or after a certain processing time for AT. For MO, the key handles must be set; for SO, it's optional.

- For SO, another call to operation with complete mechanism parameter returns with CKR_NOT_PARALLEL. For MO, this might also be possible if the amount of supported parallel operations has been exceeded.

- For MO, the private/secret key handle is used next to query the CKA_UNIQUE_ID attribute with C_GetAttribute.

- To continue operation (AT) or query status of operation (BT), call operation with new mechanism CKM_CONTINUE_OPERATION. For MO, the CKA_UNIQUE_ID is given in the mechanism parameter to specify which operation to continue. (Note that for SO the same approach can be used as well, although it's not necessary.) This either returns CKR_NOT_FINISHED again (either immediately for BT or after a certain processing time for AT) or finally CKR_OK with the key handles set.

 

It has to be clarified that CKR_NOT_FINISHED is NOT an error, but actually a "preliminary success code". Therefore, operations returning this code can also return key handles or data.

 

Open question: shall unfinished keys be returned by C_FindObjects(Init)? As they cannot be used in any cryptographic operation it's probably not advisable. The only exception is if only the CKA_UNIQUE_ID is given in the template - then a single handle is returned (to be used for cancelling an operation or in following alternative approach for BT).

 

Alternative approach for BT:

- Instead of calling the operation again with new mechanism CKM_CONTINUE_OPERATION a new attribute CKA_READY is added that can be regularly queried for this key and that is set to CK_TRUE when the key is ready.

 

Cancel an operation:

- For SO, C_SessionCancel can be used. This always applies to the single unfinished operation on the token, no matter from which session it was started.

- For MO, either a new mechanism CKM_CANCEL_OPERATION can be used with the CKA_UNIQUE_ID as parameter to cancel an operation. Alternatively C_DestroyObject can be used with the key handle (to be defined: for a prv/pub key pair do we need to destroy both?).

 

We need to discussion which combinations of BT/AT/MO/SO shall be supported. The considerations above might help to highlight problems and possible solutions. I hope we can discuss in the next TC call.

 

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: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]