Meeting minutes from the 1998 PKCS Workshop San Mateo, CA PKCS #1: RSA Cryptography Standard Jessica Staddon (RSA Laboratories) presented the PKCS #1 v2 document and Mihir Bellare (UC Davis) described the PSS signature scheme of which he is a co-inventor. General consensus was as follows: * Document is acceptable, though some simplification of the text may be helpful, and a second mask generation function based on HMAC would be useful. * For signature schemes with appendix, PSS is preferred, provided that licensing fee is nominal (e.g., < $500 for handling). FDH is an alternative. There was no significant interest in X9.31 signatures as part of PKCS. * For PSS, some further technical work is needed, such as how to include an algorithm ID in the RSA input (this could be a general way to include additional parameters). Also, a construction where hashing is deterministic, and recommendation for deterministic generation of the seed. * No significant interest in signature schemes with message recovery, enhanced encryption schemes, or key validation methods at this point. Possible interest in a specifying a key wrapping mechanism based on the encryption schemes. * A companion document giving usage guidance is recommended. It would cover issues such as key size, public exponent, key generation, typical protocols, and variants such as multiple prime factors or prime factors of different lengths. This could be updated more frequently than PKCS #1 itself. PKCS #13: Elliptic Curve Cryptography Standard Burt Kaliski (RSA Laboratories) presented a proposal for PKCS #13 v1. In general, the proposal was considered reasonable, and a PKCS for ECC appropriate. A profile of existing standards as a basis for interoperability without patent encumbrances, is the goal. The fewer choices, the better. PKCS #12: Public-Key User Information Syntax Standard Blake Ramsdell (Worldtalk) gave a critique of PKCS #12 based on Peter Gutmann's previously published comments. General consensus: * PKCS #12 v1.x document needs to be completed, reflecting actual implementation. Options that are not supported by implementations should be removed for simplicity. Some clarifications are needed, and recommended practices should be noted. * A clean slate for PKCS #12 v2.0. PKCS #5 v2 can be the reference for password-based encryption. One possibility is to define a storage format for user information, not just an interchange format. Some synergy with PKCS #15 (IC Card File Format Recommendations) is worth considering in this regard. PKCS #15: ICC File Format Standard Magnus Nyström presented the PKCS#15 proposal and the reason for this proposal. Hans Nilsson, AU-Systems presented the Swedish SEIS project and the new Swedish electronic identification standard. Finally, Scott Guthery, Microsoft related the DC/SC effort to PKCS#15 and the SEIS work. A summary of the discussion that followed: * Magnus Nyström led the PKCS#15 discussion. He started by asking the attendants whether they felt this was something important enough to create a PKCS for. Several votes in favor (or strongly in favor) of this where heard, none against. * Should ASN.1/DER (or PER) be used or is a simpler TLV (or TLS) model is better? Advantages for the former is the richness of the language, the existence of 3rd party parsers and ease of extensions. Disadvantages are ineffective coding and concerns about longer update times. Furthermore, DER parsers isn't always present in environments where a card can be used (e.g. cellular phone). The conclusion of the debate was that RSA Labs should probably try to stick with ASN.1 but try to simplify the ASN.1 and make it more 'application-friendly' (easy to do card updates as more or less 'atomic' operations). * PKCS#15 and PKCS#11: Magnus noted that PKCS#15 builds on PKCS#11, but that PKCS#11 implementations is not required for applications making use of PKCS#15. This is perhaps mostly important in restricted environments, such as cellular phones or during desktop boot-up sequences. As a consequence of this, PKCS#15 will not be restricted to certain limitations which exists in PKCS#11 today, like lack of support for multiple PINs. It is anticipated that several enhancements to PKCS#11 will be made as a result of the PKCS#15 work, however. * Several attendants, among them Eric Rescorla, noted that although the 'format' layer could be interoperable with the help of PKCS#15, the actual card layer will still be card-specific. Hans Nilsson of Sweden mentioned the ISM (Instruction Sequence Mapping) file initiative from Sweden, which defines how to map certain standardized generic commands to card specific ones. Due to certain problems, the ISM file was however later withdrawn from the swedish work. The general consensus of the meeting seemed to be that we should not spend time and energy on improving the ISM. In due time, smart cards will probably support ISO 7816-8 (or something similar) and in the meantime, a reasonable solution could be to make provisions in the format for stating which 'generic' commands a particular card supports. * One attendee mentioned that implementing PKCS#11 on a card obviates any need for a low-level format specification like PKCS#15. Magnus' response to this was that the current proposal is aimed for the most common card types today, ISO 7816 -based cards, but that he didn't rule out the possibility to include other card types in the future. One suggestion to instead use vendor-supplied PKCS#11 drivers (or CSP drivers) was rejected since this means that these drivers has to be installed on all platforms on which a user may wish to use his card. Furthermore, independent card initialization and personalization requires an open card format. * Since PKCS#15 also will support pure memory cards, Magnus raised the idea given (by someone else) yesterday, that PKCS#15 also could be the successor of PKCS#12, thereby giving one uniform format description for 'personal credentials'. Several voices in favor of this suggestion where heard, but the outcome of this also depends on the chosen encoding. Clearly, ASN.1/[DP}ER is the preferred choice in this case. * There was a discussion about support for certificates other than end-user public key certificates. As an example of this, users having trusted CA certificates on their smart cards would in practice carry their 'trust' with them. Magnus will try to include the notion of CA certificates as well as attribute certificates (suggestion by Roland Lockhart, Entrust) into PKCS#15. Bob Relyea, Netscape, mentioned the Netscape proposal regarding trust objects. One attendee was concerned that current cards won't be able to store several certificates due to memory constraints. The issue of certificate compression was discussed, but general consensus was that good compression algorithms are already patented. The notion of 'adjoint certificates' (common certificate fields are only stored once on the card) was also discussed, but no conclusion was reached in this matter. * Hans Nilsson wanted PKCS#15 to include a clarification and mapping of the key usage bits to X.509 key usage bits. This is also an issue for PKCS#11. Magnus agreed to look into this. * Scott Guthery, Microsoft argued against specifying access controls in PKCS#15, since this is the card issuers responsibility. Magnus agreed and will move this to an informative appendix. * Ernst-Michael Hamann suggested that PKCS#15 would include definitions of IDOs. With the possible exception of username/password objects the meeting rejected this proposal for being too application specific. * The meeting ended with a decision that further discussions will take place on the cryptoki list. RSA will post a revised draft to the list within one month. The goal is still to have v1.0 finished during Q1 1999. PKCS#11: Cryptographic Token Interface Standard Matthew Wood of Intel held a presentation describing Intel's encapsulation of PKCS#11 within the CDSA framework and the mutual authentication model used therein. Ernst-Michael Hamann of IBM Germany presented a proposal for extending PKCS#11 with, among other things, a new attribute for keys indicating that every usage of the key requires a new card holder verification. The proposal has been posted to pkcs-tng@rsa.com. Magnus Nyström of RSA Labs led the discussion about proposed enhancements and experiences from implementations. The discussion centered about a) finding the most pressing issues and thereby being able to prioritize the work, and b) how to proceed with the work. The result of a) is shown below. b) was finally settled on Friday, October 9, when it was decided (see below) that -unless there is any administrative problems- Matthew Wood will be the editor of PKCS#11 v2.1 - a backwards compatible revision of PKCS#11 v2.01 based on proposals from the workshop. The general view was that a majority of the proposed changes should be able to implement without destroying backwards compatibility. The day ended with four show-and-tell demonstrations, from * IBM Card Solutions Germany (Card personalization and applications thereof) * Xeti Inc, Los Altos, CA (PKIX Java toolkit) * Intel Corp (PKCS#11 inside CDSA 2.0) * Zergo, Australia (CA service) A summary of the discussions: * 'Simple' Fixes: - Short token serial numbers (16 bytes). Possible fix: Change to BCD-encoding. - TOKEN_INIT-flag, stating that the token indeed has been initialized. This has been suggested by daniel@sonadata.uk and the proposal has been posted to cryptoki@rsa.com - C_OpenToken() or C_InitializeToken() function (easier w regards to C_GetTokenInfo() and needed for Fortezza) also change C_GetTokenInfo() to use a session instead of a token (Ed's note: Hmm. This probably breaks backwards compatibility. Probably need C_GetTokenInfobyTokenHandle() instead). - Missing and unspecified return codes like for instance CKR_BAD_ARGUMENT when NULL input to, e.g., C_Digest(). - Change CK_CHAR to UTF8 - does not destroy backwards compatibility, but is more user friendly for e.g. Asian users. - Enable SO to change (some of) user's PINs (e.g. introduce C_SetUserPin()) - CKF_PROTECTED_AUTHENTICATION path for slots, not tokens? Or both? * 'Larger' issues - PIN area Multiple PINs: More or less needed in certain applications, e.g. non-repudiation. Needs cross-reference between PINs and protected objects. Should we introduce PIN objects? (Is there a risk of 'dangling' object references?) New attributes for PINs? (Suggested by mhamann@de.ibm.com: a) CKF_PIN_COUNT_LOW b) CKF_PIN_FINAL_TRY c) CKF_PIN_LOCKED d) CKF_PIN_NEEDS_CHANGE) PIN management (lifecycle) (CKF_PIN_EXPIRATION_DATE) - Certificates area Introduce new type of certificates: a) CA certificates (could be a new attribute for existing certificates) b) Attribute certificates (new subclass) Use compression of certificates?? Add trust attributes to certificates (like : 'I trust this cert as an issuing authority certificate' or 'I trust this end-user certificate') - Mechanisms Extensions for the Fortezza cards: a) C_CreateObject() (Fortezza LoadX generates 2 objects) b) C_DeriveKey/C_GenerateRandomMech() to generate Ra and Rb Fortezza pointers c) CKM_KEA_DSA_KEY_PAIR_GEN - generate KEA and DSA keys at same time TLS/SSL key generation - New functions C_SignInit() or C_SignInitSecure() for keys with a (proposed) new attribute CKA_SIGN_SECURE. The intention is that a PIN will be needed each time the key is being used (mhamann@de.ibm.com). Allow for key splitting/secret sharing (like BSAFE 4.0?) - Profiles PKCS#11 is large and complex, there is a need for defined profiles, subsets of PKCS#11 needed for different kinds of applications. Perhaps also test vectors to verify against. - Clarifications There is a need to clarify how PKCS#11 implementations should handle the case of multiple applications operating on one token, especially with regards to object management. Clarify mapping between PKCS#11 key usage and X509 key usage (or extend PKCS#11 in this respect) - Trust issues Mutual authentication as a means of solving the export license problem (suggested by relyea@netscape.com) Introducing trust objects - See Netscape's proposal posted to the mailing list. - Data objects Some consensus on (perhaps) defining one data object consisting of user name and password for a particular application, but nothing else. - Initial configuration information There is a need to declare initial configuration (relyea@netscape.com) PKCS #5: Password-Based Cryptography Standard Burt Kaliski (RSA Laboratories) presented a draft of PKCS #5 v2. General consensus: * Approach and methods are generally appropriate, though some consideration should be given to non-parallel methods for implementing the iteration count (i.e., instead of exclusive-or of independent outputs of the underlying pseudorandom function, compute the outputs iteratively). * The possibility that multiple keys may be derived from the same salt should be mentioned. For instance, an integrity-protection key and a confidentiality key might be derived from a password with a single PBKDF operation. * A usage document might cover issues such as "pepper" and non-random salts. One other suggestion: define a standard method for constructing password-check values for verifying passwords. PKCS #14: Pseudorandom Generation Methods Bob Baldwin (RSA Data Security) gave a comprehensive proposal for PKCS #14. The proposal was considered reasonable; a mailing list was to be formed to develop the PKCS #14 document. PKCS Workplan and process: Burt Kaliski led a general discussion of the PKCS process and also agreed on a work plan for the coming year. In general, participants expressed satisfaction with the current process; value was perceived in the production of documents that are readily available to a wide audience in a reasonable timeframe. Formal standards processes are helpful for long-term development of standards, but not necessarily as an alternative to the current set of PKCS documents. PKCS was also seen as having value in promoting technologies that are not encumbered by patents, but this need not be its highest priority. Burt also presented a proposal for a new PKCS based on protocols developed by RSA Laboratories for user authentication in Security Dynamics products. The protocol, which runs over a secure transport layer such as SSL, can support a variety of authentication methods including challenge-response authentication, time-based authentication, and biometrics. There was no immediate interest in developing this further as a PKCS. The tentative work plan agreed for the next year is as follows. In general, the goal is to accomplish most of this by the next workshop (tentatively Fall 1999), unless an earlier date is specified. PKCS #1 * resolve signature schemes / PSS RSA Cryptography * write usage guidelines * editor: Jessica Staddon PKCS #3 * revise similar to PKCS #13 Diffie-Hellman * proposal at next workshop PKCS #5 * revise per workshop discussion Password-Based * new draft 11/98, final 1/99 Cryptography * write usage guidelines * editor: Burt Kaliski PKCS #6 * drop in favor of X.509 v3 Extended Certificate Syntax PKCS #7 * maintain as historical document Cryptographic * point to IETF S/MIME Message Syntax PKCS #8 * update with new references Private-Key * write usage guidelines Information Syntax (e.g., other key types) PKCS #9 * record current practice Selected Attributes * purpose: support PKCS documents PKCS #10 * maintain as historical document Certificate Request * point to IETF PKIX Syntax PKCS #11 * revise per workshop discussion Cryptographic Token * develop mechanism ID registrations Interface * list of changes 11/98 * editor: Matthew Wood PKCS #12 * record current practice User Information * editor: Blake Ramsdell Syntax * draft final version 11/98 * final version 1/99 * possible future merge with #15 PKCS #13 * draft per workshop discussion Elliptic Curve * after PKCS #5 Cryptography * editor: Burt Kaliski PKCS #14 * draft per workshop discussion Pseudorandom * final 5/99 Generation * editor: Bob Baldwin PKCS #15 * revise per workshop discussion IC Card File Format * new drafts 11/98, 1/99, final 3/99 * editor: Magnus Nyström Matthew Wood and Blake Ramsdell will be providing outside editorial support to RSA Laboratories, coordinating the revisions to their respective documents. The final decision on the documents will remain with RSA Laboratories, under the usual consensus process for other documents, and the documents will be available under the usual terms. Matt and Blake's help is much appreciated. Meeting notes collected by Burt Kaliski and Magnus Nyström