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 $

Attendance

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

Regrets

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

Agenda

Welcome & Agenda Bashing: Chairs

• Merlin and Glenn Fink taking minutes (thanks).

Status Update

• All previous action items as per the 13 March 2002 telecon have been resolved.

Overview of XKMS - Tutorial Presentation, Blair Dillaway, Microsoft

• The presentation slides are available here.

XKMS Requirements - Frederick Hirsch

• The presentation slides are available here.
• Requirements Last Call Issue list is available here

B R E A K

XKMS Base Specification - Phill Hallam-Baker

• The presentation slides are available here

XBULK - Merlin Hughes

• XBulk Specification has been updated as per the new version of the XKMS Specification. Please send your comments to the list.

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 [email protected] 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 [email protected] 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?

• Source: Dennis Pinkas
• URI added to both request and response in current version
• Putting explicit policy statements is not feasible, use signature and URI ref instead. Use “name” of the policy stmt.
• Context of electronic signature validity legislation, nonrepudiation
• Use URI of the destination, not a proxy URI since XKMS is a simple request/response protocol
• Persistence of URLs is a problem. Historical traceability difficult if URL changes
• Policy binding should be established out-of-band. No way to view policy via XKMS.
• Assertion: Delegate this issue out of scope. Up to user.
• Resolution: Issue is application context specific, URI should be bound to the service URI. Clarification should be made in the spec vice the requirements. Policy should not be confused with legal issues. Policy is a set of XKMS rules as far as XKMS is concerned. If policy changes, XKMS not responsible. Policy issue is out of scope.

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

• Source: Blair Dillaway
• SOAP 1.1: what are the intellectual property issues? 1.2 clarifies this. 1.2 built on 1.1 with basically no changes. XP expects SOAP to be Intellectual Property Royalty (IPR) free.
• 1.2 is stable, cleaner.
• What is the fall-back position? Can we still support 1.1? Should we? We don’t really want to do lots of interop testing with 1.2. No tools exist. Lots of SOAP 1.1 tools exist.
• Yassir, SUN: Linkage to SOAP is thin. Can we make XKMS SOAP agnostic? XKMS is self-contained. Currently not a requirement. How can a non-SOAP binding identify itself as a service?
• Resolution: Target 1.2 for normative purposes. Add requirement in the bindings section: Services must implement SOAP 1.2, and may have other bindings. E.g., constrained devices, etc. May also provide 1.1 interop or profiling (different namespaces, etc).

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

• Source: Pinkas
• Specifying that there needed to be a hash was not necessary. Reqs doc should not specify.
• Resolution: Out of scope.

Issue 4: Remove requirement to support key usage.

• Source: Pinkas
• Resolution: Do not remove requirement. Revise requirement to be less general. Key usage may be specified at registration. Recommend closing issue.

Issue 5: Explicitly add OCSP to protocols

• Source: Pinkas
• Change MUSTs to MAYs? SHOULDs?
• Delete requirement for CRL support?
• Currently, w/o CRL response is “Incomplete” not failure.
• Need a “conformance profile” in the specification.
• Resolution: 2.5.4: Needs clarification. Delete statement requiring X.509 compatibility. Reword.

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

• Source: Pinkas
• proof of possession.
• Resolution: Issue is pertainent to specs, not the requirements document.

Issue 7: Require bulk operation

• Source: Hirsh
• Resolution: Leave alone

Issue 8: QNames

• Source: Reagle
• Resolution: QName issue is out of scope for the requirements

Issue 9: Servers require integrity via TLS, IPSec

• Source:
• Resolution: Reword to include other possibilities of integrity protocols. Remove “no-security” tag.

Editors issues (less open to discussion)

Editor Issue 1: Add a definition to Key location service

• Source: Pinkas
• Resolution: As recommended

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

• Source: Yassir Elley
• Resolution: Specification not tailored to highly constrained devices that cannot support XML. Out-of-scope.

Editor Issue 3: DOM APIs in the implementation

• Source: Gunderson
• Resolution: Question unclear. Out of scope.

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

• Resolution: Retain support for opaque data since it can be ignored

Editor Issue 5: Explain relationship to existing PKIX PKI

• Source: Anonymous
• Should we provide guidance as to when to use XKMS vice other PKI protocols.
• Resolution: Already have motivation text in the introduction. Add a few words explicitly saying when to use XKMS.
• Typographic
• Editorial issues accepted and resolved as proposed
• Many posted/handled on the list.

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

• Source: Pinkas
• Remove perceived bias toward trusted list; provide additional examples
• Resolution: Reword

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

• Source: Arsenault
• Resolution: Spec issue only

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

• Resolution: Fix the conflicting requirement 2.5.2.
  It was "The specification SHOULD enable finer granularity of key usage definition to support compliance requirements. Signatures may be supported for specific purposes, such as approval, authorship or integrity for example. One possible way of meeting this requirement is to define a <Purpose> subtype for the <KeyUsage> element."

  and is now

  "A key registration request MUST be able to specify the appropriate key usage of a key."

Editor Issue 9: Preclude other authentication mechanisms in 2.5.9

• Source: Arsenault
• Resolution: Misinterpretation. Not precluding any mechanisms.

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

• Source: Hirsh
• May time out on these requests. Return HTTP 404 error?
• Should there be a “Not Implemented” result code? This would require servers to implement a responder for this code. Would complicate the WSDL.
• Polite servers should respond with SOAP fault.
• Could remove requirement entirely.
• Resolution: Mechanisms of introspection are out-of-scope.
• Resolution: Revise requirement - "A server MAY be deployed that implements a subset of XKMS service functionality, such as Locate but not Validate, for example."

Editor Issue 11: Refine wording of revocation

• Source: Pinkas

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

• Source: Yassir Elley
• Resolution: Change 2.1.8 to MUST

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

• Source: Shivaram
• XKMS must not require there to be a central database.
• Resolution: Change 2.1.12 to say that specs should “minimize overhead” instead. Add reference to the “4 -corner” application model. Clients need only talk to the current XKMS server itself. Servers may talk but should minimize the overhead for the client.

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

• Source: Pinkas
• Resolution: As proposed

Editor Issue 15: XML extensions

• Source:Pinkas
• Resolution: Allow XML extensibility since such (XML Namespace) extensions leverage XML extensibility and may be ignored.

XKMS Spec—Phillip Hallam-Baker

Changes from Spec 1.1

Already discussed

• Register split into 4 comps
• Explicit description of processing steps: Handling of pending requests

Additions

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.

Others

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

• Differences from XKMS
• Correlation of request/response batches
• Has multiple BulkPrototypes including a ClientInfo field that allows the client to identify each binding returned.
• Status check very simple
• Issues
• Profile inherited behavior
• Do we need Authentication element?
• Support partial/paged results
• Support bulk revoke? Reissue? Recover? Much less common.
• Specify e.g., X.509 Dname templates
• Support multiple KeyBinding results? Probably not
• Extend prototype or encapsulate it?

Closing

• Review of action items (on web site)
• Allow at least two weeks of work via list and then have a telecon in June.
• Action: Yassir will draft a new version of the KeyBindingType meanings.
• Action: Blair to send proposal on Locate/Validate
• New version would be helpful. All issues are tracked on the list.
• Too early to do a complete conformance check.