XML Key Management Services WG

DRAFT 08 March 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
• Tommy Lindberg
• Vamsi Motukuru, Oracle

Regrets

• Rich Salz, DataPower

Agenda

• Announcements
• Review last telecon AIs
• New Issues - discussion & resolutions

Minutes

• In the last telecon we had the following AIs:
  
  1. 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
  2. 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

  3. Spec issues since last concall

     • section 8.1 discussion:

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

     • 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??
  4. Summary of Interop form - Jose:
     • Service endpoint providers should indicate what test cases are supported. - AI: All Service Endpoint providers - DONE
  5. AI Jose- Prepare for PR - In Progress
  6. Section 9 - Conformance - Split XKISS and XKRSS - AI: Jose - propose alternative text. - In Progress
  7. AI: Tommy- update Samples on the Web Site -In Progress
  8. AI Shivaram: Send email to the list on closed issues - DONE
  9. 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.

     Stephen - No changes required in our spec -DONE

  10. AI Shivaram: Part 2 of the spec still has references to SOAP1.1 - change to SOAP1.2 - DONE
  11. 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.
  12. AI Shivaram: Part 2: Section 4.1 there is no definition of Payload identifiers; Change Text Payload & TLS URIs to text - DONE
  13. 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 - DONE
  14. 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. -WSDL file published to the list

      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. - DONE

  15. Move to PR - pencil in around 2nd week of March - chairs, Jose, W3C team. Jose preparing docs for the same. -In Progress
• Notes from today's meeting
  1. Fix issue 332-tl1 as per Stephen/Tommy; fix by adding sentence: XKMS responders should ignore Attribute value
  2. Issue 332-tl2: Due to XML Sig specification incompleteness, this issue is a manifestation of this. Hence, keep this issue open and add this to implemenation report
  3. Issue 332-tl3: We may be able to accept this change if too many implementers don't complain or doesn't break anything. AI Tommy: suggest text and schema changes
  4. Issue 332-tl4: If a server doesn't support time instant or is too old or value for it - The Server MUST indicate failure. This indicates adding a result minor codes - UnSupportedTimeInstant, OutOfBoundsTimeInstant. AI: Tommy to provide text and schema changes.
  5. Issue 332-tl5: AI Shivaram & Stephen to look at the spec again. Resolution inclining towards - Responder does not have to support both in one message. Don't change schema.
  6. Issue 332-tl6: Ok. Make change. Don't change semantics for CompoundRequest. RespondWith MUST NOT be present in compound, pending or status request. This is a AI: for Shivaram - Editorial
  7. Issue 333-jk: Optional items - When a client responds with a Optional element that is not supported by Server, then use a ResultMinor code - OptionalElementNotSupported. Failure and MessageNotSupported is already supported. Result Major=Sender and ResultMinor=MessageNotSupported ; AI Stephen: Send text to list.
  8. Issue 334-jk: Resolution: Clients and Responders MAY use KeyName for HMAC validation. Alternatively, they may use identity or other inforamation derived from security binding.
  9. AI Jose: update implemenation report with not fixing PGP issue.
  10. AI Shivaram: update issues list to include [Editorial], etc

Next Telecon

• Next Telecon(s)
• Date: March 22th, 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, will be announced.
• Agenda: TBD