Minutes from the Ad-hoc PKCS Workshop, April 10, 2001 ---------------------------------------------- 1. Opening of meeting Burt Kaliski, RSA Laboratories, welcomed everyone and presented the agenda. About 30 attendees, attendee list at the end of this note. 2. PKCS #15 2.1 Suggested enhancements to PKCS #15 Peter Gutmann presented some issues with the current version of PKCS #15 and gave suggestions for improvements. The first issue is due to the fact that data objects does not have an identifier which means that it is impossible to cross-reference them from, e.g. private key objects. Peter's suggestion was to add an 'iD' to the commonDataObjects type. The second issue Peter discussed related to "internal objects", e.g. objects which could exist in a hardware token without being visible to the end-user, but would be visible in a soft version of a PKCS #15 token, due to the fact that token specific information does not exist. Peter's suggestion was to add an "internal" flag to the commonObjectAttributes flags. It was noted that the solution would not stop users from determining the existence of these objects even if they will be unable to access them though (namespace issue). Finally, Peter presented a proposal regarding the storage of secret keys protected by being wrapped. Peter's suggestion is to store these keys directly in the recipientInfo structure, and possibly indicate this with a new ObjectValue choice. The primary motivation for this is the fact that it's easy to store a wrapped key in the RecipientInfo but in some cases impossible to store it as Encrypted/EnvelopedData, since a token may not allow export of the key in plaintext. In addition it reduces the number of layers with one. Russ Housley noted that the latter motivation may not be worth it per se since usually not too many symmetrical keys will be stored this way. 2.2 Certificate enrollment information Nada Kapidzic Cicovic, Entegrity, proposed storage of certificate enrollment information in, e.g. a PKCS #15 data object. The purpose of this would be to simplify enrollment from any CMP (or CMC) capable client. The proposal has also been presented to IETF's working group "SACRED". Bob Relyea, Netscape, argued that he would like to see some split between things which would go into PKCS #15 and some which would go into the library implementation, arguing that the token [or token manufacturer] can not make all decisions. Resolution seemed to be to let the library/browser have default values but first look in the token for the information. Going forward, Nada will prepare a written proposal of the data object interface and submit both to ietf-sacred@imc.org and pkcs-tng@rsasecurity.com. 3. PKCS #11 3.1 Support for "advanced" tokens in PKCS #11 Stefan Andersson, Ericsson, presented work related to the concept of mobile phones as "personal trusted devices," devices carrying a user's PKI credentials and capable of not only signing and decrypting but also displaying messages that are about to sign. In combination with a short-range radio technique such as Bluetooth, this can be used e.g. for signing of emails on a PC. The current design of PKCS #11 presents a problem here; it is on a too low level to acommodate a token which is capable of forming a PKCS #7 SignedAttributes structure on its own and subsequently sign and hash it. Preferably this would be left to the phone since it needs to verify that the text to be displayed corresponds to the digest to sign in any case. Bob Relyea made a remark about phones not being able to display all sorts of contents anyway. Stefan and Magnus commented that this can be solved by, e.g. the phone inserting a signed attribute indicating what content was actually displayed to the user (e.g. when dealing with multipart MIME messages). Bob Relya noted that PKCS #11 does not even have a well-defined suppport for offline authentication yet. There was also a question if this really is feasible with today's phones, and how much PKCS #7 code that would have to be on the phone. It was noted that a working implementation of this was shown at the RSA conference using an Ericsson R520 telephone. Aram Perez, Wave Systems, raised the possibility of XML signatures. Russ Housley expressed the opinion that this might very well be an important part of future local transactions. It was decided to continue the discussion on the cryptoki mailing list, perhaps also with a written proposal from interested parties. 3.2 PKCS #11 v2.11 Matthew Wood, Intel, presented the current status of this project. Matt expects to have a final document ready for publication within a month or two. The "secondary authentication" mechanisms has been deprecated and instead a "dual-slot" method based in contributions by Magnus Alström, SmartTrust, is being adopted. Further, PIN expiration behavior has been defined. Some PKCS #15-related modifications (e.g. trusted certificates and trusted public keys) has been made too, and a range of new mechanisms has been added (including AES, X9.31 RSA, X9.42 DH, X9.63 ECC, SSL3 master secret derivation (non-RSA), TLS master secret generation, RSA-PSS). There are still some remaning (minor) issues - e.g. if SO shall be allowed to set the CKA_TRUSTED attribute. Matt thanked everyone who had contributed to the work. There was a question regarding SHA-2 mechanisms and AES modes, but it was noted that these could presumably be added as amendments. 3.3 PKCS #11 v3.0 This was an early and fairly brief discussion on this forthcoming project. Matt Wood made a proposal to split the document into two separate parts - Data structures & API and - Mechanisms and Parameters. The reason for this is, of course, the size of the current document. By having separate parts, it would also be easier to accommodate separate editors. 4. AOB 4.1 Conformance Sinisa Cicovic, Entegrity, discussed the possibility of using Entegrity's PKCS #11 workbench to test profiles against. It is currently licensed as source code, but Entegrity could also imagine a more generous licensing policy, i.e. offer this toolkit for free - but would then rather not have ownership and responsibility for maintenance. Somebody would need to manage and moderate it, however. Topic to be discussed further at the next PKCS Forum. 5. Closing remarks Burt asked for views on where and when to have the next PKCS Forum. Several participants suggested to have it earlier than the previously announced September timeframe, perhaps in June. Burt agreed to check the possibility of this. Finally, he thanked everyone for their attention and contributions. Attendees: Magnus Nystrom, RSA Burt Kaliski, RSA Simon McMahon, ERACOM David Hook, Wumpus Consulting Ross Green, ERACOM Krister Walfridsson, Precise Biometrics Lutz Behnke, TC TrustCenter Russ Housley, RSA Peter Yee, SPYRUS Claus Svensson, SmartTrust Jean-Marc Robert, Gemplus Shin Lee, Rainbow Technologies Laszlo Elfeto, Rainbow Technologies Bob Relyea, Netscape Communications Corp. Simon Blake-Wilson, Certicom Hung Uo, Litronic Inc. Weimin Yang, Litronic Aram Pérez, Wave Systems Marion Shimoda, Intel Stefan Andersson, Ericsson Hazem Hassan, Datakey Christian Gehrmann, Ericsson Inc. Jan-Ove Larsson, RSA Peter de Laval, Sectra Communications Kazumi Saito, Mitsubishi Electric Corp. Rich Nicholas, Getronics Government Peter Gutmann, University of Auckland Nada Kapidzic Cicovic, Entegrity Solutions Bill Oliver, WinMagic Inc. Thi Nguyen-Huu, WinMagic Inc. Sinisa Cicovic, Entegrity Solutions Matt Wood, Intel