TODO 3.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172
  1. * Undergoing clean-up:
  2. ** table.{h,c}: Simplify, remove hurdism.
  3. ** agent.{h,c}: Clean namespace.
  4. ** gpgsm.c: Support more than one keygrip.
  5. ** slots.{h,c}: Cleanup lookup function and the rest.
  6. ** p11-closeallsessions.c, p11-closesession.c, p11-findobjects.c,
  7. p11-findobjectsfinal.c, p11-findobjectsinit.c, p11-getattributevalue.c,
  8. p11-getmechanisminfo.c, p11-getmechanismlist.c, p11-getsessioninfo.c,
  9. p11-getslotinfo.c, p11-getslotlist.c, p11-gettokeninfo.c,
  10. p11-opensession.c, p11-sign.c, p11-signinit.c
  11. * Bugs or misfeatures:
  12. ** If more than one certificate with the same keygrip is installed in
  13. gpgsm, only the first one is found. We probably should return them
  14. all and let Mozilla choose among them (if Mozilla supports that,
  15. otherwise we need to make it configurable).
  16. * Missing features:
  17. ** Implement random number generation function C_GenerateRandom.
  18. * Standard ambiguities, or non-conformance in the applications:
  19. ** If the token is removed, the current sessions are closed. If then
  20. a new token is inserted, and the application calls C_OpenSession, a
  21. previously used session handle may be reused. It is not clear to
  22. me what behaviour the standard specifies in this case.
  23. ** Mozilla NSS has this comment (and relies on the assumption):
  24. "check to see if the module has added new slots. PKCS 11 v2.20
  25. allows for modules to add new slots, but never remove them. Slots
  26. cannot be added between a call to C_GetSlotLlist(Flag, NULL,
  27. &count) and the subsequent C_GetSlotList(flag, &data, &count) so
  28. that the array doesn't accidently grow on the caller. It is
  29. permissible for the slots to increase between successive calls with
  30. NULL to get the size."
  31. My reading of the spec is quite different. I do not think it does
  32. say that the slot list can not shrink, at least it does not say
  33. explicitely. Maybe it is a tacit assumption, because the interface
  34. is obviously broken if the list shrinks. However, the spec says:
  35. "All slots which C_GetSlotList reports must be able to be queried as
  36. valid slots by C_GetSlotInfo. Furthermore, the set of slots
  37. accessible through a Cryptoki library is checked at the time that
  38. C_GetSlotList, for list length prediction (NULL pSlotList argument)
  39. is called. If an application calls C_GetSlotList with a non-NULL
  40. pSlotList, and then the user adds or removes a hardware device, the
  41. changed slot list will only be visible and effective if
  42. C_GetSlotList is called again with NULL. Even if C_GetSlotList is
  43. successfully called this way, it may or may not be the case that
  44. the changed slot list will be successfully recognized depending on
  45. the library implementation. On some platforms, or earlier PKCS11
  46. compliant libraries, it may be necessary to successfully call
  47. C_Initialize or to restart the entire system."
  48. Note the phrase "user adds or removes a hardware device" and "the
  49. changed slot list". This implies that removal of a hardware device
  50. could lead to a shrinking slot list. If this is true, then the note
  51. in the NSS code is incorrect, and the NSS code will break if a
  52. driver shrinks the slot list.
  53. However, as long as the assumption is made, we have to comply.
  54. Copyright 2006 g10 Code GmbH
  55. This file is free software; as a special exception the author gives
  56. unlimited permission to copy and/or distribute it, with or without
  57. modifications, as long as this notice is preserved.
  58. This file is distributed in the hope that it will be useful, but
  59. WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
  60. implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
  61. PURPOSE.