One fairly major correction:
 
The 4-Corner model is in-scope for XKMS, the 'hat' of the 4 corner model is out of scope.
 
        Phill
 

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: PATO,JOE (HP-PaloAlto,ex1) [mailto:joe_pato@hp.com]
Sent: Wednesday, August 01, 2001 3:45 PM
To: 'www-xkms-ws@w3.org'
Subject: XKMS Workshop minutes (draft)

Included are draft minutes for the XKMS Workshop. Please let me know if you have any suggested changes. Note that the links to presentations don't work yet - if you presented a set of slides at the meeting, please do send a copy to Joseph Reagle@w3.org so that we can get them posted (and get these links to work!)
 

Joe Pato
Principal Scientist
Trusted E-Services Lab - HP Labs
Chief Technology Officer
Internet Security Solutions Division
<http://www.hp.com/security>  

 

HP Labs Cambridge
1 Main Street, 10th Floor
Cambridge, MA   02142
Phone: (617) 679-9376
Fax 1: (617) 679-9330
Fax 2: (781) 674-0142

 

 

XKMS Workshop
July 19, 2001, Redwood City, CA

Draft Meeting Minutes

Scribes:
Part 1: Shivaram Mysore [shivaram.mysore@sun.com], Sun Microsystems Inc
Part 2: Frederick Hirsch [hirsch@zolera.com]
 
Minutes augmented with material from Jean Pawluk, Conclusive Logic

Part 1

9.00 - 9.35 (35 minutes): Introduction
  1. Danny Weitzner, The question on the table - shall we constitute a W3C activity for XML Key Management Services? (10m)
  2. Group, Introductions Around the Room (15m)
  3. Joe Pato, Agenda (5m)
  4. Group, Agenda Bashing (5m)

9.35 - 10.30 (55 minutes): Requirements I
    Core Requirements:
  1. Phillip Hallam-Baker, VeriSign - W3C XKMS workshop position paper.
    • The Original presentation can be found here.
    • XKMS is proposed to reduce barriers in PKI deployement for both Customers and Manufacturers.
    • XKMS *must not* do X509 in XML syntax
    • Traditional PKI was not designed to be complicated. It just became so over a period of time. Now that we have a chance to design this from ground up, we should also think of how this can best fit new devices and applications. We should be able to sell security to Moms and Dads.
    • XKMS will allow thin clients that are unaware of the PKI system deployed. Complexity is migrated to middleware and away from application (and away from clients entirely).
    • Q: Joseph Reagle, W3C - Will there be a dependency on XML Query?
      A: Phill - No Dependency is desired. XML Query is not fully baked with request/response structures. It is based on SQL and exposes internal structure of the infrastructure which is not desired.
  2. Mark Curtis, Reuters - XKMS for B2B electronic services - A consumer perspective
    • The Original presentation can be found here.
    • The presentation gave an overview of what Reuters is all about and their business objectives
    • B2B Issues:
      • Operability across multiple domains
      • Interoperability between domains
        • trust relationship
      • Business relevant trust attributes
        • context of business
        • meta data for acceptance
    • Recommendations
      • Push ahead low tier service definitions
      • Outline scope of high tier requirements, e.g., Who, what and context with matching info to tell relying party that information is defined and is associated with particular trust levels
      • Map relationship with other standards
    • Q: Danny Weitzner, W3C - Higher level trust - What user level are you talking about?
      A: Mark - At a higher lever - do we understand what attributes are what we can do about it.
    • Q: Danny Weitzner, W3C - Example?
      A: Medical industry has a different privacy statement and kind of information collected as compared to a Financial industry's privacy statement and kind of info collected.
    • Comment: Phill H. Baker, Verisign - Read purpose of XML Trust Assertion Service Specification, XTASS [ research note ]. SAML is not a competitor to XTASS. XTASS could be used in some parts of XKMS/X-KRSS
    • Q: Mike Just - Can we use the key level for XYZ?
      A: Mark - This is too low level. We need a higher level of Security.

10.30 - 10.45 break

10.45 - 12.30 (105 minutes): Requirements II
    Additional areas - bulk registration, 4-corners, inter-domain trust
  1. Merlin Hughes, Baltimore (20m): Bulk operations to support smartcard management (X-BULK)
    • The Original presentation can be found here.
    • Use Cases: Smart card factories, device factories (TPMs like TCPA platform modules)
    • Goal is to deliver a separate spec that defines batch registrations using XKMS core definitions.
    • Q: Joseph Reagle, W3C - Does this take parts of XKMS and stick it into XBULK?
      A: Merlin - Yes, here is an example. See slide on X-BULK Request
    • Q: Mack, Bank Of America - Bulk process is highly tailored. I am missing the value add here :-(
      A: Merlin - Things are not tied to a particular vendor
    • Q: David - XBULK answers only one aspect of bulk key registration. There are lots of other items that are required to be answered
      A: Merlin - Agreed.
  2. Mike Just, Entrust (20m): XKMS to satisfy card manufacturing systems
    • The Original presentation can be found here.
    • Q: Barbra Fox, Microsoft - On Key Registration Service Requirements slide - Any person can get any info on the key
      A: Mike - Possible
    • Entrust talked to card manufacturers like Gemplus, Schlumberger, etc on requirements for cards to support XKMS (see slide 1 and 1 contd.). It was suggested by the group that a sub team should work on the card manufacturer requirements and then suggest it to the working group.
    • Q: Mack, BOA - On KISR - my suspicion is that I haven't found an application in the Bank that does some kind of policy, trust anchors, audit trails. They never look into this.
      A: Mike - Fair observation. May be in a later release. This does not have to be done today.
    • Q: Mack, BOA - Is the WAP device connecting to a service and then determining if it is negotiating or doing a secure transaction?
      A: Mike - No. It is the service which is providing the info and not the WAP device trying to understand what is being done now.
  3. Blair Dillaway, Microsoft (20m): Beyond XKMS - requirements for a .NET world
    • The Original presentation can be found here.
    • Scope of XKMS - Syntax of Context to be defined and not its Semantics. See Slide on Contextual Trust Management.
    • Q: Mack, BOA - Contrast simple XKMS with SAML
      A: Blair - Rationalize this effort with SAML, XTASS, etc.
    • Q: Jeff, Oblix - Envision Context as a collection of attributes?
      A: Leave it to the application. For N-Party transactions, TLS, SMIME, etc will not cut it, but, will require message-level security.
    • Q: Danny, W3C - What are your requirements regarding the last one?
      A: Blair -
      • Define standard for carrying authentication info and encrypted message.
      • How can we do this with Asynchronous messaging and N-way? It will become complicated.
      • Can XKMS wait for XMLP and come up with a generalized solution?
    • Q: Ben - What Microsoft tools implement these?
      A: Blair - Microsoft has XML DSig in .NET Beta 2. They also a prototype of XML encryption internally
  4. Daniel, Identrus - XKMS and the four-corners model
    • The Original presentation can be found here.
    • Identrus deals with Trust between Banks
    • XKMS is good because it moves trust from customer to the Bank
    • Higher level assertions are welcome and useful to us.
    • Context is very important to us. Mack, BOA added - If too many messages are going on between parties, it is difficult to track. But, with XKMS and SAML we can pack lot more info into a message and hence it is more useful and practical especially in the financial industry.
    • How we rely trust information between customers and bank is very important to us.
    • Phill Baker said Decouple client with PKIX
    • Joe Pato, HP - Trust Relationship between consumer, Trust provider and Peer to Peer ones must be clearly defined.

XKMS Workshop Notes, Part 2

7-19-01, Frederick Hirsch

  1. XMS version 1.1/1.2 proposal
  2. XBulk
  3. Scope
  4. W3C activity process
  5. Next steps

1. XMS Version 1.1/1.2 Proposal

Dr. Phillip Hallam-Baker, See the slides for details - these notes capture discussion but do not reproduce the slides.

The Trust assertion XML infrastructure research proposal (TAXI) was the basis for XKMS and XTASS, XTASS was released to public to avoid boxing patents for prior art. SAML is at v0.10 and supersedes the XTASS assertion framework. Currently XTAML draft is under development to retire XTASS.

Architectural goals

Thin client, fat server. Avoid negotiation and questions of server functionality: XKMS can be extended with additional interfaces, making it clear via WSDL which services are provided, avoiding negotiation frameworks. Client does not need to find out what server supports. Trust service implements entire specification.

[Shivaram Mysore] Does this assume you are always connected to the network? [Jeremy Epstein] Is this appropriate for a mail based system? - The general issue is online versus off-line operation.

Chaining support, not referrals. In chaining model, a directory finds what it does not know by working with other directories. In the referral model the directory tells the client potential alternative directories. To be consistent with offloading functionality to the server XKMS supports chaining and not referrals. This is similar to the operation of DNS.

ds:KeyInfo management: XKMS specifies protocol for managing ds:KeyInfo elements. Locate returns correct information from trust service but client can do trust chain validation for itself.

Key Usage identifier "closed", not extensible: three purposes are signing, exchange, encryption . Key recovery is important for encryption, not appropriate for signing, and exchange is the middle ground. To have additional profile on use of key, define another element, do not use key usage element. Avoid all the issues and discussion associated with certificate key usage bits.

Protocol Key Location

In PKIX the name in a certificate (e.g. the DN) is different from the name in protocol - the DN means nothing in VeriSign certificates. Rather use alternative key name.

[Mike Just] What does it mean to obtain multiple responses? -- If you associated multiple bindings with a key, as has happened in testing, then you will get back multiple associations.

[Joseph Reagle] Concern with typing mechanism and namespaces for response values, rather than just strings (in <String>). [Phillip Hallam-Baker] SAML incorporates a proposal from Joseph Reagle. This response was created using a SOAP generator.

[ Eric Prud'Hommeaux ] - is specification of type a goal? [Blair Dillaway] typing is in the spec. [Don Eastlake] Values within the <String> element should be valid element names, [Joseph Reagle] but need to consider namespace qualification.

Validation Context

Trust service decides who the trust service trusts - trust roots chained up to when hierarchical. Use different URIs to access different trust roots from a single service. No language for describing trust service (e.g. client can't say I trust A, B,C). If so, another interface, not an extension to one interface.

Registration

No support for suspension: easy to suspend, hard to reliably un-suspend.

SOAP

Potential issue of dependency on W3C protocol activity and SOAP -decouple by breaking specification in two. [ Joseph Reagle ]- what is normative? Syntax? Could specify using SOAP 1.2 as option? -- define bindings to SOAP, BEEP, separately. How to sign SOAP/XP messages, raises canonicalization issues - XML core specification should support moving XML fragments from one document to another, but doesn't. XML Signature found this problem first. [Don Eastlake] - XML Signature should be fixed soon, XML core might take a while.

Status

Errata

  1. KeyUsage is not referenced where it should be, and some others. Fixed in what has been built
  2. Implementations of the specification have varied - need to tighten language

Timeline

1.2 draft out soon - vendors are doing implementation, interoperability (3-6 months). Core spec 12-18 months

Conclusion - XKMS should be W3C standard. Core XML infrastructure, built on top of W3C XML standards, and will be built upon by other W3C standards. Vendor and customer support. Will be open standard or defacto.

Questions

[ Joseph Reagle ] - Key Information Service (KISS): protocol; syntax and semantics - issue for extensibility and namespace support. Would like additional separation. Validity interval, Tier 0 and Tier 1 How to send other information (XML) back in binding element?

Will need to revisit XML schema.

[ Joseph Reagle ] - key identifiers could be URIs - need versioning, hence URI (e.g. change KeyInfo KeyData, changing string to empty element.) Phillip Hallam-Baker is amenable to discussing this.

[Joe Pato ] Need to understand how this will work with connection limited environments (software installation, mail S/MIME)

2. XBulk

This will be a separate specification from XKMS, since it will be more stable and do not want to revise it with each XKMS revision, but work on this will influence XKMS, such as being able to say what private key encryption format is expected back by the client [Phillip Hallam-Baker].

See the slides on XBulk. Baltimore and Entrust will work together to create one common standard, and reuse XKMS schemas and definitions as much as possible.

XBulk will also affect WSDL - to avoid limits and issues of testing specify the maximum number of requests supported in WSDL. Also need to define appropriate SOAP errors.

XBulk supports Template mode - define template, number of key pairs and starting serial number.

3. Scope

Joe Pato called for the sense of the room with regard to pursuing a W3C activity for XKMS. No objections were raised and there was clear agreement to proceed to propose a W3C activity.

Scope Discussion

4. W3C Activity Process

Joseph Reagle, see slides and W3C process document)

Number of activities in different domains - groups within activities (working groups, interest groups, coordination groups). Usually limited to members, but some public (e.g. XML Protocol, XML Signature, XML Encryption). People at the W3C are the glue between groups. The process is to create an activity, establish a working group, establish resources, including chair, editors, authors. Document stages include working draft, last call (requirements have been addressed), candidate recommendation (implementation and interop testing have been done), proposed recommendation (referred to W3C advisor committee), and recommendation (recommended by the W3C director).

Scope

XKMS 1.2 with cleanups and then 2.0
How many working groups, dependencies, deliverables.

5. Next steps

1. Formulate consensus
2. Create and submit activity proposal - charter
This includes activity duration, milestones, patent policy (royalty free license), liaisons to other activities, dependencies on other activities, commitment by those dependent on this activity to review the work (e.g. XML Protocol).

3 Director approval
4. Advisory Committee approval

Typically it can take time for an official activity start - it took 4 months for XML encryption, but work can start informally before [Joseph Reagle].

Activity plan [Joe Pato]

Roles include chair (40% effort), editor (30% effort), authors, and participant in work groups, including charter and use cases.

Charter

An activity charter will be submitted to the W3C by Aug 15. The draft charter Phil has created will be a starting point and updated by the charter work group. If you have concerns on the charter, voice them or on Aug 15th the charter will be submitted. The working group positions do not need to be identified for the charter, apart from the chair. If interested in the chair position send a note to Joseph Reagle and Daniel Weitzner by Wed the 25th of July.

If you are interested in being an author or editor, send a note to Joe Pato. Phil can continue being an editor, but can have a coeditor. Individuals interested in chairing the activity should send a note to Danny Weitzner and Joseph Reagle.

Volunteers for Charter workgroup:

Liaisons

Use Cases Subgroup

Need to establish use cases subgroup to identify use cases and to capture time frame requirements Volunteers included David Wen and Mack Hicks.

Participant Actions