XML Key Management Services WG

DRAFT 10th July 2002 XKMS Teleconference Minutes
Chairs: Stephen Farrell, Shivaram Mysore
Note Takers: Stephen Farrell, Mike Just and Shivaram Mysore

Participants

• Shivaram Mysore, Sun Microsystems
• Stephen Farrell, Baltimore
• Mike Just, Entrust
• Phill Hallam-Baker, VeriSign
• Ed Simon, XMLsec
• Yassir Elley, Sun Microsystems
• Merlin Hughes, Baltimore

Regrets

• None

Status Update

• Previous Action items from the F2F have been completed
• Charter update in the works. Stephen/Shivaram will send out the version by next week for review. Changes include new timelines for deliverables and inclusion of new boiler plate for IPR + minor cosmetic changes.

• XKMS Requirements Status
• No additional technical comments received
• No further comments from DPLOY (IPSEC) group. Merlin indicated they had additional requirements for specifying detailed certificate content, though this is out-of-scope for XKMS. Stephen will talk to DPLOY to see if they have further comments.
• We need to demonstrate that other groups either have comments, or do not have comments on the requirements. We can then use this information to demonstrate "due diligence" as part of the Requirements Last Call. Shivaram will close the loop with W3C regarding progression through LC.
• Yassir was concerned about the wording regarding SOAP reliance. Stephen indicated that the language is general enough now so that dependence upon a particular SOAP version can be indicated in the main specification.

• XKMS Specification V2.0 DRAFT 9 - Phill Baker
• Changes made since last F2F:
  1. Protocol versioning removed (as agreed at F2F)
  2. 1-phase, 2-phase and pending request/response added
  3. Sections 2 and 3 have switched
  4. RespondWith now has properly formatted QNames
  5. New examples starting in Section 3 (generated from actual code)
  6. Example of using DNS SRV records to locate XKMS services
  7. Locate now using KeyBindingQuery instead of KeyInfo
  8. PassPhrase fixed considerably (it was used in multiple ways). Used in support of authenticating revocation requests. Exclusively base-64 MAC value now (4.2.3) and (optionally) sent to the service as part of a revocation request.
  9. UseKeyWith clarified. Some question regarding how different protocols would be added to the current list.
  10. Reason element cleaned up to use QNames.
  11. Using XML Encryption for private keys.
• Further changes/issues discussed:
  1. Keep ProcessInfo since ##other is there already? It seems that some way to carry additional information is helpful. Merlin thought that ProcessInfo offered some convenience as the additional information would be better encapsulated. There was agreement to remove ProcessInfo, but keep ClientInfo (may be munged with request-id). [see Actions below]
  2. UseKeyWith is extensible. Yassir questioned why KeyUsage is not. Phill and Stephen suggested that cryptographic key usage was limited to encryption, signature and key exchange.
  3. Regarding UseKeyWith, Stephen suggested restricting the uses to particular protocols. Phill indicated that there might be some more general uses though, so use of a URI is appropriate.
  4. Yassir has a proposal for combining Reason and Status elements. In most cases, Reason is defined within Status, though Yassir had an example in which the client may want to ask the service to not perform revocation checking. [see Actions below]
  5. Blair's suggestion for including bulk locate and validate operations raised the issue of whether to include XBulk directly into the main spec. Stephen was worried about complicating basic/minimal client implementations.
  6. Yassir raised some confusion regarding the different passphrases. Stephen and Phill indicated there are 3 types:
     1. revocation passphrase
     2. shared secret generated out-of-band by service
     3. "pass-through type" such as SecurID
  7. Will match RSA parameters to PKCS #1
  8. revocation passphrase: try reference rather than invent if possible, maybe include updating this value on use
  9. Reason needs to be extensible (currently isn't - a bug)
• Changes not made yet:
  1. protocol part not yet out
  2. keybinding not re-factored yet (some list discussion necessary?)
  3. revisit bulk/base spec distinction?
  4. locate/validate distinctions
  5. dns sample is a sample (careful with app b dns srv rec stuff)
• Other issues for consideration:
  1. Should we allow the user to have and re-use a single revocation passphrase (similar to the way S/KEY works)?
  2. Construct separate elements for BulkRegister, BulkLocate, BulkValidate or use maxOccurs with Register, Locate and Validate? Do we want to support bulk location and validation at all?
  3. Do we want to include Yassir's suggestions for changes to KeyBinding?

Action Items

1. Stephen will send an updated charter to the list within the week - Expect to have a LC on the specification in November 2002
2. Stephen will query DPLOY folks for comments on requirements
3. Shivaram will prepare/package the requirements for W3C team to progress through WG LC.
4. Specification - Phill:
   1. Remove ProcessInfo (##other can be used instead). Include a new ClientInfo element (helpful for maintaining user state). A service must not alter ClientInfo contained in a request. Add an error/warning indicating that the ClientInfo is rejected by the service (e.g. because of size).
   2. Change PassPhrase element name to RevocationPassPhraseDigest.
   3. Reason element should be extensible. Use Yassir's suggestion for combining Reason and (resurrected Status)
   4. Phill will match RSA parameters in Section 7, to correspond to PKCS #1 in support of CRT computations (for decryption and signing).
   5. protocol/payload security and protocol bindings will be moved to another spec. (for which Phill has already published a first draft)
   6. Next version of spec expected in a few weeks with a pre-F2F version by 3rd week of August (2 weeks before F2F)
   7. Follow-up version expected soon after F2F for WG LC
5. Shivaram will investigate Sun hosting XKMS at start of September to coincide with ws-security
6. All: Send comments to the list on the XML Protocol LC - see email
7. All: Spec reading must for the next F2F!!

Next Telecon & Face to Face details

• Next F2F
• Probable Dates: September 3 or 6th, 2002 - around ws-security F2F meeting
• Venue: San Francisco Bay Area
• Time: whole day

• Next Telecon
• Date: If needed, one shall be hosted before the above F2F