W3C   XML Key Management Services WG

DRAFT 1st October 2002 XKMS Teleconference Minutes
Chairs: Stephen Farrell, Shivaram Mysore
Note Takers: Joseph Reagle and Stephen Farrell

Last revised by $Author: smysore $ $Date: 2002/10/04 21:14:52 $

Participants

  1. Shivaram Mysore, Sun Microsystems
  2. Stephen Farrell, Baltimore
  3. Mike Just, Entrust
  4. Phill Hallam-Baker, Verisign
  5. Yassir Elley, Sun Microsystems
  6. Joseph Reagle, W3C
  7. Peter Rostin, RSA Security
  8. Brian LaMacchia, Microsoft
  9. Frederick Hirsch

Regrets

  1. Ed Simon, XMLsec Inc

Status Update

  1. Charter update done and sent to W3C Domain Leader. Changes include new timelines for deliverables and inclusion of new boiler plate for IPR + minor cosmetic changes.
  2. [11:34:19] Mysore: new charter has gone to W3C Domain Leader, should go to AC next.
  3. Specification has been split into 2 parts and info regarding WSS has been removed from part II
  4. Mike Just/Phill - could you please send updated issues list to be posted on the web - once a week or 15 days with a new version of the spec atleast for the next 3-4 weeks so that we can wrap this up.
  5. Clarification from Phill needed regarding Action item 2 of the F2F minutes about what exactly needs to be sent to WSS TC from XKMS group.
  6. [11:34:42] Phil: nothing has been sent to ws-sec yet, we should get the protocol doc more in shape before we do anything

XKMS Specification V2.0 DRAFT (Sept 26, 2002) - Phill Hallam-Baker

  1. [11:37:53] ISSUE 20: what to do with status element?
  2. [11:39:34] Phil: overall status needs to be invalid if any of the constituents are.
  3. [11:40:11] reason codes are informational.
  4. [11:41:43] status value is required, and the normative information
  5. [11:42:03] stephen: what happens if one processes them, and another doesn't, and they get different results.
  6. [11:42:42] phil: the reason code sets an upper bound on what you can return in the status value
  7. [11:43:24] stephen: not sure if that's approriate...
  8. [11:45:49] peter: how do you combine the returns from different services?
  9. [11:47:25] stephen: ACTION phil: phil will rewrite the text for the client status processing algorithm
  10. [11:48:10] stephen: we need the algorithm to be implementable and determinent (consistent answers)
  11. [11:49:15] ISSUE 22: calling multiple requests a compound requests.
  12. [11:50:30] stephen: are we merging xbulk functionality...
  13. [11:50:54] phil: we agreed at the F2F that we would merge their schemas, and create a profile for smartcard sort of operations
  14. [11:51:10] stephen: but a xkms specification doesn't have to support bulk operations?
  15. [11:51:31] phil: yes, not every service would have to support this.
  16. [11:54:42] phil: section 2.1 needs some text that makes it clear that compound request is not supported
  17. [11:57:45] brian: we do want multiple requests, though we presumed that multiple requests would come along without a extra ancestor element.
  18. [11:58:13] phil: probably useful to have a new root with a whole message body, in ws-sec.
  19. [12:01:20] how to show correlation between the requests and responses?
  20. [12:02:05] reagle: if multiple requests with multiple optional feature, and you get a response of "feature not supported" do you know which one it corresponds to
  21. [12:02:34] stephen: sounds similar to existing technology in which I've seen very little interop on this point.
  22. [12:06:18] stephen: in pkix this was all included and eventually they had to write appendix C to profile it all.
  23. [12:09:05] brian: will you ban asynchronous on the compound, and synchronous on the individual requests?
  24. [12:12:53] reagle: I'm concerned that the asynchronous multiple requests will be complex and hairy
  25. [12:13:21] reagle: in which case, what requires us to take all of these things on together? can the scary stuff be isolated?/
  26. [12:13:46] phil: more specs fail by punting, look at dns-sec
  27. [12:14:47] yassir: with the id and nonces, do you plan to protect against compound replay attacks and the singular ones?
  28. [12:15:23] phil: that's an argument for keeping it together, because the protocol document is going to have to address these issues.
  29. [12:17:26] (discussion: how often would someoen have to use the same private key once over multiple proof's of posession)
  30. [12:17:52] brian: each one of these requests need to be processed as if they are distinct, one proof of posession can't work over all of them.
  31. [12:19:13] yassir: what is the meaning of multiple service URIs within their compound then.
  32. [12:20:02] phil: the service URI of the compound corresponds to the compound service
  33. [12:20:44] ACTION phil: will generate some text on this, but I need an answer to the question of when we are compounding requests, do we want to support 3 of one kind, and 4 of another.
  34. [12:21:34] reagle: are these things, locates, validates?
  35. [12:21:42] phil: also XKISS and KRSS, register, etc.
  36. [12:22:34] reagle: try to keep these things simple
  37. [12:24:56] stephen: no argument against all of the same type.
  38. [12:25:03] brian: i would argue against that.
  39. [12:25:09] stephen: use case?
  40. [12:25:41] brian: why add complexity to to the parse rules. doesn't make the server's job easier.
  41. [12:25:57] brian: i can image use cases with multiple register and a validate together.
  42. [12:26:47] stephen: we have two use cases of doing multiple locates (for decrypting email) or multiple registries.
  43. [12:27:11] stephen: my experience with CMP and CMC shows this can get complex.
  44. [12:29:55] brian: we need to think about network connections, i might be a large company that is going to batch a whole slew of requests
  45. [12:31:20] frederick: we need to be clear that there's no ordinality within the constituent requests.
  46. [12:31:48] stephen: i've never seen interop on this.
  47. [12:35:27] phil: let me propose the text and then we can take pot shots at it
  48. [12:37:53] ISSUE 30: Policy URI.
  49. [12:38:21] phil: tweaks to the schema: can be on a locate or validate, can also occur on any prototypes and queries.
  50. [12:38:37] phil: what happens if you specify more than one policy URI?
  51. [12:44:31] stephen: are URIs sufficient, or does it need to be more extensible.
  52. [12:51:12] phil: I'll propose some text and if we can't get agreement will go with restricting it to 1
  53. [12:51:21] ISSUE 31: redesign of ANY
  54. [12:52:42] no comments.
  55. [12:53:52] ISSUE32: RespondWith, does someone have a better idea for the names fo the elements.
  56. [12:53:57] Phil: will send back out to the list.
  57. [12:54:32] ISSUE32: proposal to querykeybinding, to keybindingquery, phil doesn't want to do this because most of the name are little endian
  58. [12:55:02] ISSUE51: X509 attributes, where to put them in?
  59. [12:55:26] how does someone reply with extended key usage
  60. [12:56:07] earlier we said we wanted to avoid leaks from x509
  61. [12:56:49] call agrees: we don't want specific x509 data structures we want leaking over.
  62. [13:03:14] Another call in two weeks.
  63. [13:03:28] Mike will process the issues list with what's been done.
  64. ISSUE 61: Should be put a "Do not" in front of the proposed resolution (ACTION SF to send mail to Blake)
  65. ACTION Phill: send another draft of the spec in a week's time.

Next Telecon