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
- Bill Burr, NIST
- Stephen Farrell, Baltimore Technologies
- Shivaram Mysore, Sun Microsystems Inc
- Merlin Hughes, Baltimore Technologies
- Yassir Elley, Sun Microsystems Inc
- Phill Hallam-Baker, Verisign
- Trevor Perrin, Sigaba
- Anthony D. Kay, Naval Surface Warfare Center
- Glenn Fink, Naval Surface Warfare Center
- David Remy, Geo Trust
- Kefeng Chen, Geo Trust
- Yassir Elley, Sun
- Daniel Ash, Identrus
- Pank Jun Young, National Computer Agency
- Jeongwon Yoon, National Computer Agency
- David Cooper, NIST
- Frederick Hirsch, self
- Blair Dillaway, Microsoft
- Joseph Reagle, W3C
- Matt Flynn, Lockeed Martin
- Shawn Raiszadeh, Lockeed Martin
- Tim Polk, NIST
Regrets
- Mike Just, Entrust
- 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
- Mike Just and Frederick Hirsch will produce a new version of the
requirements document with suggestions incorporated
- 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.
- 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.
- Minutes to be published by this weekend
- Phill will send updated specification in 2-3 weeks time frame with more
changes based on feedback
- All: Send Spec comments to PHB and CC www-xkms@w3.org by May 13th,
2002
- Other AIs will be obtained from the minutes.
Summary/Close: Chairs
- SM: The next telecon will be announced on the list. This may possibly
be in the earlier part of June 2002
- 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
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
- 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
- Added mechanism to prevent response replay: Unauthenticated or
authenticated
- Added mechanism to prevent message substitution
- 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.
- Added UseKeyWith: Currently Protocol URI, Identifier URI. Use an
"<any>" element in manner of SAML?
- 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
- 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
- Versioning: informally added.
- Agreed to use XML namespaces for versioning and eliminate the
versioning mechanism in the spec.
- KeyBinding: What happens if there is more than one matching key?
- 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.”
- 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.
- Is Status=Valid a tautology? Is there any case where Status=Invalid is
appropriate?
- Many other things might be added to a query such as PassPhrase. What do
they mean?
- There are many defunct things in the spec that may need to be cleaned
up. Resolution: Remove Status=Valid element.
- 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.
- 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.
- Description fields are unclear. E.g., in IssuerTrust,
“Assertion” is used ambiguously.
- 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.
- 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.
- KeyUsage: Is a Qname, why not a string? A: It is a restricted Qname.
Essentially an enumerated type. Use "xkms:exchange", etc.
- 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.
- ProcessInfoType: Need an example of the use of OpaqueData type.
- 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.