XML Key Management Services WG

DRAFT 22 February 2005 XKMS Teleconference Minutes
Chairs: Stephen Farrell, Shivaram Mysore
Note Taker: Shivaram Mysore

Participants

• Shivaram Mysore
• Jose Kahan, W3C
• Stephen Farrell, Trinity College
• Guillermo Alvaro, Trinity College
• Pete Wenzel, SeeBeyond
• Vamsi Motukuru, Oracle

Regrets

• Tommy Lindberg

Agenda

• Announcements
• Review last telecon AIs
• Stephen: Impact of SHA1 vulnerability
• Jose: Conformance Section and Part2 - Security Bindings
• Jose: Implementation report - WSDL

Minutes

• In the last telecon we had the following AIs:
  
  1. AI: All - Don't forget to start thinking and writing down your ideas on what should constitute a compliant XKMS and/or XKRSS clients/servers based on your experience. Do we need to have several levels of compliancy or just one? Should they always support asynchronous, synchronous, and compound requests? DONE
  2. AI: Shivaram, Stephen and Jose will start to prepare documents etc for the formal request for transition to PR. (We don't have a deadline there, but I guess the same mid-January one would be right.) STILL OPEN - In Progress
  3. AI: Jose will check whether we need to extend the charter for this (we're formally to-be-done by year's end at the moment) STILL OPEN

  4. Spec issues since last concall (AI: Shivaram to include resolutions of these)

     • section 8.1 discussion:

       Use of stringprep's password profile was generally accepted by the group as the way to deal with this issue. - basic version w/o constraints like folding of whitespaces, case sensitiveness, etc. - use Ed's version + look at Jose. AI: Shivaram - update Spec for Section 8.1 - DONE

       Does any appendix (C) example needs to be modified - both XKISS and XKRSS - AI: Tommy will update examples as needed once text is ready. -In Progress

     • partII section 4.1 needs additional editorial text describing the tables - In Progress
     • notbound authentication requires a bit more text and examples and maybe a clarified test case (to make clear where id can go) - CHECK??
  5. Summary of Interop form - Jose:
     • AI for Vamsi to work with Jose and update the interop report -somethings that were not working some time ago are now working - DONE
     • Service endpoint providers should indicate what test cases are supported. - AI: All Service Endpoint providers - STILL OPEN
  6. AI Jose- Prepare for PR - In Progress
  7. Issues discussion:
     1. 328-jr - Fix this - DONE
     2. 329-tl - Close this issue - declined - DONE
     3. 330-tlr-3 - Consider text changes, possibly make note in security considerations, explain RevocationCode better - AI: Shivaram - DONE
     4. 331 - Servers may ignore an UnverifiedKeyBinding's Indeterminate value as status value & Clients may set an Indeterminate status value. - DONE
  8. Section 9 - Conformance - Split XKISS and XKRSS - AI: Jose - propose alternative text. - In Progress
  9. AI: Tommy- update Samples on the Web Site -In Progress
• Notes from today's meeting
  1. AI Shivaram: Send email to the list on closed issues
  2. Stephen: Do we have to change the default HMAC-SHA1 to say HMAC-SHA2 due to the recently announced weakness? AI Stephen: send note to IETF, PHB and others as required to get some clarification. Checkout Bruce Schneier's blog on impact of SHA1 weakness for more information.
  3. AI Shivaram: Part 2 of the spec still has references to SOAP1.1 - change to SOAP1.2
  4. Jose: After carefully reading Section 4 Security Bindings of Part II and Section 9 Conformance of Part I, the Security Bindings don't seem to give anything to the spec, except for some vague hints. Section 4 could have been interesting, but the text is incomplete, hard to understand, and IMHO it is useless as it is. Moreover, we didn't test those bindings (because they are untestable, just hints) and the feedback I got from developers seems to be that they didn't even read this section. Vamsi even commented that the XKMS spec is about Key Management and that Section 4 seems to be more about transport security and that we should keep them separate. The only place in the spec where Section 4 seems to be referred to is in Section 9 of Part I. The last table, Security Enhancements, is also hard to read and ambiguous. For example, I understand in the first row that it is required that one implements Locate without any security enhancement and that it is recommended that no security enhancements are used for the other operations. Then we get a list of security enhancements where all but one are recommended.
  5. AI Shivaram: Part 2: Section 4.1 there is no definition of Payload identifiers; Change Text Payload & TLS URIs to text
  6. AI Shivaram: Part 1: Just before para 355 in table 9 of section 9, fix table features; change "payload authentication I" to "payload authentication". Remove comments about section 4
  7. Jose: W3C's QA team is asking for a XKMS client which can talk to any server. They request that service providers publish a WSDL profile.

     There was considerable discussion on this (Jose, Shivaram, Vamsi, Stephen). XKMS is a combination of Application and on-the-wire protocol. As a part of the sample, we are demonstrating a combination of this interoperability. As Applications are involved, Service Level Agreements (SLAs) come into picture which means a configuration issue - either on the client or server side. What we mean by this is - a service may suggest a 2048 bit RSA key size, and this may be a weak one for another service which will only consider 4096 bit keys. Moreover, XKMS is supposed to be agnostic about other riding protocols like HTTP, HTTPS, S/MIME and SOAP. Hence, publishing a WSDL will only cater to a Web Services realm and not others.

     It was suggested and generally accepted that a WSDL be published and be included in the samples.zip file as a sample.

     AI Jose: send this minutes to the QA team to start of a email thread and arrange for a conference call to resolve this issue.

  8. Move to PR - pencil in around 2nd week of March - chairs, Jose, W3C team. Jose preparing docs for the same.
  9. AI Stephen: send email to list asking for success stories. - DONE

Next Telecon

• Next Telecon(s)
• Date: March 8th, 2005; Time - 4:30pm GMT/Dublin (if you're unlucky enough not to live in Dublin, you can check time for your local area here:-)
• Zakim Bridge (617) 761-6200 Code: "XKMS"
• Future telecons (if needed) at the same time on March 22nd
• Agenda: Final issues for moving to PR