XML Key Management Services WG

DRAFT 17 August 2004 XKMS Teleconference Minutes
Chairs: Stephen Farrell, Shivaram Mysore
Note Takers: Shivaram Mysore

Participants

• Shivaram Mysore
• Jose Kahan, W3C
• Pete Wenzel, See Beyond
• Rich Salz, Datapower
• Guillermo Alvaro, Trinity College
• Stephen Farrell, Trinity College
• Patrick Curran, Sun representing W3C QA group

Regrets

• Tommy Lindberg

Agenda

• Announcements
• Review last telecon AIs
• Current issues list
• Interop Matrix

Minutes

• In the last telecon we had the following AIs which are still carried forward:
  
  1. AI: All suggest possible events/venues for doing face-to-face interop testing within the next six months. Post suggestions to the list. Leave OPEN. - CLOSED - since we've agreen on-line testing in September
  2. AI: Jose turn Guillermo's XML into an on-line questionaire - IN PROGRESS STILL OPEN
  3. AI: All Send comments on updated schema to the list STILL OPEN
  4. AI: Tommy: As a result of the schema update (namespace URI changed), all examples have to be regenerated. Thanks to Tommy for volunteering to do this. STILL OPEN
  5. AI Jose: How we get the new schema to be placed in this new location - http://www.w3.org/2004/07/xkms.xsd ? Shivaram: Just update the exisiting one till the spec gets Recommendation status STILL OPEN (though maybe we won't need it - AI chairs: re-check with list as to whether anyone's product code requires this given current issue resolutions.)
  6. AI: Jose and Guillermo to work on the interop document associated with the Interop Matrix which will help walk thro' the interop scenarios. STILL OPEN
• AI: Rich Salz - Send a proposal to resolve the QName issue in schema which is not allowing extension for non-repudiation usage. STILL OPEN, though maybe no longer needed - check when Shivaram posts the new schema/spec edits.
• AI: Guillermo - Add more test messages to the interop matrix. Send out a template to the list so that others can contribute test messages easily. STILL OPEN
• Since Patrick understandably wasn't familiar with XKMS we described the issues we have with QA to Patrick who mainly is going to go away in think whether there're similar things he's seen in the past and continue the discussion via email. The non-trivial issues are:
  • Writing tests/scenarios for handling compound messages. Patrick didn't like this feature since it makes the spec. quite hard to test (and at least one chair agrees with him:-). He figured our scenarios approach might be the best that can be done, but may come back to us with additional advice later on.
  • The WSDL issue (how a client can know whether a server does XKRSS and/or XKISS) also came up. This is somewhat easier and Patrick's recommendation was that we mandate that if some descriptive mechanism is to be used, then that MUST be WSDL. Shivaram pointed out that we have to allow non-SOAP bindings, but Patrick said that in that case, even though its not automatable, mandating that implementors MUST somehow publish a list of which interfaces they support is useful - e.g. in the HTTP case, if there're a set of human readable web pages. AI: Shivaram check what we currently say in the specs (particularly the bindings) and suggest chages as required. AI: All/any - anyone want to publish a WSDL spec. for XKMS 2.0?
• After that we had a few status reports:
  • Shivaram will post a revised editor's copy of the spec in the next few days including resolutions to all open issues. Checking this ought to be the main agenda item for our next call.
  • Shivaram/Stephen desribed the chats we had in San Diego (incl. Phill part of the time)
    • Qname -> URI stuff
    • Order of encryption/signing is fine as is, maybe the spec could be clearer but its there already
    • We figured some wording to say what MUST be input to the signing process when XKMS messages are signed - Shivaram has the words, but basically it amounts to: the entire message and no messing with XPath etc and leaving out bits of the XKMS message. The reason this needs saying is that the signature could be in the SOAP header or elsewhere, so we can't mandate only one single scheme.
    • We'll mandate that everyone MUST support private key encryption (for recover and centrally generated keys) using shared secrets, that is, a client/server which only supported asymmetric de/encryption of private keys would not be compliant. (Roland - is that ok?)
  • Guillermo and Tommy have been doing more interop (Tommy's now/soon-to-be on vacation). XKISS working out fine, some issues to be with Guillermo's use of crypto for PoP, not protocol things though, just crypto-use stuff.

Next Telecon

• Next Telecon(s)
• Date: August 31, 2004; Time - 8:30AM - 9:30AM PST, 11:30AM - 12:30PM EST check time for your local area here
• Zakim Bridge (617) 761-6200 Code: "XKMS"
• Future telecons at the same time on TBD
• Agenda: More discussions on Interop Matrix; issue list