home *** CD-ROM | disk | FTP | other *** search
/ ftp.rsa.com / 2014.05.ftp.rsa.com.tar / ftp.rsa.com / pub / pkcs / 02workshop / minutes.txt < prev    next >
Text File  |  2014-05-02  |  13KB  |  377 lines
  1.                  Minutes from the 2002 PKCS Workshop
  2.                             Paris, France
  3.                  -----------------------------------
  4.  
  5. Workshop participants:
  6.  
  7. Magnus Nystr÷m, RSA Security
  8. Mark Knight, nCipher
  9. Alan Braggins, nCipher
  10. Matthias Esswein, Ericsson
  11. Ben Smeets, Ericsson
  12. Helge Bragstad, Schlumberger
  13. Johan Otterstr÷m, Sectra
  14. Bernard Leach
  15. John Leiseboer, RSA Security
  16. Simon McMahon, Eracom
  17. Laszlo Elteto, Rainbow
  18. Andrew Kay, Sharp
  19. Burt Kaliski, RSA Security (first day)
  20.  
  21. Minutes taken by Magnus, with support from Simon.
  22.  
  23. 1. Sunday, 6th October
  24.  
  25. 1.1 Welcome address
  26.  
  27. Burt Kaliski welcomed all attendees, wishing us a successful workshop.
  28.  
  29. 1.2 A mobile profile of PKCS #11 v2.11 (Magnus Nystr÷m)
  30.  
  31. Magnus presented this profile, which also has been posted to the
  32. list. Q: "Why is this a _mobile_ profile" Magnus: "Could be used by
  33. any implementation. But particularly important to have a profile for
  34. mobile devices since want to avoid ambiguities." Mechanism: List of
  35. mechanisms can be shortened. Should be clarified that not all
  36. mechanisms are likely to be executed on the token, this is more of a
  37. library profile. Lazlo: "Either PKCS or X509 for signing mechanism."
  38. Decision to mandate PKCS, have X509 optional. SHA-1 mandated, other
  39. digest mechanisms are optional. No need for compound calls. Profile
  40. needs more detailing in terms of supported attributes etc., but in
  41. general agreement to continue this work and to base it (at least for
  42. the time being) on PKCS #11 v2.11. Q: Should this be split in
  43. two profiles: Signature token and mobile SSL (not necessarily with
  44. client authentication). Magnus acknowledges this, but feels that 
  45. the decision can be taken later - main thing is to get the details of
  46. the profile done. Timeline: New draft later this fall, reasonable to
  47. have a profile done in Q1'03.
  48.  
  49. 1.3 Extensions to PKCS #11 v2.11 (Ben Smeets)
  50.  
  51. This proposal has also been sent to the pkcs-tng mailing list.
  52. From the discussion that followed the presentation:
  53.  
  54. 1.3.1 Secondary authentication
  55.  
  56. Better to avoid new functions, use C_SetAttribute() instead of
  57. C_AuthenticateObject(). Acknowledgement that the
  58. CKF_AUTH_PIN_AUTHENTICATED flag is an attribute of the session even
  59. though it "belongs" to a token (key) object. Maybe introduce token
  60. attributes that are session related? But that would be a new
  61. concept...Consensus to treat this as the "global" case (i.e. visible
  62. to all applications making use of the token). Simon suggests looking
  63. at the non-global case to see if there will be some problems
  64. later. C_SetAttribute() should be used also for the change secondary
  65. PIN operation. Early discussion on how this could be superseded by
  66. authentication objects. Discussion to be resumed tomorrow after the
  67. ACO/ACL discussion.
  68.  
  69. 1.3.2 New mechanism suggestions
  70.  
  71. Suggestion to change PRF mechanism descriptions to use C_DeriveKey
  72. instead of C_Sign. 
  73.  
  74. 1.3.3 General
  75.  
  76. Suggestion is to split paper in two parts - one covering new
  77. mechanisms, the other the secondary authentication proposal. Magnus
  78. suggests RSA can create and maintain registry of mechanisms. New
  79. mechanisms (and descriptions) should be evaluated and accepted on
  80. mailing list before being assigned a non-vendor specific mechanism
  81. identifier. Magnus to send out this suggestion to the mailing list.
  82.  
  83. 1.4 PKCS #11 v2.next (Simon McMachon)
  84.  
  85. Note: v2.next since all extensions/enhancements we discussed should be
  86. possible to introduce without breaking backwards compatibility.
  87. Possible next revision number is 2.20.
  88.  
  89. 1.4.1 New mechanisms and modes
  90.  
  91. This would be Blowfish CBC, Twofish CBC, DES OFB and DES CFB. Proposal
  92. has been sent to mailing list, is stable, and will be included in
  93. v2.next.
  94.  
  95. 1.4.2 Mechanisms as objects
  96.  
  97. Mechanisms defined as objects already in PKCS #11 v2.11 Amd.1.
  98. Workshop concentrated on listing new attributes. List includes:
  99.  
  100.     Mechanism type
  101.     Min_key_size
  102.     Max_key_size
  103.     All current flags turned to attributes (CKA_SIGN, CKA_ENCRYPT,...)
  104.     CKA_VALUE (a token could conceivable receive a new mechanism)
  105.     CKA_LABEL
  106.     CKA_HW
  107.     Not CKA_KEY_TYPE as some mechanisms can take several types
  108.  
  109. And some mechanism specific attributes, e.g.:
  110.  
  111.     CKA_EC_PARAMETERS - Valid for an EC mechanism.
  112.  
  113. I.e. the specific attribute set will be dependent on the mechanism.
  114.  
  115. Q: What functions to use these? All mechanism handling ones. SO can
  116. disable certain things for a mechanism, e.g. SO can disable
  117. "decipher," or set max key length to a certain value. Simon to include
  118. this in first draft of PKCS #11 v2.next.
  119.  
  120. 1.4.3 Tokens as objects:
  121.  
  122. Agreement to do this to avoid problems with the limited CK_TOKEN_INFO
  123. structure. Discussion focused on what attributes to define. On current
  124. list is (basically a mapping from the TokenInfo struct)(not
  125. exhaustive):
  126.  
  127.     CKA_LABEL
  128.     CKA_MANUFACTURER_ID
  129.     CKA_DISPLAY_CHARACTERISTICS
  130.     CKA_RNG (from TokenInfo flags)
  131.     CKA_HW
  132.     CKA_FIPS_MODE (if possible)
  133.     No pin status indicators (see later discussion on ACOs)
  134.     No clock information - it is an independent object
  135.  
  136. Q: How to handle this given that objects are not accessible before a
  137. session has been established? One way is to establish session with new
  138. flag in C_OpenSession(), e.g. CKF_LIBRARY. Only to be sent if library
  139. supports it. Enumerate objects via this library session. C_GetInfo
  140. gives you version. Q: How about "hot swap" of tokens? Should not be a
  141. problem (re-enumeration).
  142.  
  143. 1.4.4 Slot objects
  144.  
  145. Similar discussion as for token objects. On list of attributes are:
  146.  
  147.     CKA_LABEL
  148.     CK_SLOT_INFO information, converted to attributes, e.g. manufacturer.
  149.     CKA_TOKEN_PRESENT
  150.     CKA_TOKEN (referencing an CKO_TOKEN object handle)
  151.     CKA_SLOT_TYPE
  152.  
  153. Problem if people disregard slots, e.g. PINpad slot and ordinary
  154. slot. Should perhaps not make it too easy to disregard slots.
  155.  
  156. Display capabilities attributes would be attributes of the token.
  157. Slot could also have this (as well as crypto capabilities, but in
  158. which case there really are two tokens).
  159.  
  160. 1.4.5 Session objects
  161.  
  162. Decided there was no real for these right now, and as they also would
  163. be complicated to introduce in a v2.x framework it was dropped.
  164.  
  165. 1.4.6 ACLs and ACOs
  166.  
  167. (The big one.) Agreement to introduce this since it does not appear to
  168. require changes to the functional i/f. Each object will then have
  169. access control attributes associated with it. Each access control
  170. attribute will reference an authentication object. This will also be
  171. true for authentication objects themselves, which, e.g. provides for a
  172. nice way to handle PIN unlocking keys (PUKs).
  173.  
  174. Tentative definition of access control objects:
  175.  
  176.     CKA_ACCESS_EXEC              Value: Auth.object
  177.     CKA_ACCESS_READ              Value:  - " -
  178.     CKA_ACCESS_WRITE/UPDATE      Value:  - " -
  179.     CKA_ACCESS_DELETE/DESTROY    Value:  - " -
  180.     CKA_ACCESS_UNLOCK (for PINs) Value:  - " -
  181.     CKA_ACCESS_ENUMERATE         Value:  - " -
  182.  
  183. ...and authentication objects:
  184.  
  185.     CKA_CLASS
  186.     CKA_AUTH_TYPE: Pin,...
  187.  
  188. PINs:
  189.  
  190.     CKA_MAX_TRY
  191.     CKA_BAD_TRIES
  192.     CKA_STATUS (LOCKED, INITIALIZED)
  193.  
  194. For token objects, ENUM and READ are "Always", which can be indicated
  195. with a special object handle. "Never" is indicated by an INVALID
  196. OBJECT HANDLE. We'll need text on how to implement this in a v2.11
  197. compliant version. Simon to include this in v2.next.
  198.  
  199. 2. Monday, 7th October
  200.  
  201. 2.1 Ericsson's proposal on secondary authentication, cont.
  202.  
  203. Removing CKA_AUTH_PIN_AUTHENTICATED bit. CKA_AUTH_PIN_LEN replaced by
  204. max and min values (to avoid giving away information). In
  205. C_SetAttribute(): AuthPin and also NewAuthPin attributes when
  206. modifying a PIN. Proposal will be modified to make use of
  207. authentication objects instead. Ericsson to submit new proposal to
  208. list.
  209.  
  210. 2.2 PKCS #11 v2.next, continued
  211.  
  212. 2.2.1 Derive key by encryption of data
  213.  
  214. See mailing list. TBI by Simon in v2.next.
  215.  
  216. 2.2.2 Key Check Values
  217.  
  218. See mailing list. TBI by Simon.
  219.  
  220. 2.3 Other business
  221.  
  222. 2.3.1 C_ReEncrypt (Johan Otterstr÷m, Sectra)
  223.  
  224. Proposal for new function. Workshop suggests to use do C_Encrypt
  225. instead, with mechanism parameters for the decryption mechanism and
  226. the encryption mechanism and key handles supplied in the parameters as
  227. well. Simon to drive this on the list.
  228.  
  229. 2.3.2 Attribute template inheritance (Simon)
  230.  
  231. New suggestion, not presented on mailing list. For use when unwrapping
  232. keys, to mandate certain attribute values. The template would be an
  233. attribute for the master key. There is a slight problem maybe in
  234. serialization. Could restrict the set of attributes to solve it. To be
  235. discussed further on the mailing list.
  236.  
  237. 2.3.3 Only wrap with certain keys (Simon)
  238.  
  239. Intention is to make sure that only certain keys may be used to wrap a
  240. key. Assume key to be wrapped = K, master key = MK:
  241.  
  242. For K: 
  243.  
  244.     CKA_EXTRACTABLE=1
  245.     CKA_WRAPKEY=MK
  246.     CKA_WRAP_WITH_TRUSTED=TRUE (Possible, means "wrap with any trusted
  247.                                 key"). 
  248.  
  249. Master key would have attributes as:
  250.  
  251. CKA_WRAP=1
  252. CKA_WRAP_MECHANISM=...
  253. CKA_DERIVE_MECHANISM=...
  254. CKA_TRUSTED=TRUE (only to be set by SO)
  255.  
  256. (CKA_WRAP_MECHANISM/DERIVE_MECHANISM could be a list). No decision at
  257. workshop, to be discussed further on mailing list.
  258.  
  259. 2.3.4 Copying of token objects between tokens.
  260.  
  261. Decision to not study this right now since it is normally intra-vendor
  262. specific.
  263.  
  264. 2.3.5 Template for C_Initialize (Alan)
  265.  
  266. Define the pReserved as a template TLV list. For supply of library
  267. configuration information, e.g. memory management functions. If
  268. library does not recognize then fail (don't pass vendor defined things
  269. unless you know the vendor).
  270.  
  271. C_GetInfo could in principle be called prior to C_Initialise, to allow
  272. applications to configure C_Init's parameter's template arguments.
  273. No decision at workshop, to be discussed further on mailing list.
  274.  
  275. 2.3.6 Module management (Simon)
  276.  
  277. This has already been discussed on the mailing list. After some
  278. considerations, decision to use flat file due to its platform
  279. independence. If needed, on Windows, the environment variable
  280. pointing to the flat file could be in the registry. On UNIX, make use
  281. of an environment variable.
  282.  
  283. The flat file itself:
  284.  
  285.     module="<filename>"
  286.     path="<path>" 
  287.     # Path is to be interpreted for the operating platform
  288.     [profiles="[,]"]
  289.     # comment lines start with hash mark.
  290.  
  291. One module definition starts with "module=" and ends
  292. at next "module=" (or EOF). Lower case names. Case sensitive (subject to
  293. platform). Environment variable suggested to be
  294. PKCS11_MODULE_DB. First module to be installed prompts user and
  295. initialises environment if possible. Suggested default values for
  296. path:
  297.  
  298.     /opt/etc/pkcs11/ or 
  299.     C:\program files\pkcs11
  300.  
  301. Suggested default filename:
  302.  
  303.     module.txt.
  304.  
  305. 2.3.7 Java wrapper for PKCS #11
  306.  
  307. JCA is regarded as too heavy or not suitable for certain applications,
  308. there is a perceived industry demand for a PKCS #11 Java wrapper. A
  309. Java interface definition could be supported as an annex to the PKCS
  310. #11. To be discussed further on the mailing list.
  311.  
  312. 2.4 Editorial matters
  313.  
  314. 2.4.1 Key generation for HMAC
  315.  
  316. Clarify in accordance with resolution on mailing list. Clarify section
  317. "Generic Secret key objects" too, regarding the use of these keys.
  318.  
  319. 2.4.2 Domain parameters
  320.  
  321. Clarify coupling to key generation as suggested on the list.
  322.  
  323. 2.4.3 C_CopyObject - CKM_MODIFIABLE constraints
  324.  
  325. Possible security issue since CKM_MODIFIABLE can be set when
  326. copying. To be discussed further on the mailing list.
  327.  
  328. 2.4.4 Document re-org
  329.  
  330. Mechanisms and keys related to them to separate document(s). "Base"
  331. document to contain object handling and base classes and functions.
  332.  
  333. 2.5 Decisions for PKCS #11 v2.next
  334.  
  335. Since Simon we would like to have a v2.next relatively soon only those
  336. areas where we feel we have a working solution will be included in
  337. this release. These areas are:
  338.  
  339.     The CMS amendment
  340.     Mechanism Objects
  341.     Token Objects
  342.     Slot Objects
  343.     Access Control and Authentication Objects
  344.     WTLS/TLS mechanisms
  345.     New mechanisms and modes (Twofish etc.)
  346.     Key derivation by encryption of data
  347.     Key check values
  348.     All editorial corrections
  349.     Appendix on module management (Normative?)
  350.  
  351. Other items discussed at the workshop need further review by the
  352. members of the mailing list before a decision on whether to include
  353. them in a future version of PKCS #11 or not can be taken. 
  354.  
  355. Simon expects to deliver a first draft of v2.next no later than
  356. November 7. It is expected that this draft will include:
  357.  
  358. á á CMS support
  359. á á Blowfish/Twofish
  360. á á Derive key by encryption
  361. á á CKA_CHECK_VALUE
  362. á á Misc. clarifications.
  363.  
  364. 2.6 PKCS #9 amendment (Magnus)
  365.  
  366. Magnus presented a proposal (also sent to the pkcs-tng mailing list)
  367. about extensions to PKCS #9 to provide some better protection to users
  368. of trusted tokens/devices using the CMS_SIG mechanism in the PKCS #11
  369. amendment. Feeling from workshop is that first suggested attribute
  370. (allegedMIMEType) provides value, but that it is unclear if the other
  371. one (presentationCapabilities) does. Magnus to go ahead with the
  372. definition of the first one for now.
  373.  
  374. 2.7 End of workshop
  375.  
  376. Magnus thanked everyone for their efforts during these two days.
  377.