W3C   XML Key Management Services WG

23rd April 2002 XKMS F2F - Minutes
Chairs: Stephen Farrell, Shivaram Mysore
Note Takers: Merlin Hughes, Glenn Fink

$Revision: 1.4 $ $Date: 2002/06/05 00:42:05 $


  1. Bill Burr, NIST
  2. Stephen Farrell, Baltimore Technologies
  3. Shivaram Mysore, Sun Microsystems Inc
  4. Merlin Hughes, Baltimore Technologies
  5. Yassir Elley, Sun Microsystems Inc
  6. Phill Hallam-Baker, Verisign
  7. Trevor Perrin, Sigaba
  8. Anthony D. Kay, Naval Surface Warfare Center
  9. Glenn Fink, Naval Surface Warfare Center
  10. David Remy, Geo Trust
  11. Kefeng Chen, Geo Trust
  12. Yassir Elley, Sun
  13. Daniel Ash, Identrus
  14. Pank Jun Young, National Computer Agency
  15. Jeongwon Yoon, National Computer Agency
  16. David Cooper, NIST
  17. Frederick Hirsch, self
  18. Blair Dillaway, Microsoft
  19. Joseph Reagle, W3C
  20. Matt Flynn, Lockeed Martin
  21. Shawn Raiszadeh, Lockeed Martin
  22. Tim Polk, NIST


  1. Mike Just, Entrust
  2. Ed Simon, XMLSec


Welcome & Agenda Bashing: Chairs

Status Update

Overview of XKMS - Tutorial Presentation, Blair Dillaway, Microsoft

XKMS Requirements - Frederick Hirsch


XKMS Base Specification - Phill Hallam-Baker

XBULK - Merlin Hughes

Action Items

  1. Mike Just and Frederick Hirsch will produce a new version of the requirements document with suggestions incorporated
  2. MJ, FH: to send "issue closed" email and CC www-xkms@w3.org to all the people who sent comments with issues and how they were resolved.
  3. SM, SF: will send reminder to the chairs of W3C, OASIS, WAP Forum, ebXML, etc., with the new version of the requirements document and encourage them to send feedback ASAP.
  4. Minutes to be published by this weekend
  5. Phill will send updated specification in 2-3 weeks time frame with more changes based on feedback
  6. All: Send Spec comments to PHB and CC www-xkms@w3.org by May 13th, 2002
  7. Other AIs will be obtained from the minutes.

Summary/Close: Chairs

  1. SM: The next telecon will be announced on the list. This may possibly be in the earlier part of June 2002
  2. Pending feedback, the requirements document will be frozen for the time being and depending on the W3C process, we will publish it.

Detailed Notes

Merlin's incredibly detailed raw notes are here. I've astracted from Glenn's below since they're shorter, but his original ms-word document is here.

Requirements Last Call Discussion

Issue 1: Will policy URI be explicit or implicit in requests?

Issue 2: Is server required to use SOAP 1.2, 1.1?

Issue 3: Do not require client to cache request to validate returned hash.

Issue 4: Remove requirement to support key usage.

Issue 5: Explicitly add OCSP to protocols

Issue 6: Change MUST to SHOULD for spec requiring how to provide

Issue 7: Require bulk operation

Issue 8: QNames

Issue 9: Servers require integrity via TLS, IPSec

Editors issues (less open to discussion)

Editor Issue 1: Add a definition to Key location service

Editor Issue 2: Constrained device support (don’t require full XML parsing)

Editor Issue 3: DOM APIs in the implementation

Editor Issue 4: Eliminate support for opaque data in requests and responses for the sake of interoperability

Editor Issue 5: Explain relationship to existing PKIX PKI

Editor Issue 6: Give examples of other means of establishing trust relationship with server.

Editor Issue 7: Key Recovery: Will this become mandatory?

Editor Issue 8: Non-repudiation must be removed from out-of-scope

Editor Issue 9: Preclude other authentication mechanisms in 2.5.9

Editor Issue 10: Propose changing MUST to MAY on providing server introspection (2.3.1)

Editor Issue 11: Refine wording of revocation

Editor Issue 12: Requirements on the spec should be MUST not SHOULD

Editor Issue 13: What is “excessive overhead?” (2.1.12)

Editor Issue 14: Why do we need the update operation and the revoke/reapply

Editor Issue 15: XML extensions

XKMS Spec—Phillip Hallam-Baker

Changes from Spec 1.1

Already discussed


  1. Optional Represent mechanism addition to defeat Request Replay attack; DoS protection. Nonce addition to request may introduce IPR problems. May also break statelesseness of protocol
  2. Added mechanism to prevent response replay: Unauthenticated or authenticated
  3. Added mechanism to prevent message substitution
  4. Changed RespondWith processing model: Issue of complexity of allowing non-atomic key requests. Overly complicates the protocol. Blair Dillaway will work on some language to describe the issues.
  5. Added UseKeyWith: Currently Protocol URI, Identifier URI. Use an "<any>" element in manner of SAML?
  6. Use of QNames. Recommended in SAML by the XML gurus. QNames are extensible. Will be using them until problems are noted. Use QNames or URIs? Processing model: load on the application. Extension model of QNames: is it really thought through? Issue of dynamic change of naming context that may break QNames. Tabled the issue. Question generated to the XML Architecture group
  7. Should be possible to reduce X-Bulk spec, but still useful to have a separate X-Bulk spec

Outstanding issues

Examples need updating. Passphrase handling should be expanded.


141: Must/should language for TLS

146: Precise spec of request digest

238: Make status an attribute

261: UseKeyWith

655: WSDL spec

Open floor issues

  1. Versioning: informally added.
  2. Agreed to use XML namespaces for versioning and eliminate the versioning mechanism in the spec.
  3. KeyBinding: What happens if there is more than one matching key?
  4. Locate and Validate: Need a clear definition of Validate (esp. as contrasted with Locate and with X.509 key validation). Separate Locate service is important to the end-to-end PKI crowd. Locate is less assured, validate more. Locate, Validate, etc. can be emulated via SQL queries, etc. Legal entities will be more interested in Validate. Separate services make sense even though the syntax is nearly identical, but need to be defined more clearly. Similarity between the two will allow more code reuse. Locate forces the client to do the validation work locally. Action: Phillip Hallam-Baker to define meaning of “Validate.”
  5. Are the only validity responses: Valid, Invalid, Indeterminate? What about other levels of validity? This is a policy question actually and therefore out of scope.
  6. Is Status=Valid a tautology? Is there any case where Status=Invalid is appropriate?
  7. Many other things might be added to a query such as PassPhrase. What do they mean?
  8. There are many defunct things in the spec that may need to be cleaned up. Resolution: Remove Status=Valid element.
  9. Status vs. Duration: Addressed in the new spec: if the status is valid and the interval returned expires does that imply the assertion is necessarily invalid? Resolution: Change “unspecified” to “omitted.” It is useful to ask if a key was valid at a given point in time. Need more work on duration.
  10. Reason Element: Status should be “RevocationStatus”. (Para 2.7.3) RevocationStatus would imply an underlying PKI with revocation ability. Should be changed to something more descriptive. Is the Reason element redundant? Resolution: Relegate this to the list for followup.
  11. Description fields are unclear. E.g., in IssuerTrust, “Assertion” is used ambiguously.
  12. There is some confusion over the meanings of the definitions. Resolution: In the interest of time, it was decided that these definitions need to be cleaned up via the list.
  13. ResultCode type: Q: What is the difference between NoMatch and Failure results? A: NoMatch may be returned with Success if a searched for key is not found. Q: When would Refused be used? A: In case a requested service was not paid for. Resolution: These codes should be defined so these answers are clear.
  14. KeyUsage: Is a Qname, why not a string? A: It is a restricted Qname. Essentially an enumerated type. Use "xkms:exchange", etc.
  15. KeyBindingType: ID type: if using in a pure mode returns an ID that can be used to later revoke manage the association. ID is the binding from registration to lookup, revoke, etc.
  16. ProcessInfoType: Need an example of the use of OpaqueData type.
  17. Discussed the issue of KeyInfo vs KeyBinding. We want KeyBindingType to be extensible. Currently, KeyBindingType includes ds:KeyInfo, which includes an <any> element. However, we felt that ds:KeyInfo is really something to be put in a Signature, and we wanted a separate extensibility mechanism. The resolution was that we would add an <any> element as a child of KeyBindingType.

    AI: Yassir: Refactor all the Request and Response stuff, including the KeyBindingType definition possibly adding <any> element to KeyBindingType.

X-Bulk Specification: Merlin Hughes