Minutes from the April, 2003 PKCS Workshop San Francisco, CA ----------------------------------- Workshop participants: Kais Belgaied Sun Microsystems Arnaud Derverbigier RSA Security Sebastian Elfors Nexus Laszlo Elteto Rainbow Technologies Magnus Erkstam Nexus Helen Francis RSA Security Russ Housley Vigil Security David Jacobson Sun Microsystems Jeff Jacoby RSA Security Burt Kaliski RSA Security Huie-Ying Lee Sun Microsystems Fabio Martinelli IIT-CNR Kevin McKeogh nCipher Simon McMahon Eracom Darren Moffat Sun Microsystems Jamie Nicolson Netscape/AOL Magnus Nyström RSA Security Aram Pérez QuickSilver Technology Bob Relyea Netscape/AOL Paul Sangster Sun Microsystems Jim Schaad Soaring Hawk Charles Shapiro RSA Security Gurpreet Singh RSA Security Joe Tardo Redcoil Anna Vaccarelli IIT-CNR David Young RSA Security Minutes taken by Magnus, with support from Simon. 1. Sunday, 13th April 1.1. Welcome address Magnus greeted everyone welcome, and presented the agenda (see slides). 1.2. Amendments to PKCS #11 for WTLS and TLS Magnus presented Ericsson's slides on the current status of this work. Consensus to move forward by assigning needed constants, include received comments (Laszlo's) and then submit a final draft for a one month review period, after which the document will be sent to Simon McMahon for inclusion in v2.20. 1.3. Profile of PKCS #11 for mobile devices Magnus presented the current status of this work (see slides). Kais noted that C_DeriveKey() was missing from the set of mandated functions for the communication device profile (actually, C_GenerateKey() is missing too). It is needed for some of the TLS mechanisms. Next steps: Magnus to create a final draft and submit to the list for a one month review period. Will incorporate Laszlo's comments sent earlier and Kais' observation above. After this, the document should be ready for publication. 1.4. PKCS #11 v2.20 Simon presented the status of the current draft (draft 2). General: Currently, tracking of proposals is on, but is making the document unwieldy. Ok to accept changes so far and only have tracking relative to previous draft? Yes. Simon asks whether it would be appropriate to restructure the document now, in the manner discussed earlier (mechanisms/functions in separate document). Yes, none against. Discussion about scope. Yet to be included: WTLS/TLS amendment, "secure" key wrapping, and enhanced unwrapping (see below). After some discussion, decision to leave the objects proposal out of scope for v2.20, but continue to work on it in parallel. The proposal for a more complete and consistent object model has good support, but the model does introduce complexities, e.g. session objects - today you need a session in order to create objects, so how do you create session objects? Key wrapping: Basically same proposal as in Paris (see the minutes from Paris). But now a list of allowed mechanism, CKA_ALLOWED_MECHANISMS...Suggestion that we add note that it should only be one (both in the Security Considerations section and in the attribute description too. The CKA_TRUSTED attribute will have to be defined also for secret keys (only for public keys today). No CKA_WRAPKEY attribute, only CKA_WRAP_WITH_TRUSTED. This attribute should be possible to change from FALSE (default) to TRUE but locking to TRUE (i.e. not possible to change back). Unwrapping keys: Simon suggests a new attribute for unwrapping keys, CKA_UNWRAP_TEMPLATE, which instructs how attributes will be set for unwrapped keys. Consensus to include this as well in v2.20. 2. Monday, 14 April 2.1 New RSA mechanisms (and mechanism strategy in general) Burt Kaliski presented a proposal to add new RSA signature and key transport mechanisms to PKCS #11 - mainly PSS in combination with new SHA-256 and higher digests but also the 'KEM' method recently proposed also in other forums, e.g. IETF/SMIME. Burt also aired the possibility of having PKCS #11 taking the lead in defining how to use emerging algorithms (i.e. not just _reflect_, but also _guide_), but consensus was to rather stay as a follower, awaiting final standardization of mechanisms taking place elsewhere to avoid costly token or library changes when or if details in a mechanism are changed during its final stages of standardization. The decision was therefore to include PSS variants but not 'KEM' or even more recent methods right now. Related to this, new SHA mechanisms have been given mechanism numbers but have not yet been described in PKCS #11. Burt graciously accepted to draft paragraphs for these mechanisms too. 2.2 PKCS #11 v2.20, continued 2.2.1 Default and token-specific attribute values Defaults - Request that the document explicit mentions that if all attributes are not specified then they will be set to the default value for the token/library. Bob would like to be able to indicate if a set attribute is just a suggestion and that it is ok if the library change the value (e.g. if library requires SENSITIVE). Laszlo suggests using a mechanism similar to what was introduced for CKM_CMS_SIG. [Anyone taking an action here?] 2.2.2 How to indicate what went wrong when creating an object Laszlo would like a better ability for the library to inform the application about errors when creating objects. We discussed some alternatives, Laszlo will take this to the mailing list. 2.2.3 Timeline for PKCS #11 v2.20 Simon will rearrange the document as described above. Should have that version (with additions per above) available in mid May. A final draft could then be published in mid July and v2.20 in September. Let's help Simon achieve this! 2.3 The new object model (Part of this discussion happened on Sunday) 2.3.1 Session objects Simon has suggested the following attributes (see Cryptoki archives, April 9, 2003): slotID - CKA_SLOT_ID state - CKA_STATE flags - CKA_FLAGS deviceError - CKA_DEVICE_ERROR Agreed that it is better to replace slotID with a reference to the Token Object, since there can be only one token in one slot and we want to have a complete object model. Also agreement that we should avoid 'CKA_FLAGS' and instead split into a number of Boolean attributes, which gives more flexibility. Creating a session in the new model could happen as: C_OpenSession() C_CreateObject({CKA_CLASS = CKO_SESSION_OBJECT),...) Session handle = object handle C_FindObjectsInit() ... Allowing session handles to be object handles is binary backwards compatible but not source backwards compatible. 2.3.2 Slot objects Simon has suggested the following attributes for these objects: slotDescription - CKA_LABEL manufacturerID - CKA_MANUFACTURER flags - CKA_FLAGS hardwareVersion - CKA_HW_VERSION firmwareVersion - CKA_FW_VERSION As for session objects, better to have all Booleans in CKA_FLAGS as separate attributes. It was noted that one of the motivations for slots as objects is that the current version of PKCS #11 does not allow the slot list to change (especially not shrink) once C_GetSlotList() has been called (actually C_Initialize()). An object model would potentially be more flexible. However, if some constraints are met (allowed to change the slot list after a call to C_GetSlotList() with a null pSlotList), then it is possible to allow the slot list to be dynamic also in the current model. Still a minor problem with this in conjunction with threading and slot (e.g. USB slot) removal, but Simon will describe the procedure in v2.20. Since slots as objects therefore is not a requirement for dynamic slot recognition, and the handling of slots as objects is complicated by the fact that you need a session in order to deal with objects (and a session can only be created with an existing slot), slots as objects will not be part of v2.20 (The only other possibility could be if the current static CK_SLOT_INFO struct is hindering for some vendors. If this is the case, let yourself be known!) 2.3.3 Mechanism objects Simon has not suggested any new attributes for this object class. Agreement that it will have to be fully specified, and that this should be done already for v2.20, since mechanism objects already are in. Action for all to suggest mechanism attributes. 2.3.4 Authentication objects Magnus presented the current proposal, and went through a summary of outstanding issues (Some of the questions discussed was received off-list, in these instances I have indicated the sender below): a) Does successful authentication to CKA_ACCESS_WRITE enable an application to change the value of CKA_ACCESS_XXX? (Dale Gustafson, Vladimir Beker) Consensus: No. We should probably have a new attribute for all objects: CKA_ACL_MOD indicating the authentication needed to have the right to modify the ACL for an object. This object can naturally only be set when creating the object and can be seen as a "grant". b) What about Boolean combination of authentication objects? (Dale Gustafson) This is possible, but currently not in scope for the first version of this (would like to keep the complexity down as much as possible). c) What about destroying authentication objects? Won't that risk creating dangling pointers? (Vladimir Beker) Yes, but workshop consensus was to allow applications to do this - it can already happen, for example when the session which created a session object goes away. A second thread's handle to the session object will then be invalid. d) We do need something like C_Logout() also in the new model (V. Beker, D. Gustafson, L. Elteto) Suggestion from Bob was to add an attribute to authentication objects, CKA_AUTHENTICATED, which can be set to FALSE through C_SetAttributeValue(), but which can only be set to TRUE by a successful authentication. e) If an old application is linked with a "new" library, how will the library determine what to use as user and SO PIN? Proposal at the workshop was to add CKA_USER_PIN and CKA_SO_PIN as attributes to the Token object itself. These attributes, if set, would then reference authentication objects. Despite this, one must realize that it will not always be possible to represent a "new" token created by a "new" library to an "old" application, since the new object model is much more flexible. This led to a discussion about Token Objects. Magnus listed the currently supported set of attributes, and after some debate the following set was tentatively agreed on: CKA_ACCESS_ENUMERATE - Token "global" read access CKA_ACCESS_CREATE - Right to create new token objects CKA_ACCESS_WRITE - Right to modify other token attributes, e.g. the label. CKA_ACCESS_EXEC - Right to execute e.g. a random number generator on the token CKA_ACCESS_REINITIALIZE - The right to reinitialize the token CKA_USER_PIN - Pointer to user PIN (or null) CKA_SO_PIN - Pointer to SO PIN (or null) (+Components of CK_TOKEN_INFO) [This implies that CKA_ACCESS_ENUMERATE still will have a purpose also for ordinary objects, but mainly when creating the object (can't see the value of the attr unless it has already been authenticated to).] f) To what object attributes does the CKA_ACCESS_XXX attributes apply? Agreement that this will have to be specified for each object type. g) How about C_InitToken in combination with this model? (Dale, Vladimir) See the REINITIALIZE attribute above. Unclear if one could use C_SetAttributeValue or not; let's concentrate on getting the object model right first however and then worry about whether it is possible to fit it in the existing function set or not. Discussion to continue on mailing list; Magnus will submit new draft based on the discussion here and on the mailing list since the last draft. 2.4 Java version of PKCS #11 Topic continues to be raised - is it time to do something? JSR #74 from JCP (www.jcp.org) only covers PKCS#1, #5, #7, #8, #9, #10 and #12... Possible overlap with JSR-177? Should we await the more complete object model? Decision to, as a first step, investigate the JSR work item to see if there is any overlap. And after this, the workshop ended abruptly when the lights went out... $Id$