Minutes from the 2002 PKCS Workshop Paris, France ----------------------------------- Workshop participants: Magnus Nyström, RSA Security Mark Knight, nCipher Alan Braggins, nCipher Matthias Esswein, Ericsson Ben Smeets, Ericsson Helge Bragstad, Schlumberger Johan Otterström, Sectra Bernard Leach John Leiseboer, RSA Security Simon McMahon, Eracom Laszlo Elteto, Rainbow Andrew Kay, Sharp Burt Kaliski, RSA Security (first day) Minutes taken by Magnus, with support from Simon. 1. Sunday, 6th October 1.1 Welcome address Burt Kaliski welcomed all attendees, wishing us a successful workshop. 1.2 A mobile profile of PKCS #11 v2.11 (Magnus Nyström) Magnus presented this profile, which also has been posted to the list. Q: "Why is this a _mobile_ profile" Magnus: "Could be used by any implementation. But particularly important to have a profile for mobile devices since want to avoid ambiguities." Mechanism: List of mechanisms can be shortened. Should be clarified that not all mechanisms are likely to be executed on the token, this is more of a library profile. Lazlo: "Either PKCS or X509 for signing mechanism." Decision to mandate PKCS, have X509 optional. SHA-1 mandated, other digest mechanisms are optional. No need for compound calls. Profile needs more detailing in terms of supported attributes etc., but in general agreement to continue this work and to base it (at least for the time being) on PKCS #11 v2.11. Q: Should this be split in two profiles: Signature token and mobile SSL (not necessarily with client authentication). Magnus acknowledges this, but feels that the decision can be taken later - main thing is to get the details of the profile done. Timeline: New draft later this fall, reasonable to have a profile done in Q1'03. 1.3 Extensions to PKCS #11 v2.11 (Ben Smeets) This proposal has also been sent to the pkcs-tng mailing list. From the discussion that followed the presentation: 1.3.1 Secondary authentication Better to avoid new functions, use C_SetAttribute() instead of C_AuthenticateObject(). Acknowledgement that the CKF_AUTH_PIN_AUTHENTICATED flag is an attribute of the session even though it "belongs" to a token (key) object. Maybe introduce token attributes that are session related? But that would be a new concept...Consensus to treat this as the "global" case (i.e. visible to all applications making use of the token). Simon suggests looking at the non-global case to see if there will be some problems later. C_SetAttribute() should be used also for the change secondary PIN operation. Early discussion on how this could be superseded by authentication objects. Discussion to be resumed tomorrow after the ACO/ACL discussion. 1.3.2 New mechanism suggestions Suggestion to change PRF mechanism descriptions to use C_DeriveKey instead of C_Sign. 1.3.3 General Suggestion is to split paper in two parts - one covering new mechanisms, the other the secondary authentication proposal. Magnus suggests RSA can create and maintain registry of mechanisms. New mechanisms (and descriptions) should be evaluated and accepted on mailing list before being assigned a non-vendor specific mechanism identifier. Magnus to send out this suggestion to the mailing list. 1.4 PKCS #11 v2.next (Simon McMachon) Note: v2.next since all extensions/enhancements we discussed should be possible to introduce without breaking backwards compatibility. Possible next revision number is 2.20. 1.4.1 New mechanisms and modes This would be Blowfish CBC, Twofish CBC, DES OFB and DES CFB. Proposal has been sent to mailing list, is stable, and will be included in v2.next. 1.4.2 Mechanisms as objects Mechanisms defined as objects already in PKCS #11 v2.11 Amd.1. Workshop concentrated on listing new attributes. List includes: Mechanism type Min_key_size Max_key_size All current flags turned to attributes (CKA_SIGN, CKA_ENCRYPT,...) CKA_VALUE (a token could conceivable receive a new mechanism) CKA_LABEL CKA_HW Not CKA_KEY_TYPE as some mechanisms can take several types And some mechanism specific attributes, e.g.: CKA_EC_PARAMETERS - Valid for an EC mechanism. I.e. the specific attribute set will be dependent on the mechanism. Q: What functions to use these? All mechanism handling ones. SO can disable certain things for a mechanism, e.g. SO can disable "decipher," or set max key length to a certain value. Simon to include this in first draft of PKCS #11 v2.next. 1.4.3 Tokens as objects: Agreement to do this to avoid problems with the limited CK_TOKEN_INFO structure. Discussion focused on what attributes to define. On current list is (basically a mapping from the TokenInfo struct)(not exhaustive): CKA_LABEL CKA_MANUFACTURER_ID CKA_DISPLAY_CHARACTERISTICS CKA_RNG (from TokenInfo flags) CKA_HW CKA_FIPS_MODE (if possible) No pin status indicators (see later discussion on ACOs) No clock information - it is an independent object Q: How to handle this given that objects are not accessible before a session has been established? One way is to establish session with new flag in C_OpenSession(), e.g. CKF_LIBRARY. Only to be sent if library supports it. Enumerate objects via this library session. C_GetInfo gives you version. Q: How about "hot swap" of tokens? Should not be a problem (re-enumeration). 1.4.4 Slot objects Similar discussion as for token objects. On list of attributes are: CKA_LABEL CK_SLOT_INFO information, converted to attributes, e.g. manufacturer. CKA_TOKEN_PRESENT CKA_TOKEN (referencing an CKO_TOKEN object handle) CKA_SLOT_TYPE Problem if people disregard slots, e.g. PINpad slot and ordinary slot. Should perhaps not make it too easy to disregard slots. Display capabilities attributes would be attributes of the token. Slot could also have this (as well as crypto capabilities, but in which case there really are two tokens). 1.4.5 Session objects Decided there was no real for these right now, and as they also would be complicated to introduce in a v2.x framework it was dropped. 1.4.6 ACLs and ACOs (The big one.) Agreement to introduce this since it does not appear to require changes to the functional i/f. Each object will then have access control attributes associated with it. Each access control attribute will reference an authentication object. This will also be true for authentication objects themselves, which, e.g. provides for a nice way to handle PIN unlocking keys (PUKs). Tentative definition of access control objects: CKA_ACCESS_EXEC Value: Auth.object CKA_ACCESS_READ Value: - " - CKA_ACCESS_WRITE/UPDATE Value: - " - CKA_ACCESS_DELETE/DESTROY Value: - " - CKA_ACCESS_UNLOCK (for PINs) Value: - " - CKA_ACCESS_ENUMERATE Value: - " - ...and authentication objects: CKA_CLASS CKA_AUTH_TYPE: Pin,... PINs: CKA_MAX_TRY CKA_BAD_TRIES CKA_STATUS (LOCKED, INITIALIZED) For token objects, ENUM and READ are "Always", which can be indicated with a special object handle. "Never" is indicated by an INVALID OBJECT HANDLE. We'll need text on how to implement this in a v2.11 compliant version. Simon to include this in v2.next. 2. Monday, 7th October 2.1 Ericsson's proposal on secondary authentication, cont. Removing CKA_AUTH_PIN_AUTHENTICATED bit. CKA_AUTH_PIN_LEN replaced by max and min values (to avoid giving away information). In C_SetAttribute(): AuthPin and also NewAuthPin attributes when modifying a PIN. Proposal will be modified to make use of authentication objects instead. Ericsson to submit new proposal to list. 2.2 PKCS #11 v2.next, continued 2.2.1 Derive key by encryption of data See mailing list. TBI by Simon in v2.next. 2.2.2 Key Check Values See mailing list. TBI by Simon. 2.3 Other business 2.3.1 C_ReEncrypt (Johan Otterström, Sectra) Proposal for new function. Workshop suggests to use do C_Encrypt instead, with mechanism parameters for the decryption mechanism and the encryption mechanism and key handles supplied in the parameters as well. Simon to drive this on the list. 2.3.2 Attribute template inheritance (Simon) New suggestion, not presented on mailing list. For use when unwrapping keys, to mandate certain attribute values. The template would be an attribute for the master key. There is a slight problem maybe in serialization. Could restrict the set of attributes to solve it. To be discussed further on the mailing list. 2.3.3 Only wrap with certain keys (Simon) Intention is to make sure that only certain keys may be used to wrap a key. Assume key to be wrapped = K, master key = MK: For K: CKA_EXTRACTABLE=1 CKA_WRAPKEY=MK CKA_WRAP_WITH_TRUSTED=TRUE (Possible, means "wrap with any trusted key"). Master key would have attributes as: CKA_WRAP=1 CKA_WRAP_MECHANISM=... CKA_DERIVE_MECHANISM=... CKA_TRUSTED=TRUE (only to be set by SO) (CKA_WRAP_MECHANISM/DERIVE_MECHANISM could be a list). No decision at workshop, to be discussed further on mailing list. 2.3.4 Copying of token objects between tokens. Decision to not study this right now since it is normally intra-vendor specific. 2.3.5 Template for C_Initialize (Alan) Define the pReserved as a template TLV list. For supply of library configuration information, e.g. memory management functions. If library does not recognize then fail (don't pass vendor defined things unless you know the vendor). C_GetInfo could in principle be called prior to C_Initialise, to allow applications to configure C_Init's parameter's template arguments. No decision at workshop, to be discussed further on mailing list. 2.3.6 Module management (Simon) This has already been discussed on the mailing list. After some considerations, decision to use flat file due to its platform independence. If needed, on Windows, the environment variable pointing to the flat file could be in the registry. On UNIX, make use of an environment variable. The flat file itself: module="" path="" # Path is to be interpreted for the operating platform [profiles="[,]"] # comment lines start with hash mark. One module definition starts with "module=" and ends at next "module=" (or EOF). Lower case names. Case sensitive (subject to platform). Environment variable suggested to be PKCS11_MODULE_DB. First module to be installed prompts user and initialises environment if possible. Suggested default values for path: /opt/etc/pkcs11/ or C:\program files\pkcs11 Suggested default filename: module.txt. 2.3.7 Java wrapper for PKCS #11 JCA is regarded as too heavy or not suitable for certain applications, there is a perceived industry demand for a PKCS #11 Java wrapper. A Java interface definition could be supported as an annex to the PKCS #11. To be discussed further on the mailing list. 2.4 Editorial matters 2.4.1 Key generation for HMAC Clarify in accordance with resolution on mailing list. Clarify section "Generic Secret key objects" too, regarding the use of these keys. 2.4.2 Domain parameters Clarify coupling to key generation as suggested on the list. 2.4.3 C_CopyObject - CKM_MODIFIABLE constraints Possible security issue since CKM_MODIFIABLE can be set when copying. To be discussed further on the mailing list. 2.4.4 Document re-org Mechanisms and keys related to them to separate document(s). "Base" document to contain object handling and base classes and functions. 2.5 Decisions for PKCS #11 v2.next Since Simon we would like to have a v2.next relatively soon only those areas where we feel we have a working solution will be included in this release. These areas are: The CMS amendment Mechanism Objects Token Objects Slot Objects Access Control and Authentication Objects WTLS/TLS mechanisms New mechanisms and modes (Twofish etc.) Key derivation by encryption of data Key check values All editorial corrections Appendix on module management (Normative?) Other items discussed at the workshop need further review by the members of the mailing list before a decision on whether to include them in a future version of PKCS #11 or not can be taken. Simon expects to deliver a first draft of v2.next no later than November 7. It is expected that this draft will include:     CMS support     Blowfish/Twofish     Derive key by encryption     CKA_CHECK_VALUE     Misc. clarifications. 2.6 PKCS #9 amendment (Magnus) Magnus presented a proposal (also sent to the pkcs-tng mailing list) about extensions to PKCS #9 to provide some better protection to users of trusted tokens/devices using the CMS_SIG mechanism in the PKCS #11 amendment. Feeling from workshop is that first suggested attribute (allegedMIMEType) provides value, but that it is unclear if the other one (presentationCapabilities) does. Magnus to go ahead with the definition of the first one for now. 2.7 End of workshop Magnus thanked everyone for their efforts during these two days.